osnove informacijskih sistemov n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Osnove informacijskih sistemov PowerPoint Presentation
Download Presentation
Osnove informacijskih sistemov

Loading in 2 Seconds...

play fullscreen
1 / 666

Osnove informacijskih sistemov - PowerPoint PPT Presentation


  • 202 Views
  • Uploaded on

Osnove informacijskih sistemov. Univerzitetni študij Smer: programska oprema, logika in sistemi. UNIVERZA V LJUBLJANI Fakulteta za računalništvo in informatiko Doc. dr. Marko Bajec. Študijsko gradivo, verzija 1.3. Splošne informacije. Predavatelj Doc. dr. Marko Bajec, univ. dipl. inž.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Osnove informacijskih sistemov' - ermin


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
osnove informacijskih sistemov

Osnove informacijskih sistemov

Univerzitetni študij

Smer: programska oprema, logika in sistemi

UNIVERZA V LJUBLJANIFakulteta za računalništvo in informatiko

Doc. dr. Marko Bajec

Študijsko gradivo, verzija 1.3

splo ne informacije
Splošne informacije...
  • Predavatelj
    • Doc. dr. Marko Bajec, univ. dipl. inž.
    • Elektronska pošta: marko.bajec@fri.uni-lj.si
    • Informacije: http://infolab.fri.uni-lj.si/marko/
  • Asistent
    • As. Aleš Kumer, univ. dipl. inž.
    • Elektronska pošta: ales.kumer@fri.uni-lj.si

http

http

- 2 -

splo ne informacije1
Splošne informacije
  • Predavanja
    • Vsak četrtek od 11:15 do 13:00 (2 šolski uri);
  • Izpit
    • Seminarska naloga ali domače naloge (predpogoj)
    • Pisni izpit
    • Ustni izpit

- 3 -

vsebina predmeta
Vsebina predmeta
  • I. Osnovni pojmi
    • Opredelitev IS
    • Zgodovina in razvoj IS
    • Vloga IS v poslovnem sistemu
    • Vrste IS
    • Upravljanje z IT – priložnosti in izzivi
    • Poslovno okolje
    • Opredelitev sistema
    • IS kot podsistem
    • Konceptualni model IS
    • Podatek in informacija

- 4 -

vsebina predmeta1
Vsebina predmeta
  • II. Poslovne aplikacije
    • E-poslovanje
    • Več-funkcijski poslovni sistem
    • Poslovno informacijska arhitektura
    • Funkcionalni informacijski podsistemi
      • Finančni podsistem,
      • Računovodski podsistem,
      • Prodajni podsistem,
      • Proizvodni podsistem in
      • Kadrovski podsistem
    • CRM
    • ERP

- 5 -

vsebina predmeta2
Vsebina predmeta
  • III. Osnove razvoja informacijskih sistemov
    • Osnovni pojmi
    • Življenjski modeli razvoja IS
    • Metodologije razvoja IS
  • IV. Strukturni razvoj IS
    • Osnovne značilnosti strukturnega pristopa
    • Strateško načrtovanje
    • Analiza
    • Načrtovanje
    • Izvedba
    • Testiranje
    • Uvajanje

- 6 -

vsebina predmeta3
Vsebina predmeta…
  • V. Objektni razvoj IS
    • Osnovni principi objektne usmerjenosti
    • Osnove modelirnega jezika UML
    • Objektna analiza in načrtovanje
  • VI. Načrtovanje podatkovnih baz
    • Tri-nivojsko načrtovanje
    • Konceptualno načrtovanje
    • Osnove relacijskega modela in logično načrtovanje
    • Normalizacija

- 7 -

priporo ena literatura
Priporočena literatura…
  • Literatura:
    • [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] Kent Beck (1999).Extreme Programming Explained: Embrace Change, Addison-Wesley.
    • [4] Martin, R. C., Agile Software Development, Principles, Patterns, and Practices (2003), Prentice Hall

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

- 8 -

priporo ena literatura1
Priporočena literatura…
  • Literatura:
    • [5] Hoffer, J. A., George, J. F. in Valacich, J. S. (1999). Modern Systems Analysis and Design, Second edition, Addison-Wesley
    • [6] O’Brien J. in Marakas, G. M. (2006). Management Information Systems, Seventh edition, McGraw-Hill

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

- 9 -

vsebina predmeta4
Vsebina predmeta…

Poglavje II

  • Celoviti IS
  • Elektronsko poslovanje
  • Poslovni sistemi

Poglavje III

Poglavje I

  • Osnovni pojmi
  • Metodologije
  • UML
  • Agilni pristopi
  • Opredelitev IS
  • Konceptualni model IS
  • Komponente IS

- 10 -

slide11
Poglavje I

Osnovni pojmi

  • Opredelitev IS
  • Zgodovina in razvoj IS
  • Vloga IS v poslovnem sistemu
  • Vrste IS
  • Upravljanje z IT – priložnosti in izzivi
  • Poslovno okolje
  • Opredelitev sistema
  • IS kot podsistem
  • Konceptualni model IS

- 11 -

informacijski sistem
Informacijski sistem…
  • Definicija:
    • Informacijski sistem lahko opredelimo kot množico medsebojno odvisnih komponent (strojna oprema, programska oprema, ljudje), ki zbirajo, procesirajo, hranijo in porazdeljujejo podatke in s tem podpirajo delavne procese v organizaciji [5].
  • Ločimo formalne in neformalne IS
  • IS je lahko računalniško podprt

- 12 -

vloga is v poslovnem sistemu
Vloga IS v poslovnem sistemu

Strateška raven

Taktična raven

Operativna raven

- 14 -

lastnosti dobrega is
Lastnosti dobrega IS
  • Lastnosti “dobrega” informacijskega sistema:
    • Zagotavlja podatke, iz katerih lahko zaposleni na različnih ravneh v združbi pridobivajo informacije, ki jih potrebujejo pri svojem delu.
    • Daje podlago tako za reševanje vsakodnevnih vprašanj kot tudi za izvajanje upravljavskih ukrepov ter sprejemanje strateških odločitev.
    • Je usklajen s poslovnim sistemom!

- 15 -

analiza poslovnega sistema

STRANKE

IZDELKI

POSLOVNI PROCESI

UDELEŽENCI

PODATKI

TEHNOLOGIJA

Analiza poslovnega sistema

ARHITEKTURA

KONTEKST

UČINKOVITOST

TVEGANJE

INFRASTRUKTURA

- 16 -

strate ko planiranje informatike
Strateško planiranje 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

- 17 -

primer is v izobra evalnem podjetju
Primer IS v izobraževalnem podjetju…
  • Podjetje se ukvarja z izvajanjem računalniških tečajev. IS v podjetju daje podlago za reševanje vprašanj, kot so:
  • Vsakodnevna vprašanja:
    • Je Janez Novak prijavljen na tečaj Windows XP, ki se prične naslednji teden?
    • Je podjetje MIX d.o.o. plačalo račun za svojih sedem udeležencev tečaja iz prejšnjega tedna?
    • Kdo so udeleženci tečaja Visual Studio, ki se prične jutri?

- 18 -

primer is v izobra evalnem podjetju1
Primer IS v izobraževalnem podjetju
  • Upravljavska vprašanja:
    • Je prijavljenih za tečaj JBuilder dovolj, da je izvedba tečaja upravičena?
    • Kakšen je bil dobiček s tečajem, ki je bil izveden v Mariboru?
    • Kateri tečaji so bili v zadnjem letu najbolj donosni?
  • Strateška vprašanja:
    • Bi bilo smiselno dvigniti cene tečajev?
    • Je smiselno pripravljati nadaljevalne tečaje?
    • Informatika je v krizi. Je smiselno razmišljati o dodatni dejavnosti?

- 19 -

vrste is
Vrste IS

Podpora

Poslovanju

Podpora

odločanju

- 20 -

druge kategorije is
Druge kategorije IS…
  • Ekspertni sistemi
    • Sistemi, ki temeljijo na bazi znanja in so namenjen reševanju specifičnih problemov iz realnega sveta
  • Sistemi za upravljanje z znanjem
    • Sistemi, ki temeljijo na bazi znanja in omogočajo izdelavo, urejanje in širjenje poslovnega znanja znotraj združbe

- 21 -

druge kategorije is1
Druge kategorije IS
  • Strateški informacijski sistemi
    • Podpirajo strateško upravljanje poslovnih sistemov za doseganje konkurenčne prednosti (ključni izdelki, storitve in poslovni procesi)
  • Funkcionalni informacijski podsistemi
    • Vključuje aplikativne sisteme, ki podpirajo osnovne poslovne funkcije (funkcionalna področja)

- 22 -

upravljanje z it izzivi in prilo nosti
Upravljanje z IT – izzivi in priložnosti…

Poslovni sistem

Strategije / Procesi / Struktura / Kultura

  • Poslovni / IT izzivi
  • Hitrost in prilagodljivost razvojnih, proizvodnih in dostavnih ciklov
  • Prenova in med-funkcijsko povezovanje poslovnih procesov z uporabo internetnih tehnologij
  • Vpeljava e-poslovanja in e-trgovanja v strategijo, procese, strukturo in kulturo podjetja

- 23 -

upravljanje z it izzivi in prilo nosti1
Upravljanje z IT – izzivi in priložnosti…

Informacijska tehnologija

  • Poslovni / IT razvoj
  • Uporaba interneta, intraneta, ekstraneta in spleta, kot primarno IT infrastrukturo
  • Širitev uporabe spletnih tehnologij na zaposlene, stranke in dobavitelje
  • Omrežno računalništvo na globalnem nivoju, sodelovanje in sistemi za podporo odločanju

- 24 -

upravljanje z it izzivi in prilo nosti2
Upravljanje z IT – izzivi in priložnosti

Poslovna vrednost

  • Poslovni / IT cilji
  • Strankam ponuditi pravo stvar ob pravem času za najnižjo ceno
  • Uskladitev proizvajalnega in poslovnega procesa z dobavitelji in kupci
  • Povezovanje z dobavitelji in distributerji na področju prodaje

- 25 -

opredelitev sistema
Opredelitev sistema
  • Sistem je celota, ki se sestoji iz več komponent ali podsistemov in množice povezav med njimi.
  • Sisteme lahko razdelimo v tri temeljne skupine:
    • Naravni sistemi: iz naravnih sestavin, delujejo po naravnih zakonitostih, za naravne smotre; uravnavajo se sami;
    • Tehnični sistemi: iz naravnih snovi snuje človek, uporabljajo naravne zakonitosti, delujejo za cilje organizacije; krmiljenje je avtomatizirano, samodejno;
    • Organizacijski sistemi: snuje človek iz naravnih in tehničnih sistemov; delujejo po načelih in predpisih za smotre in cilje organizacije; krmiljenje je zavestno – iz človekove volje.
  • S sistemi se ukvarja teorija sistemov

- 27 -

shema sistema
Shema sistema

SISTEM

Komponenta 1

OKOLJE

Komponenta 2

vhod

izhod

Komponenta 3

Komponenta n

Lastnosti sistema

  • Vsaka komponenta je za sistem pomembna – obstoj in funkcija komponente vplivata na obstoj in funkcijo celotnega sistema.
  • Nobena komponenta ni izolirana.
  • Sistem s svojo funkcijo vpliva na funkcijo komponente.

- 28 -

sinergija procesov v poslovnem okolju
Sinergija procesov v poslovnem okolju

Materija

Podatki o temeljnih procesih

Ukrepi, usmeritve

informacije

- 30 -

konceptualni model is klju ni viri
Konceptualni model IS - ključni viri…
  • Zaposleni
    • Informatiki (sistemski analitiki, razvijalci programske opreme, sistemski operaterji)
    • Uporabniki (vsi, ki uporabljajo IS)
  • Strojna oprema
    • Strojna oprema
    • Pomnilniki

- 32 -

konceptualni model is klju ni viri1
Konceptualni model IS - ključni viri…
  • Programska oprema in postopki
    • Sistemska programska oprema (operacijski sistem…)
    • Aplikacije (podpora poslovnim funkcijam oziroma procesom)
    • Postopki oziroma navodila uporabnikom IS (postopki za zajem podatkov, postopki za odpravljanje napak, postopki za razdeljevanje plačilnih list…)

- 33 -

konceptualni model is klju ni viri2
Konceptualni model IS - ključni viri
  • Podatkovni viri
    • O izdelkih, o strankah, o zaposlenih, o sredstvih...
  • Omrežja
    • Komunikacijski kanali, dostopne točke, nadzorni sistemi…

- 34 -

konceptualni model is aktivnosti
Konceptualni model IS - aktivnosti…
  • Vhod
    • Zajem in priprava podatkov
    • Primer: odčitavanje črtnih kod, RFID
  • Obdelava
    • Obdelava podatkov (računanje, primerjanje, sortiranje, agregiranje…)

- 35 -

konceptualni model is aktivnosti1
Konceptualni model IS - aktivnosti…
  • Izhod
    • Posredovanje rezultatov obdelav (informacij) uporabnikom
    • Osnovni cilj informacijskega sistema je pridobivanje “informacij” za uporabnike
    • Primeri:
      • Poročila uprave in ostala poslovna dokumentacija v tekstovni in grafični obliki,
      • Zvočni zapisi.

- 36 -

konceptualni model is aktivnosti2
Konceptualni model IS - aktivnosti…
  • Shranjevanje podatkov
    • Podatki se shranijo v podatkovno bazo za kasnejšo uporabo
    • Predstavlja eno izmed ključnih komponent IS
  • Nadzor
    • Nadzor zmogljivosti sistema
    • Odkrivanje ozkih grl

- 37 -

podatek in informacija
Podatek in informacija
  • Podatek in informacija sta besedi, ki označujeta različna pojma.

- 38 -

podatek in informacija1
Podatek in informacija

Podatek

Podatek je predstavitev informacije na formaliziran način, ki je primeren za komunikacijo, interpretacijo ali obdelavo (s strani človeka ali stroja). Predstavimo ga lahko s pomočjo simbolov ali analognih veličin, ki ji je pripisan, ali se ji lahko pripiše nek pomen.

Informacija

Informacija je znanje, ki se nanaša na objekte, kot so dejstva, dogodki, stvari, procesi ali ideje, vključno s koncepti, ki imajo v okviru nekega konteksta določen pomen (ISO).

- 39 -

podatek in informacija2
Podatek in informacija
  • Informacijska enačba
    • Informacija je novo spoznanje, ki ga človek doda svojemu poznavanju sveta. Odnos med informacijo, podatki, časom in interpretatorjevim znanjem predstavlja informacijska enačba:
      • I – informacija, ki jo posredujejo podatki
      • i – informacijska funkcija
      • D – podatki
      • S – prejemnikovo znanje
      • t – čas, ki je na voljo prejemniku za interpretacijo podatkov

Borje Langefors

I = i (D, S, t)

- 40 -

podatek in informacija3
Podatek in informacija
  • Zaključki:
    • Podatki niso informacija
    • Podatki ne vsebujejo informacije
    • Podatki posredujejo informacijo prejemniku, katerega znanje je konsistentno z izbrano predstavitvijo podatkov in modelom sveta, na katerega se nanašajo.
    • Če je količina podatkov tako velika, da se jih v času, ki je na voljo za ukrepanje na njihovi osnovi, ne da interpretirati, se lahko zgodi, da s podatki ni posredovana nobena informacija.

- 41 -

slide42
Poglavje II

Poslovne aplikacije

  • E-poslovanje
  • Več-funkcijski poslovni sistem
  • Poslovno informacijska arhitektura
  • Funkcionalni informacijski podsistemi
  • CRM
  • ERP

- 42 -

e poslovanje
E-poslovanje

E-business

E - poslovanje

  • E-poslovanje se lahko izvaja:
    • med podjetji (B2B),
    • med podjetjem in partnerji,
    • med podjetjem in strankami (B2C).

S terminom e-poslovanje označujemo uporabo informacijskih tehnologij in omrežij (internet, intranet, ekstranet…) za podporo elektronskemu trgovanju, podjetniškemu komuniciranju in sodelovanju ter spletnim poslovnim procesom.

- 43 -

ve funkcijski poslovni sistem
Več-funkcijski poslovni sistem

Cross-functional enterprise systems

  • Presegajo meje tradicionalnih poslovnih funkcij in se odpirajo navzven;
  • Stranke, dobavitelji, partnerji in zaposleni postajajo pomemben člen poslovnih procesov;
  • Prenova in izboljšanje ključnih poslovnih procesov.

- 44 -

poslovno informacijska arhitektura
Poslovno informacijska arhitektura…
  • ERP – Integriran poslovni informacijski sistem
    • zagotoviti učinkovite interne poslovne procese na področju proizvodnje, razpečave (distribucije) in financ
  • CRM – Upravljanje odnosov s strankami
    • pridobiti in zadržati dobičkonosne stranke
    • trženje, prodaja, podpora

EnterpriseResourcePlanning

CustomerRelationshipManagement

- 45 -

poslovno informacijska arhitektura1
Poslovno informacijska arhitektura…
  • PRM – Upravljanje odnosov s partnerji
    • pridobiti in zadržati partnerje, ki lahko povečajo prodajo in razpečavo (distribucijo) izdelkov ali storitev podjetja
  • SCM – Upravljanje oskrbovalne verige
    • razviti učinkovite procese iskanja virov in nabave izdelkov ter storitev potrebnih za poslovanje

Partner RelationshipManagement

SupplyChainManagement

- 46 -

poslovno informacijska arhitektura2
Poslovno informacijska arhitektura…
  • KM – Upravljanje z znanjem
    • zaposlenim zagotoviti ustrezna odločitvena orodja in orodja, ki podpirajo skupinsko delo

Upravljanje z znanjem

- 47 -

funkcionalni informacijski podsistemi
Funkcionalni informacijski podsistemi…
  • S pojmom sistem za upravljanje s poslovnimi funkcijami označimo nabor aplikativnih sistemov, ki v podjetju podpirajo
    • finančno,
    • računovodsko,
    • prodajno,
    • proizvodno in
    • kadrovsko poslovno funkcijo

- 49 -

prodajni podsistem
Prodajni podsistem…
  • Prodajni podsistem je odgovoren za načrtovanje, nadzor in obdelavo transakcij povezanih s prodajno funkcijo (upravljanje prodaje, oglaševanje, promocije…)

- 51 -

proizvodni podsistem
Proizvodni podsistem
  • Proizvodni podsistem skrbi za načrtovanje, nadzor in izvajanje proizvodnega procesa.
  • Osnovni koncepti:
    • CIM (Computer-IntegratedManufacturing)Računalniško podprta proizvodnja
    • CAM (Computer-AidedManufacturing)Računalniško podprto krmiljenje strojev in naprav
    • CAPP (Computer-AidedProcessPlanning)Računalniško podprta izdelava tehnoloških postopkov
    • CAD (Computer-AidedDesign)Računalniško podprto konstruiranje

- 53 -

kadrovski podsistem
Kadrovski podsistem…
  • Kadrovski podsistem podpira procese namenjene upravljanju s kadri oziroma zaposlenimi:
    • pridobivanje kadrov,
    • izbiranje in zaposlovanje novih kadrov,
    • razporeditev na delovna mesta in ocena uspešnosti,
    • usposabljanje
    • načrtovanje kariere

- 55 -

ra unovodski podsistem
Računovodski podsistem…
  • Računovodski podsistem podpira:
    • evidentiranje in izdelavo poročil o poslovnih transakcijah
    • sledenje toku sredstev skozi podjetje
    • izdelavo finančnih poročil (izkazov stanja)
  • Računovodski podsistem zagotavlja informacije potrebne za načrtovanje in vodenje poslovnih dejavnosti

- 57 -

temeljni ra unovodski aplikativni sistemi
Temeljni računovodski aplikativni sistemi…

Plače

Obdelava naročil

Glavna knjiga

Obvladovanje

zalog

Obveznosti iz

poslovanje

Terjatve

- 59 -

temeljni ra unovodski aplikativni sistemi1
Temeljni računovodski aplikativni sistemi…
  • Obdelava naročil
    • zajem in obdelava naročil strank
    • priprava podatkov za:
      • aplikativni sistem za obvladovanja zalog,
      • aplikativni sistem za terjatve
  • Obvladovanje zalog
    • obdelava podatkov o stanju zalog
    • priprava podatkov za:
      • dostavo,
      • ponovna naročila

- 60 -

temeljni ra unovodski aplikativni sistemi2
Temeljni računovodski aplikativni sistemi…
  • Terjatve
    • evidenca zneskov dolga strank
    • priprava:
      • faktur,
      • mesečnih izkazov,
      • poročil o vodenju kreditov
  • Obveznosti iz poslovanja
    • evidenca nakupov, dolgov in izvedenih plačil dobaviteljem
    • priprava:
      • poročilo o upravljanju z denarnimi sredstvi

- 61 -

temeljni ra unovodski aplikativni sistemi3
Temeljni računovodski aplikativni sistemi
  • Plače
    • evidenca dela zaposlenih in podatkov o nadomestilih
    • priprava:
      • izplačil plač,
      • dokumentov in poročil plačilne liste
  • Glavna knjiga
    • združevanje podatkov iz drugih računovodskih sistemov
    • priprava:
      • periodičnih izkazov stanja,
      • poslovnih poročil

- 62 -

finan ni podsistem
Finančni podsistem…
  • Finančni podsistem podpira:
    • upravljane s financami poslovnega sistema
    • razporejanje in nadzor finančnih virov
  • Upravljanje s finančnimi viri obsega:
    • upravljanje z denarnimi sredstvi in vrednostnimi papirji
    • načrtovanje proračunskih sredstev
    • finančno napovedovanje
    • finančno planiranje

- 63 -

crm upravljanje odnosov s strankami
CRM – Upravljanje odnosov s strankami

CustomerRelationshipManagement

  • CRM je poslovni aplikativni sistem, ki je v celoti osredotočen na stranko.
  • CRM združuje avtomatizacijo procesov prodaje, neposredno trženje, upravljanje z računi, upravljanje z naročili in podporo strankam
  • Primarna cilja CRM:
    • Podjetju oziroma zaposlenim zagotoviti enoten in celovit pogled nad vsemi podatki o strankah
    • Strankam omogočiti enoten in celovit pogled na podjetje

- 65 -

crm upravljanje odnosov s strankami1
CRM – Upravljanje odnosov s strankami

Temeljni sklopi CRM

  • Upravljanje s stiki in računi
    • Zajem in sledenje vseh stikov stranke s podjetjem
  • Prodaja
    • Prodajnemu osebju zagotavlja potrebna programska orodja in podatke za učinkovito prodajo izdelkov
    • Zagotavlja hiter dostop do podatkov o strankah (pretekli nakupi, specifične zahteve, potencialna področja zanimanja…)

- 66 -

crm upravljanje odnosov s strankami2
CRM – Upravljanje odnosov s strankami

Temeljni sklopi CRM

  • Trženje in izpolnitev
    • Omogoča pripravo in izvedbo oglaševalskih akcij ter analizo odzivov nanje
    • Zagotavlja hiter odziv na zahteve strank
  • Podpora
    • Podpornemu osebju zagotavlja programska orodja in podatke za učinkovito izvajanje podpornih aktivnosti
  • Zadržanje in zvestoba
    • Omogoča identifikacijo in nagrajevanje najzvestejših in naj-dobičkonosnejših strank

- 67 -

crm upravljanje odnosov s strankami3
CRM – Upravljanje odnosov s strankami

Prednosti

  • Omogoča identifikacijo najboljših strank;
  • Omogoča prilagajanje in personifikacijo produktov in storitev skladno z zahtevami, željami in navadami strank;
  • Stranki omogoča enako izkušnjo neodvisno od mesta oziroma načina dostopa (neposredno v prodajalni, prek spleta, telefona…)

- 70 -

crm upravljanje odnosov s strankami4
CRM – Upravljanje odnosov s strankami

Pasti

  • CRM ne zagotavlja uspeha
    • Preko 50% CRM projektov ne izpolni začetnih pričakovanj
    • 20% implementacij CRM je škodovalo odnosu z obstoječimi dolgoletnimi strankami
  • Glavna razloga za neuspeh sta:
    • Pomanjkanje razumevanja
    • Nezadostna priprava

- 71 -

crm upravljanje odnosov s strankami5
CRM – Upravljanje odnosov s strankami

Trendi

  • Operativen CRM
    • Stranki olajša komunikacijo s podjetjem (telefon, faks, e-pošta, klepet, mobilne naprave)
  • Analitični CRM
    • Omogoča natančno analizo in napovedovanje navad, vrednot in dobičkonosnosti strank

- 72 -

crm upravljanje odnosov s strankami6
CRM – Upravljanje odnosov s strankami

Trendi

  • Sodelovalni CRM
    • Poenostavlja načine interakcije in sodelovanja s strankami, dobavitelji in partnerji
  • CRM Portal
    • Vsem uporabnikom omogoča dostop do potrebnih orodij in informacij glede na njihove vloge in zahteve.

- 73 -

erp integriran is
ERP – Integriran IS

EnterpriseResourcePlanning

  • Integrirana več funkcijska programska oprema, ki s prenovo proizvodnih, razpečevalskih (distribucijskih), finančnih, kadrovskih in drugih osnovnih poslovnih procesov omogoča večjo učinkovitost, prilagodljivost in donosnost podjetja
  • ERP je tehnološka hrbtenica e-poslovanja

- 74 -

erp integriran is1
ERP – Integriran IS

Temeljni sklopi ERP

- 75 -

erp integriran is2
ERP – Integriran IS

Nekateri ključni procesi ERP

- 76 -

erp integriran is3
ERP – Integriran IS

Primer ERP – ColgatePalmolive

- 77 -

erp integriran is4
ERP – Integriran IS

Prednosti vpeljave ERP

  • Kakovost in učinkovitost
    • ERP je ogrodje, ki služi kot osnova za integracijo in izboljšanje internih poslovnih procesov
    • Izboljšanje kvalitete in učinkovitosti proizvodnje, razpečave (distribucije) in strežbe strank
  • Zmanjšanje stroškov
    • Opazno zmanjšanje stroškov na področju obdelave transakcij in IT podpore (programska, strojna in informacijska podpora)

- 78 -

erp integriran is5
ERP – Integriran IS

Prednosti vpeljave ERP

  • Podpora odločanju
    • ERP zagotavlja hiter in agregiran dostop do ključnih informacij o stanju in uspehu podjetja in tako omogoči vodstvu sprejemanje boljših predvsem pa pravočasnih odločitev
  • Poslovna agilnost
    • Vpeljava ERP sistema podre ločnice med poslovnimi procesi, informacijskimi sistemi in viri informacij tako na oddelčnem, kot tudi na funkcijskem nivoju
    • Z ERP se vzpostavi prilagodljiva organizacijska struktura, ki se je sposobna učinkovito spoprijeti z novimi poslovnimi izzivi

- 79 -

erp integriran is6
ERP – Integriran IS

Stroški vpeljave ERP

- 80 -

erp integriran is7
ERP – Integriran IS

Trendi

  • Podcenjevanje kompleksnosti načrtovanja in razvoja ERP sistema s strani vodstva in IT strokovnjakov;
  • Zapostavljanje ključnih uporabnikov v procesu načrtovanja in razvoja;
  • Neustrezen obseg usposabljanja;

- 81 -

erp integriran is8
ERP – Integriran IS

Trendi

  • Prehiter prehod na nov sistem;
  • Napake pri pretvarjanju oziroma pri uvozu podatkov in pri testiranju;
  • Zanašanje na trditve in obljube ponudnikov rešitev ERP in njihovih zastopnikov brez ustreznega predhodnega (neodvisnega) testiranja;

- 82 -

slide83
Poglavje III

Osnove razvoja informacijskih sistemov

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

- 84 -

kaj nas zanima pri razvoju is
Kaj nas zanima pri razvoju IS?...
  • V okviru razvoja IS nas zanima, kako razviti računalniške rešitve, ki bodo čim bolje podprle delovanje IS.
  • V okviru razvoja IS se ukvarjamo z:
    • Razvojem računalniške rešitve
    • Nabavo ustrezne strojne opreme
    • Namestitvijo sistemske programske opreme
    • Uvedbo rešitve
    • Vzdrževanjem rešitve

- 85 -

kaj nas zanima pri razvoju is1
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?

- 86 -

razvoj is in vrste is
Razvoj IS in vrste IS
  • Pristop k razvoju IS je odvisen tudi od vrste IS.
  • Nekatere vrste IS zahtevajo specifične pristope:
    • Ekspertni sistemi
    • Odločitveni sistemi
    • Sistemi za podporo delovnim procesom
  • Največ napora gre še vedno za razvoj IS za podporo operativnem delovanjuPS.

- 87 -

sinonimi za ra unalni ke programe
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

- 88 -

ivljenjski modeli razvoja is

P1.2 – Življenjski modeli razvoja IS

Življenjski modeli razvoja IS…
  • Razvoj IS zajema številna opravila, navadno razdeljena v faze:
    • Analiza
    • Načrtovanje
    • Implementacija
    • Testiranje
    • Uvedba
    • Vzdrževanje
  • Življenjski model razvoja IS (SDLC*) pove, v kakšnem sosledju in na kakšen način si v okviru razvoja IS sledijo posamezne faze.

Kot večina razvojnih procesov sledi tudi

razvoj IS določenemu življenjskemu ciklu

oziroma razvojnemu modelu, ki določa

zaporedje faz razvoja.

* SDLC - System Development Life Cycle

- 89 -

ivljenjski modeli razvoja is1
Ž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.

- 90 -

zaporedni ali slapovni model

testiranje

Načrtovanje

Spec.

zahtev

Izvedba

Načrt

Uvedba

Koda

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

čas

- 91 -

zaporedni ali slapovni model1
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.

- 92 -

zaporedni ali slapovni model2
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.

- 93 -

zaporedni ali slapovni model3
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.

- 94 -

iterativni model
Iterativni model…
  • Razvit kot odziv na pomanjkljivosti slapovnega pristopa.
  • Faze razvoja izvajamo v več iteracijah.

Iteracija

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

- 95 -

iterativni model1
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.

- 96 -

iterativni model2
Iterativni model…

testiranje

Iteracija #1

Analiza

Načrtovanje

Izvedba

Uvedba

testiranje

Iteracija #2

Učenje in

izkušnje

Analiza

Načrtovanje

Izvedba

Uvedba

izdelki

Iteracija #3

izdelki

Učenje in

izkušnje

Analiza

čas

Tipično trajanje ene iteracije: 7 do 14 dni

- 97 -

iterativni model3
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.

- 98 -

planiranje na makro in mikro ravni

S

R1

R1

I1

I4

I2

I3

I2

I1

R2

R2

R3

E

cca 2weeks

cca 2-4 months

Project

start

Project

end

Miniature milestones –

task list

SALSD

Requirements

Planiranje na makro in mikro ravni

1. Release Planning

2. Iteration Planning

3. Task Planning

?

- 99 -

iterativni model4
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

- 100 -

iterativni model5
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.

- 101 -

prototipni model
Prototipni model…
  • Gre za različico iterativnega modela.
  • Temelji na izdelavi prototipov in njihovi postopni izboljšavi, dokler ne dosežemo zadovoljive kakovosti.

Prototip

Prototip označuje predhodno izdelane in navadno

še nepopolne različice sistema ali dela sistema.

- 102 -

prototipni model1

Iteracije

(evoluativni razvoj)

Prototipni model

Analiza

problema

Začetne

zahteve

Delovni

prototip

Razvoj

prototipa

Problemi,

Napaka,

pomanjkljivosti

Uporaba in

testiranje

prototipa

Nov

prototip

Revizija in

Izboljšava

prototipa

Nove zahteve

- 103 -

inkrementalni model
Inkrementalni model…
  • Temelji na postopni gradnji celotne IR in sprotni predaji posameznih inkrementov uporabniku.
  • Ne razvijamo celotne IR hkrati. Omejimo se na posamezen sklop, ki ga razvijemo v celoti in predamo uporabniku.

Inkrement

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

- 104 -

inkrementalni model1
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.

- 105 -

inkrementalni model2
Inkrementalni model…

Uvedba in

testiranje

celotnega

sistema

Klasičen razvoj

Razvoj celotne IR

Inkrementalni razvoj

Razvoj in predajaprvega sklopa IR

Razvoj in predajadrugega sklopa IR

Razvoj in predajatretjega sklopa IR

Inkrement #1

Inkrement #2

Inkrement #3

čas

Uvedba in

testiranje

sklopa

Uvedba in

testiranje

sklopa

Uvedba in

testiranje

sklopa

- 106 -

inkrementalni model3
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.

- 107 -

inkrementalni model4
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.

- 108 -

inkrementalni model5
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

- 109 -

inkrementalni model6
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.

- 110 -

inkrementalni model7
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.

- 111 -

kaj je metodologija razvoja is

P1.3 – Metodologije razvoja IS

Metodologija

Proces

Standard

Orodje

Skrito znanje

Izkušnja

Filozofija

Tehnika

Kaj je metodologija razvoja IS?
  • Nekaj definicij:
    • Metodologija je priporočena zbirka filozofij, faz, postopkov, pravil, tehnik, orodij, dokumentacije, upravljanja in izobraževanja za razvijalce IS (Maddison).
    • Metodologija razvoja IS je priporočen način razvoja IS, ki temelji na filozofiji in množici principov (Avison, 2003).
    • Metodologija je množica dogovorov (konvencij), s katerimi se (projektna) skupina/organizacija strinja (Cockburn, 2002).
    • Metodologija je vse kar redno delamo, da bi dosegli končni rezultat – delujoča PO pri končnem uporabniku (Cockburn, 2002).

- 112 -

kaj je metodologija razvoja is1
Kaj je metodologija razvoja IS?

ISlovar

  • Iz terminološkega slovarja:
    • METODOLOGIJA: skupek metod, postopkov in standardov, ki sestavljajo zaključeno celoto pri izvajanju inženirskih pristopov k razvoju produkta.
    • METODA: seznam postopkov in pravil za izvedbo določene naloge.
    • METODOLOGIJA RAZVOJA IS: postopen način razvoja informacijskega sistema, ki vključuje uporabo različnih tehnik in orodij, celovit v smislu korakov življenjskega cikla razvoja

- 113 -

zgodovina metodologij
Zgodovina metodologij…
  • Obdobje pred pojavom metodologij (do zgodnjih 1970)
    • Ni formalnih metodologij, poudarek na reševanju tehničnih problemov, ključna vloga je programer
  • Zgodnje obdobje metodologij (do zgodnjih 1980)
    • SDLC, tehnike podatkovnega in procesnega modeliranja, večji poudarek na zajemu zahtev, analizi in načrtovanju
    • Royce, Boehm, Codd

- 115 -

zgodovina metodologij1
Zgodovina metodologij
  • Obdobje metodologij (do sredine/konca 1990)
    • iterativni in inkrementalni razvoj, RAD, objektna usmerjenost, večanje teže metodologij, strateško načrtovanje
    • Booch, Rumbaugh, Jacobson, Martin, Yourdon, Gamma
  • Obdobje ponovne ocenitve metodologij (danes)
    • kritika težkih metodologij, lahke metodologije, spletne aplikacije, nove tehnologije, hitro spreminjanje zahtev, trend agilnosti
    • Beck, Ambler, Cockburn, Highsmith

Agilnost

- 116 -

metodologija kot sociolo ka komponenta
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.

- 117 -

formalizacija metodologij
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,...

- 118 -

dojemanje metodologij

Formalizirana

metodologija

Postopki, tehnike,

smernice,...

Je osnova za

razumevanje

metodologije

Je osnova za

formalizacijo

metodologije

Neformalna

metodologija

Dojemanje

metodologije,

znanje, izkušnje,

principi,

ideali

Je osnova za

spremembo

dojemanja

metodologije

Je osnova za

uporabo

metodologije

Uporaba

Metodologije

Izkušnje,

nove ideje,

znanje

Dojemanje metodologij

- 119 -

ponudba komercialnih metodologij
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,…)

- 120 -

vrste metodologij
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.

- 121 -

delitev glede na te o metodologije
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.

- 123 -

delitev glede na ute itev metodologije
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

- 124 -

pojem agilnosti

Agilnost

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

- 125 -

principi agilnih metodologij
Principi agilnih metodologij…
  • Neposredna komunikacija – najboljši način za izmenjavo informacij.

- 127 -

principi agilnih metodologij2
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.

- 129 -

principi agilnih metodologij4
Principi agilnih metodologij
  • Odkloni od načrtovane rešitve nas vodijo k pravi rešitvi.

- 131 -

izbira metodologije
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

- 132 -

modeli za klasifikacijo metodologij
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,

- 133 -

modeli za klasifikacijo metodologij1
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.

- 134 -

izbira metodologije1
Izbira metodologije…

Izbira glede na lastnosti projekta

  • Primer modela za klasifikacijo projektov

- 135 -

izbira metodologije2
Izbira metodologije…

Obseg metodologije

  • Obseg nekaterih komercialnih metodologij

- 136 -

izbira metodologije3
Izbira metodologije…

Izbira glede na podprte življenjske cikle

- 137 -

izbira metodologije4
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

- 138 -

uporaba metodologij v praksi
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.

- 139 -

slide139
Poglavje IV

Strukturni razvoj

  • Osnovne značilnosti strukturnega pristopa
  • Primer strukturne metodologije
  • Strateško načrtovanje
  • Analiza
  • Načrtovanje
  • Izvedba
  • Testiranje
  • Uvajanje

- 140 -

strukturni razvoj
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”.

- 141 -

primer strukturne metodologije
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.

- 142 -

informacijski in eniring ie
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.

- 143 -

informacijski in eniring ie1
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.

- 144 -

informacijski in eniring ie2

KAJ

KAKO

PODATKI

AKTIVNOSTI

Informacijski inženiring – IE

Glavne faze IE

  • IE v grobem zajema štiri faze:
    • Strateško planiranje
    • Analiza
    • Načrtovanje
    • Izvedba
  • IE posebej obravnava podatke, posebej aktivnosti

Planiranje

Analiza

Načrtovanje

Izvedba

- 145 -

strate ko planiranje informatike sp
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

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

- 146 -

strate ko planiranje informatike sp1
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.

- 147 -

strate ko planiranje informatike sp2
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.

- 148 -

strate ko planiranje informatike sp3
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.

- 149 -

strate ko planiranje informatike sp4

1992

Osnovna različica

Body of Knowledge

Prilagojene različice

Priročnik

2006

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.

- 150 -

strate ko planiranje informatike sp5

3-4 mesece

Strateško planiranje informatike – SP

Shema procesa izdelave SP

  • Proces SP zajema 6 postopkov:
    • Pregled in analiza obstoječega stanja;
    • Opredelitev poslovno-informacijske arhitekture;
    • Opredelitev informacijske vizije;
    • Opredelitev projektov;
    • Izdelava akcijskega načrta;
    • Spremljanje izvajanja in vzdrževanje strateškega plana.

151

- 151 -

strate ko planiranje informatike sp6
Strateško planiranje informatike – SP

Postopki pri strateškem planiranju

- 152 -

strate ki plan razvoja informatike
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!

- 153 -

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

- 154 -

razvoj po strukturnem pristopu1
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;
    • Uvajanje
    • Vzdrževanje.

- 155 -

razvoj po strukturnem pristopu2
Razvoj po strukturnem pristopu

Kje smo?

  • Postopki strukturnega pristopa:
    • Zajem in specifikacija zahtev;
    • Analiza;
    • Načrtovanje;
    • Izvedba;
    • Testiranje;
    • Uvajanje
    • Vzdrževanje.

- 156 -

zajem in specifikacija zahtev
Zajem in specifikacija zahtev

Opredelitev in namen

  • Zajem in specifikacija zahtev je ena pomembnejših aktivnosti razvoja oziroma nakupa IR.
  • Osnovni namen zajema in specifikacije zahtev je opredeliti želeno IR na način, ki bo omogočal:
    • Pri nakupu IR izbirati med obstoječimi rešitvami,
    • Pri razvoju IR opredeliti osnovno funkcionalnost ter tehnološke in druge nefunkcionalne zahteve in omejitve za izgradnjo želene IR.

- 157 -

zajem in specifikacija zahtev1
Zajem in specifikacija zahtev

Končni izdelek

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

- 158 -

zajem in specifikacija zahtev2
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.

- 159 -

zajem in specifikacija zahtev3
Zajem in specifikacija zahtev

Postopek zajema in specifikacije zahtev

- 160 -

razvoj po strukturnem pristopu3
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;
    • Uvajanje
    • Izobraževanje.

- 161 -

zajem in specifikacija zahtev4
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

- 162 -

zajem in specifikacija zahtev5
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.

- 163 -

razvoj po strukturnem pristopu4
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;
    • Uvajanje
    • Izobraževanje.

- 164 -

zajem in specifikacija zahtev6
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.

- 165 -

zajem in specifikacija zahtev7
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

- 166 -

zajem in specifikacija zahtev8
Zajem in specifikacija zahtev

Specifikacija zahtev

Funkcionalne zahteve

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.

- 167 -

zajem in specifikacija zahtev9
Zajem in specifikacija zahtev

Specifikacija zahtev

Nefunkcionalne zahteve

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 avtentikacijonej se uporabi digitalno potrdilo.
  • Izdajatelj digitalnega potrdila je lahko CVI RS, NLB, PS.

- 168 -

razvoj po strukturnem pristopu5
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;
    • Uvajanje
    • Izobraževanje.

- 169 -

zajem in specifikacija zahtev10
Zajem in specifikacija zahtev

Potrditev zahtev

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

- 170 -

razvoj po strukturnem pristopu6
Razvoj po strukturnem pristopu

Kje smo?

  • Postopki strukturnega pristopa:
    • Zajem in specifikacija zahtev;
    • Analiza;
    • Načrtovanje;
    • Izvedba;
    • Testiranje;
    • Uvajanje
    • Vzdrževanje.

- 171 -

razvoj po strukturnem pristopu7
Razvoj po strukturnem pristopu

Kje smo?

  • Postopki strukturnega pristopa:
    • Zajem in specifikacija zahtev;
    • Analiza;
    • Načrtovanje;
    • Izvedba;
    • Testiranje;
    • Uvajanje
    • Vzdrževanje.

- 172 -

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

- 173 -

analiza1
Analiza

Opredelitev in namen

  • Analiza daje odgovor na vprašanje, KAJ naj IS podpira. Kaj se izvaja v poslovnih funkcijah in kakšne podatke te rabijo?
  • Analiza služi kot:
    • sredstvo za definicijo zahtev,
    • osnova za dogovor med naročnikom in izvajalcem
    • osnova za kasnejše faze razvoja.

- 174 -

analiza2
Analiza

Končni izdelek

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

- 175 -

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

- 176 -

analiza4
Analiza

Shema postopka

- 177 -

razvoj po strukturnem pristopu8
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;
    • Uvajanje
    • Izobraževanje.

- 178 -

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

- 179 -

analiza6
Analiza

Splošno o modeliranju

  • Modele razvijamo zato, da bi sisteme bolje razumeli.

- 180 -

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

- 181 -

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

- 182 -

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

- 183 -

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

- 184 -

analiza izdelava modela sistema
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.

- 185 -

analiza izdelava modela sistema1
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

- 186 -

analiza izdelava modela sistema2
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.

- 187 -

analiza izdelava modela sistema3

mentalni model

svet

konceptualni model

PB

logični model

Analiza – Izdelava modela sistema

Podatkovni model

- 188 -

analiza izdelava modela sist

V konceptualnem modelu

lahko nastopajo tudi sestavljeni

in večvrednostni atributi!

Analiza – Izdelava modela sist.

Podatkovni model – primer

  • Konceptualni podatkovni model

Študent

Vpisna številka

Priimek

Ime

Naslov

Telefon

E-mail

Status

?

Predmet

Predmet

Naziv

Dodatne obveznosti

Semester

Kreditne točke

Izpit

Zap. št. polaganja

Ocena pisno

Ocena ustno

Datum ocene

Delavec

Rok

Prijava

Delavec

Priimek

Ime

E-mail

Geslo

Rok

Datum izpita

Prijavljenih

Maks. prijavljenih

Meja pozitivno

Datum prijave

Datum odjave

Zap. št. polaganja

Kolokvij

Letnik

Plača izpit

- 189 -

analiza izdelava modela sistema4
Analiza – Izdelava modela sistema

Podatkovni model – primer

  • Primer nerazumljivega podatkovnega modela

- 190 -

analiza izdelava modela sistema5
Analiza – Izdelava modela sistema

Podatkovni model – primer

  • Entitetne tipe je potrebno dokumentirati
  • Primer dokumentacije:

- 191 -

analiza izdelava modela sistema6
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

- 192 -

analiza izdelava modela sistema7

Primer dvoumne povezave

vključuje

je član

Profesor

Katedra

Laboratorij

1..1

1..1

1..*

1..*

Pr1

L1

K1

Pr2

L2

K2

Pr3

L3

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

- 193 -

analiza izdelava modela sistema8

vključuje

je član

Profesor

Laboratorij

Katedra

1..1

1..*

1..*

1.1

Pr1

K1

L1

Pr2

K2

L2

Pr3

K3

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – identifikacija povezav

  • Dvoumno povezavo odpravimo z restrukturiranjem modela

- 194 -

analiza izdelava modela sistema9

je skrbnik

ima

Katedra

Član

Oprema

0..1

1..*

1..1

0..*

K1

O1

Čl1

K2

O2

Čl2

Čl3

K3

O3

Kateri katedri pripada oprema O2?

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – Identifikacija povezav

Primer nepopolne povezave

- 195 -

analiza izdelava modela sistema10

je skrbnik

ima

Katedra

Član

Oprema

0..1

1..*

1..1

0..*

1..1

1..*

pripada

K1

O1

Čl1

K2

O2

Čl2

Čl3

K3

Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – identifikacija povezav

  • Odpravimo z prestrukturiranjem modela.

- 196 -

analiza izdelava modela sistema11
Analiza – Izdelava modela sistema

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

  • Identifikacija odvečnih povezav
    • Povezava je odvečna, če je možno priti do iste informacije prek drugih povezav!
    • Izdelati želimo minimalen podatkovni model  odvečne povezave zato odstranimo.
    • Zgolj pregledovanje poti med entitetnimi tipi ne zadošča (povezave imajo lahko različen pomen)

K 1.7

- 197 -

analiza izdelava modela sistema12

je predstojnik

Profesor

Katedra

1..1

0..1

1..*

1..1

pripada

1..*

je član

Laboratorij

1..1

Analiza – Izdelava modela sistema

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

  • Ali je kakšna povezava odveč?

- 198 -

analiza izdelava modela sistema13

pripada

Profesor

Katedra

1..*

1..1

1..*

1..1

pripada

1..*

je član

Laboratorij

1..1

Analiza – Izdelava modela sistema

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

  • Ali je kakšna povezava odveč?

- 199 -

analiza izdelava modela sistema14
Analiza – Izdelava modela sistema

Podatkovni model – metoda načrtovanja – preverjanje transakcij

  • Preveriti moramo, če model podpira vse zahtevane transakcije.
    • Transakcije izvajamo ročno
    • Če neke transakcije ne uspemo izvesti, je model pomanjkljiv (manjka bodisi entitetni tip, povezava ali atribut)
  • Možna dva pristopa:
    • Preverjanje prek opisa transakcij
    • Preverjanje prek transakcijskih poti

K 1.8

- 200 -

analiza izdelava modela sistema15
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.

- 201 -

analiza izdelava modela sistema16
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
      • ...

- 202 -

analiza izdelava modela sistema17
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 (če pot za neko transakcijo ni možna)
      • Da identificira dele modela, ki so transakcijsko kritični
      • Da odkrije odvečne dele modela (deli, ki jih ne potrebuje nobena transakcija)

- 203 -

analiza izdelava modela sistema18

ima

1..1

0..1

1..*

?

Predmet

predID

Smer

smerID

se predava na

b

1..*

se nanaša na

za

Rok

rokID

Prijava

0..*

1..1

1..1

0..*

0..*

1..1

pripada

Program

progID

1..1

je opravljal

iz

Študent

vpisSt

Izpit

stPol

0..*

1..1

0..*

a

Analiza – Izdelava modela sistema

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

  • Izpiši vse predmete, ki jih je opravil določen študent
  • Izpiši vse študente, ki so se vpisali v določen letnik, določene smeri,
  • določenega programa

- 204 -

analiza izdelava modela sistema19
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.

- 205 -

analiza izdelava modela sistema20
Analiza – Izdelava modela sistema

Procesni model – diagram funkcionalne razgradnje – opredelitev

  • Z diagramom funkcionalne razgradnje prikažemo hierarhijo funkcij, ki jih želimo s sistemom podpreti.
  • Hierarhijo funkcij lahko prikažemo na različne načine, najbolj običajno kot navpično hierarhijo.

- 206 -

analiza izdelava modela sistema21
Analiza – Izdelava modela sistema

Procesni model – diagram funkcionalne razgradnje

- 207 -

analiza izdelava modela sistema22
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.

- 208 -

analiza izdelava modela sistema23
Analiza – Izdelava modela sistema

Procesni model – diagram funkcionalne razgradnje - primer

- 209 -

analiza izdelava modela sistema24
Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – opredelitev

  • Diagrame podatkovnih tokov (DFD) uporabimo za prikaz okolja, v katerem bo sistem deloval, ter za prikaz odvisnosti med procesi, ki jih bo sistem podprl.
  • DFD združuje podatkovni in procesni pogled na obravnavano področje.
  • DFD je uvedel Tom DeMarco leta 1978. Od takrat nastalo več različic DFD tehnike. Razlikujejo se predvsem v notaciji.

DFD – Data Flow Diagram

- 210 -

analiza izdelava modela sistema25
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

- 211 -

analiza izdelava modela sistema26
Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – proces

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

Vhodni

podatki

Izhodni

podatki

Proces sistema

Notranja shramba

podatkov

Zunanji prejemnik

- 212 -

analiza izdelava modela sistema27
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

Raven podrobnosti

Funkcionalna razgradnja

- 213 -

analiza izdelava modela sistema28
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.

Prijava na izpit

Vnos končne ocene

1

2

- 214 -

analiza izdelava modela sistema29
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,…)

- 215 -

analiza izdelava modela sistema30
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

Podatki o

izpitnem roku

Izpitni rok

Vnos končne ocene

2

Ocena pisno,

Ocena ustno

Izpit

ID prijave

Podatki o

preteklih

polaganjih

Prijava

- 216 -

analiza izdelava modela sistema31
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!

- 217 -

analiza izdelava modela sistema32
Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – podatkovna shramba

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

Izpit

Podatkovna baza

- 218 -

analiza izdelava modela sistema33
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)

Vnos izpitnega roka

Podatki o

izpitnem roku

2

Izpitni rok

- 219 -

analiza izdelava modela sistema34
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!

- 220 -

analiza izdelava modela sistema35
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.

- 221 -

analiza izdelava modela sistema36
Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – podatkovna shramba

Procesni model

Podatkovni model

- 222 -

analiza izdelava modela sistema37
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.

- 223 -

analiza izdelava modela sistema38
Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – zunanja entiteta

Študent

indeks

Podatki o

izpitnem roku

Izpitni rok

Vnos končne ocene

2

Ocena pisno,

Ocena ustno

Izpit

ID prijave

Podatki o

preteklih

polaganjih

Prijava

Podatki

o izpitih

Poročila o

uspešnosti

generacije

Analiza uspešnosti generacije

3

Univerza v Ljubljani

- 224 -

analiza izdelava modela sistema39
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.

- 225 -

analiza izdelava modela sistema40
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.

- 226 -

analiza izdelava modela sistema41

KOTEKSTNI DIAGRAM

korenski proces

kontekst sistema

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.

- 227 -

analiza izdelava modela sistema42
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. Shrambe so namenjene odlagališču podatkov pri prenosu le-teh med procesi. Podatkovna shramba je del sistema!
    • Podatkovni tokovi med korenskim procesom in zunanjimi entitetami opredeljujejo vmesnike med sistemom in okoljem.

- 228 -

analiza izdelava modela sistema43
Analiza – Izdelava modela sistema

Procesni model – diagram podatkovnih tokov – primer kontekstnega diagrama

Študent

Podatkovni tokovi brez nazivov

ne povedo skoraj nič!!

MŠŠ

e-študent

0

Računovodstvo FRI

Vpisna prijavno-informacijska služba

Univerza v Ljubljani

- 229 -

analiza izdelava modela sistema44
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.

- 230 -

analiza izdelava modela sistema45
Analiza – Izdelava modela sistema

Napačna raba shrambe

Procesni model – diagram podatkovnih tokov – kontekstni diagram

Sumarni podatki za

podatkovno skladišče

Univerza v Ljubljani

Diplome

0.2

Podatki o diplomah

Podatki o polaganjih

Povprečne

ocene

Teme, ocene

diplom,

kandidati za

diplome,

mentorji

Roki, prijave,

Izpiti, ocene

Sumarni podatki za

podatkovno skladišče

Vpis

0.3

Izpitna evidenca

0.1

Sumarni podatki za

podatkovno skladišče

Vpisni

podatki

Vpisna evidenca

Vpisna prijavno-informacijska služba

Vpisni podatki

Kandidati

za vpis

Osebni podatki,

indeks

Podatki o plačilih

izpitov

Omejitev

vpisa

Podatki za vpis

Študent

MŠŠ

Računovodstvo FRI

Podatki o plačilih

vpisnine

- 231 -

analiza izdelava modela sistema46
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.

- 232 -

analiza izdelava modela sistema47
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

- 233 -

analiza izdelava modela sistema48
Analiza – Izdelava modela sistema

Procesni model – procesni diagram

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

- 234 -

analiza izdelava modela sistema49
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

- 235 -

analiza izdelava modela sistema50
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

- 236 -

analiza izdelava modela sistema51
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.

- 237 -

analiza izdelava modela sistema52
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

- 238 -

analiza izdelava modela sistema53
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.

- 239 -

analiza izdelava modela sistema54

Izbira kandidatov za mednarodne izmenjave

Analiza – Izdelava modela sistema

Procesni model – procesni diagram – primer

Obvestilo ULJ o razpisu

Razpis pripravljen

Priprava razpisa

Objava

razpisa

Razpis objavljen

Zbiranje prijav

Razpis zaključen

Izbira kandidatov

Priprava podatkov za ULJ

Podatki pripravljeni

Obvestilo kandidatov o izboru

Obvestilo ULJ o izboru

Kandidati določeni

AND

Priprava podatkov za KŠZ

Kandidati zavrnjeni

AND

Podatki pripravljeni

Seja

KŠZ

XOR

Kandidati potrjeni

- 240 -

analiza izdelava modela sistema55

Izbira kandidatov za mednarodne izmenjave

Analiza – Izdelava modela sistema

Procesni model – procesni diagram – primer – dodatni gradniki

Seznam za ULJ

S/Ekoordinator

Izbira kandidatov

IR za izbiro kandidatov

Priprava podatkov za ULJ

Podatki pripravljeni

Kandidati določeni

AND

MS Excel

Priprava podatkov za KŠZ

Seznam za KŠZ

Podatki pripravljeni

Seja

KŠZ

S/Ekoordinator

KŠZ

- 241 -

analiza izdelava modela sistema56

Izbira kandidatov za mednarodne izmenjave

Analiza – Izdelava modela sistema

Procesni model – procesni diagram – primer – steze

KŠZ

ULJ

S/E

koordinator

Izdaja obvestila o razpisu

Obvestilo ULJ o razpisu

Priprava razpisa

Razpis pripravljen

Objava razpisa

Razpis objavljen

Podatki pripravljeni

Zbiranje prijav

Seja

KŠZ

- 242 -

analiza izdelava modela sistema57
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.

- 243 -

analiza izdelava modela sistema58
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.

- 244 -

analiza izdelava modela sistema59
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

- 245 -

analiza izdelava modela sistema60
Analiza – Izdelava modela sistema

Model procesne logike – odločitvene tabele in drevesa

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

- 246 -

analiza izdelava modela sistema61
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.

- 247 -

analiza izdelava modela sistema62
Analiza – Izdelava modela sistema

Model procesne logike – odločitvene tabele

Pravilo – kombinacija vrednosti pogojev.

Vrednost pogoja 2

v pravilu p

Akcije, ki jih izvedemo, če velja pravilo p.

- 248 -

analiza izdelava modela sistema63
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:

p1 = Pogoj 1: status vpisa

p2 = Pogoj 2: letnik

p1 = {redno, izredno, ponavlja, pavzira}

zv(p1) = 4

p2 = {1, 2, 3, 4, 5, ABS}

zv(p2) = 6

Število pravil = 4 * 6 = 24

- 249 -

analiza izdelava modela sistema64
Analiza – Izdelava modela sistema

Model procesne logike – odločitvene tabele – primer

Prijava na izpitni rok

- 250 -

analiza izdelava modela sistema65
Analiza – Izdelava modela sistema

Model procesne logike – odločitvena drevesa

  • Zgradba odločitvenega drevesa:
    • Odločitveno drevo je sestavljeno iz vozlišč ter povezav med njimi.
    • Vozlišča predstavljajo pogoje, povezave med njimi pa možne vrednosti posameznih pogojev.
    • Posamezna pot v drevesu, od korena do predzadnjega vozlišča, predstavlja kombinacijo pogojev ali pravilo.
    • List drevesa, ki je na koncu poti, prikazuje seznam akcij pravila.

- 251 -

analiza izdelava modela sistema66
Analiza – Izdelava modela sistema

Model procesne logike – odločitvena drevesa

Pogoj p1

Pot od korena do lista: pravilo

V(p1)  p1

V(p1)  p1

V(p1)  p1

Pogoj p2

A  {a1, a2, …, an}

A  {a1, a2, …, an}

V(p2)  p2

V(p2)  p2

A  {a1, a2, …, an}

A  {a1, a2, …, an}

List: seznam akcij pravila

- 252 -

analiza izdelava modela sistema67
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.

- 253 -

analiza izdelava modela sistema68
Analiza – Izdelava modela sistema

Model procesne logike – odločitvena drevesa – primer

- 254 -

analiza izdelava modela sistema69
Analiza – Izdelava modela sistema

Model procesne logike – odločitvena drevesa – primer

- 255 -

diagramske tehnike
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.

di/ai

Začetno stanje

Stanje S1

Stanje S2

d1/a1

d0/a0

dk/ak

{d0, d1, di, dk}: dogodki

{a0, a1, ai, ak}: akcije

Končno stanje

- 256 -

diagramske tehnike1
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.

- 257 -

diagramske tehnike2
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.

- 258 -

diagramske tehnike3
Diagramske tehnike

Status študenta

Model procesne logike – diagram prehajanja stanj – primer – prikaz z grafom

Ponavljalec

Pogoji za napredovanje niso izpolnjeni /[Ponoven vpis v letnik]

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]

Pavzer

Pogoji za napredovanje so izpolnjeni /[Vpis v višji letnik omogočen]

Pogoji za napredovanje niso izpolnjeni, število ponovnih vpisov > 1 /[Odvzem statusa študenta]

- 259 -

diagramske tehnike4
Diagramske tehnike

Status študenta

Model procesne logike – diagram prehajanja stanj – primer – prikaz s tabelo

- 260 -

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

- 261 -

razvoj po strukturnem pristopu9
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;
    • Uvajanje
    • Izobraževanje.

- 262 -

analiza izdelava prototipov
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.

- 263 -

analiza izdelava prototipov1
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 (RapidApplicationDevelopment– RAD).

- 264 -

analiza izdelava prototipov2
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.

- 265 -

analiza izdelava prototipov3
Analiza – Izdelava prototipov

Izdelava prototipov v okviru analize – Primer MS Visio

  • Primer

- 266 -

analiza izdelava prototipov4
Analiza – Izdelava prototipov

Izdelava prototipov v okviru analize – Primer Delphi

  • Primer

- 267 -

razvoj po strukturnem pristopu10
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;
    • Uvajanje
    • Izobraževanje.

- 268 -

analiza predlog tehni ne arhitekture
Analiza – Predlog tehnične arhitekture

Izdelava predloga tehnične arhitekture

  • V okviru analize ne analiziramo zgolj funkcionalnih zahtev, temveč tudi tehnične in druge nefunkcionalne zahteve.
  • Na osnovi tega podamo predlog tehnične arhitekture sistema.
  • Upoštevamo tudi strategijo podjetja oziroma standarde, ki so v podjetju določeni za celoten informacijski sistem.

- 269 -

analiza predlog tehni ne arhitekture1
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.

- 270 -

analiza predlog tehni ne arhitekture2
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

- 271 -

razvoj po strukturnem pristopu11
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;
    • Uvajanje
    • Izobraževanje.

- 272 -

analiza opredelitev strategije testiranja
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)?

- 273 -

analiza opredelitev strategije testiranja1
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?

- 274 -

analiza opredelitev strategije testiranja2
Analiza – Opredelitev strategije testiranja

Strategija testiranja – prva aktivnost v okviru postopka testiranja

- 275 -

razvoj po strukturnem pristopu12
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;
    • Uvajanje
    • Izobraževanje.

- 276 -

analiza predstavitev rezultatov
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.

- 277 -

analiza predstavitev rezultatov1
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.

- 278 -

razvoj po strukturnem pristopu13
Razvoj po strukturnem pristopu

Kje smo?

  • Postopki strukturnega pristopa:
    • Zajem in specifikacija zahtev;
    • Analiza
    • Načrtovanje;
    • Izvedba;
    • Testiranje;
    • Uvajanje
    • Izobraževanje.

- 279 -

na rtovanje
Načrtovanje

Opredelitev in namen

  • Glavni namen načrtovanja je izdelati načrt zgradbe sistema glede na specifikacije, ki so bile zbrane v fazi analize.
  • Načrt daje odgovor na vprašanje, KAKO izdelatisistem, da bo ustrezal zahtevam, ki smo jihevidentirali v fazi analize.

- 280 -

na rtovanje1
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.

- 281 -

na rtovanje2
Načrtovanje

Končni izdelek

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

- 282 -

na rtovanje3
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.

- 283 -

na rtovanje4
Načrtovanje

Shema postopka

- 284 -

na rtovanje5
Načrtovanje

Shema postopka

- 285 -

na rtovanje izdelava na rta pb
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.

- 286 -

na rtovanje izdelava na rta pb1
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

svet

konceptualni model

PB

logični model

- 287 -

na rtovanje izdelava na rta pb2

Logično načrtovanje

Načrtovanje – Izdelava načrta PB

Podpora CASE orodij

i-CASE

Konceptualni

PM

  • Odločitev o PB:
  • Relacijska
  • Hierarhična
  • Objektna

Logični PM

Fizični PM

(skripta)

Reverse Engineering

SUPB

Podatkovna

baza

ODBC

- 288 -

na rtovanje izdelava na rta pb3

ANALIZA

NAČRTOVANJE

Konceptualni model

Relacijski model

Entitetni tip

Relacija / Tabela

Atribut

Atribut / Stolpec

Enolični identifikator

Ključ

Povezava 1:n

Tuji ključ

Povezava m:n

Vmesna tabela

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

- 289 -

na rtovanje izdelava na rta pb4
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.

- 290 -

na rtovanje izdelava na rta pb5
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

- 291 -

na rtovanje izdelava na rta pb6

Relacija

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.

- 292 -

na rtovanje izdelava na rta pb7

Atribut relacije

Načrtovanje – Izdelava načrta PB

Atribut relacije

  • Atribut je poimenovani stolpec relacije.

- 293 -

na rtovanje izdelava na rta pb8
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:

- 294 -

na rtovanje izdelava na rta pb9

Stopnja relacije

n-terica relacije

Števnost relacije

Načrtovanje – Izdelava načrta PB

Osnovne karakteristike relacije

  • N-tericaje ena vrstica v relaciji.
  • Števnost relacije je število n-teric relacije.
  • Stopnja relacije je število atributov v relaciji.

- 295 -

na rtovanje izdelava na rta pb10
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 so relacije, ki ustrezajo normalnim oblikam. Te določajo pravila, ki jim morajo relacije zadoščati, da pri vnašanju, spreminjanju in brisanju podatkov ne prihaja do anomalij.

- 296 -

na rtovanje izdelava na rta pb11
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.

D1 je domena atributa A1:

množica vrednosti, ki jih A1

lahko zavzame!

- 297 -

na rtovanje izdelava na rta pb12
Načrtovanje – Izdelava načrta PB

Relacijska shema

  • Vsaki relaciji pripada relacijska shema.
  • Relacijsko shemo sestavlja oznaka sheme R ter lista oznak atributov Ai s pripadajočimi oznakami domen Di:
    • R (A1: D1, A2: D2, ..., An: Dn)
  • Relacijska shema predstavlja semantiko ali pomen relacije.

- 298 -

na rtovanje izdelava na rta pb13

Shema relacije

Relacija, predstavljena kot tabela

Shema relacije

Domene atributov

relacije

Načrtovanje – Izdelava načrta PB

Relacijska shema

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

- 299 -

na rtovanje izdelava na rta pb14
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  v relaciji ni dveh enakih n-teric.

- 300 -

na rtovanje izdelava na rta pb15
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.

- 301 -

na rtovanje izdelava na rta pb16

Celice ne vsebujejo atomarnih vrednosti

Celice vsebujejo več vrednosti

Načrtovanje – Izdelava načrta PB

Lastnosti relacij – primer

- 302 -

na rtovanje izdelava na rta pb17
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 X  Y (X funkcionalno določa Y oziroma Y je funkcionalno odvisen od X), če v nobeni relaciji, ki pripada shemi R, ne obstajata dve n-terici, ki bi se ujemali v vrednostih atributov X in se ne bi ujemali v vrednostih atributov Y.

- 303 -

na rtovanje izdelava na rta pb18
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) }

- 304 -

na rtovanje izdelava na rta pb19
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.

- 305 -

na rtovanje izdelava na rta pb20
Načrtovanje – Izdelava načrta PB

Ključi relacije

  • Predpostavimo, da obstaja relacijska shema z atributi A1 A2, ... An, katere podmnožica je množica atributov X.
  • Atributi X so ključ relacijske sheme oziroma pripadajočih relacij, če sta izpolnjena naslednja dva pogoja:
    • X  A1 A2 ... An
    • ne obstaja X’, ki bi bila prava podmnožica od X in ki bi tudi funkcionalno določala A1 A2 ... An

- 306 -

na rtovanje izdelava na rta pb21
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.

- 307 -

na rtovanje izdelava na rta pb22
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.

- 308 -

na rtovanje izdelava na rta pb23

Primarni ključ v tabeli Artikel

Primarni ključ v tabeli Račun

Tuji ključ v tabeli Račun  kaže na primarni ključ v tabeli Artikel

Načrtovanje – Izdelava načrta PB

Ključi relacije primer

ARTIKEL

RAČUN

- 309 -

na rtovanje izdelava na rta pb24
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)

- 310 -

na rtovanje izdelava na rta pb25
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.

- 311 -

na rtovanje izdelava na rta pb26
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.

- 312 -

na rtovanje izdelava na rta pb27

Primarni ključ  ne sme biti NULL

Zahtevamo obveznost podatka

Pedagog

Katedra

EMŠO N13 <pk>

DavcnaSt C9 not null

Ime C20

Priimek C20

DtmRoj D

Katedra N3 <fk>

Katedra N3 <pk>

Naziv C20 not null

StLab N2

Vodja N3 <fk>

Omejitev povezave

Načrtovanje – Izdelava načrta PB

Omejitve nad podatki – primeri omejitev

- 313 -

na rtovanje izdelava na rta pb28
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.

- 314 -

na rtovanje izdelava na rta pb29
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: uporabnikom dajejo možnost, da do podatkov dostopajo na prilagojen način  isti podatki so lahko s strani različnih uporabnikov v istem času vidni na različne načine.
    • Poenostavitev: poenostavljajo kompleksne operacije nad osnovnimi relacijami.

- 315 -

na rtovanje izdelava na rta pb30
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.

- 316 -

na rtovanje izdelava na rta pb31
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.

- 317 -

na rtovanje izdelava na rta pb32
Načrtovanje – Izdelava načrta PB

Primer pogleda

ARTIKEL

RAČUN

SELECT A.sifra, A.naziv, sum(R.kolicina) AS Prodanih

FROM artikel A, racun R

WHERE A.sifra = R.sifra

GROUP BY A.sifra, A.naziv

- 318 -

na rtovanje izdelava na rta pb33
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.

- 319 -

na rtovanje izdelava na rta pb34
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.

- 320 -

na rtovanje izdelava na rta pb35
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

- 321 -

na rtovanje izdelava na rta pb36
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.

- 322 -

na rtovanje izdelava na rta pb37
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.

- 323 -

na rtovanje izdelava na rta pb38
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.

- 324 -

na rtovanje izdelava na rta pb39
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

- 325 -

na rtovanje izdelava na rta pb40
Načrtovanje – Izdelava načrta PB

Normalizacija – prva normalna oblika

  • Relacija je v prvi normalni obliki, če:
    • Nima ponavljajočih atributov  ne obstajajo atributi ali skupine atributov, ki bi imele več vrednosti pri isti vrednosti ostalih atributov (na presečišču ene vrstice in enega stolpca je več vrednosti)
    • Ima definiran primarni ključ in določene funkcionalne odvisnosti
  • Koraki:
    • Odstranimo ponavljajoče atribute
    • Določimo funkcionalne odvisnosti
    • Določimo primarni ključ

- 326 -

na rtovanje izdelava na rta pb41

Skupina ponavljajočih se atributov.

Načrtovanje – Izdelava načrta PB

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

- 327 -

na rtovanje izdelava na rta pb42

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  naziv, pošta  kraj, (VŠ, šifra predmeta)  ocena }

Določimo primarni ključ

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

Načrtovanje – Izdelava načrta PB

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

- 328 -

na rtovanje izdelava na rta pb44
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  noben atribut, ki ni del ključa, ni funkcionalno odvisen le od dela primarnega ključa, temveč od celotnega ključa

- 330 -

na rtovanje izdelava na rta pb45

Relacijo razbijemo

Študent( VŠ, priimek, ime, pošta, kraj)

Predmet( šifra predmeta, naziv)

Indeks( #VŠ, #šifra predmeta, ocena)

Načrtovanje – Izdelava načrta PB

!

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

!

- 331 -

na rtovanje izdelava na rta pb47
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  med atributi, ki niso del primarnega ključa, ni odvisnosti.

- 333 -

na rtovanje izdelava na rta pb48

!

Relacijo razbijemo

Študent( VŠ, priimek, ime, #pošta)

Pošta(pošta, kraj)

Predmet( šifra predmeta, naziv)

Indeks( #VŠ, #šifra predmeta, ocena)

Načrtovanje – Izdelava načrta PB

Študent( VŠ, priimek, ime, pošta, kraj)

Predmet( šifra predmeta, naziv)

Indeks( #VŠ, #šifra predmeta, ocena)

- 334 -

na rtovanje izdelava na rta pb50
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.

- 336 -

na rtovanje izdelava na rta pb51

Za izredne študenta

Za redne študenta

Študent( VŠ, priimek, ime, #pošta)

Redni študent( #VŠ, rok diplome)

Izredni študent( #VŠ, datum plačila šolnine)

Načrtovanje – Izdelava načrta PB

Študent( VŠ, priimek, ime, #pošta, datum plačila šolnine, rok diplome)

- 337 -

na rtovanje izdelava na rta pb53
Načrtovanje – Izdelava načrta PB

Ponovitev

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

- 339 -

na rtovanje izdelava na rta pb54
Načrtovanje – Izdelava načrta PB

Primer pretvorbe konceptualnega v relacijski model

Student

Študent

Vpisna številka

Priimek

Ime

Naslov

Telefon

E-mail

Status

VpisSt N8 <pk>

Priimek C20

Ime C20

Ulica C25

Posta N4

Drzava C20

GSM N15

Tel N15

Email C25 null

Status N1

Izpit

Izpit

VpisSt = VpisSt

ZapStPol N2 <pk>

VpisSt N8 <pk, fk>

OcPisno N2,2

OcUstno N2,2

DatumOc D

Zap. št. polaganja

Ocena pisno

Ocena ustno

Datum ocene

- 340 -

na rtovanje izdelava na rta pb55
Načrtovanje – Izdelava načrta PB

Primer pretvorbe konceptualnega v relacijski model

  • Dodatno poskrbimo za:
    • Indekse
    • Integriteto povezav
    • Druge omejitve
    • Poglede

Student

VpisSt N8 <pk>

Priimek C20

Ime C20

Ulica C25

Posta N4

Drzava C20

GSM N15

Tel N15

Email C25 null

Status N1

Izpit

VpisSt = VpisSt

ZapStPol N2 <pk>

VpisSt N8 <pk, fk>

OcPisno N2,2

OcUstno N2,2

DatumOc D

- 341 -

razvoj po strukturnem pristopu14
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.

- 342 -

na rtovanje izdelava na rta modulov
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

Načrt

Programski modul

Programski modul

Proces

Funkcija

Programski modul

Programski modul

Proces

Funkcija

Funkcija

Proces

Programski modul

Funkcija

Funkcija

Programski modul

Programski modul

- 343 -

na rtovanje izdelava na rta modulov1
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

Fizična enota

1..n

1..n

- 344 -

na rtovanje izdelava na rta modulov2
Načrtovanje – izdelava načrta modulov

Programski moduli

  • Tipi programskih modulov:
    • Zaslonska maska
    • Obdelava
    • Poročilo ali izpis

- 345 -

na rtovanje izdelava na rta modulov3
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.

- 346 -

na rtovanje izdelava na rta modulov4
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

- 347 -

na rtovanje izdelava na rta modulov5
Načrtovanje – izdelava načrta modulov

Strukturni diagram – primer

Dodajizpitni rok

Izračunajdan roka

Preveriposlovnapravila

dan roka

pravila

OK

številkakršenegapravila

podatek

kontrolna zastavica

- 348 -

razvoj po strukturnem pristopu15
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.

- 349 -

na rtovanje na rt dokumentacije
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.

- 350 -

na rtovanje na rt dokumentacije1
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.

- 351 -

na rtovanje na rt dokumentacije2
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

- 352 -

na rtovanje na rt dokumentacije3
Načrtovanje – načrt dokumentacije

Izdelava načrta dokumentacije

  • Sistemsko-tehnična dokumentacija dokumentira informacijsko rešitev s sistemsko-tehničnega vidika. Npr.:
    • Podatkovni model;
    • Arhitektura sistema;
    • Komponente sistema;
    • Opis testnega, produkcijska in razvojnega okolja;
    • Opis sistemske programske opreme in druge infrastrukture, ki je potrebna za delovanje sistema;

- 353 -

na rtovanje na rt dokumentacije4
Načrtovanje – načrt dokumentacije

Izdelava načrta dokumentacije

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

- 354 -

na rtovanje na rt dokumentacije5
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 in obseg dokumentacije je odvisen od dogovora med izvajalcem in naročnikom. Praviloma se podrobneje dokumentirajo samo pomembnejši podsistemi in kritični postopki.

- 355 -

razvoj po strukturnem pristopu16
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.

- 356 -

na rtovanje na rt testiranja
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

- 357 -

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

- 358 -

na rtovanje na rt testiranja2
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.

- 359 -

na rtovanje na rt testiranja3
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: v kateri fazi izvajamo testiranje? (npr. testiranje v fazi razvoja ali testiranje v fazi namestitve in uvedbe)
    • Okolje testiranja: v katerem okolju je potrebno test izvesti? (npr. v testnem okolju)
    • Področje testiranja: kaj se s testom testira? (npr. funkcionalnost sklopa, integracija sklopa, GUI,...)
    • Način izvedbe testiranja: podroben opis, ki pove, kako se izvede test. Opis je odvisen od področja testiranja.

- 360 -

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

- 361 -

na rtovanje na rt testiranja5
Načrtovanje – načrt testiranja

Uporaba scenarijev

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

- 362 -

na rtovanje na rt testiranja6
Načrtovanje – načrt testiranja

Opredelitev scenarija

Načrt poteka testiranja

  • Scenarij:
  • Vhodni podatki
  • Pričakovani rezultati
  • Načrt za izvedbo testa

Test T3

- 363 -

na rtovanje na rt testiranja7
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.

- 364 -

na rtovanje na rt testiranja8
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: sklop: Objava rezultatov

okolje: razvoj

T7: sklop: Opravljanje pisnih izpitov (integracijski test)

okolje: testno

T8: sklop: Vnos obvestil

okolje: razvoj

....

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

okolje: testno

Tn: sklop: celoten sistem (končni test)

okolje: produkcijsko

- 365 -

na rtovanje na rt testiranja9
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:

Testiranje funkcionalnosti: testirati po scenarijih S1, S3, S4, S8

Testiranje GUI: preveriti skladnost elementov GUI z načrtom programskega modula/podsistema PM3

- 366 -

na rtovanje na rt testiranja10
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!«.

- 367 -

razvoj po strukturnem pristopu17
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.

- 368 -

na rtovanje na rt namestitve in uvedbe
Načrtovanje – načrt namestitve in uvedbe

Načrt namestitve in uvedbe

  • Naloga aktivnosti je izdelati načrt namestitve in uvedbe IR v razvojno, testno in produkcijsko okolje ter uvedbo uporabnikov in skrbnikov za delo z IR.
  • Načrt namestitve in uvedbe v razvojnem okolju pripravijo člani projektne skupine razvijalca, pri izdelavi načrta namestitve in uvedbe v testnem oz. produkcijskem okolju pa sodelujejo tudi predstavniki končnih uporabnikov.

- 369 -

na rtovanje na rt namestitve in uvedbe1
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),

- 370 -

na rtovanje na rt namestitve in uvedbe2
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.

- 371 -

na rtovanje na rt namestitve in uvedbe3
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

- 372 -

razvoj po strukturnem pristopu18
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

- 373 -

na rtovanje predstavitev na rta
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.

- 374 -

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

- 375 -

razvoj po strukturnem pristopu19
Razvoj po strukturnem pristopu

Kje smo?

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

- 376 -

testiranje
Testiranje

Opredelitev in namen

  • Glavni namen testiranja jezagotoviti, da IR deluje tako, kot smo načrtovali.
  • Postopek testiranja se prepleta skozi ves življenjski cikel razvoja IR: analiza, načrtovanje, izvedba inuvedba.

Podroben opis aktivnosti testiranja je podan po posameznih postopkih.

- 377 -

testiranje1
Testiranje

Končni izdelek

  • 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).

- 378 -

testiranje2
Testiranje

Vloge

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

- 379 -

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

- 380 -

testiranje4
Testiranje

Primer okolja za testiranje

Razvojni AS

Razvojni PS

Produkcijski AS

Produkcijski PS

Razvoj in vmesnotestiranje

Končno testiranje in produkcija

Testni AS in PS

- 381 -

testiranje5
Testiranje

Shema postopka

- 382 -

testiranje6
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

- 383 -

testiranje7
Testiranje

Vrste in potek testiranja

- 384 -

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

- 385 -

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

- 386 -

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

- 387 -

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

- 388 -

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

- 389 -

razvoj po strukturnem pristopu20
Razvoj po strukturnem pristopu

Kje smo?

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

- 390 -

namestitev in uvedba
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.

- 391 -

namestitev in uvedba1
Namestitev in uvedba

Končni izdelek

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

- 392 -

namestitev in uvedba2
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.

- 393 -

namestitev in uvedba3
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.

- 394 -

namestitev in uvedba4
Namestitev in uvedba

Shema postopka

- 395 -

namestitev in uvedba5
Namestitev in uvedba

Shema postopka

- 396 -

razvoj po strukturnem pristopu21
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.

- 397 -

namestitev in uvedba namestitev ir
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.

- 398 -

namestitev in uvedba namestitev ir1
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 se izvede, ko je aplikacija razvita in potrjena s potrditvenim testom v testnem okolju.

- 399 -

razvoj po strukturnem pristopu22
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.

- 400 -

namestitev in uvedba dodelitev pravic
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.

- 401 -

razvoj po strukturnem pristopu23
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.

- 402 -

namestitev in uvedba prevedba
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.

- 403 -

namestitev in uvedba prevedba1
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.

- 404 -

namestitev in uvedba prevedba2
Namestitev in uvedba – Prevedba

Prevedba podatkov

  • Prevedba podatkov v testno okolje se izvede v sklopu namestitve testnega okolja. Po potrebi se lahko izvede večkrat.
    • Zagotavljanje testnih podatkov ter ponovljivosti testov je lahko zelo kompleksna naloga…
  • Prevedba podatkov v produkcijsko okolje se izvede v sklopu namestitve IR v produkcijsko okolje.
    • Navadno gre za ponovitev že preverjenih in utečenih postopkov prevedbe, ki zagotovijo pravilen prenos podatkov.

- 405 -

razvoj po strukturnem pristopu24
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.

- 406 -

namestitev in uvedba potrditveni test
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.

- 407 -

razvoj po strukturnem pristopu25
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.

- 408 -

namestitev in uvedba kon ni test
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.

- 409 -

razvoj po strukturnem pristopu26
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.

- 410 -

namestitev in uvedba uvajanje
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.

- 411 -

namestitev in uvedba uvajanje1
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.

- 412 -

namestitev in uvedba uvajanje2
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;

- 413 -

namestitev in uvedba uvajanje3
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.

- 414 -

razvoj po strukturnem pristopu27
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.

- 415 -

namestitev in uvedba prehod
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.

- 416 -

namestitev in uvedba prehod1
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 (Phasedstrategy);
    • Zamenjava ali vse naenkrat (Replacementstrategy, BigBang);
    • Vzporedno delovanje (Parallelstrategy).
  • Poleg omenjenih strategij uvedbe se lahko uporabljajo tudi različne kombinacije.

- 417 -

namestitev in uvedba prehod2
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.

- 418 -

namestitev in uvedba prehod3
Namestitev in uvedba – Prehod

Strategije uvedbe – Fazni pristop – problem začasnih vmesnikov

- 419 -

namestitev in uvedba prehod4
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.

- 420 -

namestitev in uvedba prehod5
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.

- 421 -

namestitev in uvedba prehod6

Zamenjava

Vse naenkrat

Vzporedno

Možni pristopi

Po področjih

V celoti vzporedno

Po lokacijah

Delno vzporedno

Postopoma

Po modulih

V celoti zamenjava

Po starih aplikacijah

Namestitev in uvedba – Prehod

Strategije uvedbe

- 422 -

slide422
Poglavje V

Objektni razvoj

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

- 423 -

objektni razvoj
Objektni razvoj

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.

- 424 -

objektni razvoj1
Objektni razvoj

Osnovne značilnosti objektnega pristopa

  • Strukturni pristop
  • Podatki
    • Študent
    • Profesor
    • Učilnica
    • Predmet
  • Procesi
    • Vzdrževanje izpitnih rokov
    • Opravljanje izpita
    • Vodenje izpitne evidence

Učilnica

Podatkovna baza

Profesor

Študent

Programski modul

Programski modul

Programski modul

Podatkovna baza

Programski modul

Programski modul:

Pregled zasedenosti učilnice

Programski modul

Programski modul

Programski modul

- 425 -

objektni razvoj2
Objektni razvoj

Osnovne značilnosti objektnega pristopa

  • 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:
          • 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

Učilnica

Profesor

Študent

Ali je učilnica NP15 15.5.07 prosta?

Objekt Marko: PROFESOR

Objekt NP15: UČILNICA

- 426 -

objektni razvoj3
Objektni razvoj

Primerjava postopkov strukturnega in objektnega razvoja IR

Vzdrževanje

Uvajanje

Testiranje

Izvedba

Načrtovanje

Analiza

Zajem zahtev

Življenjski cikel razvoja IR

- 427 -

objektni pristop
Objektni pristop

Vsebina

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

- 428 -

razvoj po objektnem pristopu
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;

- 429 -

objektni razvoj4
Objektni razvoj

Definicija objekta

  • Objekt lahko predstavlja fizično entiteto ali konceptualni pojem.
    • Učitelj, učenec,…
    • Predmet, test,…
  • S stališča razvoja IR je objekt koncept, abstrakcija ali stvar z natančno določenimi mejami in pomenom za IR.

- 430 -

objektni razvoj5
Objektni razvoj

Definicija objekta

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

- 431 -

objektni razvoj6
Objektni razvoj

Abstrakcija

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

Vesna: Profesor

Ime: Vesna Jug

Telefon: 01/4768 814

Prijavi (int pid): boolean

- 432 -

objektni razvoj7
Objektni razvoj

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

- 433 -

objektni razvoj8
Objektni razvoj

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.

- 434 -

objektni razvoj9
Objektni razvoj

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, kajlahko počne in kaj selahko z njim počne!

- 435 -

objektni razvoj10
Objektni razvoj

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.

- 436 -

objektni razvoj11
Objektni razvoj

Razred

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

Objekti

Razred

  • Ime razreda: Profesor
  • Lastnosti:
  • Ime
  • Priimek
  • Obnašanje

- 437 -

objektni razvoj12
Objektni razvoj

Razred

  • Koliko razredov je na sliki?

- 438 -

razvoj po objektnem pristopu1
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;

- 439 -

objektni razvoj13
Objektni razvoj

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.

- 440 -

objektni razvoj14
Objektni razvoj

Enkapsulacija ali skrivanje podatkov

  • Želimo se naučiti voziti avtomobil. Kaj moramo o avtomobilu vedeti?
    • Kako se upravlja z volanom, kako sezavira in p pospešuje,…
    • Potrebno vedeti, kako deluje motor? Kako pride do vžiga?Kaj natančno se zgodi, kopritisnemo na plin?
  • Za delo z objektom ne potrebujemo vseh podatkov o objektu, temveč samo določene – vmesnik (interface).

- 441 -

objektni razvoj15
Objektni razvoj

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 sezna odzivati na vmesnik…

- 442 -

objektni razvoj16
Objektni razvoj

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.

- 443 -

razvoj po objektnem pristopu2
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;

- 444 -

objektni razvoj17
Objektni razvoj

Hierarhija in dedovanje

  • Dedovanje je ključen koncept objektnega razvoja.
    • Pove, da ima objekt v času svojega kreiranja dostop tudi do lastnosti drugih razredov poleg dostopa do razreda, kateremu pripada.
    • Podedovan razred združi vse lastnosti (lastne in podedovane) v svojo definicijo.
  • Primer:
    • Profesorje poseben primer pedagoškega delavca.
    • Objekt tipa profesor ima lastnosti pedagoškega delavca ter svoje lastne lastnosti.

- 445 -

objektni razvoj18
Objektni razvoj

Hierarhija in dedovanje

  • Primer razreda Profesor in Pedagoški delavec
  • Opis:
    • P ima enake lastnostikot PD.
    • Za P nas zanima tudiakademski naziv teršt. predmetov, ki jihpoučuje.
    • P lahko razpisuje tuditeme za diplome.
    • P ima pri vnašanju ocen več pravic kot PD. Lahko vpisuje tudi ocene ustno…

Pedagoški delavec

Profesor

Ime

Priimek

EMŠO

Telefon

Delovno mesto

Datum rojstva

Naslov

Akademski naziv

Število predmetov

Vnesi oceno

Razpiši temo diplome

Razpiši izpitni rok

Vnesi oceno

- 446 -

objektni razvoj19
Objektni razvoj

Hierarhija in dedovanje

  • Razrede lahko zapišemo v hierarhijo.

Oseba

Delavec

Raziskovalec

Pedagoški delavec

Strokovni sodelavec

Profesor

Asistent

Redni profesor

- 447 -

objektni razvoj20
Objektni razvoj

Hierarhija in dedovanje

  • Hierarhija razredov v Delphi razvojnem okolju…

- 448 -

objektni razvoj21
Objektni razvoj

Hierarhija in dedovanje

  • Delček razredne hierarhije java.awt…

- 449 -

razvoj po objektnem pristopu3
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;

- 450 -

objektni razvoj22
Objektni razvoj

Zakaj UML?

Skupinski razvoj

Jezik za

modeliranje

Poenoten

proces

- 451 -

objektni razvoj23
Objektni razvoj

UML – univerzalni modelirni jezik

Univerzalni modelirni jezik

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

- 452 -

objektni razvoj24
Objektni razvoj

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

- 453 -

objektni razvoj25
Objektni razvoj

UML – Zgodovina do 1997

- 454 -

objektni razvoj26

Fusion

Meyer

opisi operacij,

oštevilčenje sporočil

predpogoji in

popogoji

Harel

diagrami stanj

Gamma, et.al

Wirfs-Brock

ogrodja, vzorci,

opombe

odgovornosti

Odell

Shlaer - Mellor

klasifikacija

življenjski cikli

objekta

Objektni razvoj

Drugi viri in prispevki

Booch

Rumbaugh

Jacobson

- 455 -

objektni razvoj27
Objektni razvoj

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…

- 456 -

objektni razvoj28
Objektni razvoj

UML diagramske tehnike

- 457 -

objektni razvoj29
Objektni razvoj

?

UML diagramske tehnike – enostavnost

prijava na

izbirni predmet

študent

seznam predavanj

izbira predmetov

za poučevanje

profesor

vnos podatkov o profesorjih

Referent

vnos podatkov o študentih

sistem za

pripravo urnika

zaključitev prijave

- 458 -

objektni razvoj30
Objektni razvoj

UML diagramske tehnike – kompleksnost

- 459 -

objektni razvoj31

DocumentList

Repository

FileManager

<<entity>>

Customer

name

addr

receive()

Document

withdraw()

fetch()

send()

GraphicFile

File

FileList

Objektni razvoj

UML diagramske tehnike – hrbtenica razvoja

diagram primera uporabe

razredni diagram

diagram stanj

Use-Case 1

Actor A

Actor B

Use-Case 2

diagram

implementacije

Poznavalec

obravnavanega

področja

Use-Case 3

razred

diagram

paketov

Razvijalec

Forward Engineering(specifikacija -> koda)

Reverse Engineering (koda -> specifikacija)

diagram sodelovanja

diagram

komponent

urejanje izvorne kode, prevajanje,

razhroščevanje, povezovanje

diagram zaporedja

- 460 -

objektni razvoj32
Objektni razvoj

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 spremenjenezahteve

Nov ali spremenjensistem

Proces razvoja IR

- 461 -

objektni razvoj33
Objektni razvoj

Proces razvoja – RUP

  • RUP – RationalUnifiedProcess
    • primer procesa objektnega razvoja
    • avtor: podjetje Rational

- 462 -

objektni razvoj34
Objektni razvoj

Proces razvoja – RUP

  • Glavne lastnosti RUP:
    • Daje smernice za učinkovit razvoj kakovostne programske opreme
    • Zmanjšuje tveganje in povečuje predvidljivost
    • Zajema in vpeljuje najboljše izkušnje
      • učenje iz izkušenj drugih
      • mentorstvo v elektronski obliki
      • razširitev izobraževalnega gradiva
    • Pospešuje skupno vizijo in kulturo
    • Vpeljuje načrt za uvedbo orodij
    • Omogoča enostaven in hiter dostop do informacij v elektronski obliki (spletna stran,...)

- 463 -

objektni razvoj35
Objektni razvoj

Proces razvoja – RUP

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

Iterativni razvoj

Uporaba

komponentne

arhitekture

Preverjanje

kakovosti

Obvladovanje

zahtev

Vizualno

modeliranje

Nadzorovanje sprememb

- 464 -

objektni razvoj36
Objektni razvoj

Proces razvoja – RUP

  • Primeri uporabe so osnova mnogim aktivnostim procesa:
    • Izdelava in potrditev razvojnega modela
    • Določitev preizkusnih primerov in postopkov za model preizkušanja
    • Načrtovanje iteracij
    • Izdelava uporabniške dokumentacije
    • vpeljava sistema
    • Primeri uporabe pripomorejo k uskladitvi vsebine različnih modelov

- 465 -

objektni razvoj37
Objektni razvoj

Proces razvoja – RUP

  • Primeri uporabe so hrbtenica procesa RUP.

- 466 -

objektni razvoj rup
Objektni razvoj – 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

- 467 -

objektni razvoj rup1

Končni

uporabnik

Končni upor.

Funkcionalnost

Funkcionalnost

System Integrators

Sistemski povezovalec

Zmogljivost

Prilagodljivost

Throughput

Zmogljivost

Razširljivost

Prepustnost

Objektni razvoj – RUP

RUP – arhitekturna usmerjenost – 3+1 pogledi na arhitekturo

Logični

pogled

Logični

pogled

Izvedbeni

pogled

Izvedbeni

pogled

Analitik/

Razvijalec

Analitik/Razvijalec

Programer

Upravljanje z IR

Programer

Upravljanje s prog. op.

Zgradba

Zgradba

Primer uporabe

Primer uporabe

Procesni

pogled

Procesni

pogled

Postavitveni pogled

Postavitveni pogled

***System Engineering

Sistemski inženir

Topologija sistema

Predaja v uporabo, namestitev

komunikacije

System topology

Delivery, installation

communication

- 468 -

objektni razvoj rup2
Objektni razvoj – 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.

- 469 -

objektni razvoj rup3
Objektni razvoj – 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.

Zbiranje

informacij

Začetna faza

Konstrukcija

Prevzem

čas

- 470 -

objektni razvoj rup4
Objektni razvoj – RUP

RUP – makro mejniki

Mejnik

Določeni cilji

projekta/

naloge

Mejnik

Stabilna arhitektura

Mejnik

Izdelek delujoč/ ustrezen

Mejnik

Uporabnik

zadovoljen

Zbiranje

informacij

Začetna faza

Konstrukcija

Prevzem

čas

- 471 -

objektni razvoj rup5
Objektni razvoj – RUP

RUP – mikro mejniki

Zbiranje

informacij

Začetna faza

Konstrukcija

Prevzem

čas

I1

I2

I3

I4

I5

I6

I7

I8

Iteracija

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

- 472 -

objektni razvoj rup6

Poslovno

modeliranje

Zajem zahtev

Izvedba

Testiranje

Objektni razvoj – RUP

RUP – gradnja modela sistema prek postopkov RUP

Modelira poslovno okolje

Primeri uporabe

poslovnega okolja

Konceptualni modelposlovnega okolja

Prikazuje tiste primere uporabe iz poslovnega okolja, za katere se bo razvijala IR

Model primerov

uporabe

Analiza in načrtovanje

Prikazuje načrt za implementacijo rešitve

Model

načrta

Prikazuje dejansko

Izvedbo rešitve

Model

izvedbe

Prikazuje načrt testiranja

Model

testiranja

- 473 -

objektni razvoj rup7

V vsaki iteraciji gremo

čez vse postopke

Razvoj IR konvergira od vzpostavitve projekta in zbiranja zahtev/podatkov proti konstrukciji in uvedbi

Objektni razvoj – RUP

RUP – prednosti arhitekturno usmerjenega pristopa

Osnovni postopki

Podporni postopki

- 474 -

jezik uml in proces rup
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

- 475 -

razvoj po objektnem pristopu4
Razvoj po objektnem pristopu

Kje smo?

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

- 476 -

rup zajem zahtev
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.

- 477 -

rup zajem zahtev1
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)

- 478 -

rup zajem zahtev2
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

- 479 -

rup zajem zahtev3
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

- 480 -

rup zajem zahtev4
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

Primer uporabe

Kupi vstopnico

- 481 -

rup zajem zahtev5
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

- 482 -

rup zajem zahtev6
RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

  • Primer osnovnega toka dogodkov – Kupi vstopnico preko interneta:
    • Sistem prikaže seznam prireditev
    • Kupec izbere prireditev
    • Sistem vrne kupcu seznam terminov, kjer so še prosti sedeži za izbrano prireditev in podrobne podatke o prireditvi.
    • Kupec izbere termin
    • Sistem prikaže kupcu matriko sedežev z označenimi zasedenimi in rezerviranimi sedeži.
    • Kupec izbere enega ali več prostih sedežev
    • Sistem označi izbrane sedeže kot rezervirane
    • Sistem zahteva vnos imena in št. kreditne kartice
    • Kupec vnese ime in št. kreditne kartice
    • Sistem komunicira z zunanjim sistemom ponudnika kreditnih kartic
    • Zunanji sistem vrne sporočilo o uspešni transakciji
    • Sistem označi sedeže kot prodane
    • Sistem prikaže zaslon z vstopnico/cami, ki vsebuje tudi referenčne št. vstopnic
    • Sistem pošlje e-pošto stranki z enakimi podatki kot v točki 12

- 483 -

rup zajem zahtev7
RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

  • Primer alternativnega toka dogodkov – Kupi vstopnico preko interneta:
    • Sistem prikaže seznam prireditev
    • Kupec izbere prireditev
    • Sistem vrne kupcu sporočilo, da so vse vstopnice na vseh terminih prodane.

- 484 -

rup zajem zahtev8
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:
    • 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

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

Podtok A

Podtok B

- 485 -

rup zajem zahtev9
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

Bančni

sistem

Stranka

- 486 -

rup zajem zahtev10
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

- 487 -

rup zajem zahtev11
RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

  • Odvisnost “vključuje” - <<include>>:
    • Vedno poteka le med dvema primeroma uporabe in sicer od “izhodiščnega” primera uporabe, ki vključuje tudi drug primer uporabe
    • Omogoča ponovno uporabo primera uporabe

Odvisnost “vključuje”

<<include>>

Kupi vstopnico

<<include>>

Stranka

Plačaj s kartico

Rezerviraj

vstopnico

- 488 -

rup zajem zahtev12
RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

  • Odvisnost “razširja” - <<extend>>:
    • Vedno poteka le med dvema primeroma uporabe in sicer od primera uporabe, ki razširja “izhodiščni” primer uporabe
    • Omogoča, da se primer uporabe izvede pod določenim pogojem (razširitvena točka - “extension point”).

Odvisnost “razširja”

<<extend>>

Kupi vstopnico

Pridobi dodaten

račun

Stranka

- 489 -

rup zajem zahtev13
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

Kupi vstopnico

Stranka

Rezerviraj

vstopnico

Prijavi bonus

Stranka “VIP”

Preglej bonus

- 490 -

rup zajem zahtev14
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

- 491 -

rup zajem zahtev15
RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

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

Meja sistema

Kupi vstopnico

Stranka

Rezerviraj

vstopnico

Prijavi bonus

Stranka “VIP”

Preglej bonus

- 492 -

rup zajem zahtev16
RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

  • Možen pristop pri načrtovanju diagrama primerov uporabe:
    • Identificiraj akterje
    • Identificiraj primere uporabe sistema
    • Poveži akterje in primere uporabe (ugotovi na kakšne načine različni akterji uporabljajo sistem)
    • Odstrani odvečne primere uporabe (npr. neuporabljeni primeri uporabe)
    • Odstrani odvečne akterje (npr. podvojeni akterji; akterji, ki to niso ipd.)
    • Preveri in popravi morebitne napake

- 493 -

rup zajem zahtev17
RUP – Zajem zahtev

RUP – zajem zahtev – primeri uporabe

  • Pogoste napake pri načrtovanju primerov uporabe:
    • Nejasno/nepravilno opredeljene meje sistema
    • Veliko število primerov uporabe na enem diagramu
    • Križanje povezav, nepreglednost diagrama
    • Primeri uporabe niso napisani s stališča akterja oz. uporabnika (npr. “Kupi vstopnico” vs. “Prodaj vstopnico”)
    • Model primerov uporabe je podoben diagramu podatkovnih tokov

- 494 -

primer
Primer

<<include>>

Kupi vstopnico

preko spleta

RUP – zajem zahtev – primeri uporabe

<<include>>

Plačaj preko

spleta

Spletni

plačilni

sistem

Stranka

Rezerviraj

vstopnico

Prijavi bonus

<<extend>>

Stranka “VIP”

Preglej bonus

Unovči bonus

Uredi prireditve

Referent

Dodeli stranki

status“VIP”

- 495 -

rup zajem zahtev18

Model primerov uporabe

Akterji

Primeri uporabe

Dodatne

specifikacije

Slovar

...

Opisi primerov uporabe

RUP – Zajem zahtev

RUP – zajem zahtev – pomembni izdelki

- 496 -

rup zajem zahtev19
RUP – Zajem zahtev

RUP – zajem zahtev – Model primerov uporabe

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

Akterji

Primeri uporabe

...

Opisi primerov uporabe

- 497 -

rup zajem zahtev20

Namesto alternativnega toka bi lahko

za nekatere tokove uporabili tudi podtokove.

RUP – Zajem zahtev

RUP – zajem zahtev – Model primerov uporabe – primer opisa primera uporabe

- 498 -

rup zajem zahtev21
RUP – Zajem zahtev

RUP – zajem zahtev – Model primerov uporabe – primer opisa primera uporabe

- 499 -

rup zajem zahtev22
RUP – Zajem zahtev

RUP – zajem zahtev – dodatne specifikacije

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

- 500 -

razvoj po objektnem pristopu5
Razvoj po objektnem pristopu

Kje smo?

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

- 501 -

objekta analiza in na rtovanje
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,

- 502 -

objekta analiza in na rtovanje1
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

- 503 -

objekta analiza in na rtovanje2

Slovar

Končen izdelek analize in načrtovanja

Objekta analiza in načrtovanje

RUP – Analiza in načrtovanje – vhodni in izhodni izdelki

Analiza in

načrtovanje

Model načrta

Model primerov

uporabe

Arhitekturasistema

Dodatne

specifikacije

Podatkovni model

- 504 -

objekta analiza in na rtovanje3

Načrtovalec PB

Načrtovalec

Arhitekt

Objekta analiza in načrtovanje

RUP – Analiza in načrtovanje – vloge

Realizacija

primera uporabe

Paket/Podsistem

Razred

Pregledovalec

arhitekture

Pregledovalec

načrta

Arhitekturasistema

Model načrta

Podatkovni model

- 505 -

objekta analiza in na rtovanje4
Objekta analiza in načrtovanje

RUP – Analiza in načrtovanje – koraki

Analizaarhitekture

Načrtarhitekture

Analiza sočasnostiin porazdeljenosti

Pregledarhitekture

Načrtovanjepodsistemov

Načrtovanjerazredov

Preglednačrta

Načrtovanjeprimerovuporabe

Analizaprimerovuporabe

Pregledovalec arhitekture

Pregledovalec načrta

Načrtovalec

Arhitekt

- 506 -

razvoj po objektnem pristopu6
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

- 507 -

objekta analiza in na rtovanje5
Objekta analiza in načrtovanje

Izbrani primeri uporabe za realizacijo

Analiza arhitekture

Analiza arhitekture

Model primerov

uporabe

Dodatnespecifikacije

Smernice za načrtovanje

Arhitekturasistema

Slovar

Model načrta

Poslovni model

- 508 -

objekta analiza in na rtovanje6
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

- 509 -

objekta analiza in na rtovanje7
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.
  • Vhodi:
    • Znanje o domeni (vključno s poslovnim modelom, če obstaja)
    • Zahteve
    • Slovar

Razredi analize ali ključne abstrakcije

- 510 -

objekta analiza in na rtovanje8
Objekta analiza in načrtovanje

RUP – Od razredov analize do izvedbenih elementov – komponent

Analiza

Načrt

Izvedba

- 511 -

objekta analiza in na rtovanje9
Objekta analiza in načrtovanje

Primer ključnih abstrakcij

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

Študijski program

Študent

Predmet

Izpitni rok

Prijava

Vpis

- 512 -

objekta analiza in na rtovanje10
Objekta analiza in načrtovanje

Primer ključnih abstrakcij

  • Povezave med identificiranimi abstrakcijami…

Študijski program

Predmet

Izpitni rok

Prijava

Vpis

Študent

- 513 -

objekta analiza in na rtovanje11

Arhitekt

Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – analiza potreb po sistemskih storitvah

Želena funkcionalnost

Okolje implementacije

Dodatnespecifikacije

Model primerov

uporabe

Arhitekt je odgovoren za izbiro ustreznih načrtovalskih vzorcev za realizacijo potrebnih sistemskih storitev (dostop do relacijske podatkovne baze, uporaba digitalnih potrdil, obvladovanje transakcij,…

- 514 -

objekta analiza in na rtovanje12
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

- 515 -

objekta analiza in na rtovanje13
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.

- 516 -

objekta analiza in na rtovanje14
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.
    • PipesandFilters: 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…

- 517 -

objekta analiza in na rtovanje15
Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni

Aplikacijski podsistemi(Application subsystems)

Ločeni aplikacijski podsistemi, ki skupaj

tvorijo aplikacijski sistem. Specifične aplikacije organizacije.

Poslovni podsistemi(Business specific)

Številni ponovno uporabni podsistemi, ki so specifični za aplikativna področja (npr. telekomunikacije, bančništvo itd.)

Vmesni nivo(Middleware)

Vmesni nivo sestavljajo razni pomožni podsistemi (utility classes) in sistemi, ki so od platforme neodvisni (npr. Storitve za porazdeljena in heterogena okolja)

Sistemska programska oprema(System software)

Zajema programsko opremo za dejansko infrastrukturo, npr. operacijski sistemi, vmesniki do specifičnih naprav ipd.

- 518 -

objekta analiza in na rtovanje16
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

- 519 -

objekta analiza in na rtovanje17
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.

- 520 -

objekta analiza in na rtovanje18
Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni

  • Ciklične odvisnosti so nezaželene…

A

B

A

B

C

A

B

C

A’

- 521 -

objekta analiza in na rtovanje19
Objekta analiza in načrtovanje

RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni

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

<<layer>>

Ime ravni

<<layer>>

Business Services

<<layer>>

Application

- 522 -

razvoj po objektnem pristopu7
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

- 523 -

objektna analiza in na rtovanje
Objektna analiza in načrtovanje

Analiza arhitekture

Analizirani primeri uporabe

Analiza primerov uporabe

Razredi analize

Model primerov

uporabe

Slovar

Dodatnespecifikacije

Smernice za načrtovanje

Arhitekturasistema

Model načrta(dopolnjen)

Izbrani primeri uporabe za realizacijo

- 524 -

objektna analiza in na rtovanje1
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

- 525 -

objektna analiza in na rtovanje2
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. Pri tem se poveže s sistemom

“SKK” in uporabi njegovo spletno

storitev “CardCheck”.

Sistem preveri veljavnost kreditne kartice.

- 526 -

objektna analiza in na rtovanje3
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

- 527 -

objektna analiza in na rtovanje4

Model Primerov Uporabe

Model Načrta

Diagrami Razredov

Diagrami sodelovanja

Diagrami Zaporedja

Primer Uporabe

Realizacija Primera Uporabe

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Primer Uporabe

- 528 -

objektna analiza in na rtovanje5

<<boundary>>

<<boundary>>

<<control>>

<<entity>>

<<entity>>

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

- 529 -

objektna analiza in na rtovanje6

<<boundary>>

<<boundary>>

<<control>>

<<entity>>

<<entity>>

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Razredi analize:

Meja sistema

- 530 -

objektna analiza in na rtovanje7
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Ikonski prikaz razredov analize:

- 531 -

objektna analiza in na rtovanje8
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Mejni razred - <<boundary>>:
    • Mejni razred je posrednik med okoljem in sistemom
    • Ogradi sistem pred spremembami v okolici
    • Odvisen od sprememb v okolju
  • Več vrst mejnih razredov:
    • Razredi uporabniškega vmesnika
    • Razredi sistemskega vmesnika
    • Razredi vmesnika do naprav

- 532 -

objektna analiza in na rtovanje9

<<boundary>>

<<boundary>>

<<boundary>>

<<control>>

<<entity>>

<<entity>>

<<entity>>

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Mejni razredi modelirajo interakcijo med okoljem in sistemom

- 533 -

objektna analiza in na rtovanje10
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:

Kupi vstopnico

Bančni

sistem

Stranka

<<boundary>>

<<boundary>>

ZMStrankaKupiVstopnico

SVBančniSistem

- 534 -

objektna analiza in na rtovanje11
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.

- 535 -

objektna analiza in na rtovanje12
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Poslovni razred - <<entity>>:
    • Ključni koncept sistema, ki ga razvijamo
    • Od okolja je neodvisen
    • Hrani in upravlja podatke
    • Navadno gre za trajen razred
    • Njegovo obnašanje je strogo vezano na entiteto, ki jo predstavlja
    • Poslovni razred navadno ni vezan le na en primer uporabe
    • V nekaterih primerih modeliramo tudi podatke o akterju, ki jih hranimo znotraj sistema, čeprav je akter izven sistema. Tak razred imenujemo tudi “zastopnik akterja” (surrogate).

- 536 -

objektna analiza in na rtovanje13

<<boundary>>

<<boundary>>

<<boundary>>

<<control>>

<<entity>>

<<entity>>

<<entity>>

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Poslovni razredi hranijo in upravljajo ključne podatke sistema

- 537 -

objektna analiza in na rtovanje14
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

- 538 -

objektna analiza in na rtovanje15
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Primer:

<<entity>>

Sedež

<<entity>>

Vstopnica

<<entity>>

Slovar

Kupi vstopnico

Prireditev

<<entity>>

Termin

<<entity>>

Stranka

Ključne abstrakcije

“Zastopnik”

akterja Stranka

- 539 -

objektna analiza in na rtovanje16

<<stereotip>>

ImeRazreda

atribut : tip = začVrednost

atribut : tip = začVrednost

atribut : tip = začVrednost

<<entity>>

IzbirniPredmet

predmetID :String=“100”

začetek : Time

konec: Time

številoDni: Enum

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

V analizi se na ukvarjaj s podpisi (signaturami) atributov

atribut

objektna analiza in na rtovanje17
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

Račun

stanje

ime

številka

Dvigni()

Položi()

Varčevalni

Osebni

VrniObresti()

Dvigni()

Dvigni()

- 541 -

objektna analiza in na rtovanje18
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Primer:

<<entity>>

Dogodek

<<entity>>

<<entity>>

<<entity>>

Prireditev

Trening

Zborovanje

<<entity>>

<<entity>>

<<entity>>

Tekma

Koncert

Film

- 542 -

objektna analiza in na rtovanje19
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

- 543 -

objektna analiza in na rtovanje20

<<entity>>

IzbirniPredmet

<<entity>>

Študent

<<entity>>

Urnik

<<entity>>

Predmet

je predpogoj za

Rekurzivna povezava

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Modelira pomensko povezavo med primerki razredov

Enostavna povezava

Asociacija je strukturna povezava

objektna analiza in na rtovanje21

<<entity>>

IzbirniPredmet

<<entity>>

Profesor

<<entity>>

Katedra

<<entity>>

Predmet

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Vloga, ki jo igra razred v povezavi

Nosilec

predmeta

Vodja katedre

Ime vloge

Predpogoj

objektna analiza in na rtovanje22
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

glavniPredmet

<<entity>>

<<entity>>

Urnik

IzbirniPredmet

dodatniPredmet

dodaj študenta

<<entity>>

<<entity>>

Urnik

IzbirniPredmet

odstrani študenta

Vsaka povezava igra svojo vlogo

objektna analiza in na rtovanje23

0..*

*

1..*

0..1

2..4

2, 4..6

Objektna analiza in načrtovanje
  • Nedoločeno
  • Točno ena
  • Nič ali več (več, neomejeno)
  • Ena ali več
  • Nič ali ena
  • Določen interval
  • Več nepovezanih intervalov
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Števnost:

1

objektna analiza in na rtovanje24

<<entity>>

IzbirniPredmet

<<entity>>

Študent

<<entity>>

Urnik

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Števnost

0..4

0..*

1

0..*

glavniPredmet

0..*

0..2

dodatniPredmet

objektna analiza in na rtovanje25

Razred1

Razred2

Razred1

Razred2

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Navigacija – usmerjenost povezave:

Neusmerjena

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

Usmerjena

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 rtovanje26

1

1

Usmerjena povezava

<<entity>>

IzbirniPredmet

<<entity>>

Urnik

<<control>>

KVpišiPredmet

<<boundary>>

ZMVpišiPredmet

0..4

0..*

glavniPredmet

0..2

0..*

dodatniPredmet

Neusmerjena povezava

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
objektna analiza in na rtovanje27
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

<<entity>>

Stranka

  • Primer:

Ime

Priimek

1

<<entity>>

<<entity>>

Sedež

*

Prireditev

1

<<entity>>

<<entity>>

1

Številka

1..*

1

*

Termin

Ime

*

Vstopnica

Vrsta

Opis

Tribuna

Začetek

Status

Trajanje

- 551 -

objektna analiza in na rtovanje28
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Kontrolni razred - <<control>>:
    • Kontrolni razred koordinira dogajanje znotraj primera uporabe.
    • Sistem lahko izvaja nekatere primere uporabe tudi brez kontrolnih razredov, vendar le takšne, ki obsegajo le enostavno rokovanje s shranjenimi podatki (npr. zapiši/ preberi atribut).
    • Bolj kompleksni primeri uporabe navadno zahtevajo enega ali več kontrolnih razredov, ki koordinirajo obnašanje objektov drugih razredov v sistemu.
    • Kontrolni razredi učinkovito ločijo mejne in poslovne razrede in s tem naredijo sistem še bolj odporen na spremembe v okolju.
    • Ločijo tudi obnašanje, ki je specifično za primer uporabe od poslovnih razredov, s čimer omogočijo ponovno uporabo poslovnih razredov v več primerih uporabe in celo različnih sistemih.

- 552 -

objektna analiza in na rtovanje29
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).

- 553 -

objektna analiza in na rtovanje30

<<boundary>>

<<boundary>>

<<boundary>>

<<control>>

<<entity>>

<<entity>>

<<entity>>

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…
  • Kontrolni razred koordinira obnašanje primera uporabe

- 554 -

objektna analiza in na rtovanje31
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:

Kupi vstopnico

Bančni

sistem

Stranka

<<control>>

KKupiVstopnico

Kupi vstopnico

- 555 -

objektna analiza in na rtovanje32
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).

- 556 -

objektna analiza in na rtovanje33
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Model primerov

uporabe

Kupi vstopnico

Stranka

Bančni sistem

Model načrta

<<boundary>>

<<boundary>>

<<control>>

SVBančniSistem

ZMStrankaKupiVstopnico

KKupiVstopnico

<<entity>>

<<entity>>

1

<<entity>>

Sedež

Prireditev

*

<<entity>>

1

1

Termin

Ime

Številka

Vstopnica

*

1..*

<<entity>>

*

Začetek

Opis

*

Vrsta

Status

Stranka

Tribuna

Trajanje

1

Ime

Priimek

- 557 -

objektna analiza in na rtovanje34
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.

- 558 -

objektna analiza in na rtovanje35
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

- 559 -

objektna analiza in na rtovanje36

Diagrami sodelovanja

Diagrami Zaporedja

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

Realizacija primerov uporabe

- 560 -

objektna analiza in na rtovanje37
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

- 561 -

objektna analiza in na rtovanje38
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.

- 562 -

objektna analiza in na rtovanje39
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

- 563 -

objektna analiza in na rtovanje40
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 rtovanje41
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
objektna analiza in na rtovanje42

:Odjemalec

:Ponudnik

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)

ČAS

Življenjska črta

objekta

Rekurzivno

sporočilo

1: IzvediOdgovornost

1.1: IzvediDrugo Odgornost

Sporočilo

Hierarhično

številčenje

sporočil

Fokus

(aktivnost objekta)

- 566 -

objektna analiza in na rtovanje43
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

- 567 -

objektna analiza in na rtovanje44
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

- 568 -

objektna analiza in na rtovanje45
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

- 569 -

objektna analiza in na rtovanje46

:Odjemalec

:Ponudnik

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

1: IzvediOdgovornost

Smer

Sporočilo

objektna analiza in na rtovanje47
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

- 571 -

objektna analiza in na rtovanje48

// IzvediOdgovornost

:Odjemalec

:Ponudnik

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
  • Na podlagi diagrama sodelovanja razdelimo odgovornosti

Diagram sodelovanja

Diagram razredov

Ponudnik

// IzvediOdgovornost

- 572 -

objektna analiza in na rtovanje49
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

- 573 -

objektna analiza in na rtovanje50
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

- 574 -

objektna analiza in na rtovanje51
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

?

razred brez odgovornosti

- 575 -

objektna analiza in na rtovanje52
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

- 576 -

objektna analiza in na rtovanje53

<<entity>>

IzbirniPredmet

<<entity>>

Urnik

<<entity>>

Študent

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
  • Agregacija: modelira odnos celota - del

Celota/agregat

del

0..4

0..*

1

0..*

glavniPredmet

0..*

0..2

dodatniPredmet

objektna analiza in na rtovanje54

Razred1

Razred2

Razred1

Razred2

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
  • Premislek
    • Kontekst, neodvisnost delov od celote?

asociacija

agragacija

Ko si v dvomih, uporabi asociacijo

objektna analiza in na rtovanje55
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.

- 579 -

objektna analiza in na rtovanje56

Razred1

Razred2

<<entity>>

Urnik

<<entity>>

Študent

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
  • Kompozicija:
  • Diskusija - kompozicija ali agregacija?

kompozicija

1

0..*

?

- 580 -

objektna analiza in na rtovanje57
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

Primera:

Kakšna je števnost?

objektna analiza in na rtovanje58
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

<<entity>>

UrnikIzbirniInfo

status

// označi kot izbran()

// označi kot neizbran()

// ali je izbran?()

dodatniPredmet

0..*

0..2

<<entity>>

<<entity>>

Urnik

IzbirniPredmet

glavniPredmet

0..*

0..4

<<entity>>

UrnikGlavniIzbirniInfo

ocena

// ali je izdelal?()

// vnesi oceno()

// vrni oceno()

objektna analiza in na rtovanje59
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav
  • Diskusija: Ali bi kje postavili kompozicijo/asociacijo?

- 583 -

objektna analiza in na rtovanje60

Odejmalec

Ponudnik

:Odjemalec

:Ponudnik

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

Diagram sodelovanja

1: izvediOdgovornost

Navigacija (pogojno!)

Povezava

Razredni diagram

0..*

0..*

Osnovni ponudniki

izvediOdgovornost()

Povezava v diagramu sodelovanja pomeni povezavo v razrednem diagramu !

objektna analiza in na rtovanje61
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!

- 585 -

objektna analiza in na rtovanje62
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

Diagram VOPC – View of participation classes

Pogled na razrede, ki sodelujejo v primeru uporabe

- 586 -

objektna analiza in na rtovanje63
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

- 587 -

objektna analiza in na rtovanje64

Razred analize

Sistemska storitev

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
  • Opiši lastnosti sistemskih storitev
objektna analiza in na rtovanje65
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – sistemske storitve
  • Preslikava med razredi in sistemskimi storitvami

Razred

Sistemska storitev

Prireditev

Trajnost

Termin

Trajnost

Vstopnica

Trajnost, Varnost?

Sedež

Trajnost

KKupiVstopnico

Porazdelitev

objektna analiza in na rtovanje66
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – sistemske storitve
  • Lastnosti sistemskih storitev
  • Trajnost za razredVstopnica:
    • Granulacija: od 15 do 25 bajtov
    • Kapaciteta: do10.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 rtovanje67
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?

- 591 -

objektna analiza in na rtovanje68
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

Ponovimo za vsak primer uporabe

- 592 -

objektna analiza in na rtovanje69
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe

- 593 -

objektna analiza in na rtovanje70
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

- 594 -

objektna analiza in na rtovanje71

<<boundary>>

<<control>>

<<entity>>

<<entity>>

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – poenotenje
objektna analiza in na rtovanje72
Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe - poenotenje

Rezultat poenotenja razredov je enoten načrt. Pogledi VOPC ševedno ostanejo, vendar uporabljajo skupne razrede.

- 596 -

objektna analiza in na rtovanje73

Model Načrta

Dodatne

Specifikacije

Slovar

Model Primerov Uporabe

Razredi Analize

Objektna analiza in načrtovanje
  • RUP – Koraki analize primerov uporabe – poenotenje
slide597
Poglavje VI

Načrtovanje podatkovnih baz

  • Tri-nivojsko načrtovanje
  • Konceptualno načrtovanje
  • Osnove relacijskega modela in logično načrtovanje
  • Normalizacija

- 598 -

trije nivoji na rtovanja trije modeli
Trije nivoji načrtovanja – trije modeli...
  • Konceptualno načrtovanje – konceptualni oz. semantični podatkovni model
  • Logično načrtovanje – logični podatkovni model
  • Kreiranje fizične podatkovne baze – fizična podatkovna baza oz. fizični podatkovni model

- 599 -

trije nivoji na rtovanja trije modeli1
Trije nivoji načrtovanja – trije modeli

i-CASE

Konceptualni

PM

  • Odločitev o PB:
  • Relacijska
  • Hierarhična
  • Objektna

Logični PM

Fizični PM

(skripta)

Reverse Engineering

SUPB

Podatkovna

baza

ODBC

- 600 -

konceptualno na rtovanje
Konceptualno načrtovanje
  • Konceptualno načrtovanje je opredelitev podatkovnih potreb oz. zahtev poslovne domene s pomočjo konceptualnega modela.
  • Konceptualno načrtovanje preko konceptualnega modela poskrbi za opis pomena podatkov, potrebnih za poslovno domeno.
  • Konceptualnega načrtovanja ne moremo avtomatizirati, za njegovo izvedbo je odgovoren analitik. Gre za prenos semantike v model.

- 601 -

pomen konceptualnega na rtovanja
Pomen konceptualnega načrtovanja
  • Je najbolj kritično – napake se prenašajo naprej na naslednje modele.
  • Zahteva sodelovanje uporabnikov. Uporabniki so nosilci znanja o poslovni domeni, so poznavalci semantike.
  • Konceptualno načrtovanje mora upoštevati tudi poslovna pravila.

- 602 -

umestitev konceptualnega na rtovanja

mentalni model

svet

konceptualni model

PB

logični model

Umestitev konceptualnega načrtovanja

- 603 -

predstavitev konceptualnih modelov
Predstavitev konceptualnih modelov
  • Najpogosteje uporabljana tehnika za predstavitev konceptualnih podatkovnih modelov sta diagram entiteta-razmerje ter razredni diagram. Obravnavali bomo prvega!
  • Nazivi, ki se uporabljajo:
    • Konceptualni podatkovni model
    • Podatkovni model
    • Entitetni model
    • ER model
  • Obstaja tudi razširjeni model entiteta razmerje

- 604 -

gradniki entitetnega modela
Gradniki entitetnega modela
  • Entitetni tip
  • Atribut
  • Razmerje
  • Enolični identifikator

- 605 -

entitetni tip entiteta
Entitetni tip – entiteta...
  • Entitete so posamezni primerki tipov objektov iz poslovne domene: dogodki, predmeti, osebe, pravila, dejstva
  • O entitetah obstaja določena predstava o tem:
    • kakšne lastnosti dejansko imajo
    • kakšne lastnosti jim moramo določiti (morajo imeti), da bodo izpolnjevale poslanstvo entitetnega modela
  • Na osnovi predstave o tem in percepcije, lahko entitete klasificiramo v entitetne tipe: vse entitete, ki ustrezajo določeni predstavi, pripadajo posameznemu entitetnemu tipu.

- 606 -

entitetni tip entiteta1
Entitetni tip – entiteta
  • Vsak trenutek pripada posameznemu entitetnemu tipu množica entitet tega entitetnega tipa, ki jo imenujemo entitetna množica
  • Entitetna množica je časovno spremenljiva: entitete nastajajo, se spreminjajo in tudi izginjajo (izstopajo iz množice).
  • Entitetna množica je v nekem trenutku lahko tudi prazna.

- 607 -

atribut
Atribut...
  • Entitete imajo določene lastnosti, posamezne entitete (istega entitetnega tipa) se med seboj razlikujejo po vrednosti njihovih lastnosti
  • Entiteta ima praviloma veliko lastnosti, le del teh lastnosti je zanimiv oz. pomemben za opazovano poslovno domeno
  • Lastnosti, ki so pomembne za opazovano poslovno domeno, vključimo v konceptualni model tako, da jih kot atribute določimo entiteti (entitetnemu tipu)

- 609 -

atribut1
Atribut...
  • Govorimo lahko o več vrstah lastnosti:
    • Entitetna imena: naziv, ime, opis
    • Prave entitetne lastnosti: višina, teža, cena, vrednost
    • Lastnosti, ki jih določimo za potrebe poslovnih procesov, poslovnih funkcij in poslovnih pravil: statusi
  • Atribut določimo za tisto lastnost, ki je za poslovno domeno pomembna

- 610 -

atribut2

(1,1)

EMŠO

OSEBA

(1,3)

Ime

(1,1)

Priimek

(0,n)

Vzdevek

Atribut
  • Kardinalnost atributa je minimalna in maksimalna Glede na kardinalnost atributa ločimo:
    • Totalni atribut (1,n), kjer je n >= 1
    • Parcialni atribut (0,n), kjer je n >= 1
    • Enovrednostni atribut (m,1), kjer je m € {0,1}
    • Večvrednostni atribut (m,n), kjer je m € {0,1} in n>1
  • Minimalna števnost 0 pomeni, da je atribut lahko brez vrednosti (ni obvezen).
  • Atribut pripada določenemu tipu: numerični, znakovni,…
  • Za večino tipov je potrebno določiti tudi dolžino.

- 611 -

predstavitev atributa

(1,1)

EMŠO

OSEBA

(1,3)

Ime

(1,1)

Priimek

(0,n)

Vzdevek

Predstavitev atributa

OSEBA

EMŠO

Ime

Priimek

Vzdevek

- 612 -

razmerja med entitetami
Razmerja med entitetami
  • Entitete niso svet zase, medsebojno se povezujejo preko razmerij, povezav
  • Razmerje ima določen pomen
  • Predstavitev razmerja v modelu entiteta-razmerje je povezava.
  • Med opazovanim parom (v splošnem podmnožici) entitet je lahko več razmerij: OSEBA, KRAJ – stalno bivališče, začasno bivališče

- 613 -

predstavitev razmerja
Predstavitev razmerja...

OSEBA

živi

KRAJ

živi

OSEBA

KRAJ

Pomen razmerja

- 614 -

predstavitev razmerja1
Predstavitev razmerja

OSEBA

živi

KRAJ

živi v

ima

OSEBA

KRAJ

Vloga entitete v razmerju

- 615 -

kardinalnost razmerja
Kardinalnost razmerja...
  • Kardinalnost (števnost) predstavlja število entitet entitetnega tipa, ki so v razmerju glede na pomen razmerja.
  • Vsaka entiteta ima svojo kardinalnost v razmerju – kardinalnost glede na vlogo. Entiteti OSEBA, POŠTA:
    • Ena (naključno izbrana) oseba ima stalno bivališče v enem kraju
    • V enem (naključno izbranem) kraju ima stalno bivališče več oseb

- 616 -

kardinalnost razmerja1
Kardinalnost razmerja...

A

(n,m)

povezava

(p,r)

B

- 617 -

obveznost razmerja
Obveznost razmerja
  • Obveznost pove, ali sta dve entiteti vedno v razmerju ali lahko tudi nista v razmerju: obvezno, neobvezno razmerje
  • Obveznost lahko obravnavamo pod okriljem števnosti, zaradi česar dodatno uvedemo števnost 0

- 619 -

razmerje tudi opisuje lastnost entitete
Razmerje tudi opisuje lastnost entitete
  • Razmerje tudi opisuje lastnost entitete
  • Primer: OSEBA, POŠTA
  • Razmerje ima atributiven značaj

- 620 -

enoli ni identifikator entitete
Enolični identifikator entitete...
  • Enolični identifikator entitete je podmnožica lastnosti entitete (atributov in razmerij – drugih entitet), ki enolično razlikujejo posamezno instanco entitete znotraj entitetne množice
  • Z ozirom na to, ali tvorijo enolični identifikator entitete le atributi entitete ali pa je v enoličnem identifikatorju tudi kakšno razmerje, ločimo med močnim entitetnim tipom in šibkim entitetnim tipom

- 621 -

enoli ni identifikator entitete1
Enolični identifikator entitete
  • Imamo lahko več enoličnih identifikatorjev, vendar moramo enega izbrati – določiti
  • Izbrani – določeni enolični identifikator je podlaga za ključ v relacijskem modelu

- 622 -

predstavitev enoli nega identifikatorja

(1,1)

EMŠO

OSEBA

(1,3)

Ime

(1,1)

Priimek

(0,n)

Vzdevek

Predstavitev enoličnega identifikatorja

OSEBA

EMŠO

Ime

Priimek

Vzdevek

- 623 -

mo ni entitetni tip
Močni entitetni tip
  • Enolični identifikator sestavljajo le atributi entitete (identifikacijski atributi)
  • {a1, … ak} je enolični identifikator entitete A, če ustreza naslednjim pogojem:
    • a1, … akso vsi totalni enovrednostni atributi, kar zagotavlja, da imajo vsi identifikacijski atributi definirano natanko eno vrednost (eno dimenzijo)
    • T: V1 x …x Vk ET je totalna ali parcialna enovrednostna funkcija, kar zagotavlja, da se vsak element kartezijskega produkta vrednostnih množic, ki so območja identifikacijskih atributov, preslika v največ eno entiteto tipa A
    • Je minimalna podmnožica, ne obstaja prava podmnožica, za katero bi tudi veljal pogoj b)

- 624 -

ibki entitetni tip
Šibki entitetni tip
  • Enolični identifikator ni sestavljen le iz lastnih atributov, temveč tudi iz razmerij oz. drugih entitet v razmerju oz. njenih identifikatorjev.
  • {a1, … ak}  IT1 ..  ITn je enolični identifikator entitete A, če ustreza naslednjim pogojem:
    • a1, … akso vsi totalni enovrednostni atributi, I pa identifikatorji entitetnih tipov
    • T: V1 x …x Vkx ET1 x .. X ETn ET je totalna ali parcialna enovrednostna funkcija, kar zagotavlja, da se vsak element kartezijskega produkta vrednostnih množic, ki so območja identifikacijskih atributov, preslika v največ eno entiteto tipa A
    • Je minimalna podmnožica, ne obstaja prava podmnožica, za katero bi tudi veljal pogoj b)

- 625 -

generalizacija in specializacija
Generalizacija in specializacija...
  • Entitetni tip A s podtipoma B in C
  • B in C pokrivata A totalno in ekskluzivno, če velja: EB  EC = EA in EB  EC = {}
  • B in C pokrivata A totalno in prekrivno, če velja: EB  EC = EA in EB  EC ≠ {}
  • B in C pokrivata A delno in ekskluzivno, če velja: EB  EC  EA in EB  EC = {}
  • B in C pokrivata A delno in prekrivno, če velja: EB  EC  EA in EB  EC ≠ {}

- 626 -

generalizacija in specializacija1
Generalizacija in specializacija

OSEBA

Totalno in ekskluzivno

MOŠKI

ŽENSKA

OSEBA

Delno in prekrivno

ŠTUDENT

ŠPORTNIK

- 627 -

konceptualni model

V konceptualnem modelu

lahko nastopajo tudi sestavljeni

in večvrednostni atributi!

Konceptualni model

Primer konceptualnega modela

Študent

Vpisna številka

Priimek

Ime

Naslov

Telefon

E-mail

Status

?

Predmet

Predmet

Naziv

Dodatne obveznosti

Semester

Kreditne točke

Izpit

Zap. št. polaganja

Ocena pisno

Ocena ustno

Datum ocene

Delavec

Rok

Prijava

Delavec

Priimek

Ime

E-mail

Geslo

Rok

Datum izpita

Prijavljenih

Maks. prijavljenih

Meja pozitivno

Datum prijave

Datum odjave

Zap. št. polaganja

Kolokvij

Letnik

Plača izpit

- 628 -

logi no na rtovanje podatkovne baze
Logično načrtovanje podatkovne baze...
  • 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

svet

konceptualni model

PB

logični model

- 629 -

podpora orodij case

Logično načrtovanje

Podpora orodij CASE

i-CASE

Konceptualni

PM

  • Odločitev o PB:
  • Relacijska
  • Hierarhična
  • Objektna

Logični PM

Fizični PM

(skripta)

Reverse Engineering

SUPB

Podatkovna

baza

ODBC

- 630 -

prehod iz konceptualnega v logi ni model

ANALIZA

NAČRTOVANJE

Konceptualni model

Relacijski model

Entitetni tip

Relacija / Tabela

Atribut

Atribut / Stolpec

Enolični identifikator

Ključ

Povezava 1:n

Tuji ključ

Povezava m:n

Vmesna tabela

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

- 631 -

relacijski podatkovni model
Relacijski podatkovni model

Primer pretvorbe konceptualnega v relacijski model

Student

Študent

Vpisna številka

Priimek

Ime

Naslov

Telefon

E-mail

Status

VpisSt N8 <pk>

Priimek C20

Ime C20

Ulica C25

Posta N4

Drzava C20

GSM N15

Tel N15

Email C25 null

Status N1

Izpit

Izpit

VpisSt = VpisSt

ZapStPol N2 <pk>

VpisSt N8 <pk, fk>

OcPisno N2,2

OcUstno N2,2

DatumOc D

Zap. št. polaganja

Ocena pisno

Ocena ustno

Datum ocene

- 632 -

funkcionalne odvisnosti
Funkcionalne odvisnosti...
  • Predpostavimo, da obstaja relacijska shema R z množico atributov, katere podmnožici sta X in Y.
  • V relacijski shemi R velja X  Y (X funkcionalno določa Y oziroma Y je funkcionalno odvisen od X), če v nobeni relaciji, ki pripada shemi R, ne obstajata dve n-terici, ki bi se ujemali v vrednostih atributov X in se ne bi ujemali v vrednostih atributov Y.

- 633 -

funkcionalne odvisnosti1
Funkcionalne odvisnosti
  • Množico funkcionalnih odvisnosti, ki veljajo med atributi funkcionalne sheme R in v vseh njenih relacijah, označimo s F

X  Y  F   r ( Sh(r) = R   t,  u (t  r in u  r in

t.X = u.X  t.Y = u.Y )

kjer

t.X, u.X, t.Y in u.Y označujejo vrednosti atributov X

oziroma Y v n-tericah t oziroma u.

- 634 -

primeri funkcionalnih odvisnosti
Primeri funkcionalnih odvisnosti
  • Imamo relacijo s shemo
    • Izpit( VpŠt, Priimek, Ime, ŠifraPredmeta, Datum izpita,
    • 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 relacijske sheme Izpit so:

F  { VpŠt  (Priimek, Ime), (VpŠt, ŠifraPredmeta,

DatumIzpita)  (OcenaPisno, OcenaUstno) }

- 635 -

klju i relacije
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.

- 636 -

klju i relacije1
Ključi relacije...
  • Predpostavimo, da obstaja relacijska shema z atributi A1 A2 ... An katere podmnožica je množica atributov X.
  • Atributi X so ključ relacijske sheme oziroma pripadajočih relacij, če sta izpolnjena naslednja dva pogoja:
    • X  A1 A2 ... An
    • ne obstaja X’, ki bi bila prava podmnožica od X in ki bi tudi funkcionalno določala A1 A2 ... An

- 637 -

klju i relacije2
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.

- 638 -

klju i relacije3
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.

- 639 -

primeri klju ev

Primarni ključ v tabeli Artikel

Primarni ključ v tabeli Račun

Tuji ključ v tabeli Račun  kaže na primarni ključ v tabeli Artikel

Primeri ključev

ARTIKEL

RAČUN

- 640 -

normalizacija
Normalizacija...
  • Kaj si bomo pogledali?
    • Namen normalizacije.
    • Uporaba normalizacije pri načrtovanju relacijske podatkovne baze.
    • Problemi zaradi redundance podatkov v osnovnih relacijah.
    • Postopek normalizacije.
    • Osnovne normalne oblike:
      • I. normalna oblika,
      • II. Normalna oblika,
      • III. Normalna oblika
      • IV. Poslovna normalna oblika

- 641 -

namen normalizacije
Namen normalizacije...
  • 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.

- 642 -

prednosti pravilnega na rtovanja
Prednosti pravilnega načrtovanja
  • Osnovni cilj načrtovanja relacijske podatkovne baze je grupirati atribute v relacije tako, da bo čim manj redundance med podatki.
  • Potencialne koristi pravilnega načrtovanja so:
    • Spremembe podatkov v podatkovni bazi dosežemo z minimalnim številom operacij  večja učinkovitost; manj možnosti za podatkovne nekonsistentnosti.
    • Manjše potrebe po diskovnih kapacitetah za shranjevanje osnovnih relacij  manjši stroški.

- 643 -

primer1

Atribut z odvečnimi (ponavljajočimi) podatki

Primer
  • Relacija StaffBranch ima odvečne podatke.

- 644 -

a urne anomalije
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

- 645 -

anomalije pri dodajanju
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.

- 646 -

anomalije pri brisanju
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.

- 647 -

anomalije pri spreminjanju
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.

- 648 -

postopek normalizacije
Postopek normalizacije
  • Postopku preoblikovanja relacij v obliko, pri kateri do ažurnih anomalij ne more priti, pravimo normalizacija.
  • Obstaja več stopenj normalnih oblik. Obravnavali bomo:
    • 1NO – Prva normalna oblika
    • 2NO – Druga normalna oblika
    • 3NO – Tretja normalna oblika in
    • 4PNO – Četrta poslovna normalna oblika

- 649 -

1no prva normalna oblika
1NO – prva normalna oblika
  • Relacija je v prvi normalni obliki, če:
    • Nima ponavljajočih atributov  ne obstajajo atributi ali skupine atributov, ki bi imele več vrednosti pri isti vrednosti ostalih atributov (na presečišču ene vrstice in enega stolpca je več vrednosti)
    • Ima definiran primarni ključ in določene funkcionalne odvisnosti
  • Koraki:
    • Odstranimo ponavljajoče atribute
    • Določimo funkcionalne odvisnosti
    • Določimo primarni ključ

- 650 -

primer relacija v nenormalizirani obliki

Skupina ponavljajočih se atributov.

Primer – relacija v nenormalizirani obliki

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

- 651 -

primer pretvorba v 1no

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  naziv, pošta  kraj, (VŠ, šifra predmeta)  ocena }

Določimo primarni ključ

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

Primer – pretvorba v 1NO...

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

- 652 -

2no druga normalna oblika
2NO – druga normalna oblika
  • Relacija je v drugi normalni obliki:
    • Če je v prvi normalni obliki in
    • Ne vsebuje parcialnih odvisnosti  noben atribut, ki ni del ključa, ni funkcionalno odvisen le od dela primarnega ključa, temveč od celotnega ključa
  • Druga normalna oblika je odvisna predvsem od ključa relacije. Relacija je avtomatsko v drugi normalni obliki, če:
    • Je njen primarni ključ sestavljen le iz enega atributa,
    • Je njen primarni ključ sestavljen iz vseh atributov relacije ali
    • Je njen primarni ključ sestavljen iz vseh razen enega atributa relacije

- 654 -

primer pretvorba v 2no

Relacijo razbijemo

Študent( VŠ, priimek, ime, pošta, kraj)

Predmet( šifra predmeta, naziv)

Indeks( #VŠ, #šifra predmeta, ocena)

Primer – pretvorba v 2NO...

!

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

!

- 655 -

3no tretja normalna oblika
3NO – tretja normalna oblika
  • Relacija je v tretji normalni obliki:
    • Če je v drugi normalni obliki in
    • Če ne vsebuje tranzitivnih funkcionalnih odvisnosti  med atributi, ki niso del primarnega ključa, ni odvisnosti.
  • Relacija je avtomatsko v tretji normalni obliki, če:
    • Je njen ključ sestavljen iz vseh atributov relacije
    • Je njen ključ sestavljen iz vseh razen enega atributa relacije.

- 657 -

primer pretvorba v 3no

!

Relacijo razbijemo

Študent( VŠ, priimek, ime, #pošta)

Pošta(pošta, kraj)

Predmet( šifra predmeta, naziv)

Indeks( #VŠ, #šifra predmeta, ocena)

Primer – pretvorba v 3NO...

Študent( VŠ, priimek, ime, pošta, kraj)

Predmet( šifra predmeta, naziv)

Indeks( #VŠ, #šifra predmeta, ocena)

- 658 -

4pno etrta poslovna normalna oblika
4PNO – č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.

- 660 -

primer pretvorba v 4pno

Za izredne študenta

Za redne študenta

Študent( VŠ, priimek, ime, #pošta)

Redni študent( #VŠ, rok diplome)

Izredni študent( #VŠ, datum plačila šolnine)

Primer – pretvorba v 4PNO...

Študent( VŠ, priimek, ime, #pošta, datum plačila šolnine, rok diplome)

- 661 -

uporaba nenormaliziranih relacij
Uporaba nenormaliziranih relacij...
  • Včasih zavestno uporabljamo relacije, ki ne ustrezajo najvišjim normalnim oblikam.
  • Prve in druge normalne oblike nikoli ne kršimo.
  • Višjim normalnim oblikam se včasih odrečemo na račun doseganja boljše učinkovitosti.

- 663 -

uporaba nenormaliziranih relacij1
Uporaba nenormaliziranih relacij
  • Primer:
    • Rezultat (športnik, tekmovanje, čas prvega teka, čas drugega teka, čas skupaj)
    • Relacija ni v tretji normalni formi.
    • Čas skupaj je izpeljan atribut  ni odvisen od ključa, temveč je seštevek časov obeh tekov.
    • Skupen čas računamo ob vpisu v bazo, zato izboljšamo učinkovitost pri nadaljnji obdelavi podatkov.

- 664 -

na rtovanje fizi ne podatkovne baze
Načrtovanje fizične podatkovne baze...
  • Načrtovanje fizične PB je korak, ki sledi logičnemu načrtovanju.
  • Vhod v načrtovanje fizične PB so:
    • Logični podatkovni model,
    • Relacijska shema
    • dokumentacija

mentalni model

svet

konceptualni model

PB

logični model

- 665 -

na rtovanje fizi ne podatkovne baze1

Načrtovanje fizične PB

Načrtovanje fizične podatkovne baze...

i-CASE

Konceptualni

PM

  • Odločitev o PB:
  • Relacijska
  • Hierarhična
  • Objektna

Logični PM

Fizični PM

(skripta)

Reverse Engineering

SUPB

Podatkovna

baza

ODBC

- 666 -

na rtovanje fizi ne podatkovne baze2
Načrtovanje fizične podatkovne baze
  • Fizično načrtovanje PB opredeljuje proces, s katerim izdelamo opis implementacije PB na sekundarnem pomnilnem mediju.
  • Opisuje
    • osnovne relacije,
    • datotečno organizacijo,
    • indekse za dosego učinkovitega dostopa do podatkov,
    • povezane omejitve in
    • varnostne mehanizme.

- 667 -