Razvoj informacijskih sistemov

Visokošolski strokovni študij

Študijsko gradivo, verzija 2.3

UNIVERZA V LJUBLJANI

Fakulteta za računalništvo in informatiko Doc. dr. Marko Bajec

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 2 -

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 SISTEMOV Visokoš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.

Citiranje: glej [1,15-20] = glej v knjigi M. Fowler, strani od 15 do 20.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 4 -

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 SISTEMOV Visokoš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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 6 -

II

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 7 -

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 SISTEMOV Visokoš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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 9 -

Poglavje I

Splošno o razvoju IS

   Osnovni pojmi Življenjski modeli razvoja IS Metodologije razvoja IS

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 10 -

P1.1 – Osnovni pojmi

Informacijski sistem…

IS - opredelitev Ponovitev

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 11 -

Informacijski sistem…

Vrste IS Ponovitev

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 12 -

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 SISTEMOV Visokoš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?

…

Information System is about an implementation of IT into a human enterprise!

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 14 -

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 delovanju PS.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 15 -

Sinonimi za računalniške programe

Terminologija

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 16 -

P1.2 – Življenjski modeli razvoja IS

Življenjski modeli razvoja IS…

  Razvoj IS zajema številna opravila, navadno razdeljena v faze:     Analiza Načrtovanje Implementacija Testiranje Kot večina razvojnih procesov sledi tudi razvoj IS določenemu življenjskemu ciklu oziroma razvojnemu modelu , ki določa zaporedje faz razvoja.

  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.

* SDLC - System Development Life Cycle

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 17 -

Ž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 SISTEMOV Visokoš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.

Analiza testiranje Načrtovanje Spec. zahtev Izvedba Načrt Uvedba Koda čas

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 19 -

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 SISTEMOV Visokoš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 SISTEMOV Visokoš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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 22 -

Iterativni model…

  Razvit kot odziv na pomanjkljivosti slapovnega pristopa. Faze razvoja izvajamo v več iteracijah .

Iteracija je specifično zaporedje aktivnosti, izvedenih na osnovi načrta in z določenim kriterijem vrednotenja, ki se konča z izdajo izdelka.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 23 -

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 24 -

Iterativni model…

testiranje

Iteracija #1

Analiza Načrtovanje Izvedba Uvedba izdelki Učenje in izkušnje testiranje

Iteracija #2

Analiza Načrtovanje Izvedba Uvedba izdelki Učenje in izkušnje

Iteracija #3

Analiza čas Tipično trajanje ene iteracije: 7 do 14 dni

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 25 -

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 26 -

S R I

1 1

Planiranje na makro in mikro ravni

1. Release Planning 2. Iteration Planning 3. Task Planning I

1

R

1

I

2 ?

R

2

cca 2-4 months cca 2 weeks I

3

R

3

I

4

I

2

R

2

E Project start Project end

SALSD Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Requirements - 27 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 SISTEMOV Visokoš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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 29 -

Prototipni model…

  Gre za različico iterativnega modela.

Temelji na izdelavi izboljšavi, dokler ne dosežemo zadovoljive kakovosti.

prototipov in njihovi postopni

Prototip označuje predhodno izdelane in navadno še nepopolne različice sistema ali dela sistema.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 30 -

Prototipni model

Analiza problema

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Začetne zahteve Razvoj prototipa Delovni prototip Uporaba in testiranje prototipa Nov prototip Problemi, Napaka, pomanjkljivosti Revizija in Izboljšava prototipa Nove zahteve Iteracije (evoluativni razvoj)

- 31 -

Inkrementalni model…

 Temelji na postopni gradnji celotne IR in sprotni predaji posameznih inkrementov uporabniku.

Inkrement predstavlja zaokroženo funkcionalnost sistema (sklop, podsistem, modul).

 Ne razvijamo celotne IR hkrati. Omejimo se na posamezen sklop, ki ga razvijemo v celoti in predamo uporabniku.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 32 -

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 33 -

Inkrementalni model…

Klasičen razvoj

Razvoj celotne IR

Inkrementalni razvoj

Razvoj in predaja prvega sklopa IR Inkrement #1 Razvoj in predaja drugega sklopa IR Inkrement #2 Razvoj in predaja tretjega sklopa IR Inkrement #3 Uvedba in testiranje celotnega sistema čas Uvedba in testiranje sklopa

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Uvedba in testiranje sklopa

- 34 -

Uvedba in testiranje sklopa

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 SISTEMOV Visokoš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 SISTEMOV Visokoš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 tveganost projekta tveganost projekta

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Čas

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 SISTEMOV Visokoš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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 39 -

P1.3

– Metodologije razvoja IS

Kaj je metodologija razvoja IS?

Tehnika  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 40 -

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 razvoja : postopen način razvoja informacijskega sistema, ki vključuje uporabo različnih tehnik in orodij, celovit v smislu korakov življenjskega cikla

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 41 -

Izobra

2. Osnovna zgradba metodologij

Slapovni metodologije metodologije Metdologija kot izdelek Iterativni Baza uporabnikov Inkrementalni Cilj metodologije cikel Uporabnost Paradigma in izku metodologije Proces

Metodologija

Filozofija Postopek Izobra ževanje Metdologija kot izdelek Baza uporabnikov Zahtevnost metodologje Namen Domena metodologije Ozadje metodologije Cilj metodologije Paradigma metodologije Filozofija Namen metodologije Sociolo ška komponenta Tehnika Osrednji Uporabnost in izku šnje Slapovni postopek Metodologija Sociolo ška Življenjski cikel Proces Iterativni Orodje Tehnika Inkrementalni metodologje Proces Faza Tehnika Postopek Inkrement Podporni postopek Vloga Aktivnost cikel Izku šnje in znanje vhod izhod Podporni postopek Podizdelek Izdelek Del izdelka [inkrementalno iterativni razvoj] Iteracija Inkrement Uporabnost in izku šnje Vloga Aktivnost Postopek vhod izhod Podizdelek Izku šnje in znanje Vloga Aktivnost vhod izhod Celostna tehnika Podatkovna tehnika Celostna tehnika Podatkovna tehnika Procesna tehnika OO tehnika Procesna Tehnika proj.

vodenja tehnika Organizacijska tehnika Tehnika dela z ljudmi OO tehnika Primer Predloga Tehnika proj.

vodenja Organizacijska tehnika ljudmi Predloga Del izdelka Izku šnje in znanje [inkrementalno iterativni razvoj] Izdelek Razli čica

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

- 42 -

Zgodovina metodologij…

 Obdobje pred pojavom metodologij (do zgodnjih 1970)  Ni formalnih metodologij, poudarek na reševanju tehničnih problemov, ključna vloga je programer Razvoj ad hoc  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 Zajem zahtev Analiza Načrtovanje Kodiranje Testiranje

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 43 -

Zgodovina metodologij

Skupni stro ški Pri čni z izvedbo naslednje iteracije Na črtovanje naslednje iteracije Dolo čitev ciljev, alternativ in omejitev

Za četek

Na črt zahtev, načrt življen.

cikla Analiza tveganj Analiza tveganj Identifikacija in odpravljanje tveganj Oceni alternative Analiza tveganj Analiza tveganj Prototip 1 Prototip 2 Operativni prototip Prototip 3 Koncept delovanja Simulacije Modeli Na črt razvoja Na črt integracije in testiranja Podrobno na črtovanje Razvoj izdelkov za iteracijo in preverjanje njihove pravilnosti   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 44 -

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 SISTEMOV Visokoš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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 46 -

Dojemanje metodologij

Formalizirana metodologija

Postopki, tehnike, smernice,...

Je osnova za razumevanje metodologije

Neformalna metodologija

Dojemanje metodologije, znanje, izkušnje, principi, ideali Je osnova za uporabo metodologije

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Uporaba Metodologije

Izkušnje, nove ideje, znanje

- 47 -

Je osnova za formalizacijo metodologije Je osnova za spremembo dojemanja metodologije

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 SISTEMOV Visokoš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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 49 -

Delitev glede na tip metodologije

Filozofija Cilj: izgradnja programske rešitve Tehnične metodologije Cilj: organizacijska rešitev (lahko tudi programska) Socio-tehnične metodologije Procesno usmerjene metodologije Podatkovno-procesne metodologije Organizacijsko usmerjene metodologije Objektno usmerjene metodologije Metodologije usmerjene v človeka Metodologije za hiter razvoj (RAD)

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Zaporedni (slapovni) razvoj Iterativni in inkrementalni razvoj Življenjski cikel

- 50 -

Prototipiranje

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. Visoka Lahka metodologija

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Nizka Nizka Optimiziranost Težka metodologija Visoka

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 Klasi čen model Model RAD

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

čas

- 52 -

čas

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 53 -

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 54 -

Principi agilnih metodologij…

 Neposredna komunikacija – najboljši način za izmenjavo informacij. visoka e-po šta dva človeka ob tabli pogovor »iz oči v oči« videokonferenca video dvo telefon sme rna kom unik acij a nizka posredna

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

papir eno sme audio rna kom unik acij a Posrednost komunikacije

- 55 -

neposredna

Principi agilnih metodologij…

Majhna razvojna skupina Maksimalna velikost problema Nepotrebna dodatna teža metodologije je draga.

Optimalna teža metodologije Teža (=obseg × gostota) metodologije Velika razvojna skupina Maksimalna velikost problema Večje razvojne skupine potrebujejo težje metodologije.

Optimalna teža metodologije Teža (=obseg × gostota) metodologije

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 56 -

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 57 -

Principi agilnih metodologij…

Visoka Lahka metodologija Izbira metodologije

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 58 -

Težka metodologija Nizka Nizka Optimiziranost Proces, formalnost, dokumentacija Visoka

- 58 -

Principi agilnih metodologij

 Odkloni od načrtovane rešitve nas vodijo k pravi rešitvi.

Začetek Rešitev načrtovana na začetku Prava rešitev

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 59 -

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 60 -

Modeli za klasifikacijo metodologij…

Izbira glede na težo metodologije

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 61 -

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 62 -

Izbira metodologije…

Izbira glede na lastnosti projekta

 Primer modela za klasifikacijo projektov življenje nenadomestljiv denar nadomestljiv denar udobje L6 L6 L20 L20 ponovljivost L100 L100 L200 L200 L500 L500 L1000 L1000 L6 E6 L6 E6 L20 E20 L20 E20 L40 E40 L40 E40 L100 E100 L100 E100 L200 E200 L200 E200 L500 E500 L500 E500 L1000 E1000 L1000 E1000 E6 D6 E6 D6 E20 D20 E20 D20 E40 D40 E40 D40 E100 D100 E100 D100 E200 D200 E200 D200 E500 E500 D500 D500 E1000 D1000 E1000 D1000 D6 C6 D6 C6 D20 C20 D20 C20 D40 C40 D40 C40 D100 C100 D100 C100 D200 C200 D200 C200 D500 C500 D1000 C1000 D500 C500 D1000 C1000 C6 C6 C20 C20 C40 C40 C100 C100 C200 C200 C500 C500 C1000 C1000 1-6 7-20 21-40 41-100 101-200 201-500 501-1000 Število ljudi, ki sodelujejo na projektu ± 20%

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 63 -

Izbira metodologije…

Obseg metodologije

 Obseg nekaterih komercialnih metodologij Faza Metodologija Strategija Izvedljivost Analiza Logi čno načrtovanje Fizi čno načrtovanje Programiranje Testiranje Uvedba Evaluacija Vzdr ževanje

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 64 -

Legenda: Samo omenjeno Osnovna navodila, ve č je prepuščeno lastni interpretaciji Manj podroben opis Podroben opis skupaj s tehnikami

Izbira metodologije…

Izbira glede na podprte življenjske cikle

Življenjski cikel Kriteriji Deluje s slabo razumljenimi zahtevami Deluje s slabo razumljeno arhitekturo Rezultat je zanesljiv sistem Rezultat je nadgradljiv sistem Upravlja s tveganji Slapovni razvoj Slabo Slabo Odlično Odlično Slabo Omogoča predvidljiv razvoj Potrebuje malo režije Dovoljuje spremembe med projektom Stranki omogoča

Visokošolski strokovni študij, Smer Informatika

nadzor napredovanja Vodstvu omogoča nadzor napredovanja Ne zahteva veliko izkušenj Srednje Srednje Slabo Slabo Srednje Srednje Modificiran slapovni razvoj Srednje do odlično Srednje do odlično Odlično Odlično Srednje Srednje Odlično Srednje Srednje Srednje do odlično Slabo do srednje Iterativni razvoj Odlično Odlično Odlično Odlično Odlično Srednje Srednje Srednje Odlično Slabo Inkremental ni razvoj Slabo do srednje Evolucijsko prototipiranj e Srednje do odlično Kodiraj in popravi Slabo Slabo Srednje do odlično Odlično Srednje do odlično Odlično Srednje Slabo do srednje Srednje Odlično Slabo do srednje Slabo Srednje do odlično Odlično Srednje Srednje Srednje Srednje do odlično Odlično Odlično Srednje Slabo Slabo Slabo do srednje Slabo Slabo Odlično Slabo do odlično Srednje Slabo Odlično

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 Visoka Lahka Izbira glede na tip projekta metodologija

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Težka metodologija Nizka Nizka Optimiziranost

- 66 -

Proces, formalnost, dokumentacija Visoka

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 67 -

Uporaba metodologij...

 Povzetek raziskave v slovenskih podjetjih

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 68 -

Poglavje II

Strukturni razvoj

       Osnovne značilnosti strukturnega pristopa Primer strukturne metodologije Strateško načrtovanje Analiza Načrtovanje Testiranje Namestitev in uvedba

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 69 -

Strukturni razvoj

Osnovne značilnosti strukturnega pristopa

    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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 70 -

Primer strukturne metodologije

Informacijski inženiring - IE

    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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 71 -

Informacijski inženiring – IE

Osnovne značilnosti 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 72 -

Informacijski inženiring – IE

Osnovne značilnosti 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.

Podatkovna usmerjenost

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Procesna usmerjenost

- 73 -

Dogodkovna usmerjenost

Informacijski inženiring – IE

Glavne faze IE

 IE v grobem zajema štiri faze:    Strateško planiranje Analiza Načrtovanje  Izvedba

Planiranje Analiza Načrtovanje

 IE posebej obravnava podatke, posebej aktivnosti

Izvedba RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 74 -

Strateško planiranje informatike – SP

Opredelitev SP

 Razvoj IS združbe se po IE začne s fazo strateškega planiranja informatike .

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.

Fidler in Rogerson, 1996 RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 75 -

Strateško planiranje informatike – SP

Cilji 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 -

Strateško planiranje informatike – SP

Problemi brez 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 77 -

Strateško planiranje informatike – SP

Problemi brez 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 78 -

Strateško planiranje informatike – SP

Metodologija IS

    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.

1992 2006 RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Osnovna različica Body of Knowledge

- 79 -

Prilagojene različice Priročnik

Strateško planiranje informatike – SP

Shema procesa izdelave SP

Razna dokumentacija Izpolnjeni vprašalniki

Legenda

Postopek  Izdelava dolgoročnega plana Izdelava kratkoročnega plana

Proces SP zajema 6 postopkov:

  Pregled in analiza obstoječega stanja; Poslovno informacijsk Opredelitev poslovno-informacijske arhitekture; Terminska opredelitev opredelitev Poročilo o izbranih letnega plana projektov izvajanju letnega plana  Pregled in analiza stanja   Opredelitev projektov; Opredelitev Opredelitev informacijske vizije arhitekture Opredelitev projektov Izdelava letnega načrta Spremljanje izvajanja in vzdrževanje strateškega plana Spremljanje izvajanja in vzdrževanje strateškega plana.

3-4 mesece

Seznam Projektov Prioritete projektov Izdelek

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika

Vhod postopka Analiza

- 80 80

Izdelava dolgoročnega plana Izdelava kratkoročnega plana Razna dokumentacija Vprašalniki Poslovno informacijsk a arhitektura dokumentacija Informacijska vizija Podrobna opredelitev izbranih projektov Terminska opredelitev letnega plana Poročilo o izvajanju letnega plana Pregled in analiza obstoječega stanja Opredelitev arhitekture Opredelitev vizije Opredelitev projektov Izdelava letnega načrta Spremljanje izvajanja in vzdrževanje strateškega plana Izpolnjeni vprašalniki Seznam Projektov Prioritete projektov

Legenda

Postopek Izdelek Izhod postopka Vhod postopka Analiza

Pregled in analiza obstoječega stanja

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 81 -

Opredelitev poslovno informacijske arhitekture Opredelitev informacijske vizije Opredelitev projektov Izdelava letnega načrta Spremljanje izvajanja in vzdrževanje strateškega plana

Strateški plan razvoja informatike

Trajanje izdelave SP in sodelujoči

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 82 -

Razvoj po strukturnem pristopu

Osnovne značilnosti strukturnega pristopa k razvoju

   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 vedno ohranja ključen pomen. : temelji na objektni filozofiji, vendar podatkovna baza še

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 83 -

Razvoj po strukturnem pristopu

Ključni postopki strukturnega razvoja

 Strukturni pristop k razvoju zajema več postopkov:     Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba;    Testiranje; Namestitev in uvedba Vzdrževanje.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 84 -

Razvoj po strukturnem pristopu

Kje smo?

 Postopki strukturnega pristopa:    Zajem in specifikacija zahtev; Analiza; Načrtovanje;     Izvedba; Testiranje; Namestitev in uvedba Vzdrževanje.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 85 -

Zajem in specifikacija zahtev

Opredelitev in namen

 Zajem in specifikacija zahtev nakupa IR.

je ena pomembnejših aktivnosti razvoja oziroma  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 86 -

Zajem in specifikacija zahtev

Končni izdelek

e  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 87 -

Zajem in specifikacija zahtev

Vloge in koraki

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 88 -

Zajem in specifikacija zahtev

Postopek zajema in specifikacije zahtev



RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 89 -

Razvoj po strukturnem pristopu

Kje smo?

 Postopki strukturnega pristopa:   Zajem in specifikacija zahtev; • • • Zajem zahtev, Ureditev zahtev in Potrditev zahtev Analiza;     Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 90 -

Zajem in specifikacija zahtev

Zajem zahtev

 Obstajajo različne tehnike zajema zahtev:    Razgovori Vprašalniki Opazovanje pri delu   Analiza obstoječega sistema Skupinsko načrtovanje aplikacij

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 91 -

Zajem in specifikacija zahtev

Zajem 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 92 -

Razvoj po strukturnem pristopu

Kje smo?

 Postopki strukturnega pristopa:   Zajem in specifikacija zahtev; • • • Zajem zahtev, Ureditev zahtev Potrditev zahtev in Analiza;     Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 93 -

Zajem in specifikacija zahtev

Ureditev 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 94 -

Zajem in specifikacija zahtev

Specifikacija zahtev

 Specifikacija zahtev ima navadno naslednjo strukturo: 1. Kratek opis namena IR ali njenega podsistema 2. Opis funkcionalnih zahtev 3. Opis nefunkcionalnih zahtev 4. Opis vmesnikov 5. Slovar izrazov

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 95 -

Zajem in specifikacija zahtev

Specifikacija zahtev Funkcionalne zahteve so zahteve, ki se nanašajo na želeno funkcionalnost sistema.

Odjava iz izpitnega roka

Sistem 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.

…

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 96 -

Zajem in specifikacija zahtev

Specifikacija zahtev Nefunkcionalne zahteve so zahteve, ki se nanašajo na tehnične in druge nevsebinske zahteve sistema.

• • • • • 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 INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 97 -

Razvoj po strukturnem pristopu

Kje smo?

 Postopki strukturnega pristopa:   Zajem in specifikacija zahtev; • • • Zajem zahtev, Ureditev zahtev in Potrditev zahtev Analiza;     Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 98 -

Zajem in specifikacija zahtev

Potrditev zahtev

 Namen aktivnosti naročnik želi. potrditev zahtev je predstavitev specifikacije zahtev naročniku in pridobitev soglasja o tem, da so zajete zahteve res to, kar si

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 99 -

Razvoj po strukturnem pristopu

Kje smo?

 Postopki strukturnega pristopa:    Zajem in specifikacija zahtev; Analiza; Načrtovanje;     Izvedba; Testiranje; Namestitev in uvedba Vzdrževanje.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 100 -

Analiza

Opredelitev in namen

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 101 -

Analiza

Opredelitev in namen

 Analiza daje odgovor na vprašanje, kakšne podatke te rabijo?

KAJ naj IS podpira. Kaj se izvaja v poslovnih funkcijah in  Analiza služi kot:    sredstvo za definicijo zahtev, osnova za dogovor med naročnikom in izvajalcem osnova za kasnejše faze razvoja.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 102 -

Analiza

Končni izdelek

e     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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 103 -

Analiza

Vloge in koraki

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 104 -

Analiza

Shema postopka



RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 105 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 106 -

Analiza

Splošno o modeliranju

 Modeliranje je uveljavljena inženirska tehnika na mnogih področjih:     Gradbeništvo, Strojništvo, Kemija, Ekonomija,   Sociologija, Računalništvo…

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 107 -

Analiza

Splošno o modeliranju

 Modele razvijamo zato, da bi sisteme bolje razumeli.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 108 -

Analiza

Splošno o modeliranju

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 109 -

Analiza

Splošno o modeliranju

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 110 -

Analiza

Splošno o modeliranju

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 111 -

Analiza

Analiza po strukturnem pristopu

 Model , ki ga izdelamo v fazi analize po strukturnem pristopu , se v grobem deli na:    Podatkovni model, Procesni model in Model procesne logike.

Model sistema Podatkovni model Procesni model Model procesne logike

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 112 -

Analiza – Izdelava modela sistema

Izdelava modela sistema po strukturnem pristopu

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 113 -

Analiza – Izdelava modela sistema

Strukturne diagramske tehnike

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 114 -

Analiza – Izdelava modela sistema

Podatkovni model

 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 .

Model sistema Podatkovni model Procesni model Model procesne logike

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 115 -

Analiza – Izdelava modela sistema

Podatkovni model

svet mentalni model konceptualni model logični model PB

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 116 -

Analiza – Izdelava modela sist.

V konceptualnem modelu lahko nastopajo tudi sestavljeni in večvrednostni atributi!

Podatkovni model – primer

 Konceptualni podatkovni model

Predmet

Predmet Naziv Dodatne obveznosti Semester Kreditne točke …

Izpit

Zap. št. polaganja Ocena pisno Ocena ustno Datum ocene

?

Študent

Vpisna številka Priimek Ime Naslov Telefon E-mail Status …

Rok

Rok Datum izpita Prijavljenih Maks. prijavljenih Meja pozitivno …

Prijava

Datum prijave Datum odjave Zap. št. polaganja Kolokvij Letnik Plača izpit …

Delavec

Delavec Priimek Ime E-mail Geslo …

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 117 -

Analiza – Izdelava modela sistema

Podatkovni model – primer

 Primer nerazumljivega podatkovnega modela VIP_F POSTA a a VRSTA_POT a SKLEPI b a a a a a a PRED_OBC a a a STAT_IZPITA a a ZAHTEVA a a STUDENT a a VIP POTRDILO a a a a a ZAVO D a a a a a a a a a a a a a IZJEME PRED_PR a STAT_PR a a VPIS a a NACIN a a a a a SMER a a a a a a VAJE a VSI a a a a SKUPINA a a a a PRED_DIF r r a a IZBIRNI a a a a a a a a a a a a a a PREDMET a a a a a a PRED_IZB a VSI_F NAC_OC a b DELNA_OC a a a b NAC_IZV a PRED_AT EKVIVAL PREDPOG a b a b IZPIT a a a a a a a PRIJAVA NAC_DEL a a a a a IZPRASEVALE C a APP PRE_PRE SPP c b a a a a a b a a a a PP a a a a VRSTA_OC PRE_DEL a a a c b a a STAT_POS ROK a a PRIJAVA_U a a aa ROK_U DELAVEC a a a a a a a a a OBVESTILA a

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 118 -

Analiza – Izdelava modela sistema

Podatkovni model – primer

  Entitetne tipe je potrebno dokumentirati Primer dokumentacije:

Naziv entitetnega tipa

Delavec

Opis

Predstavlja pedagoškega delavca, ki je nosilec enega ali več predmetov

Sinonim

Pedagoški delavec Rok Predstavlja datum, na katerega je za nek predmet in določeno ciljno skupino (letnik, smer,...) razpisan izpitni rok.

Rok, pisni izpit, kolokvij

Število entitet

Vsaka katedra ima enega ali več pedagoških delavcev. Niso vsi delavci nosilci predmetov.

Na leto se razpiše okrog 300 pisnih izpitov. Vsak predmet mora imeti vsaj tri roke letno ...

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 119 -

Analiza – Izdelava modela sistema

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

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 120 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – identifikacija povezav

 V postopku identifikacije povezav smo pazljivi na dvoumne in nepopolne povezave .

K 1.2

Primer dvoumne povezave Profesor 1..* je član 1..1

Katedra 1..1

vključuje 1..* Laboratorij Pr1 Pr2 Pr3 K1 K2 L1 L2 L3 RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 121 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – identifikacija povezav

 Dvoumno povezavo odpravimo z restrukturiranjem modela

Profesor 1..* je član 1..1

Laboratorij 1..* vključuje 1.1

Katedra Pr1 Pr2 Pr3 L1 L2 K1 K2 K3 RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 122 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – Identifikacija povezav Primer nepopolne povezave ima Katedra 1..1

1..* Član 0..1

je skrbnik 0..* Oprema K1 K2 K3 Čl1 Čl2 Čl3 O1 O2 O3 Kateri katedri pripada oprema O2?

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 123 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – identifikacija povezav

 Odpravimo z prestrukturiranjem modela.

Katedra 1..1

1..1

ima 1..* Član pripada 0..1

je skrbnik 0..* Oprema 1..* K1 K2 K3 Čl1 Čl2 Čl3 O1 O2 RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 124 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – odvečne povezave

 Identifikacija odvečnih povezav   

K 1.7

Povezava je odvečna, če je možno priti do iste informacije prek drugih povezav!

Izdelati želimo minimalen podatkovni model povezave zato odstranimo.

 odvečne Zgolj pregledovanje poti med entitetnimi tipi ne zadošča (povezave imajo lahko različen pomen)

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 125 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – odvečne povezave

 Ali je kakšna povezava odveč?

Profesor 1..* 1..1

je predstojnik 0..1

Katedra 1..1

je član pripada 1..1

1..* Laboratorij RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 126 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – odvečne povezave

 Ali je kakšna povezava odveč?

Profesor 1..* 1..* pripada je član 1..1

Katedra 1..1

pripada 1..1

1..* Laboratorij RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 127 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – preverjanje transakcij

  Preveriti moramo, če model podpira vse zahtevane transakcije.

 

K 1.8

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

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 128 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – preverjanje prek opisa transakcij

 Preverjanje prek opisa transakcij   Vsako transakcijo opišemo; Preverimo, če model zajema vse entitetne tipe, povezave in atribute, ki jih transakcija potrebuje.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 129 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – preverjanje prek opisa transakcij

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 130 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – preverjanje prek transakcijskih poti

 Preverjanje prek transakcijskih poti   Transakcije preverimo na modelu – pot transakcije narišemo Pristop načrtovalcu omogoča: • • • Da identificira pomanjkljivosti modela možna) (če pot za neko transakcijo ni Da identificira dele modela, ki so transakcijsko kritični Da odkrije odvečne dele modela (deli, ki jih ne potrebuje nobena transakcija)

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 131 -

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – preverjanje prek transakcijskih poti 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 b ?

Program progID 1..1

ima 0..1

Smer smerID 1..* se predava na se nanaša na 0..* za 1..1

1..* Predmet predID Prijava 0..* 0..* 1..1

Rok rokID 1..1

pripada 1..1

Študent vpisSt 1..1

je opravljal a RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 0..* Izpit stPol - 132 0..* iz

Analiza – Izdelava modela sistema

Izdelava modela sistema – procesni model

 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 .

Model sistema Podatkovni model Procesni model Model procesne logike

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 133 -

Analiza – Izdelava modela sistema

Procesni model – diagram funkcionalne razgradnje – opredelitev

 Z diagramom funkcionalne razgradnje podpreti.

prikažemo hierarhijo funkcij, ki jih želimo s sistemom  Hierarhijo funkcij lahko prikažemo na različne načine, najbolj običajno kot navpično hierarhijo .

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 134 -

Analiza – Izdelava modela sistema

Procesni model – diagram funkcionalne razgradnje

Funkcija 1.1

Funkcija 1 Funkcija 1.2

Funkcija 1 Funkcija 1.3

Funkcija 1 Funkcija 1.1

Funkcija 1.2

Funkcija 1.3

Funkcija 1.1

Funkcija 1.2

Funkcija 1.3

Funkcija 1.1

Funkcija 1 Funkcija 1.2

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Funkcija 1.2.1

Funkcija 1.2.2

135 -

Funkcija 1.3

Analiza – Izdelava modela sistema

Procesni model – diagram funkcionalne razgradnje – smernice

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 136 -

Analiza – Izdelava modela sistema

Procesni model – diagram funkcionalne razgradnje - primer

Vzdrževanje in pregled izpitnih rokov Elektronski indeks/ kartotečni list Prijava na izpit

Študijska Informatika

(izpitna evidenca) Naročanje potrdil Odjava iz izpita Opravljanje pisnih izpitov Pregled števila prijavljenih kandidatov Opravljanje ustnih izpitov Vnos rezultatov Vpis končne ocene Objava rezultatov

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 137 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – opredelitev

   Diagrame podatkovnih tokov podprl.

(DFD) uporabimo za prikaz okolja, v katerem bo sistem deloval, ter za prikaz odvisnosti med procesi, ki jih bo sistem DFD združuje podatkovni in procesni pogled na obravnavano področje.

DFD je uvedel Tom DeMarco nastalo več različic DFD tehnike. Razlikujejo se predvsem v notaciji.

leta 1978. Od takrat

DFD – Data Flow Diagram RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 138 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – osnovni gradniki

 DFD sodi med enostavnejše diagramske tehnike.

 Osnovni gradniki DFD so:  Proces    Tok podatkov Podatkovno skladišče Zunanja entiteta

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 139 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – proces

 Proces predstavlja množico aktivnosti, ki vhodne podatke pretvorijo v izhodne.

Notranja shramba podatkov Vhodni podatki Proces sistema Izhodni podatki Zunanji prejemnik RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 140 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – proces

 Proces je generičen pojem in lahko predstavlja dogajanje na različnih ravneh (funkcija, proces, pod-proces, naloga, aktivnost ipd.)

Proces RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Funkcionalna razgradnja 141 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – proces

   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.

1 Prijava na izpit 2 Vnos končne ocene RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 142 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – tok podatkov

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 143 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – tok podatkov

 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

Izpitni rok Prijava RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 2 Vnos končne ocene Ocena pisno, Ocena ustno Podatki o preteklih polaganjih 144 Izpit

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – tok podatkov

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 145 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – podatkovna shramba

 Podatkovna shramba kasnejšo uporabo. predstavlja prostor, kamor procesi shranjujejo podatke za druge procese ali  Podatkovna shramba je lahko enostavna (npr. zajema le elementarne podatke) ali kompleksna (npr. predstavlja celo zbirko podatkov).

Izpit Podatkovna baza RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 146 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – podatkovna shramba

 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)

Izpitni rok RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 2 Vnos izpitnega roka 147 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – podatkovna shramba

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 148 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – podatkovna shramba

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 149 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – podatkovna shramba RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 150 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – zunanja entiteta

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 151 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – zunanja entiteta Študent Izpitni rok Prijava Univerza v Ljubljani indeks 2 Vnos končne ocene Ocena pisno, Ocena ustno Podatki o preteklih polaganjih Poročila o uspešnosti generacije 3 Analiza uspešnosti generacije Izpit Podatki o izpitih RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 152 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – način risanja DFD

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 153 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – način risanja DFD

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 154 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – način risanja DFD

 Kontekstni diagram:  razčlenjevanje DFD začnemo na najvišji ravni, kjer nastopa en sam proces – korenski proces .

KOTEKSTNI DIAGRAM korenski proces

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

kontekst sistema

155 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – način risanja DFD

 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 procesi. Podatkovna shramba je del sistema!

. Shrambe so namenjene odlagališču podatkov pri prenosu le-teh med  Podatkovni tokovi med korenskim procesom in zunanjimi entitetami opredeljujejo vmesnike med sistemom in okoljem.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 156 -

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – primer kontekstnega diagrama Študent Podatkovni tokovi brez nazivov ne povedo skoraj nič!!

MŠŠ 0 e-študent Računovodstvo FRI Univerza v Ljubljani RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 157 Vpisna prijavno informacijska služba

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – način risanja DFD

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 158 -

Analiza – Izdelava modela sistema

Univerza v Ljubljani Podatki o polaganjih Sumarni podatki za Napačna raba shrambe podatkovno skladišče Podatki o diplomah Roki, prijave, Izpiti, ocene 0.2

Diplome Računovodstvo FRI RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 0.1

Izpitna evidenca Osebni podatki, indeks Študent Podatki o plačilih vpisnine 159 Vpisna evidenca Vpisni podatki 0.3

Vpis Vpisna prijavno informacijska služba MŠŠ

Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – način risanja DFD

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 160 -

Analiza – Izdelava modela sistema

Procesni model – procesni diagram

 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.

eEPC – Extended Event-Driven Process Chain RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 161 -

Analiza – Izdelava modela sistema

Procesni model – procesni diagram

 Tipični gradniki procesnih diagramov:    Dogodek Aktivnost Krmilni tok     Operator Vloga Aplikacija Informacijski objekt

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 162 -

Analiza – Izdelava modela sistema

Procesni model – procesni diagram

 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.

Prijava zaključena Ocena vpisana RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 163 -

Analiza – Izdelava modela sistema

Procesni model – procesni diagram

 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.

Razpis ustnega roka Vnos končne ocene RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 164 -

Analiza – Izdelava modela sistema

Procesni model – procesni diagram

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 165 -

Analiza – Izdelava modela sistema

Procesni model – procesni diagram

 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.

AND

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 166 -

Analiza – Izdelava modela sistema

Procesni model – procesni diagram

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 167 -

Izbira kandidatov za mednarodne izmenjave

Analiza – Izdelava modela sistema

Procesni model – procesni diagram – primer Obvestilo ULJ o razpisu Priprava razpisa Razpis pripravljen Objava razpisa Razpis objavljen Zbiranje prijav Razpis zaključen Izbira kandidatov Kandidati določeni

AND

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Priprava podatkov za ULJ Priprava podatkov za KŠZ Podatki pripravljeni Podatki pripravljeni Seja KŠZ 168 -

XOR

Kandidati zavrnjeni Kandidati potrjeni Obvestilo ULJ o izboru Obvestilo kandidatov o izboru

AND

Izbira kandidatov za mednarodne izmenjave

Analiza – Izdelava modela sistema

Procesni model – procesni diagram – primer – dodatni gradniki IR za izbiro kandidatov RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Izbira kandidatov S/E koordinator Kandidati določeni Priprava podatkov za ULJ

AND

S/E koordinator Priprava podatkov za KŠZ Podatki pripravljeni Seznam za ULJ Podatki pripravljeni MS Excel Seznam za KŠZ Seja KŠZ KŠZ 169 -

Izbira kandidatov za mednarodne izmenjave

Analiza – Izdelava modela sistema

Procesni model – procesni diagram – primer – steze ULJ Izdaja obvestila o razpisu Obvestilo ULJ o razpisu S/E koordinator Priprava razpisa Razpis pripravljen Objava razpisa Razpis objavljen Zbiranje prijav RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 170 Podatki pripravljeni KŠZ Seja KŠZ

Analiza – Izdelava modela sistema

Izdelava modela sistema – model procesne logike

 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.

Model sistema Podatkovni model Procesni model Model procesne logike

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 171 -

Analiza – Izdelava modela sistema

Model procesne logike – strukturiran jezik

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 172 -

Analiza – Izdelava modela sistema

Model procesne logike – strukturiran jezik – primer

 Primer opisa:  Vnos diplomske teme Izberi študijski program //izpišejo se vsi študijski programi Izberi študenta //izpišejo se vsi kandidati, ki so pri mentorju dvignili temo Vnesi naslov teme Vnesi opis teme Potrdi 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 173 -

Analiza – Izdelava modela sistema

Model procesne logike – odločitvene tabele in drevesa

  Odločitvene tabele logike.

in odločitvena drevesa uporabimo pri modeliranju zapletenejše procesne Tehniki sta primerni predvsem, ko v procesni logiki nastopa veliko pogojev , ki v različnih kombinacijah sprožajo različne akcije.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 174 -

Analiza – Izdelava modela sistema

Model procesne logike – odločitvene tabele

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 175 -

Analiza – Izdelava modela sistema

Model procesne logike – odločitvene tabele Pravilo – kombinacija vrednosti pogojev.

Vrednost pogoja 2 v pravilu p Pogoj 1 Pogoj 2 … Pogoj n Akcija 1 Akcija 2 … Akcija m Pravilo 1

V(p 1 ) V(p 2 ) … V(p n ) D/N D/N … D/N

Pravilo 2

V(p 1 ) V(p 2 ) … V(p n ) D/N D/N … D/N … … … …

…

… … …

Pravilo p

V(p 1 ) V(p 2 ) … V(p n ) D/N D/N … D/N

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Akcije, ki jih izvedemo, če velja pravilo p.

176 -

Analiza – Izdelava modela sistema

Model procesne logike – odločitvene tabele

 Pravila v odločitveni tabeli predstavljajo kombinacije vrednosti, ki jih posamezni pogoji lahko zavzamejo.

 Število pravil:   zv : zaloga vrednosti n : število pogojev

Primer:

p 1 p 2 = Pogoj 1: status vpisa = Pogoj 2: letnik p 1 = {redno, izredno, ponavlja, pavzira} zv(p 1 ) = 4 p 2 = {1, 2, 3, 4, 5, ABS} zv(p 2 ) = 6 Število pravil = 4 * 6 = 24

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 177 -

Analiza – Izdelava modela sistema

Model procesne logike – odločitvene tabele – primer Prijava na izpitni rok

Izpitni rok razpisan Dovoljen pristop k izpitu Pravočasna prijava Izpolnjeni vsi predpogoji Število zaporednih polaganj presega 3 Prvo polaganje v izpitnem obdobju Drugo polaganje v jesenskem obdobju Četrto polaganje v šolskem letu Sprejmi prijavo Zavrni prijavo Sestavi komisijo Izdaj plačilni nalog

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 178 -

D N N × D D D D N N D N × D D D D N N N N D D D D N × D N N ×

Pravila

D D D D D D D D D D N D D × × × D N N D D D N N × D N N D D N D N D N N N N N D N × ×

Analiza – Izdelava modela sistema

Model procesne logike – odločitvena drevesa

 Zgradba odločitvenega drevesa:    Odločitveno drevo je sestavljeno iz vozlišč njimi.

ter povezav med 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 179 -

Analiza – Izdelava modela sistema

Model procesne logike – odločitvena drevesa Pogoj p 1 Pot od korena do lista: pravilo Pogoj p 2

V(p 1 )  p 1 A  {a 1 , a 2 , …, a n } A  {a 1 , a 2 , …, a n } A  {a 1 , a 2 , …, a n } A  {a 1 , a 2 , …, a n }

List: seznam akcij pravila RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 180 -

Analiza – Izdelava modela sistema

Model procesne logike – odločitvena drevesa

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 181 -

Analiza – Izdelava modela sistema

Model procesne logike – odločitvena drevesa – primer

Izpitni rok razpisan?

Zavrni 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!

Zavrni prijavo: Predpogoji niso izpolnjeni!

Predpogoji izpolnjeni?

Prvo polaganje v izpitnem obdobju?

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 182 -

Analiza – Izdelava modela sistema

Model procesne logike – odločitvena drevesa – primer

Prvo polaganje v izpitnem obdobju?

Je skupno število polaganj > 3?

Je to jesensko obdobje?

Komisijski izpit: * sestavi komisijo * izdaj plačilni nalog * sprejmi prijavo Sprejmi prijavo Je skupno število polaganj > 3 Zavrni prijavo: Že opravljal v zimskem/letnem obdobju!

Komisijski izpit: * sestavi komisijo * izdaj plačilni nalog * sprejmi prijavo Sprejmi prijavo

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 183 -

Diagramske tehnike

Model procesne logike – diagram prehajanja stanj

 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.

d i /a i Začetno stanje Stanje S 1 d 1 /a 1 Stanje S 2

{d 0 , d 1 , d i , d k }: dogodki {a 0 , a 1 , a i , a k }: akcije

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 184 Končno stanje

Diagramske tehnike

Model procesne logike – diagram prehajanja stanj

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 185 -

Diagramske tehnike

Model procesne logike – diagram prehajanja stanj

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 186 -

Diagramske tehnike

Status študenta Model procesne logike – diagram prehajanja stanj – primer – prikaz z grafom Pogoji za napredovanje niso izpolnjeni / [Ponoven vpis v letnik] Ponavljalec Pogoji za napredovanje so izpolnjeni / [Vpis v višji letnik omogočen] Redno vpisan Pogoji za napredovanje so izpolnjeni / [Vpis v višji letnik omogočen] Pogoji za napredovanje niso izpolnjeni / [Odvzem statusa študenta] RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Pogoji za napredovanje so izpolnjeni / [Vpis v višji letnik omogočen] 187 Pogoji za napredovanje niso izpolnjeni, število ponovnih vpisov > 1 / [Odvzem statusa študenta] Pavzer

Diagramske tehnike

Status študenta Model procesne logike – diagram prehajanja stanj – primer – prikaz s tabelo Dogodek Pogoji za napredovanje so izpolnjeni Pogoji za napredovanje niso izpolnjeni Pogoji za napredovanje niso izpolnjeni, število ponovnih vpisov > 1 Redno vpisan S1

S1 / [Vpis v višji letnik omogočen] S2 / [Ponoven vpis s letnik] S3 / [Odvzem statusa študenta]

Stanje Ponovno vpisan S2

S1 / [Vpis v višji letnik omogočen] S3 / [Odvzem statusa študenta]

Pavzer S3

S1 / [Vpis v višji letnik omogočen]

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 188 -

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 189 -

Vaja – rešitev

Podatkovni model Hotelska stranka Navadna stranka Hotelski gost RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Status

sifra statusa opis statusa

Pritozba

Stevilka pritozbe Opis pritozbe

Tip Nastanitve

sifra tipa nastanitve opis nastanitve

Racun

leto sifra racuna datum

Stranka

sifra stranke ime priimek stevilka OD

Hotelski Usluzbenec

sifra hotelskega usluzbenca ime priimek naslov tel

190 Hotelski Gost

datum nastanitve datum odjave

Soba

sifra sobe stevilo lezisc zasedeno dodatne lastnosti

Tip Sobe

sifra tipa sobe opis

Poraba minibara

datum porabe kolicina porabe

Hotelska Usluga

kolicina cena

Tip Hotelske Usluge

sifra tipa hotelske usluge opis enota cena

Vaja – rešitev

Status stranke – frekvenca bivanja v hotelu NOV GOST

Prvič v hotelu?

Je bil v hotelu že več kot dva krat?

Gre vedno za isto sezono?

?

SEZONSKI GOST REDNI GOST

Manjka status!

Predlog: Navaden gost.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Slabo poimenovanje: sezonski gost je tudi redni gost!

Predlog: redni gost  letni gost.

191 -

Vaja – rešitev

Status stranke – posebni statusi

Status <>

NOV GOST RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko AND AND 192 Ali se je kdaj pritožil?

Ali spada med 10% najdono snejših?

Ima posebne potrebe?

Je znana oseba?

Posebni statusi OBČUTLJIV GOST SUPER GOST POSEBEN GOST POMEMBEN GOST

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 193 -

Analiza – Izdelava prototipov

Izdelava prototipov v okviru analize

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 194 -

Analiza – Izdelava prototipov

Izdelava prototipov v okviru analize

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 195 -

Analiza – Izdelava prototipov

Izdelava prototipov v okviru analize

 Nekaj primerov orodij za izdelavo prototipov:    Vizualna razvojna okolja: npr. Delphi; Risarska orodja: npr. MS Visio; CASE orodja: npr. Oracle Designer.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 196 -

Analiza – Izdelava prototipov

Izdelava prototipov v okviru analize – Primer MS Visio

 Primer

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 197 -

Analiza – Izdelava prototipov

Izdelava prototipov v okviru analize – Primer Delphi

 Primer

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 198 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 199 -

Analiza – Predlog tehnične arhitekture

Izdelava predloga tehnične arhitekture

  V okviru analize ne analiziramo zgolj funkcionalnih zahtev, temveč tudi tehnične druge nefunkcionalne zahteve .

Na osnovi tega podamo predlog tehnične arhitekture sistema . in  Upoštevamo tudi strategijo podjetja oziroma standarde, ki so v podjetju določeni za celoten informacijski sistem.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 200 -

Analiza – Predlog tehnične arhitekture

Izdelava predloga 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 201 -

Analiza – Predlog tehnične arhitekture

Izdelava predloga tehnične arhitekture – vsebina 1. Arhitektura sistema

1.1 Strojna oprema 1.2 Sistemska programska oprema 1.3 Komunikacijska oprema 1.4 Druga oprema 1.5 Postavitveni diagram (opcijsko)

2. Postopki, predpisi in standardi

2.1 Zagotavljanje varnosti 2.2 Varnostne kopije (Backup) 2.3 Vzpostavitev sistema (Recovery) 2.4 Obravnava napak

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 202 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 203 -

Analiza – Opredelitev strategije testiranja

Strategija 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 204 -

Analiza – Opredelitev strategije testiranja

Strategija 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 205 -

Analiza – Opredelitev strategije testiranja

Strategija testiranja – prva aktivnost v okviru postopka testiranja RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 206 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 207 -

Analiza – Predstavitev rezultatov

Predstavitev rezultatov analize uporabniku

  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 -

Analiza – Predstavitev rezultatov

Predstavitev rezultatov analize uporabniku

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 209 -

Razvoj po strukturnem pristopu

Kje smo?

 Postopki strukturnega pristopa:    Zajem in specifikacija zahtev; Analiza Načrtovanje;    Izvedba; Testiranje; Namestitev in uvedba.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 210 -

Načrtovanje

Opredelitev in namen

  Glavni namen načrtovanja zbrane v fazi analize.

je izdelati načrt zgradbe sistema glede na specifikacije, ki so bile Načrt daje odgovor na vprašanje, evidentirali v fazi analize.

KAKO izdelati sistem, da bo ustrezal zahtevam, ki smo jih

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 211 -

Načrtovanje

Cilji načrtovanja

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 212 -

Načrtovanje

Končni izdelek

e  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 213 -

Načrtovanje

Vloge in koraki

    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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 214 -

Načrtovanje

Shema postopka



RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 215 -

Načrtovanje

Shema postopka



RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 216 -

Načrtovanje – Izdelava načrta PB

Namen aktivnosti

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 217 -

svet

Načrtovanje – Izdelava načrta PB

Izdelava logičnega podatkovnega modela

   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 .

mentalni model konceptualni model logični model PB

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 218 -

Načrtovanje – Izdelava načrta PB

Podpora CASE orodij Konceptualni PM Odločitev o PB:

-Relacijska -Hierarhična -Objektna

i-CASE Logični PM Logično načrtovanje Fizični PM (skripta) Reverse Engineering SUPB RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Podatkovna baza - 219 ODBC

Načrtovanje – Izdelava načrta PB

Prehod iz konceptualnega v logični model

 Prehod iz konceptualnega v logični model je navadno avtomatiziran s strani CASE orodij.

Primer: vrsta baze: relacijska SUPB: Oracle ANALIZA NAČRTOVANJE Konceptualni model Entitetni tip Atribut Enolični identifikator Povezava 1:n Povezava m:n RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 220 Relacijski model Relacija / Tabela Atribut / Stolpec Ključ Tuji ključ Vmesna tabela

Načrtovanje – Izdelava načrta PB

Tipični koraki pri izdelavi relacijskega modela

 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 .

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 221 -

Načrtovanje – Izdelava načrta PB

Osnovni koncepti relacijskega modela

 Pri relacijskem modeliranju se srečamo z naslednjimi koncepti:     Relacija Atribut Domena n-terica      Funkcionalna odvisnost Ključ Pogled Normalizacija …

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 222 -

Načrtovanje – Izdelava načrta PB

Predstava relacije

 Relacijo si lahko predstavljamo kot dvodimenzionalno tabelo s stolpci in vrsticami.

 Velja za logično strukturo podatkovne baze in ne za fizično.

Ime

Tine Meta Jure Ana

Starost (v letih)

15 20 40 5

Teža (v kg)

50 45 80 10

Relacija RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 223 -

Načrtovanje – Izdelava načrta PB

Atribut relacije

 Atribut je poimenovani stolpec relacije.

Ime

Tine Meta Jure Ana

Starost (v letih)

15 20 40 5

Teža (v kg)

50 45 80 10

Atribut relacije RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 224 -

Načrtovanje – Izdelava načrta PB

Domena relacije

  Domena je množica dovoljenih vrednosti enega ali več atributov, ki so vključeni v to domeno.

Primeri domen:

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 225 -

Načrtovanje – Izdelava načrta PB

Osnovne karakteristike relacije

   N-terica je ena vrstica v relaciji.

Števnost relacije je število n-teric relacije.

Stopnja relacije je število atributov v relaciji.

Stopnja relacije Števnost relacije RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Ime

Tine Meta Jure Ana

Starost (v letih)

15 20 40 5

Teža (v kg)

50 45 80 10

- 226 n-terica relacije

Načrtovanje – Izdelava načrta PB

Relacijska podatkovna baza in normalizacija

 Relacijska podatkovna baza je množica normaliziranih relacij z enoličnimi imeni.

 Normalizirane relacije anomalij.

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

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 227 -

Načrtovanje – Izdelava načrta PB

Matematična definicija relacije

 Relacijo matematično definiramo kot podmnožico kartezičnega produkta množic, ki predstavljajo domeno vrednosti atributov relacije.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

r



D

1 

D

2  ...



D n

D1 je domena atributa A 1 : množica vrednosti, ki jih A 1 lahko zavzame!

- 228 -

Načrtovanje – Izdelava načrta PB

Relacijska shema

  Vsaki relaciji pripada relacijska shema .

Relacijsko shemo sestavlja oznaka sheme R ter lista oznak atributov A i s pripadajočimi oznakami domen D i :  R (A 1 : D 1 , A 2 : D 2 , ..., A n : D n )  Relacijska shema predstavlja semantiko pomen relacije . ali

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 229 -

Načrtovanje – Izdelava načrta PB

Relacijska shema Ime

Tine Meta Jure Ana

Starost (v letih)

15 20 40 5

Teža (v kg)

50 45 80 10

Shema relacije Relacija, predstavljena kot tabela 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 RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 230 Shema relacije Domene atributov relacije

Načrtovanje – Izdelava načrta PB

Lastnosti relacij

 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  n-teric.

v relaciji ni dveh enakih

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 231 -

Načrtovanje – Izdelava načrta PB

Lastnosti relacij

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 232 -

Načrtovanje – Izdelava načrta PB

Lastnosti relacij – primer Ime

Tine Meta Jure Ana

Starost (v letih), teža (v kg)

S15_T50 S20_T45 S40_T80 S5_T10

Celice ne vsebujejo atomarnih vrednosti Zakonca Leto poroke (celo število)

Tine, Meta 1995 Ana, Jure 1980

Celice vsebujejo več vrednosti RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 233 -

Načrtovanje – Izdelava načrta PB

Funkcionalne odvisnosti

 Predpostavimo, da obstaja relacijska shema R z množico atributov, katere podmnožici sta X in Y.

 V relacijski shemi R velja vrednostih atributov Y.

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

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 234 -

Načrtovanje – Izdelava načrta PB

Funkcionalne odvisnosti - primer

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 235 -

Načrtovanje – Izdelava načrta PB

Ključi relacije

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 236 -

Načrtovanje – Izdelava načrta PB

Ključi relacije

 Predpostavimo, da obstaja relacijska shema z atributi A 1 A 2 , ... A n , 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  A 1 A 2 ... A n ne obstaja X’, ki bi bila prava podmnožica od X in ki bi tudi funkcionalno določala A 1 A 2 ... A n

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 237 -

Načrtovanje – Izdelava načrta PB

Ključi relacije

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 238 -

Načrtovanje – Izdelava načrta PB

Ključi relacije

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 239 -

Načrtovanje – Izdelava načrta PB

Ključi relacije primer Šifra Naziv ARTIKEL Zaloga

A10 A12 BC80 X12 Telovadni copati Nike Trenerka Bali Moška jakna QuickSilver Ženska jakna QuickSilver 10 4 1 0

Primarni ključ v tabeli Artikel Primarni ključ v tabeli Račun Račun Šifra artikla

15/05 15/05 A10 X12

RAČUN Količina

1 1

Tuji ključ v tabeli Račun



kaže na primarni ključ v tabeli Artikel RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 240 -

Načrtovanje – Izdelava načrta PB

Omejitve nad podatki

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 241 -

Načrtovanje – Izdelava načrta PB

Omejitve nad podatki

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 242 -

Načrtovanje – Izdelava načrta PB

Omejitve nad podatki

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 243 -

Načrtovanje – Izdelava načrta PB

Omejitve nad podatki – primeri omejitev Primarni ključ



ne sme biti NULL EMŠO DavcnaSt Ime Priimek DtmRoj Katedra Pedagog N13 C9 not null C20 C20 D N3 Zahtevamo obveznost podatka Omejitev povezave Katedra Naziv StLab Vodja Katedra N3 C20 not null N2 N3 RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 244 -

Načrtovanje – Izdelava načrta PB

Pogledi

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 245 -

Načrtovanje – Izdelava načrta PB

Namen uporabe pogledov

 Zakaj uporabljamo poglede:    Varnost : predstavljajo odličen mehanizem za zagotavljanje varnosti  skrivajo posamezne dele podatkovne baze pred določenimi uporabniki.

Prilagojenost uporabnikom različne načine.

: 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 Poenostavitev : poenostavljajo kompleksne operacije nad osnovnimi relacijami.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 246 -

Načrtovanje – Izdelava načrta PB

Spreminjanje pogledov

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 247 -

Načrtovanje – Izdelava načrta PB

Spreminjanje pogledov

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 248 -

Načrtovanje – Izdelava načrta PB

Primer pogleda Šifra Naziv ARTIKEL Zaloga Račun Šifra artikla

A10 A12 BC80 X12 Telovadni copati Nike Trenerka Bali Moška jakna QuickSilver Ženska jakna QuickSilver 10 4 1 0 15/05 15/05 16/05 17/05 A10 X12 A10 A10

RAČUN Količina

1 1 3 1

SELECT A.

sifra , A.

naziv , sum(R.

kolicina ) AS Prodanih FROM artikel A, racun WHERE A.

sifra = R.

sifra R GROUP BY A.

sifra , A.

naziv RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Šifra

A10 X12 ...

Naziv

Telovadni copati Nike Ženska jakna QuickSilver

- 249 Prodanih

5 1

Načrtovanje – Izdelava načrta PB

Normalizacija

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 250 -

Načrtovanje – Izdelava načrta PB

Normalizacija

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 251 -

Načrtovanje – Izdelava načrta PB

Normalizacija – ažurne anomalije

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 252 -

Načrtovanje – Izdelava načrta PB

Normalizacija – ažurne anomalije pri dodajanju

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 253 -

Načrtovanje – Izdelava načrta PB

Normalizacija – ažurne anomalije pri brisanju

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 254 -

Načrtovanje – Izdelava načrta PB

Normalizacija – ažurne anomalije pri spreminjanju

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 255 -

Načrtovanje – Izdelava načrta PB

Normalne oblike

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 256 -

Načrtovanje – Izdelava načrta PB

Normalizacija – prva normalna oblika

 Relacija je v prvi normalni obliki , če:  Nima ponavljajočih atributov je več vrednosti)  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  Ima definiran primarni ključ in določene funkcionalne odvisnosti  Koraki:    Odstranimo ponavljajoče atribute Določimo funkcionalne odvisnosti Določimo primarni ključ

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 257 -

Načrtovanje – Izdelava načrta PB

Indeks( VŠ, priimek, ime, pošta, kraj, ( šifra predmeta, naziv, ocena ) ) Skupina ponavljajočih se atributov.

VŠ 64010632 64016209 priimek Bratina Bizjak ime Simon Tadeja pošta 4100 kraj Kranj 2250 Ptuj šifra predmeta 20020 20021 20033 20060 20033 naziv IS TPO IPI E1 IPI ocena 10 8 8 9 6

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 258 -

Načrtovanje – Izdelava načrta PB

Indeks( VŠ, priimek, ime, pošta, kraj, ( šifra predmeta, naziv, ocena ) ) Odpravimo ponavljajoče atribute Indeks( VŠ, priimek, ime, pošta, kraj, šifra predmeta, naziv, ocena ) Identificiramo funkcionalne odvisnosti F

 

{ VŠ



(priimek, ime, pošta, kraj), šifra predmeta kraj, (VŠ, šifra predmeta)



ocena }



naziv, pošta Določimo primarni ključ Indeks( VŠ, priimek, ime, pošta, kraj, šifra predmeta, naziv, ocena ) RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 259 -

Načrtovanje – Izdelava načrta PB

VŠ 64010632 64010632 64010632 64016209 64016209 priimek Bratina Bratina Bratina Bizjak Bizjak ime Simon Simon Simon Tadeja Tadeja pošta 4100 4100 4100 2250 2250 kraj Kranj Kranj Kranj Ptuj Ptuj šifra predmeta 20020 20021 20033 20060 20033 naziv IS TPO IPI E1 IPI 9 6 8 8 ocena 10 VŠ 64010632 64016209 priimek Bratina Bizjak ime Simon Tadeja pošta 4100 kraj Kranj 2250 Ptuj šifra predmeta 20020 20021 20033 20060 20033 naziv IS TPO IPI E1 IPI ocena 10 8 8 9 6

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 260 -

Načrtovanje – Izdelava načrta PB

Normalizacija – druga normalna oblika

 Relacija je v drugi normalni obliki :   Če je v prvi normalni obliki in Ne vsebuje parcialnih odvisnosti ključa, ni funkcionalno odvisen le od dela primarnega ključa, temveč od celotnega ključa  noben atribut, ki ni del

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 261 -

Načrtovanje – Izdelava načrta PB

!

Indeks( VŠ, šifra predmeta, priimek, ime, pošta, kraj, naziv, ocena ) !

Študent( VŠ, priimek, ime, pošta, kraj) Predmet( šifra predmeta, naziv) Indeks( #VŠ, #šifra predmeta, ocena) Relacijo razbijemo RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 262 -

Načrtovanje – Izdelava načrta PB

VŠ 64010632 64010632 64010632 64016209 64016209 priimek Bratina Bratina Bratina Bizjak Bizjak ime Simon Simon Simon Tadeja Tadeja pošta 4100 4100 4100 2250 2250 kraj Kranj Kranj Kranj Ptuj Ptuj šifra predmeta 20020 20021 20033 20060 20033 naziv IS TPO IPI E1 IPI 9 6 ocena 10 8 8 šifra predmeta 20020 20021 20033 20060 20033 naziv IS TPO IPI E1 IPI

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

VŠ 64010632 64010632 64010632 64016209 64016209 šifra predmeta 20020 20021 20033 20060 20033 ocena 9 6 10 8 8

- 263 -

VŠ 64010632 64016209 priimek Bratina Bizjak ime Simon Tadeja pošta 4100 2250 kraj Kranj Ptuj

Načrtovanje – Izdelava načrta PB

Normalizacija – tretja normalna oblika

 Relacija je v tretji normalni obliki :   Če je v drugi normalni obliki in Če ne vsebuje tranzitivnih funkcionalnih odvisnosti  atributi, ki niso del primarnega ključa, ni odvisnosti.

med

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 264 -

Načrtovanje – Izdelava načrta PB

!

Študent( VŠ, priimek, ime, pošta, kraj) Predmet( šifra predmeta, naziv) Indeks( #VŠ, #šifra predmeta, ocena) Relacijo razbijemo Študent( VŠ, priimek, ime, #pošta) Pošta(pošta, kraj) Predmet( šifra predmeta, naziv) Indeks( #VŠ, #šifra predmeta, ocena) RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 265 -

Načrtovanje – Izdelava načrta PB

VŠ 64010632 64016209 priimek Bratina Bizjak ime Simon Tadeja pošta 4100 2250 kraj Kranj Ptuj VŠ 64010632 64016209 priimek Bratina Bizjak ime Simon Tadeja pošta 4100 2250 pošta 4100 2250 kraj Kranj Ptuj

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 266 -

Načrtovanje – Izdelava načrta PB

Normalizacija – četrta poslovna normalna oblika

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 267 -

Načrtovanje – Izdelava načrta PB

Š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) RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 268 -

Načrtovanje – Izdelava načrta PB

VŠ 64010632 64016209 64010670 64620010 65120987 Priimek Bratina Bizjak Berce Mele Leban Ime Simon Tadeja Marjan Silvana Tibor Datum plačila šolnine 19.4.2002

12.4.2004

Rok diplome 15.3.2005

1.4.2005

15.7.2005

VŠ 64010632 64016209 64010670 64620010 65120987 Priimek Bratina Bizjak Berce Mele Leban

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Ime Simon Tadeja Marjan Silvana Tibor VŠ 64016209 64010670 Datum plačila šolnine 19.4.2002

12.4.2004

VŠ 64010632 64620010 Rok diplome 15.3.2005

1.4.2005

15.7.2005

Načrtovanje – Izdelava načrta PB

Tipični koraki pri izdelavi relacijskega modela

 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

Ponovitev RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 270 -

Načrtovanje – Izdelava načrta PB

Primer pretvorbe konceptualnega v relacijski model Študent

Vpisna številka Priimek Ime Naslov Telefon E-mail Status …

Izpit

Zap. št. polaganja Ocena pisno Ocena ustno Datum ocene

VpisSt = VpisSt

VpisSt Priimek Ime Ulica Posta Drzava GSM Tel Email Status …

Student

N8 C20 C20 C25 N4 C20 N15 N15 C25 N1 ZapStPol VpisSt OcPisno OcUstno DatumOc

Izpit

N2 N8 N2,2 N2,2 D null

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 271 -

Načrtovanje – Izdelava načrta PB

Primer pretvorbe konceptualnega v relacijski model

 Dodatno poskrbimo za:    Indekse Integriteto povezav Druge omejitve   Poglede …

VpisSt = VpisSt

VpisSt Priimek Ime Ulica Posta Drzava GSM Tel Email Status …

Student

N8 C20 C20 C25 N4 C20 N15 N15 C25 N1 ZapStPol VpisSt OcPisno OcUstno DatumOc

Izpit

N2 N8 N2,2 N2,2 D null

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 272 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 273 -

Načrtovanje – izdelava načrta modulov

Namen aktivnosti

 Namen aktivnosti je prikazati, kako bodo posamezne funkcije in procesi, identificirani v sklopu analize, realizirani v okviru rešitve.

Analiza Proces Proces Proces Funkcija Funkcija Funkcija Funkcija Funkcija Načrt Programski modul Programski modul Programski modul Programski modul Programski modul Programski modul Programski modul RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 274 -

Načrtovanje – izdelava načrta modulov

Namen aktivnosti

  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.

Logična enota 1..n

1..n

Fizična enota RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 275 -

Načrtovanje – izdelava načrta modulov

Programski moduli

 Tipi programskih modulov:    Zaslonska maska Obdelava Poročilo ali izpis Programski modul Zaslonska maska Izpis/ poročilo Paketna obdelava

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 276 -

Načrtovanje – izdelava načrta modulov

Strukturni diagram

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 277 -

Načrtovanje – izdelava načrta modulov

Strukturni diagram

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 278 -

Načrtovanje – izdelava načrta modulov

Strukturni diagram – primer Dodaj izpitni rok dan roka Izračunaj dan roka podatek kontrolna zastavica RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 279 Preveri poslovna pravila pravila OK številka kršenega pravila

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 280 -

Načrtovanje – načrt dokumentacije

Izdelava načrta 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 281 -

Načrtovanje – načrt dokumentacije

Izdelava načrta 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 282 -

Načrtovanje – načrt dokumentacije

Izdelava načrta dokumentacije

  Uporabniška dokumentacija je osnovna pomoč za uporabnike oziroma uporabo rešitve.

Možne različne oblike…

Vir: ERP sistem Pantheon RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 283 -

Načrtovanje – načrt dokumentacije

Izdelava načrta dokumentacije

 Sistemsko-tehnična dokumentacija vidika. Npr.: dokumentira informacijsko rešitev s sistemsko-tehničnega      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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 284 -

Načrtovanje – načrt dokumentacije

Izdelava načrta dokumentacije

 Navodila za operativno skrbništvo delovanje sistema. Npr: zajemajo opis ključnih postopkov, ki so potrebni za operativno      Postopek izdelave varnostnih kopij; Postopek ustavitve sistema; Postopek ponovnega zagona sistema; Postopek namestitve nadgradenj in popravkov; Postopek vzpostavitve nadomestnega sistema;  …

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 285 -

Načrtovanje – načrt dokumentacije

Izdelava načrta dokumentacije

  V okviru načrta dokumentacije izdelamo vzorce dokumentacije in jih predstaviti naročniku ter uporabniku. Cilj je uskladitev o obliki dokumentacije.  Nivo podrobnosti kritični postopki.

in obseg dokumentacije je odvisen od dogovora med izvajalcem in naročnikom. Praviloma se podrobneje dokumentirajo samo pomembnejši podsistemi in

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 286 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 287 -

Načrtovanje – načrt testiranja

Izdelava načrta 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 288 -

Načrtovanje – načrt testiranja

Načrt poteka 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 programskih modulov. odvisen od načrta

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 289 -

Načrtovanje – načrt testiranja

Načrt za izvedbo testa

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 290 -

Načrtovanje – načrt testiranja

Načrt za izvedbo testa

 Načrt za izvedbo testa mora opredeliti vsaj:    Namen testiranja : čemu je namenjena izvedba testa? (npr. testiranje programske enote »Prijava na izpit«) Faza testiranja uvedbe) : v kateri fazi izvajamo testiranje? (npr. testiranje v fazi razvoja ali testiranje v fazi namestitve in 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 291 -

Načrtovanje – načrt testiranja

Uporaba scenarijev

   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 vključeni. potrdimo ali ovržemo pravilnost delovanja modulov/ sklopov, ki so bili v testu

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 292 -

Načrtovanje – načrt testiranja

Uporaba scenarijev

 Za izvedbo testa po nekem scenariju je potrebno določiti vhodne podatke ter pričakovane rezultate .

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 293 -

Načrtovanje – načrt testiranja

Opredelitev scenarija Načrt poteka testiranja

Razvojno okolje T 1 Testno oklolje T 2 T 3 T 4 T 5 T 6 T 8 T n-1 T 7 Produkcijsko okolje T n

Scenarij :



Vhodni podatki

 

Pričakovani rezultati Načrt za izvedbo testa

Test T

3 RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 294 -

Načrtovanje – načrt testiranja

Načrt testiranja – izdelek

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 295 -

Načrtovanje – načrt testiranja

Načrt testiranja – primer načrta poteka testiranja Načrt poteka testiranja

T1: sklop: prijava na izpit okolje: razvoj

T2:

sklop: odjava iz izpita okolje: razvoj

T3:

sklop: pregled števila prijavljenih kandidatov okolje: razvoj T4: sklop: Izpis seznama prijavljenih kandidatov okolje: razvoj

T5:

sklop: Vnos rezultatov okolje: razvoj

T6: T7: T8:

sklop: Objava rezultatov okolje: razvoj sklop: Opravljanje pisnih izpitov (integracijski test) okolje: testno Razvojno okolje sklop: Vnos obvestil T 1 okolje: razvoj ....

Tn-1: sklop: celoten sistem (potrditveni test) okolje: testno

Tn:

sklop: celoten sistem (končni test) okolje: produkcijsko Testno oklolje Produkcijsko okolje T 2

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 296 -

T 3 T 4 T 5 T 6 T 7 T 8 T n-1 T n

Načrtovanje – načrt testiranja

Načrt testiranja – primer načrta za izvedbo testa NAČRT TESTIRANJA ZA TEST T2

Namen testiranja: testiranje sklopa odjava iz izpita Faza testiranja: testiranje v fazi razvoja Okolje testiranja: razvojno okolje Področje testiranja: funkcionalnost sklopa, GUI

Način izvedbe testiranja:

1. Testiranje funkcionalnosti: testirati po scenarijih S1, S3, S4, S8 2. Testiranje GUI: preveriti skladnost elementov GUI z načrtom programskega modula/podsistema PM3

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 297 -

Načrtovanje – načrt testiranja

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 INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 298 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 299 -

Načrtovanje – načrt namestitve in uvedbe

Načrt namestitve in uvedbe

  Naloga aktivnosti je izdelati načrt namestitve in uvedbe IR okolje ter uvedbo uporabnikov in skrbnikov za delo z IR. v razvojno, testno in produkcijsko 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 300 -

Načrtovanje – načrt namestitve in uvedbe

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črtovanje – načrt namestitve in uvedbe

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črtovanje – načrt namestitve in uvedbe

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 303 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 304 -

Načrtovanje – predstavitev načrta

Predstavitev načrta naročniku

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 305 -

Načrtovanje – predstavitev načrta

Predstavitev načrta naročniku

  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 zahtevam. potrditvijo naročnika (navadno podpis dokumenta), da načrt ustreza

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 306 -

Razvoj po strukturnem pristopu

Kje smo?

 Postopki strukturnega pristopa:    Zajem in specifikacija zahtev; Analiza; Načrtovanje;    Izvedba; Testiranje; Namestitev in uvedba.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 307 -

Testiranje

Opredelitev in namen

 Glavni namen testiranja kot smo načrtovali.

je zagotoviti, da IR deluje tako,  Postopek testiranja uvedba. se prepleta skozi ves življenjski cikel razvoja IR: analiza, načrtovanje, izvedba in

Podroben opis aktivnosti testiranja je podan po posameznih postopkih. RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 308 -

Testiranje

Končni izdelek

e  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 309 -

Testiranje

Vloge

   Testiranje se izvaja na različnih ravneh. Prvo testiranje izvaja že sam testiranje s strani razvijalec neposredno ob razvoju. Sledi sistematično preizkuševalca , zatem pa še testiranje s strani končnega uporabnika .

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 310 -

Testiranje

Okolje za 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 311 -

Testiranje

Primer okolja za testiranje Razvojni AS Razvojni PS Produkcijski AS Razvoj in vmesno testiranje RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Testni AS in PS 312 Produkcijski PS Končno testiranje in produkcija

Testiranje

Shema postopka



RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 313 -

Testiranje

Vrste in potek testiranja

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 314 -

Testiranje

Vrste in potek testiranja Vrsta testa

Test programskih enot Test integracije Sistemski test

Vsebina testiranja

Uporabniški vmesnik, funkcionalnost programske enote, skladnost z zahtevami in standardi Test integracije programskih enot, test integracije v okolje (vmesniki) Obnašanje v okolju, zmogljivosti, dostopnost, nefunkcionalne zahteve

Okolje testiranja

Razvojno okolje, Testno okolje Testno okolje Testno okolje Test sprejemljivosti Potrditveni test Test sprejemljivosti Končni test Preverjanje delovanja celotne funkcionalnosti, preverjanje nefunkcionalnih zahtev Test funkcionalnosti v omejenem obsegu v produkcijskem okolju

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 315 -

Testno okolje Produkcijsk o okolje

Vloge

Razvijalec, Preizkuševalec Integrator, Preizkuševalec, Ključni uporabnik Skrbnik podatkovne baze, Sistemski administrator, Skrbnik aplikacije, Preizkuševalec, Ključni uporabnik Ključni uporabnik Ključni uporabnik

Testiranje

Vrste in potek testiranja

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 316 -

Testiranje

Vrste in potek testiranja

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 317 -

Testiranje

Vrste in potek testiranja

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 318 -

Testiranje

Vrste in potek testiranja

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 319 -

Testiranje

Vrste in potek testiranja

 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 -

Razvoj po strukturnem pristopu

Kje smo?

 Postopki strukturnega pristopa:    Zajem in specifikacija zahtev; Analiza; Načrtovanje;    Izvedba; Testiranje; Namestitev in uvedba.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 321 -

Namestitev in uvedba

Opredelitev in namen

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 322 -

Namestitev in uvedba

Končni izdelek

e  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 323 -

Namestitev in uvedba

Vloge in koraki

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 324 -

Namestitev in uvedba

Vloge in koraki

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 325 -

Namestitev in uvedba

Shema postopka



RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 326 -

Namestitev in uvedba

Shema postopka



RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 327 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 328 -

Namestitev in uvedba – Namestitev IR

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 329 -

Namestitev in uvedba – Namestitev IR

Namestitev IR

 Namestitev IR v testno okolje poteka v več fazah (med razvojem) ali v celoti (ob zaključku).  Namestitev IR v produkcijsko okolje testom v testnem okolju.

se izvede, ko je aplikacija razvita in potrjena s potrditvenim

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 330 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 331 -

Namestitev in uvedba – Dodelitev pravic

Dodelitev pravic za delo z IR

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 332 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 333 -

Namestitev in uvedba – Prevedba

Prevedba podatkov

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 334 -

Namestitev in uvedba – Prevedba

Prevedba podatkov

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 335 -

Namestitev in uvedba – Prevedba

Prevedba podatkov

 Prevedba podatkov v testno okolje lahko izvede večkrat. se izvede v sklopu namestitve testnega okolja. Po potrebi se  Zagotavljanje testnih podatkov ter ponovljivosti testov je lahko zelo kompleksna naloga…  Prevedba podatkov v produkcijsko okolje izvede v sklopu namestitve IR v produkcijsko okolje.

se  Navadno gre za ponovitev že preverjenih in utečenih postopkov prevedbe, ki zagotovijo pravilen prenos podatkov.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 336 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 337 -

Namestitev in uvedba – Potrditveni test

Izvedba potrditvenega testa

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 338 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 339 -

Namestitev in uvedba – Končni test

Izvedba končnega testa

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 340 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 341 -

Namestitev in uvedba – Uvajanje

Uvajanje uporabnikov in skrbnikov za delo z IR

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 342 -

Namestitev in uvedba – Uvajanje

Uvajanje uporabnikov in skrbnikov za delo z IR

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 343 -

Namestitev in uvedba – Uvajanje

Uvajanje uporabnikov in skrbnikov za delo z IR – Smernice

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 344 -

Namestitev in uvedba – Uvajanje

Uvajanje uporabnikov in skrbnikov za delo z IR – Smernice

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 345 -

Razvoj po strukturnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 346 -

Namestitev in uvedba – Prehod

Prehod na nov sistem

 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 -

Namestitev in uvedba – Prehod

Strategije uvedbe

 V praksi se za uvedbo IR uporabljajo različne strategije. V grobem jih delimo v tri skupine:    Fazni pristop ( Phased strategy ); Zamenjava BigBang ); ali vse naenkrat ( Replacement strategy, Vzporedno delovanje ( Parallel strategy ).

 Poleg omenjenih strategij uvedbe se lahko uporabljajo tudi različne kombinacije.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 348 -

Namestitev in uvedba – Prehod

Strategije uvedbe – Fazni pristop

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 349 -

Namestitev in uvedba – Prehod

Strategije uvedbe – Fazni pristop – problem začasnih vmesnikov Zunanji sistemi Star sistem Star sistem

Uvedba celotnega sistema naenkrat Uvedba po delih I faza.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 350 -

Namestitev in uvedba – Prehod

Strategije uvedbe – Zamenjava ali vse naenkrat

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 351 -

Namestitev in uvedba – Prehod

Strategije uvedbe – Vzporedno delovanje

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 352 -

Namestitev in uvedba – Prehod

Strategije uvedbe Zamenjava Vse naenkrat Vzporedno Možni pristopi Postopoma Po področjih V celoti vzporedno Po lokacijah Delno vzporedno Po modulih Po starih aplikacijah V celoti zamenjava RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 353 -

Poglavje III

Objektni razvoj

   Osnovni principi objektne usmerjenosti Osnove modelirnega jezika UML in procesa RUP Objektna analiza in načrtovanje

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 354 -

Objektni pristop

Osnovne značilnosti objektnega pristopa

  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 -

Objektni pristop

Osnovne značilnosti objektnega pristopa Učilnica Študent

Programski modul: Pregled zasedenosti učilnice

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Profesor Strukturni pristop

1.

2.

Podatki  Študent  Profesor  Učilnica  Predmet  … Procesi  Vzdrževanje izpitnih rokov  Opravljanje izpita  Vodenje izpitne evidence  … Podatkovna baza Podatkovna baza Programski modul Programski modul Programski modul Programski modul Programski modul Programski modul Programski modul

- 356 -

Objektni pristop

Osnovne značilnosti objektnega pristopa Učilnica Študent

Objekt Marko: PROFESOR

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Profesor Ali je učilnica NP15 15.5.07 prosta?

Objekt NP15: UČILNICA

Objektni pristop

 

Objekt tipa ŠTUDENT

 Lastnosti: – Priimek, – Ime, – Vpisna številka, – …  Funkcije: – Prijava na izpit – Odjava iz izpita – Pregled elektronskega indeksa – …

Objekt tipa UČILNICA

 Lastnosti:

- 357 -

– 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 – …

Objektni pristop

Primerjava postopkov strukturnega in objektnega razvoja IR

Zajem zahtev Analiza Načrtovanje Izvedba

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Življenjski cikel razvoja IR - 358 -

Uvajanje Testiranje Vzdrževanje

Objektni pristop

Vsebina

 Sledi:    Osnovni principi objektne usmerjenosti Osnove modelirnega jezika UML in procesa RUP Objektna analiza in načrtovanje

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 359 -

Razvoj po objektnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 360 -

Osnovni principi objektne usmerjenosti

Definicija objekta

 Objekt lahko predstavlja fizično entiteto ali konceptualni pojem .

  Učitelj, učenec,… Predmet, test,…  S stališča razvoja IR je objekt mejami in pomenom za IR . koncept, abstrakcija ali stvar z natančno določenimi

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 361 -

Osnovni principi objektne usmerjenosti

Definicija objekta

 Objekti lahko predstavljajo tudi konkretne koncepte s področja računalniških jezikov in rešitev :    Seznam Indeks …

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 362 -

Osnovni principi objektne usmerjenosti

Abstrakcija

 Objekt je abstrakcija neke entitete, ki je pomembna za IR…

Vesna: Profesor

Ime: Vesna Jug Telefon: 01/4768 814 Prijavi (int pid): boolean

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 363 -

Osnovni principi objektne usmerjenosti

Stanje, obnašanje in identiteta objekta

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 364 -

Osnovni principi objektne usmerjenosti

Stanje, obnašanje in identiteta objekta

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 365 -

Osnovni principi objektne usmerjenosti

Stanje, obnašanje in identiteta objekta

 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, kaj lahko počne in kaj se lahko z njim počne !

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 366 -

Osnovni principi objektne usmerjenosti

Razred

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 367 -

Osnovni principi objektne usmerjenosti

Razred

 Odnos med objektom in razredom je podoben odnosu med entiteto in entitetnim tipom.

Objekti Razred Ime razreda: Profesor

• •

Lastnosti:

Ime • Priimek • …

Obnašanje

…

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 368 -

Osnovni principi objektne usmerjenosti

Razred

 Koliko razredov je na sliki?

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 369 -

Razvoj po objektnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 370 -

Osnovni principi objektne usmerjenosti

Enkapsulacija ali skrivanje podatkov

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 371 -

Osnovni principi objektne usmerjenosti

Enkapsulacija ali skrivanje podatkov

 Ž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, ko pritisnemo na plin?

 Za delo z objektom ne potrebujemo vseh podatkov o objektu, temveč samo določene – vmesnik ( interface ).

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 372 -

Osnovni principi objektne usmerjenosti

Enkapsulacija ali skrivanje podatkov

 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 se zna odzivati na vmesnik…

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 373 -

Osnovni principi objektne usmerjenosti

Enkapsulacija ali skrivanje podatkov

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 374 -

Razvoj po objektnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 375 -

Osnovni principi objektne usmerjenosti

Hierarhija in dedovanje

 Dedovanje razvoja.

  je ključen koncept objektnega 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 376 -

Osnovni principi objektne usmerjenosti

Hierarhija in dedovanje

  Primer razreda Profesor in Pedagoški delavec Opis:     P ima enake lastnosti kot PD.

Pedagoški delavec

Ime Priimek

Profesor

Akademski naziv Število predmetov Za P nas zanima tudi akademski naziv ter št. predmetov, ki jih poučuje.

EMŠO Telefon Delovno mesto Datum rojstva Naslov … Vnesi oceno Razpiši temo diplome P lahko razpisuje tudi teme za diplome.

… Razpiši izpitni rok Vnesi oceno P ima pri vnašanju ocen več pravic kot PD. Lahko vpisuje tudi ocene ustno…

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 377 -

Osnovni principi objektne usmerjenosti

Hierarhija in dedovanje

 Razrede lahko zapišemo v hierarhijo .

Raziskovalec Asistent Oseba Delavec Pedagoški delavec Profesor Redni profesor Strokovni sodelavec RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 378 -

Osnovni principi objektne usmerjenosti

Hierarhija in dedovanje

 Hierarhija razredov v Delphi razvojnem okolju…

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 379 -

Osnovni principi objektne usmerjenosti

Hierarhija in dedovanje

 Delček razredne hierarhije java.awt

…

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 380 -

Razvoj po objektnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 381 -

Jezik UML in proces RUP

Zakaj UML?

Skupinski razvoj RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Jezik za modeliranje 382 Poenoten proces

Jezik UML in proces RUP

UML – univerzalni modelirni jezik Univerzalni modelirni jezik (UML) je jezik za specifikacijo, vizualizacijo, konstrukcijo in dokumentacijo izdelkov v okviru objektnega razvoja informacijskih rešitev.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 383 -

Jezik UML in proces RUP

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!!!

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 384 -

Jezik UML in proces RUP

UML – Zgodovina do 1997 RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 385 -

Jezik UML in proces RUP

Drugi viri in prispevki Booch Rumbaugh Jacobson Meyer

predpogoji in popogoji

Fusion

opisi operacij, oštevilčenje sporočil

Harel

diagrami stanj

Gamma, et.al

ogrodja, vzorci, opombe

Shlaer - Mellor

življenjski cikli objekta

Odell

klasifikacija

Wirfs-Brock

odgovornosti

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 386 -

Jezik UML in proces RUP

UML danes

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 387 -

Jezik UML in proces RUP

UML diagramske tehnike

Objektni diagrami Diagrami primerov uporabe Razredni diagrami

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Diagrami aktivnosti Diagrami impleme ntacije Diagrami stanj

388 UML diagrami

Kompo nentni diagrami Diagrami zapore dja Diagrami sodelova nja

Jezik UML in proces RUP

UML diagramske tehnike – enostavnost študent profesor prijava na izbirni predmet izbira predmetov za poučevanje Referent RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko ?

seznam predavanj vnos podatkov o profesorjih vnos podatkov o študentih zaključitev prijave 389 sistem za pripravo urnika

Jezik UML in proces RUP

UML diagramske tehnike – kompleksnost RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 390 -

Jezik UML in proces RUP

UML diagramske tehnike – hrbtenica razvoja diagram primera uporabe razredni diagram diagram stanj

add file [ numberOffile==MAX ] / flag OFF Openning

Use-Case 1 Actor A Actor B

close file

Poznavalec obravnavanega področja Use-Case 2 Use-Case 3

UI MFC Reading

<> name receive() withdraw() fetch() razred

Closing close file add file Writing DocumentApp

Razvijalec

9: sortByName ( ) 1: Doc view request ( ) user : »ç¿ëÀÚ mainWnd : MainWnd 2: fetchDoc( ) 4: create ( ) 8: fillFile ( ) fileMgr : FileMgr 3: create ( ) 6: fillDocument ( ) gFile : GrpFile repository : Repository 7: readFile ( ) 5: readDoc ( ) document : Document

diagram sodelovanja

Persistence Rog ueWave g lobal

diagram paketov FileManager GraphicFile File diagram komponent diagram implementacije Repository DocumentList Document FileList

ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ - À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼ -¹ö - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹× µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö Window95 Windows95 Windows95 ¹®¼-°ü¸® Ŭ¶óÀ̾ðÆ®.EXE

Windows NT Windows NT ¹®¼-°ü¸® ¿£Áø.EXE

Solaris IBM Mainframe µ¥ÀÌŸº£À̽º¼-¹ö ÀÀ¿ë¼-¹ö.EXE

¹®¼-°ü¸® ¾ÖÇø´ Alpha UNIX

Forward Engineering (specifikacija -> koda) Reverse Engineering (koda -> specifikacija)

ƯÁ ¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äà »ÇÑ´Ù.

È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼-À Ç Á ¤º¸¸¦ ÇØ´ç ¹®¼- °´Ã ¼¿¡ ¼³Á ¤À » ¿äà »ÇÑ´Ù.

user mainWnd fileMgr : FileMgr document : Document gFile repository 1: Doc view reques t ( ) 2: fetc hDoc ( ) 3: c reate ( ) 4: c reate ( ) 5: readDoc ( ) 6: fill Doc ument ( ) 8: fill File ( ) 7: readFile ( ) 9: s ortByName ( ) È-¸é °´Ã¼´Â ÀоîµéÀÎ °´Ã ¼µé¿¡ ´ëÇØ À ̸§º°·Î Á¤·Ä À» ½Ã ÄÑ È-¸é¿¡ º¸¿©Á Ø´Ù.

diagram zaporedja urejanje izvorne kode, prevajanje, razhroščevanje, povezovanje RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 391 -

Razvoj po objektnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 392 -

Jezik UML in proces RUP

Proces razvoja

  Proces določa kdo dela kaj, kdaj in kako za doseganje določenega cilja. Cilj razvoja IR je njena izgradnja ali izboljšava.

Nove ali spremenjene zahteve Nov ali spremenjen sistem Proces razvoja IR RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 393 -

Jezik UML in proces RUP

Proces razvoja – RUP

 RUP   – Rational Unified Process primer procesa objektnega razvoja avtor: podjetje Rational

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 394 -

Jezik UML in proces RUP

RUP – glavne lastnosti

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 395 -

Jezik UML in proces RUP

RUP – šest poglavitnih dobrih praks

 RUP opisuje, kako učinkovito uporabiti šest najboljših izkušenj s področja razvoja IR.

Iterativni razvoj Obvladovanje zahtev Uporaba komponentne arhitekture Vizualno modeliranje Preverjanje kakovosti Nadzorovanje sprememb RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 396 -

Jezik UML in proces RUP

RUP – primeri uporabe kot osnova drugim aktivnostim

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 397 -

Jezik UML in proces RUP

RUP – primeri uporabe so hrbtenica procesa RUP

 Primeri uporabe so hrbtenica procesa RUP.

Zajem zahtev Analiza Načrtovanje Implementacija Testiranje

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 398 -

Jezik UML in proces RUP

RUP – arhitekturna usmerjenost

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 399 -

Jezik UML in proces RUP

RUP – arhitekturna usmerjenost – 4+1 pogledi na arhitekturo Razvijalec

Zgradba

Končni Končni upor.

Funkcionalnost Zmogljivost

Razširljivost

Throughput

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 400 Programer

Upravljanje s prog. op.

System topology

Predaja v uporabo, namestitev

communication

Jezik UML in proces RUP

RUP – prednosti arhitekturno usmerjenega pristopa

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 401 -

Jezik UML in proces RUP

RUP – faze življenjskega cikla razvoja po 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.

čas Začetna faza Zbiranje informacij Konstrukcija Prevzem RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 402 -

Jezik UML in proces RUP

RUP – makro mejniki čas Začetna faza Mejnik Določeni cilji projekta/ naloge Zbiranje informacij Mejnik Stabilna arhitektura Konstrukcija Mejnik Izdelek delujoč/ ustrezen Prevzem Mejnik Uporabnik zadovoljen RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 403 -

Jezik UML in proces RUP

RUP – mikro mejniki Zbiranje informacij Konstrukcija Začetna faza čas I 1 I 2 I 3 I 4 I 5 I 6 Prevzem I 7 I 8 Iteracija je specifično zaporedje aktivnosti izvedenih na osnovi načrta in z določenim kriterijem vrednotenja, ki se konča z izdajo izdelka.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 404 -

Jezik UML in proces RUP

RUP – gradnja modela sistema prek postopkov RUP Poslovno modeliranje Primeri uporabe poslovnega okolja Konceptualni model poslovnega okolja Zajem zahtev Model primerov uporabe Analiza in načrtovanje Model načrta Izvedba Model izvedbe Testiranje Modelira poslovno okolje Prikazuje tiste primere uporabe iz poslovnega okolja, za katere se bo razvijala IR Prikazuje načrt za implementacijo rešitve Prikazuje dejansko Izvedbo rešitve Model testiranja Prikazuje načrt testiranja RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 405 -

RUP – prednosti arhitekturno usmerjenega pristopa Osnovni postopki V vsaki iteraciji gremo čez vse postopke Podporni postopki RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 406 -

Jezik UML in proces RUP

RUP – osnovni in podporni postopki

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 407 -

Razvoj po objektnem pristopu

Kje smo?

 Objektni pristop:    Osnovni principi objektne usmerjenosti; Jezik UML in proces RUP; Zajem zahtev;  Objekta analiza in načrtovanje

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 408 -

RUP – Zajem zahtev

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 SISTEMOV Visokoš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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 410 -

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 Diagrami primerov uporabe   Ključna elementa diagramov primerov uporabe sta akter in primer uporabe Med seboj jih povezujemo

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 411 -

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 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

Akter Stranka RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 412 -

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 413 Primer uporabe Kupi vstopnico

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 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

Tok dogodkov RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 414 -

RUP – Zajem zahtev



RUP – zajem zahtev – primeri uporabe

Primer osnovnega toka dogodkov – Kupi vstopnico preko interneta: 1. Sistem prikaže seznam prireditev 2. Kupec izbere prireditev 3. Sistem vrne kupcu seznam terminov, kjer so še prosti sedeži za izbrano prireditev in podrobne podatke o prireditvi.

4. Kupec izbere termin 5. Sistem prikaže kupcu matriko sedežev z označenimi zasedenimi in rezerviranimi sedeži.

6. Kupec izbere enega ali več prostih sedežev 7. Sistem označi izbrane sedeže kot rezervirane 8. Sistem zahteva vnos imena in št. kreditne kartice 9. Kupec vnese ime in št. kreditne kartice 10. Sistem komunicira z zunanjim sistemom ponudnika kreditnih kartic 11. Zunanji sistem vrne sporočilo o uspešni transakciji 12. Sistem označi sedeže kot prodane 13. Sistem prikaže zaslon z vstopnico/cami, ki vsebuje tudi referenčne št. vstopnic 14. Sistem pošlje e-pošto stranki z enakimi podatki kot v točki 12

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 415 -



RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

Primer alternativnega toka dogodkov – Kupi vstopnico preko interneta: 1.

2.

3.

Sistem prikaže seznam prireditev Kupec izbere prireditev Sistem vrne kupcu sporočilo, da so vse vstopnice na vseh terminih prodane.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 416 -

RUP – Zajem zahtev



RUP – zajem zahtev – primeri uporabe

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.

2.

3.

4.

5.

Sistem prikaže uporabniku seznam oseb Uporabnik iz seznama izbere določeno osebo Sistem prikaže podrobnosti osebe Uporabnik lahko izbere brisanje osebe (glej

Podtok A

) ali ažuriranje podatkov o osebi (glej

Podtok B

).

Sistem osveži prikaz 4A.1 Sistem izbriše podatke o osebi 4A.2 Sistem izpiše sporočilo o uspešnem brisanju podatkov o osebi

Podtok A

4B.1 Uporabnik ažurira podatke o osebi in spremembe potrdi 4B.2 Sistem izpiše sporočilo o uspešnem ažuriranju podatkov o osebi

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 417 Podtok B

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 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.

Komunikacija Kupi vstopnico Stranka RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 418 Bančni sistem

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 419 -

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 Odvisnost “vključuje” - <>:   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

Odvisnost “vključuje” Stranka RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Kupi vstopnico Rezerviraj vstopnico 420 Plačaj s kartico

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 Odvisnost “razširja” - <>:   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”).

Odvisnost “razširja” Stranka Kupi vstopnico <> Pridobi dodaten račun RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 421 -

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 Generalizacija med akterji  Prikazuje, da določen akter lahko sistem uporablja tudi na tak način kot določen drugi akter.

Generalizacija med akterji Stranka Kupi vstopnico Rezerviraj vstopnico Stranka “VIP” Prijavi bonus Preglej bonus RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 422 -

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 Generalizacija med primeri uporabe  Omogoča, da določen primer uporabe “razbijemo” na bolj podrobne primere uporabe

Generalizacija med primeri uporabe Plačaj s kartico Plačaj z bančno kartico Plačaj s kreditno kartico RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 423 -

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 Meja sistema  Mejo sistema lahko eksplicitno prikažemo s pomočjo pravokotnika

Meja sistema RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Stranka Stranka “VIP” 424 Kupi vstopnico Rezerviraj vstopnico Prijavi bonus Preglej bonus

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 Možen pristop pri načrtovanju diagrama primerov uporabe: 1. Identificiraj akterje 2. Identificiraj primere uporabe sistema 3. 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 425 -

RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

 Pogoste napake pri načrtovanju primerov uporabe: 1. Nejasno/nepravilno opredeljene meje sistema 2. Veliko število primerov uporabe na enem diagramu 3. Križanje povezav, nepreglednost diagrama 4. 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 426 -

Primer

RUP – zajem zahtev – primeri uporabe Kupi vstopnico preko spleta Stranka Rezerviraj vstopnico Plačaj preko spleta RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Stranka “VIP” Referent Prijavi bonus <> Preglej bonus Unovči bonus Uredi prireditve Dodeli stranki status“VIP” 427 Spletni plačilni sistem

RUP – Zajem zahtev

RUP – zajem zahtev – pomembni izdelki Model primerov uporabe Akterji Primeri uporabe ...

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Opisi primerov uporabe 428 Slovar Dodatne specifikacije

        

RUP – Zajem zahtev

RUP – zajem zahtev – Model primerov uporabe

Ime Kratek opis Tokovi dogodkov Diagrami aktivnosti in diagrami stanj Diagrami primerov uporabe Posebne zahteve Pred-pogoji Po-pogoji Razširitvene točke

Model primerov uporabe Akterji Primeri uporabe ...

Opisi primerov uporabe RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 429 -

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."

RAZVOJ INFORMACIJSKIH SISTEMOV

2. The system displays a blank schedule form.

©Laboratorij za informatiko 430 -

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

RUP – Zajem zahtev

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

©Laboratorij za informatiko

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

Visokošolski strokovni študij, Smer Informatika 431 -

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

RUP – zajem zahtev – dodatne specifikacije

      Funkcionalnost Uporabnost Zanesljivost Učinkovitost Podpora Omejitve pri načrtovanju

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 432 -

Razvoj po objektnem pristopu

Kje smo?

 Objektni pristop:    Osnovni principi objektne usmerjenosti; Jezik UML in proces RUP; Zajem zahtev;  Objekta analiza in načrtovanje

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 433 -

Objekta analiza in načrtovanje

RUP – namen analize in načrtovanja

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 434 -

Objekta analiza in načrtovanje

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 RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 435 -

Objekta analiza in načrtovanje

Končen izdelek analize in načrtovanja RUP – Analiza in načrtovanje – vhodni in izhodni izdelki Model načrta Model primerov uporabe Analiza in načrtovanje Slovar RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Dodatne specifikacije 436 Podatkovni model Arhitektura sistema

Objekta analiza in načrtovanje

RUP – Analiza in načrtovanje – vloge



Realizacija primera uporabe Arhitekt Model načrta RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Načrtovalec Arhitektura sistema Pregledovalec arhitekture Paket/ Podsistem Razred Pregledovalec načrta Načrtovalec PB 437 Podatkovni model

Objekta analiza in načrtovanje

RUP – Analiza in načrtovanje – koraki Arhitekt Analiza arhitekture Pregledovalec arhitekture Načrt arhitekture Analiza sočasnosti in porazdeljenosti Pregled arhitekture Načrtovalec Analiza primerov uporabe RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Načrtovanje podsistemov Načrtovanje primerov uporabe Načrtovanje razredov 438 Pregled načrta Pregledovalec načrta

Razvoj po objektnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 439 -

Objekta analiza in načrtovanje

Analiza arhitekture Slovar Dodatne specifikacije Smernice za načrtovanje Arhitektura sistema Analiza arhitekture Izbrani primeri uporabe za realizacijo Model primerov uporabe RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Poslovni model 440 Model načrta

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture

 Osnovni koraki aktivnosti analiza arhitekture sistema:    Identifikacija ključnih abstrakcij Analiza potreb po sistemskih storitvah Opredelitev arhitekturnih ravni

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 441 -

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – Identifikacija ključnih abstrakcij

 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.

Razredi analize ali ključne abstrakcije

 Vhodi:  Znanje o domeni (vključno s poslovnim modelom, če obstaja)   Zahteve Slovar

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 442 -

Objekta analiza in načrtovanje

RUP – Od razredov analize do izvedbenih elementov – komponent Analiza Načrt Izvedba RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 443 -

Objekta analiza in načrtovanje

Primer ključnih abstrakcij

 Nekaj ključnih abstrakcij s področja študijska informatike…

Študent Prijava Izpitni rok Vpis Študijski program Predmet RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 444 -

Objekta analiza in načrtovanje

Primer ključnih abstrakcij

 Povezave med identificiranimi abstrakcijami…

Študent Prijava Izpitni rok Vpis RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Študijski program 445 Predmet

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – analiza potreb po sistemskih storitvah Želena funkcionalnost Okolje implementacije Dodatne specifikacije Arhitekt Model primerov uporabe RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Arhitekt je odgovoren za izbiro ustreznih načrtovalskih vzorcev za realizacijo potrebnih sistemskih storitev (dostop do relacijske podatkovne baze, uporaba digitalnih potrdil, obvladovanje transakcij,… 446 -

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – analiza potreb po sistemskih storitvah

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 447 -

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 448 -

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 449 -

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni Aplikacijski podsistemi (Application subsystems) Poslovni podsistemi (Business specific) Vmesni nivo (Middleware) Sistemska programska oprema (System software) Ločeni aplikacijski podsistemi, ki skupaj tvorijo aplikacijski sistem. Specifične aplikacije organizacije.

Številni ponovno uporabni podsistemi, ki so specifični za aplikativna področja (npr. telekomunikacije, bančništvo itd.) Vmesni nivo sestavljajo razni pomožni podsistemi (utility classes) in sistemi, ki so od platforme neodvisni (npr. Storitve za porazdeljena in heterogena okolja) Zajema programsko opremo za dejansko infrastrukturo, npr. operacijski sistemi, vmesniki do specifičnih naprav ipd. RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 450 -

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 451 -

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 452 -

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni

 Ciklične odvisnosti so nezaželene…

A A A B B B C C A’

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 453 -

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni

 Arhitekturne plasti lahko modeliramo s pomočjo paketov in stereotipa <>

<> Application <>

Ime ravni

<> Business Services RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 454 -

Razvoj po objektnem pristopu

Kje smo?

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 455 -

Objektna analiza in načrtovanje

Analiza arhitekture Slovar Dodatne specifikacije Smernice za načrtovanje Arhitektura sistema Analiza primerov uporabe Model primerov uporabe RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Izbrani primeri uporabe za realizacijo 456 Analizirani primeri uporabe Razredi analize Model načrta (dopolnjen)

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 457 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – dopolnitev opisov primerov uporabe

 V okviru analize primerov uporabe opise posameznih primerov uporabe dopolnimo s podatki, potrebnimi za nadaljnji razvoj, ki jih že imamo na razpolago.

Sistem preveri veljavnost kreditne kartice.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 458 Sistem preveri veljavnost kreditne kartice. Pri tem se poveže s sistemom “SKK” in uporabi njegovo spletno storitev “CardCheck”.

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 459 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Model Primerov Uporabe Model Načrta

Primer Uporabe Realizacija Primera Uporabe Primer Uporabe RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Diagrami Zaporedja Diagrami sodelovanja 460 Diagrami Razredov



Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Dinamika primera uporabe mora biti v celoti dodeljena razredom, ki realizirajo ta primer uporabe

<> <> <> <> RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko <> 461 -



Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Razredi analize:

<> <> <> <> <> RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 462 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 Ikonski prikaz razredov analize:

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 463 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 Mejni razred - <>:    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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 464 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 Mejni razredi modelirajo interakcijo med okoljem in sistemom

<> <> <> <> <> RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko <> <> 465 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

  Identifikacija mejnih razredov: “en mejni razred za vsak par akter – primer uporabe” Primer:

Stranka Kupi vstopnico Bančni sistem <> ZMStrankaKupiVstopnico <> SVBančniSistem RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 466 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 467 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 Poslovni razred - <>:    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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 468 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 Poslovni razredi hranijo in upravljajo ključne podatke sistema

<> <> <> <> <> RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko <> <> 469 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 470 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 Primer:

<> Sedež <> Vstopnica Kupi vstopnico Slovar Ključne abstrakcije RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 471 <> Prireditev <> Termin <> Stranka

“Zastopnik” akterja Stranka

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov… <> ImeRazreda atribut : tip = začVrednost atribut : tip = začVrednost atribut : tip = začVrednost

V analizi se na ukvarjaj s podpisi (signaturami) atributov atribut

<> IzbirniPredmet predmetID :String=“100” začetek : Time konec: Time številoDni: Enum

Objektna analiza in načrtovanje

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

Dvigni() Račun stanje ime številka Dvigni() Položi() Osebni Varčevalni VrniObresti() Dvigni() RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 473 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 Primer:

<> Dogodek <> Prireditev <> Zborovanje <> Trening <> Tekma <> Koncert <> Film RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 474 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 475 -



Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Modelira pomensko povezavo med primerki razredov

<> Študent <> IzbirniPredmet

Enostavna povezava je predpogoj za

<> Urnik <> Predmet

Rekurzivna povezava Asociacija je strukturna povezava

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 Vloga, ki jo igra razred v povezavi

<> IzbirniPredmet <> Profesor Nosilec predmeta Vodja katedre

Ime vloge

Predpogoj <> Predmet <> Katedra

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov… glavniPredmet <> Urnik <> IzbirniPredmet dodatniPredmet <> Urnik dodaj študenta odstrani študenta <> IzbirniPredmet

Vsaka povezava igra svojo vlogo

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Števnost:

   Nedoločeno Točno ena Nič ali več (več, neomejeno)

1 0..* * 1..*

    Ena ali več Nič ali ena Določen interval Več nepovezanih intervalov

0..1

2..4

2, 4..6

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Števnost

<> Študent 1 0..* <> Urnik 0..* 0..* glavniPredmet 0..2

0..4

<> IzbirniPredmet dodatniPredmet

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Navigacija – usmerjenost povezave:

Neusmerjena

Razred1 Razred2

Razred1 vidi Razred2 in Razred 2 vidi Razred1. Drug od drugega sta odvisna.

Usmerjena

Razred1 Razred2

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

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov… <> ZMVpišiPredmet 1 1 <> KVpišiPredmet <> Urnik 0..* 0..*

Usmerjena povezava

0..4

glavniPredmet 0..2

dodatniPredmet <> IzbirniPredmet

Neusmerjena povezava

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

  Identifikacija atributov in povezav, ki modelirajo podatke poteka na enak način kot pri podatkovnem modeliranju

<>

Primer:

Stranka Ime Priimek <> Prireditev Ime Opis Trajanje <> Termin Začetek <> Vstopnica Status <> Sedež Številka Vrsta Tribuna RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 483 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 Kontrolni razred - <>:    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 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 485 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 Kontrolni razred koordinira obnašanje primera uporabe

<> <> <> <> <> RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko <> <> 486 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

  Identifikacija kontrolnih razredov: na začetku uporabimo pravilo “en kontrolni razred za vsak primer uporabe” Primer:

Stranka Kupi vstopnico Bančni sistem <> KKupiVstopnico Kupi vstopnico RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 487 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

  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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 488 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov… Model primerov uporabe Kupi vstopnico Bančni sistem Stranka Model načrta <> ZMStrankaKupiVstopnico <> KKupiVstopnico <> SVBančniSistem <> Prireditev Ime Opis Trajanje <> 1 1..* Termin Začetek 1 <> Vstopnica * Status RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 489 <> Stranka Ime Priimek <> Sedež Številka Vrsta Tribuna

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

 Vaja:  Identificirajte razrede analize, ki nastopajo v okviru določenega primera uporabe iz podane problemske domene.

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 490 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 491 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

 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

Primer Uporabe RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Diagrami Zaporedja Diagrami sodelovanja Realizacija primerov uporabe 492 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 493 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav



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 -

Objektna analiza in načrtovanje

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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 495 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav Potrebnih je več diagramov interakcije Osnovni tok Alternativni tok 1 Alternativni tok 2 Alternativni tok 3 AF3 AF1 AF2 Alternativni tok 4 Alternativni tok 5 Alternativni tok n

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

 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črtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav DIAGRAMI ZAPOREDJA - UML

Objekt, ki uporablja storitev (predaja odgovornost) Objekt, ki zagotavlja storitev (izvaja odgovornost)

Č A S :Odjemalec

Življenjska črta objekta

1: IzvediOdgovornost :Ponudnik

Rekurzivno sporočilo

1.1: IzvediDrugo Odgornost

Sporočilo

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

Fokus (aktivnost objekta)

498 -

Hierarhično številčenje sporočil

Kupec

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

:ZMStrankaKupiVstopnico :KKupiVstopnico :Prireditev :Termin :Vstopnica :Sedež :SVBančniSistem SKK 10: IzberiTermin( ) 11: VrniSeznamSedeževZaIzbranTermin( )

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 499 -

Ponavljaj za vse izbrane sedeže Ponavljaj za vse izbrane sedeže



Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

Fragmenti za prikazovanje podtokov, alternativnih tokov, zank na skupnem diagramu

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 500 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

   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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 501 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav DIAGRAMI SODELOVANJA - UML

Objekt, ki uporablja storitev (predaja odgovornost) Objekt, ki zagotavlja storitev (izvaja odgovornost) Povezava

:Odjemalec :Ponudnik 1: IzvediOdgovornost

Smer Sporočilo

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

32: PrikažiSporočiloOUspešnemNakupuZRefŠt( ) 21: ZahtevajVnosKKInImena( ) 14: PrikažiMatrikoProstihSedežev( ) 9: PrikažiPodrobnostiInTerminePredstave( ) 4: PrikažiSeznamPredstav( ) Kupec 22: VnesiImeInKK( ) 15: IzberiSedeže( ) 10: IzberiTermin( ) 5: IzberiPredstavo( ) 1: PričniNakup( ) SKK 26: IzvediTransakcijo :ZMStrankaKupiVstopnico :SVBančniSistem 23: ZaključiNakup( ) 16: RezervirajIzbraneSedeže( ) 11: VrniSeznamSedeževZaIzbranTermin( ) 6: VrniPodrobnostiPredstave( ) 2: VrniSeznamPredstav( ) :KKupiVstopnico 7: VrniPodrobnePodatekOPredstavi( ) 3: VrniSeznamPredstav( ) :Prireditev

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

27: ProdajSedežZaTermin( ) 19: RezervirajSedežZaTermin( ) 17: PreveriStatus( ) 12: VrniSeznamSedeževInNjihovStatusZaTermin( ) 8: VrniSeznamterminovZaPredstavo( )

503 -

29: VrniŠtevilkoKarte( ) 28: OznačiRezervacijoKotProdano( ) 20: KreirajRezervacijoZaTermin( ) 18: VrniStatusZaTermin( ) 13: VrniStatusZaTermin( ) :Sedež :Termin :Vstopnica



Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

Na podlagi diagrama sodelovanja razdelimo odgovornosti

Diagram sodelovanja :Odjemalec :Ponudnik // IzvediOdgovornost Diagram razredov RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Ponudnik // IzvediOdgovornost 504 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

<> ZMStrankaKupiVstopnico <> KKupiVstopnico PričniNakup () PrikažiSeznamPredstav () IzberiPredstavo () PrikažiPodrobnostiInTerminePredstave () IzberiTermin () PrikažiMatrikoProstihSedežev () IzberiSedeže () ZahtevajVnosKKInImena () VnesiImeInKK () PrikažiSporočiloOUspešnemNakupuZRefŠt () VrniSeznamPredstav () VrniPodrobnostiPredstave () VrniSeznamSedeževZaIzbranTermin () RezervirajIzbraneSedeže () ZaključiNakup () IzračunajCeno () <> SVBančniSistem IzvediTransakcijo () <> Prireditev Ime Opis Trajanje VrniSeznamPredstav () VrniPodrobnePodatekOPredstavi () <> Sedež Številka Vrsta Tribuna VrniSeznamSedeževInNjihovStatusZaTermin () PreveriStatus () RezervirajSedežZaTermin () 1..1

1..1

0..* <> Termin Začetek VrniSeznamterminovZaPredstavo ()

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

1..1

0..* 0..* <> Vstopnica Status VrniStatusZaTermin () KreirajRezervacijoZaTermin () OznačiRezervacijoKotProdano ()

505 -

0..* 1..1

<> Stranka Ime Priimek

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 506 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

<> ZMStrankaKupiVstopnico <> KKupiVstopnico PričniNakup () PrikažiSeznamPredstav () IzberiPredstavo () PrikažiPodrobnostiInTerminePredstave () IzberiTermin () PrikažiMatrikoProstihSedežev () IzberiSedeže () ZahtevajVnosKKInImena () VnesiImeInKK () PrikažiSporočiloOUspešnemNakupuZRefŠt () VrniSeznamPredstav () VrniPodrobnostiPredstave () VrniSeznamSedeževZaIzbranTermin () RezervirajIzbraneSedeže () ZaključiNakup () IzračunajCeno () <> SVBančniSistem IzvediTransakcijo () <> Prireditev Ime Opis Trajanje VrniSeznamPredstav () VrniPodrobnePodatekOPredstavi () <> Sedež Številka Vrsta Tribuna VrniSeznamSedeževInNjihovStatusZaTermin () PreveriStatus () RezervirajSedežZaTermin () 1..1

1..1

0..* <> Termin Začetek VrniSeznamterminovZaPredstavo ()

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

1..1

0..* 0..* <> Vstopnica Status VrniStatusZaTermin () KreirajRezervacijoZaTermin () OznačiRezervacijoKotProdano ()

507 -

0..* 1..1

<> Stranka Ime Priimek

?

razred brez odgovornosti

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 508 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

 Agregacija: modelira odnos celota - del

Celota/agregat del

<> Študent 1 0..* <> Urnik 0..* 0..* glavniPredmet 0..2

0..4

<> IzbirniPredmet dodatniPredmet

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

 Premislek  Kontekst, neodvisnost delov od celote?

Razred1 Razred2

asociacija

Razred1

agragacija

Razred2

Ko si v dvomih, uporabi asociacijo

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 511 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

 Kompozicija:

Razred1 Razred2

kompozicija

 Diskusija - kompozicija ali agregacija?

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko <> Študent 1 ?

0..* <> Urnik 512 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

Primera:

Kakšna je števnost?



Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

Asociacijski razred:    Razred, povezan s povezavo Vsebuje lastnosti povezave En primerek na povezavo

<> UrnikIzbirniInfo status // označi kot izbran() // označi kot neizbran() // ali je izbran?() <> 0..* Urnik 0..* dodatniPredmet 0..2

glavniPredmet 0..4

<> IzbirniPredmet <> UrnikGlavniIzbirniInfo ocena // ali je izdelal?() // vnesi oceno() // vrni oceno()



Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

Diskusija: Ali bi kje postavili kompozicijo/asociacijo?

<> Prireditev Ime Opis Trajanje VrniSeznamPredstav () VrniPodrobnePodatekOPredstavi () <> Sedež Številka Vrsta Tribuna VrniSeznamSedeževInNjihovStatusZaTermin () PreveriStatus () RezervirajSedežZaTermin () 1..1

1..1

0..* <> Termin Začetek VrniSeznamterminovZaPredstavo () 1..1

0..* 0..* <> Vstopnica Status VrniStatusZaTermin () KreirajRezervacijoZaTermin () OznačiRezervacijoKotProdano () VrniŠtevilkoKarte ()

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 515 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav Diagram sodelovanja 1: izvediOdgovornost :Odjemalec :Ponudnik

Navigacija (pogojno!)

Razredni diagram Odejmalec 0..*

Povezava

0..* Osnovni ponudniki Ponudnik izvediOdgovornost()

Povezava v diagramu sodelovanja pomeni povezavo v razrednem diagramu !

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 517 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

<> ZMStrankaKupiVstopnico <> KKupiVstopnico PričniNakup () PrikažiSeznamPredstav () IzberiPredstavo () PrikažiPodrobnostiInTerminePredstave () IzberiTermin () PrikažiMatrikoProstihSedežev () IzberiSedeže () ZahtevajVnosKKInImena () VnesiImeInKK () PrikažiSporočiloOUspešnemNakupuZRefŠt () 1..1

1..1

VrniSeznamPredstav () VrniPodrobnostiPredstave () VrniSeznamSedeževZaIzbranTermin () RezervirajIzbraneSedeže () ZaključiNakup () IzračunajCeno () 0..1

0..1

0..1

1..1

0..1

<> SVBančniSistem IzvediTransakcijo () 0..* 0..* <> Prireditev Ime Opis Trajanje VrniSeznamPredstav () VrniPodrobnePodatekOPredstavi () <> Sedež Številka Vrsta Tribuna VrniSeznamSedeževInNjihovStatusZaTermin () PreveriStatus () RezervirajSedežZaTermin () 1..1

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

1..1

0..* 0..* <> Termin Začetek VrniSeznamterminovZaPredstavo ()

518 -

1..1

0..* 0..* <> Vstopnica Status VrniStatusZaTermin () KreirajRezervacijoZaTermin () OznačiRezervacijoKotProdano () VrniŠtevilkoKarte ()

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – sistemske storitve

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 519 -

Objektna analiza in načrtovanje

 

RUP – Koraki analize primerov uporabe – sistemske storitve

Sestavi seznam vseh potrebnih sistemskih storitev Sestavi seznam razredov, ki potrebujejo sistemske storitve

Razred analize Sistemska storitev

 Opiši lastnosti sistemskih storitev

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – sistemske storitve

 Preslikava med razredi in sistemskimi storitvami Prireditev Termin Vstopnica

Razred

Sedež KKupiVstopnico

Sistemska storitev

Trajnost Trajnost Trajnost, Varnost?

Trajnost Porazdelitev

Objektna analiza in načrtovanje

 

RUP – Koraki analize primerov uporabe – sistemske storitve

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.

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – sistemske storitve

 Kakšne bi bile lahko lastnosti trajnosti za razred

Predstava

?

 Granulacija?

  Kapaciteta?

Pogostost dostopa?

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 523 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 524 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 525 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – poenotenje

 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 526 -

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – poenotenje <> <> <> <>

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe - poenotenje RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 528 -

Rezultat poenotenja razredov je enoten načrt. Pogledi VOPC še vedno ostanejo, vendar uporabljajo skupne razrede.

Objektna analiza in načrtovanje

RUP – Koraki analize primerov uporabe – poenotenje Model Načrta Dodatne Specifikacije Slovar Model Primerov Uporabe Razredi Analize

Objektna analiza in načrtovanje

Od razreda do kode

 Razredne diagrame lahko pretvorimo v kodo <> ZMStrankaKupiVstopnico PričniNakup () PrikažiSeznamPredstav () IzberiPredstavo () PrikažiPodrobnostiInTerminePredstave () IzberiTermin () PrikažiMatrikoProstihSedežev () IzberiSedeže () ZahtevajVnosKKInImena () VnesiImeInKK () PrikažiSporočiloOUspešnemNakupuZRefŠt () 1..1

<> Prireditev Ime Opis Trajanje VrniSeznamPredstav () VrniPodrobnePodatekOPredstavi () 0..* <> KKupiVstopnico 1..1

VrniSeznamPredstav () VrniPodrobnostiPredstave () VrniSeznamSedeževZaIzbranTermin () RezervirajIzbraneSedeže () ZaključiNakup () IzračunajCeno () 1..1

0..1

0..1

0..1

<> SVBančniSistem IzvediTransakcijo () 0..1

0..* <> Sedež Številka Vrsta Tribuna VrniSeznamSedeževInNjihovStatusZaTermin () PreveriStatus () RezervirajSedežZaTermin () 1..1

1..1

0..* 0..* <> Termin Začetek VrniSeznamterminovZaPredstavo () 1..1

0..* 0..* <> Vstopnica Status VrniStatusZaTermin () KreirajRezervacijoZaTermin () OznačiRezervacijoKotProdano () VrniŠtevilkoKarte ()

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 ); … RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 530 -

Razred z atributi in metodami

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) { } }

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 531 -

Podporni in globalni razredi

<> 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(); } }

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 532 -

Asociacija

Schedule Student

class Schedule { public Schedule() { } private theStudent; } class Student { public Student() { } private Schedule theSchedule; }

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 533 -

Enosmerna asociacija

Student Schedule

class Student { public Student() { } private Schedule theSchedule; } class Schedule { public Schedule() { } }

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 534 -

Vloge pri asociaciji

Professor

instructor

CourseOffering

class Professor { public Professor() {} private CourseOffering theCourseOffering; } class CourseOffering { public CourseOffering () {} private Professor instructor; }

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 535 -

Števnost asociacij

Schedule

class Schedule { public Schedule() {} private CourseOffering[] primaryCourses = new CourseOffering[4] } 0..4 primaryCourses

CourseOffering

class CourseOffering { public CourseOffering() {} }

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 536 -

Vmesni razred

0..*

Schedule

0..*

Schedule

0..* 0..4

primaryCourses 0..2

alternateCourses

CourseOffering ExaminationInfo

- grade: Char = I

Realizacija vmesnega razreda je stvar odločitve v načrtovanju

alternateCourses 0..2

CourseOffering RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko

1 0..4

ExaminationInfo

ExaminationInfo

- grade: Char = I

537 -

Vmesni razred - realizacija

0..*

Schedule

1 0..4

ExaminationInfo

ExaminationInfo

-grade: Char = I … … alternateCourses 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;

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 538 -

0..2

CourseOffering

Rekurzivna asociacija

0..*

Course

prerequisites import java.util.Vector; class Course { public Course() {} // The unbounded multiple association // is stored in a vector private Vector prerequisites; }

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 539 -

Agregacija

Schedule

0..* class Schedule { public Schedule() { } private Student theStudent; } 1

Student

import java.util.Vector; class Student { public Student() { } private Vector theSchedule; }

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko Java nima eksplicitnega konstrukta za agregacijo.

540 -

Generalizacija (dedovanje)

GroundVehicle + register()

1

Truck + tonnage: float + getTax()

class GroundVehicle { public int licenseNumber; public void register() { } } class Truck extends GroundVehicle { public float tonnage; public void getTax() { } }

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 541 -

Abstraktni razredi

Animal

{

Abstract

}

+ talk () {abstract

}

abstract class Animal { public abstract void talk(); }

Lion + talk () Tiger + talk ()

class Tiger extends Animal { public Tiger() { } public void talk() { } }

RAZVOJ INFORMACIJSKIH SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko 542 -

Poglavje 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 SISTEMOV Visokošolski strokovni študij, Smer Informatika ©Laboratorij za informatiko - 543 -

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

CIM PIM PIM → PSM x Tehnologija/platforma x PSM x Most med PSM x in PSM y PIM → PSM y Tehnologija/platforma y PSM y PSM x → K x Delujoča izvorna koda sistema Koda x Most med Kodo x in Kodo y Koda y PSM y → K y

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…

Klasičen razvoj … Zajem zahtev Analiza Načrtovanje Kodiranje … Večinoma besedilo Diagrami in besedilo Diagrami in besedilo Koda … Zajem zahtev Analiza – izdelava PIM Načrtovanje – tran. PIM v PSM Kodiranje – tran. PSM v Kodo … MDD Večinoma besedilo PIM PSM Koda

generiranje

V MDD je bistvena izdelava PIM in izbira ustreznih implementacijskih tehnologij, precej pa se zmanjša pomen klasičnega kodiranja.

Primerjava klasičnega razvoja in MDD…

 Poveča se pomen analitičnih vlog in hkrati zmanjša izdelavo / preverjanje PIM pomen vlog implementacije PSM   PIM Izbira platform, arhitektur, vzorcev, nastavitve orodja itd.

Analitik in načrtovalec PIM

na podlagi izdelkov zajema zahtev ter določi izdelkov poslovnega modeliranja izdelata model PIM. z orodjem generira  izdela

Izdelovalec PSM

s pomočjo orodja za transformiranje PIM pretvori v enega ali več modelov PSM. Pred transformacijo mora izbrati Izdelovalec PSM ciljne platforme, arhitekture, vzorce, tehnologije itd. 

Razvijalec definicij transformacij

Analitik in načrtovalec PIM je vloga, ki skrbi za izdelavo definicij transformacij za transformacijska orodja. Razvijalec def. transformacij

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:    • • • manjši pomen vlog implementacije večji pomen vlog analize Proces: • nove vloge, nova znanja 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