Razvoj informacijskih sistemov

Razvoj informacijskih sistemovVisokošolski strokovni študij

UNIVERZA V LJUBLJANIFakulteta za računalništvo in informatiko

Doc. dr. Marko Bajec

Študijsko gradivo, verzija 2.3

Splošne informacije... Predavatelj

Doc. dr. Marko Bajec, univ. dipl. ing. Elektronska pošta: [email protected] Informacije: http://infolab.fri.uni-lj.si/marko/

Asistent As. dr. Damjan Vavpotič, univ. dipl. ing. Elektronska pošta: [email protected] Informacije: http://aris.fri.uni-lj.si/~damjan/

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

- 2 -

http

http

mailto:[email protected]

mailto:[email protected]

Splošne informacije Predavanja

Vsak ponedeljek od 10:15 do 13:00 (3 šolske ure); Predavanja so obvezna!

Izpit Seminarska naloga (predpogoj) Pisni izpit Ustni izpit


- 3 -

Priporočena literatura… Objektni razvoj (UML in RUP)

[1] Martin Fowler (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition. Addison-Wesley.

[2] Thomas A. Pender (2002). UML Weekend Crash Course. Wiley Publishing.

[3] Booch, G., J. Rumbaugh in I. Jacobson (1999). The Unified Software Development Process. Addison Wesley.


- 4 -

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

Priporočena literatura… Agilne in lahke metodlogije

[4] Kent Beck (1999). Extreme Programming Explained: Embrace Change, Addison-Wesley.

[5] Martin, C. Robert (2003). Agile Software Development: Principles, Patterns and Practices. Prentice Hall.

[6] Cockburn, A (2002). Agile Software Development. Pearson Education.


- 5 -

Priporočena literatura Splošno o razvoju IS

[7] Silič Marin et al (2000). EMRIS - Enotna metodologija razvoja informacijskih sistemov. Ljubljana: Vlada RS, CVI.

[8] Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise (2004). MDA Distilled: Principles of Model-Driven Architecture. Addison-Wesley.

[9] Hoffer, J. A., George, J. F. in Valacich, J. S. (1999). Modern Systems Analysis and Design, Second edition, Addison-Wesley

Avison, D. E. in Fitzgerald, G. (2003). Information systems development: methodologies, techniques and tools, McGraw-Hill, London.


- 6 -

Vsebina predmeta… I. Splošno o razvoju IS

Osnovni pojmi Življenjski modeli razvoja IS

Metodologije razvoja IS Definicija metodologije Zgradba metodologije Zgodovina nastajanja metodologij Formalizacija metodologij Komercialne metodologije Vrste metodologij Izbira metodologije


- 7 -

II

Infolab

* Kaj je metodologija* Vrste metodologij (objektne, strukturne,....)* Teža metodologije (lahke, agilne)

Vsebina predmeta II. Strukturni razvoj

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


- 8 -

Vsebina predmeta III. Objektni razvoj

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

IV. Modelno usmerjen razvoj MDA – Model Driven Architecture in MDD – Model-

Driven Development. Razlike med MDA/MDD in klasičnim pristopom k

razvoju IS


- 9 -

Poglavje ISplošno o razvoju IS


- 10 -

Osnovni pojmi Življenjski modeli razvoja IS Metodologije razvoja IS

Informacijski sistem… Definicija:

Informacijski sistem lahko opredelimo kot množico medsebojno odvisnih komponent (strojna oprema, programska oprema, ljudje), ki zbirajo, procesirajo, hranijo in porazdeljujejo podatke in s tem podpirajo delavne procese v organizaciji.

Ločimo formalne in neformalne IS.

IS je lahko računalniško podprt.


- 11 -

Ponovitev

P1.1 – Osnovni pojmi

IS - opredelitev

Informacijski sistem… Vrste IS:

Transakcijski IS (TPS-Transaction Processing System) Upravljalski (poslovodni) IS (MIS-Management Information

System) Direktorski IS (ESS-Executive Support System) Odločitveni IS (DSS-Decision Support System) Ekspertni IS (EIS-Expert Information System) Sistemi za avtomatizacijo pisarniškega poslovanja

(OAS-Office Automation System) Sistemi za podporo delovnim procesom (WfS-Workflow

Management System)


- 12 -

PonovitevVrste IS

Kaj nas zanima pri razvoju IS?... V okviru razvoja IS nas zanima, kako razviti

računalniške rešitve, ki bodo čim bolje podprle delovanje IS.

V okviru razvoja IS se ukvarjamo z: Razvojem računalniške rešitve Nabavo ustrezne strojne opreme Namestitvijo sistemske programske opreme Uvedbo rešitve Vzdrževanjem rešitve


- 13 -

Kaj nas zanima pri razvoju IS? Razvoj IS ni zgolj programiranje! Ni zgolj inženirsko delo…

Pri razvoju IS imajo velik pomen tudi sociološki dejavniki: Kako dojemamo problematiko? Kako razumemo potrebe uporabnikov? Kako uvedemo rešitve v prakso? …


- 14 -

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

Razvoj IS in vrste IS Pristop k razvoju IS je odvisen tudi od vrste

IS. Nekatere vrste IS zahtevajo specifične

pristope: Ekspertni sistemi Odločitveni sistemi Sistemi za podporo delovnim procesom

Največ napora gre še vedno za razvoj IS za podporo operativnem delovanjuPS.


- 15 -

Strateška raven

Taktična raven

Operativna raven

Sinonimi za računalniške programe V okviru razvoja IS med drugim nastanejo

računalniški programi.

Izraz “Računalniški program” ima številne sinonime: Program Aplikacija Aplikativni sistem Informacijska rešitev Računalniška rešitev …


- 16 -

Terminologija

Življenjski modeli razvoja IS… Razvoj IS zajema številna opravila,

navadno razdeljena v faze: Analiza Načrtovanje Implementacija Testiranje Uvedba Vzdrževanje

Življenjski model razvoja IS (SDLC*) pove, v kakšnem sosledju in na kakšen način si v okviru razvoja IS sledijo posamezne faze.


- 17 -

P1.2 – Življenjski modeli razvoja IS

* SDLC - System Development Life Cycle

Kot večina razvojnih procesov sledi tudi razvoj IS določenemu življenjskemu ciklu oziroma razvojnemu modelu, ki določa zaporedje faz razvoja.

Življenjski modeli razvoja IS… Poznamo različne življenjske modele:

Zaporedni ali slapovni model Interativni model Prototipni model Inkrementalni model

V praksi se večinoma uporablja kombinacija različnih modelov.


- 18 -

Zaporedni ali slapovni model… Zaporedni ali slapovni model temelji na

zaporednem izvajanju faz. Ko se ena faza v celoti konča, se začne

naslednja.


- 19 -

Analiza

Načrtovanje

Izvedba

Uvedba

Spec. zahtev

Načrt

Koda

testiranje

čas

Zaporedni ali slapovni model… Značilnosti:

Najstarejši razvojni model, značilen za prve oblike strukturnega pristopa.

Faze si sledijo zaporedno. Vračanje nazaj ni mogoče. Primeren za relativno kompleksne projekte, če

zahteve dobro razumemo in se med projektom ne bodo bistveno spreminjale.

Omogoča dobro in natančno projektno vodenje.


- 20 -

Zaporedni ali slapovni model… Prednosti:

Pomaga zmanjševati količino režijskega dela, ki ni v neposredni povezavi z izdelavo programske opreme (npr. vodenje projekta), saj je mogoče načrtovanje v celoti izvesti vnaprej.

Slabosti: Ni fleksibilen. Vsaka naknadna sprememba zahteva

veliko dodatnega napora. Nenaraven: v praksi težko pričakovati, da se lahko

nek postopek v celoti zaključiti, preden se začne z naslednjim.

Ne omogoča paralelnega izvajanja delov postopkov.


- 21 -

Zaporedni ali slapovni model Zaradi kritik pojav modificiranih različic

slapovnega razvoja. Odprava nekaterih pomanjkljivost:

uvedba bolj enostavnega prehajanja med postopki, paralelno izvajanje delov različnih postopkov, ...

Slapovni model kljub vsemu nudi zelo čvrsto oporo sistematičnemu razvoju.

Možno uporabiti v kombinaciji z drugimi modeli.


- 22 -

Iterativni model… Razvit kot odziv na pomanjkljivosti

slapovnega pristopa. Faze razvoja izvajamo v več iteracijah.


- 23 -

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

Iteracija

Iterativni model… V vsaki iteraciji razvijemo določen del

funkcionalnosti celotnega sistema. Iteracija gre navadno čez vse faze razvoja:

analizo, načrt, izvedbo… V začetnih iteracijah razvijemo najbolj

tvegane dele sistema.

Gre za evolucijski razvoj.


- 24 -

Iterativni model…


- 25 -

Analiza

izdelki

testiranje

čas

Načrtovanje Izvedba Uvedba

Učenje in izkušnje

Iteracija #1

Analiza

izdelki

Načrtovanje Izvedba Uvedba

Učenje in izkušnje

Iteracija #2testiranje

AnalizaIteracija #3

Tipično trajanje ene iteracije: 7 do 14 dni

Iterativni model… Lastnosti iteracij:

Trajanje: od 7 do 14 dni (tipično) Vsaka iteracija gre čez vse faze (ne z enako

intenzivnostjo) Naslednja iteracija se lahko začne šele takrat, ko je

prejšnja končana. Vsebina naslednje iteracija je določena na osnovi

rezultatov prejšnje. Med izvajanjem iteracije ne sprejemamo sprememb.


- 26 -

Planiranje na makro in mikro ravni


- 27 -

R1 R2 R3

Projectstart

S

Projectend

E

1. Release Planning

cca 2-4 months

2. Iteration Planning

R1 R2I1 I2 I3 I4

cca 2 weeks

3. Task Planning

I1 I2?

SALSD Requirements Miniature milestones – task list

Iterativni model… Prednosti:

Prednosti iterativnega razvoja (proti zaporednemu): Najbolj tvegani deli so razrešeni še preden postane

investicija velika Začetne iteracije omogočijo zgodnje povratne

informacije s strani uporabnikov Preizkušanje in povezovanje v sistem sta

nepretrgana Ciljni mejniki omogočajo kratkoročno osredotočenje Napredek merimo z ocenjevanjem izvedenega dela Možna je predaja izvedenega dela projekta še preden

je dokončan celoten projekt


- 28 -

Iterativni model Slabosti:

ne omogoča dobrega načrtovanja poteka projekta. ni mogoče točno predvideti, koliko iteracij bo

potrebnih za razvoj dokončnega (dovolj dobrega) izdelka.

vodenje projekta je zahtevno.


- 29 -

Prototipni model… Gre za različico iterativnega modela. Temelji na izdelavi prototipov in njihovi

postopni izboljšavi, dokler ne dosežemo zadovoljive kakovosti.


- 30 -

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

Prototip

Prototipni model


- 31 -

Analizaproblema

Razvoj prototipa

Uporaba in testiranje prototipa

Revizija inIzboljšavaprototipa

Začetnezahteve

Delovniprototip

Problemi,Napaka,pomanjkljivosti

Novprototip Nove zahteve

Iteracije(evoluativni razvoj)

Inkrementalni model… Temelji na postopni gradnji celotne IR in

sprotni predaji posameznih inkrementov uporabniku.

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


- 32 -

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

Inkrement

Inkrementalni model… Ne razvijamo celotne IR hkrati. Omejimo se

na posamezen inkrement, ki ga razvijemo v celoti, predamo uporabniku ter nadaljujemo z naslednjim sklopom.

Ob predaji novi sklop povežemo z ostalimi sklopi.

Inkremente je moč razvijati tudi vzporedno.

Rezultat razvoja po inkrementalnem modelu je IR, sestavljena iz integriranih sklopov.


- 33 -

Inkrementalni model…


- 34 -

Razvoj in predajaprvega sklopa IR

čas

Razvoj celotne IR

Razvoj in predajadrugega sklopa IR

Razvoj in predajatretjega sklopa IR

Klasičen razvoj

Inkrementalni razvoj

Inkrement #1 Inkrement #2 Inkrement #3

Uvedba intestiranje

sklopa

Uvedba intestiranje

sklopa

Uvedba intestiranje

sklopa

Uvedba intestiranjecelotnega

sistema

Inkrementalni model… Priporočeno določiti ustrezen razpored

razvoja sklopov. Zaporedje lahko določimo na različne

načine: na podlagi pomembnosti sklopov, na podlagi upoštevanja tveganja,…

Pri razporejanju sklopov na osnovi pomembnosti najprej razporedimo sklope z najpomembnejšo funkcionalnostjo. Na tak način funkcionalnost postopno nadgrajujemo do končnega sistema.


- 35 -

Inkrementalni model… Pri razporejanju sklopov glede na

pomembnost lahko uporabimo analizo MOSCOW, kjer funkcionalnosti IR razdelimo na:

funkcije, ki jih je nujno potrebno implementirati, funkcije, ki bi jih bilo dobro implementirati, funkcije, ki bi jih lahko implementirali – niso obvezne

in funkcije, ki jih ne bomo implementirali.


- 36 -

Inkrementalni model… Na podlagi analize MOSCOW lahko funkcije

sistema ustrezno časovno razporedimo. Pri razporejanju sklopov upoštevajoč tveganost (v

smislu tveganja, da razvit sklop ne bo ustrezal naročniku) najprej razvijemo najbolj tvegane in zahtevne sklope, kar omogoča hitrejše znižanje stopnje tveganja pri celotnem projektu


- 37 -

Skl

op 1

Skl

op 2

Skl

op 3

Tveg

anje

Čas

Skl

op 4

tveganost projekta

tveg

anos

t skl

opa

Skl

op 1

Skl

op 2

Skl

op 3

Tveg

anje

Čas

Skl

op 4

tveganost projekta

tveg

anos

t skl

opa

Inkrementalni model… Prednosti:

Uporabnik prej dobi del zahtevane IR, saj se IR razvija po delih.

Rešitev, ki jo uporablja, se postopoma nadgrajuje, sam pa lahko sodeluje pri testiranju razvitih sklopov.

Naročnik laže sledi napredovanju projekta. Slabosti:

Ni mogoče uporabiti pri vseh projektih. Nekaterih rešitev ni moč predati v uporabo po delih.

IR moramo razdeliti na sklope in predvideti odvisnosti med njimi. Pri neustreznem načrtovanju se lahko zgodi, da sklope neustrezno razporedimo.


- 38 -

Inkrementalni model Poseben primer inkrementalnega modela

je razdelitev vsebine na samostojne projekte.

Inkrementalni model možno učinkovito uporabiti v kombinaciji z iterativnim modelom: razdelitev na inkremente, vsak inkrement se izvaja iterativno.


- 39 -

Kaj je metodologija razvoja IS? Nekaj definicij:

Metodologija je priporočena zbirka filozofij, faz, postopkov, pravil, tehnik, orodij, dokumentacije, upravljanja in izobraževanja za razvijalce IS (Maddison).

Metodologija razvoja IS je priporočen način razvoja IS, ki temelji na filozofiji in množici principov (Avison, 2003).

Metodologija je množica dogovorov (konvencij), s katerimi se (projektna) skupina/organizacija strinja (Cockburn, 2002).

Metodologija je vse kar redno delamo, da bi dosegli končni rezultat – delujoča PO pri končnem uporabniku (Cockburn, 2002).


- 40 -

MetodologijaProces

Tehnika

Orodje Standard

Filozofija

Izkušnja

Skrito znanje

P1.3 – Metodologije razvoja IS

Kaj je metodologija razvoja IS? Iz terminološkega slovarja:

METODOLOGIJA: skupek metod, postopkov in standardov, ki sestavljajo zaključeno celoto pri izvajanju inženirskih pristopov k razvoju produkta.

METODA: seznam postopkov in pravil za izvedbo določene naloge.

METODOLOGIJA RAZVOJA IS: postopen način razvoja informacijskega sistema, ki vključuje uporabo različnih tehnik in orodij, celovit v smislu korakov življenjskega cikla razvoja


- 41 -

http://www.islovar.org/

2. Osnovna zgradba metodologij

Proces

Postopek

Aktivnost PodizdelekVloga

OrodjeStandard

vhod

izhod

Izkušnje inznanje

Metodologija

Življenjskicikel

Faza

Tehnika

Filozofija

Podatkovnatehnika

Procesnatehnika

OO tehnika

Tehnika proj.vodenja

Organizacijskatehnika

Tehnika dela zljudmi

Celostnatehnika

Osrednjipostopek

Podpornipostopek

Iteracija

Paradigmametodologije

Ciljmetodologije

Domenametodologije

Sociološkakomponenta

Izdelek

Različica

Predloga

Primer

Slapovni

Iterativni

Inkrementalni

Inkrement

Del izdelka

Uporabnost inizkušnje

Izobraževanje

Metdologijakot izdelek

Bazauporabnikov

Zahtevnostmetodologje

Namenmetodologije

[inkrementalno-iterativni razvoj]

Ozadjemetodologije


- 42 -

Proces

Postopek

Aktivnost PodizdelekVloga

OrodjeStandard

vhodizhod

Izkušnje inznanje

Metodologija

Življenjskicikel

Tehnika

Filozofija

Izdelek

Uporabnostin izkušnje

Proces

Postopek

Aktivnost PodizdelekVlogavhod

izhod

Izkušnje inznanje

Življenjskicikel

Faza

Osrednjipostopek

Podpornipostopek

Iteracija

Izdelek

Različica

Predloga

Primer

Slapovni

Iterativni

Inkrementalni

Inkrement

Del izdelka

[inkrementalno-iterativni razvoj]

Uporabnost inizkušnje

Izobraževanje

Metdologijakot izdelek

Bazauporabnikov

Zahtevnostmetodologje

FilozofijaParadigmametodologije

Ciljmetodologije

Domenametodologije

Sociološkakomponenta

Namenmetodologije

Ozadjemetodologije

Tehnika

Podatkovnatehnika

Procesnatehnika

OO tehnika

Tehnika proj.vodenja

Organizacijskatehnika

Tehnika dela zljudmi

Celostnatehnika

Zgodovina metodologij… Obdobje pred pojavom metodologij (do

zgodnjih 1970) Ni formalnih metodologij, poudarek na reševanju

tehničnih problemov, ključna vloga je programer

Zgodnje obdobje metodologij (do zgodnjih 1980) SDLC, tehnike podatkovnega in procesnega

modeliranja, večji poudarek na zajemu zahtev, analizi in načrtovanju

Royce, Boehm, Codd


- 43 -

Analiza

Načrtovanje

Kodiranje

Testiranje

Zajemzahtev

Razvoj ad hoc

Zgodovina metodologij Obdobje metodologij (do sredine/konca

1990) iterativni in inkrementalni razvoj, RAD, objektna

usmerjenost, večanje teže metodologij, strateško načrtovanje

Booch, Rumbaugh, Jacobson, Martin, Yourdon, Gamma

Obdobje ponovne ocenitve metodologij (danes) kritika težkih metodologij, lahke metodologije,

spletne aplikacije, nove tehnologije, hitro spreminjanje zahtev, trend agilnosti

Beck, Ambler, Cockburn, Highsmith


- 44 -

Začetek

Skupni stroški

Podrobnonačrtovanje

Analizatveganj

Analizatveganj

Analizatveganj

Analizatveganj

Identifikacija inodpravljanje

tveganj

Prototip 1Prototip 2

Prototip 3

Operativniprototip

Ocenialternative

SimulacijeModeli

Kod

iranj

e

Test

iranj

epr

og, e

not

Inte

grac

ija in

test

iranj

e

Pot

rditv

eni

test

Pre

daja

Konceptdelovanja

Načrt zahtev,načrt življen.

cikla

Načrtrazvoja

Načrtintegracije in

testiranja

Načrtovanjenaslednjeiteracije

Določitev ciljev,alternativ in

omejitev

Razvoj izdelkovza iteracijo inpreverjanje

njihove pravilnosti

Prični zizvedbo

naslednjeiteracije

Agilnost

Metodologija kot sociološka komponenta Metodologija razvoja IS ima pomembno

sociološko komponento: Poleg tehnik in orodij zajema skupek dogovorov, ki v

organizaciji oziroma skupini veljajo pri razvoju informacijskih rešitev;

Je prežeta s filozofijo in miselnostjo organizacije in njenih zaposlenih;

Je dinamična in odvisna od posameznikov, ki sestavljajo organizacijo.

Zajema vse kar počnemo, da izdelamo izdelek oziroma opravimo storitev, ki je cilj našega dela.


- 45 -

Formalizacija metodologij Metodologije razvoja IS v mnogih podjetjih

niso formalizirane! Postopki, tehnike, orodja itd. niso dokumentirani; Razvoj poteka stihijsko (na vsakem projektu je

drugače; ni definirano, kako nek postopek izvedemo; kakšna orodja se uporabljajo je prepuščeno posameznikom,...

Posledice Slabša kakovost izdelka Razvoj je nesledljiv in netransparenten Tveganje, da izdelek ne bo pravi, Težje vzdrževanje,...


- 46 -

Dojemanje metodologij


- 47 -

Formalizirana metodologija

Postopki, tehnike, smernice,...

Neformalna metodologija

Dojemanje metodologije,

znanje, izkušnje, principi,

ideali

UporabaMetodologije

Izkušnje, nove ideje,

znanje

Je osnova zaformalizacijometodologije

Je osnova zarazumevanjemetodologije

Je osnova zauporabometodologije

Je osnova zaspremembo

dojemanjametodologije

Ponudba komercialnih metodologij Obstaja tudi precej ponudnikov

“komercialnih” metodologij. Nekaj primerov:

IE (Information Engineering) (Oracle CDM) SSADM Rational Unified Process STRADIS Agilne metodologije (XP, SCRUM, FDD,…)


- 48 -

Vrste metodologij Obstaja več načinov za delitev metodologij. Delitev metodologij nam pomaga pri izbiri

ustrezne metodologije.

Nekatere možne delitve: glede na tip metodologije, glede na težo metodologije, glede na utežitev metodologije.


- 49 -

Delitev glede na tip metodologije


- 50 -

Pro

cesn

e in

stru

ktur

nete

hnik

e

Pod

atko

vne

tehn

ike

Obj

ektn

ete

hnik

e

Pos

ebne

tehn

ike

dela

z lju

dmi

Zaporedni(slapovni) razvoj

Iterativni ininkrementalni razvoj Prototipiranje

Objektno usmerjenemetodologije

Podatkovno-procesnemetodologije

Procesno usmerjenemetodologije

Metodologije za hiter razvoj(RAD)

Življenjski cikel

Tehn

ike

Metodologijeusmerjene v človeka

Organizacijskousmerjene

metodologije

Tehničnemetodologije

Socio-tehničnemetodologije

Filozofija

Cilj: organizacijska rešitev(lahko tudi programska)

Cilj: izgradnjaprogramske rešitve

Delitev glede na težo metodologije Teža je določena z obsegom in gostoto

Obseg metodologije je določen s številom različnih elementov, ki jih metodologija opisuje.

Gostoto lahko definiramo kot zahtevan nivo podrobnosti oziroma formalnosti.


- 51 -Optimiziranost

Pril

agod

ljivo

st

Nizka

Visoka

Nizka Visoka

Proces, formalnost, dokumentacija

Izku

šnje

, dis

cipl

inira

nost

, raz

umev

anje

Lahkametodologija

Težkametodologija

Delitev glede na utežitev metodologije Tipi metodologij glede na utežitev

Spredaj utežene: dajejo poudarek analizi in načrtovanju

Zadaj utežene: dajejo poudarek kodiranju in testiranju

Uravnotežene: kombinacija obeh pristopov


- 52 -

čas

cena

spr

emem

be(n

apak

e)

čas

cena

spr

emem

be(n

apak

e)

Klasičen model Model RAD

Pojem agilnosti Začetki: leto 2001, srečanje strokovnjakov

s področja lahkih metodologij. Skupna izjava

Manifesto for Agile SW Development.

Na osnovi izjave je bilo izpeljanih več konkretnih priporočil za razvoj PO: Načela in priporočila za agilno modeliranje (Ambler). Principi agilnih metodologij (Cockburn, Highsmith).


- 53 -

Agilnost

http://www.agilemanifesto.org/







Osnovna načela agilnosti

Posamezniki in njihova komunikacija so pomembnejši kot sam proces in orodja.

Delujoča programska oprema je pomembnejša kot popolna dokumentacija.

Vključevanje (sodelovanje) uporabnika je pomembnejše kot pogajanje na osnovi pogodb.

Upoštevanje sprememb je pomembnejše od sledenja planu.


- 54 -

Principi agilnih metodologij… Neposredna komunikacija – najboljši način

za izmenjavo informacij.


- 55 -

dvosmerna komunikacija

enosmerna komunikacija

dva človekaob tabli

telefon

e-poštavideo

audio

papir

pogovor»iz oči v oči«

Uči

nkov

itost

kom

unik

acije

Posrednost komunikacije

visoka

nizka

posredna neposredna

videokonferenca

Principi agilnih metodologij…


- 56 -

Teža (=obseg × gostota) metodologije

Velik

ost p

robl

ema

Majhna razvojna skupina

Optimalna težametodologije

Maksimalna velikostproblema

Teža (=obseg × gostota) metodologije

Vel

ikos

t pro

blem

a

Velika razvojna skupina

Optimalna težametodologije

Maksimalna velikostproblema

Nepotrebna

dodatna teža

metodologije je draga.

Večje razvojne skupine potrebujejo težje metodolo

gije.

Principi agilnih metodologij… Višja stopnja formalnosti metodologije je

primerna za projekte z višjo stopnjo kritičnosti.

Boljša komunikacija in več povratnih informacij zmanjšuje potrebo po vmesnih izdelkih.

Čim večji so discipliniranost, izkušnje in znanje razvojne skupine, tem manjša je potreba po podrobno definiranem procesu, formalnosti in dokumentaciji.


- 57 -

Principi agilnih metodologij…


- 58 -

- 58 -

Optimiziranost

Prila

godl

jivos

t

Nizka

Visoka

Nizka Visoka


Izku

šnje

, disc

iplin

irano

st, r

azum

evan

je Lahkametodologija

Težkametodologija

Izbirametodologije

Principi agilnih metodologij Odkloni od načrtovane rešitve nas vodijo k

pravi rešitvi.


- 59 -

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

Prava rešitev

Izbira metodologije Pri izbiri si pomagamo z:

Modeli za klasifikacijo metodologij Modeli za klasifikacijo projektov Izbira metodologije glede na podprte postopke in

življenjski cikel Izbira metodologije na podlagi agilnih principov


- 60 -

Modeli za klasifikacijo metodologij… Lahke metodologije uporabimo v primeru,

ko: je glavni (in dokončno opredeljen) cilj razvoj

programske rešitve, imamo odgovorne, disciplinirane, izkušene in

motivirane razvijalce, ki so seznanjeni s posebnimi tehnikami dela,

stranko, ki razume bistvo lahkih metodologij in je pripravljena sodelovati,

imamo nepredvidljive in spreminjajoče se zahteve za programsko rešitev,

je cilj razvoja relativno majhen sistem z nižjo stopnjo kritičnosti, ki ga je mogoče razviti z majhno razvojno ekipo,


- 61 -

Izbira glede na težo metodologije

Modeli za klasifikacijo metodologij… Težke metodologije uporabimo kadar:

cilj ni le razvoj programskega sistema ampak tudi prenova organizacijskega sistema,

imamo manj izkušene razvijalce, pri katerih točno opredeljena formalna pravila nadomeščajo izkušnje in znanje,

naročnik zahteva visoko stopnjo formalizma (izdelovanje dokumentacije),

imamo relativno dobro definirane in stabilne zahteve, je cilj razvoja obsežnejši sistem z višjo stopnjo

kritičnosti, ki zahteva izdelavo ustreznih načrtov in dokumentacije.


- 62 -

Izbira metodologije… Primer modela za klasifikacijo projektov


- 63 -

L6

E6

D6

C6 C20

D20

E20

L20 L40

E40

D40

C40 C100

D100

E100

L100 L200 L500 L1000

E1000E500E200

D200

C200 C500

D500 D1000

C1000

L6

E6

D6

C6 C20

D20

E20

L20 L40

E40

D40

C40 C100

D100

E100

L100 L200 L500 L1000

E1000E500E200

D200

C200 C500

D500 D1000

C1000

L6

E6

D6

C6 C20

D20

E20

L20 L40

E40

D40

C40 C100

D100

E100

L100 L200 L500 L1000

E1000E500E200

D200

C200 C500

D500 D1000

C1000

L6

E6

D6

C6 C20

D20

E20

L20 L40

E40

D40

C40 C100

D100

E100

L100 L200 L500 L1000

E1000E500E200

D200

C200 C500

D500 D1000

C1000

Število ljudi, ki sodelujejo na projektu ± 20%

1-6 7-20 21-40 41-100 101-200 201-500 501-1000

udobje

Krit

ično

st (o

dpov

ed s

iste

ma

lahk

o po

vzro

či iz

gubo

…)

nadomestljivdenar

nenadomestljivdenar

življenje

produktivnost

sledljivostponovljivost

Izbira glede na lastnosti projekta

Izbira metodologije… Obseg nekaterih komercialnih metodologij


- 64 -

IE S

SA

DM

RU

P

DS

DM

XP

Strategija

Izvedljivost

Analiza

Logično načrtovanje

Fizično načrtovanje

Programiranje

Testiranje

Uvedba

Evaluacija

Vzdrževanje

Metodologija

Faza

MN

ova

Samo omenjeno

Osnovna navodila, več jeprepuščeno lastni interpretaciji

Manj podroben opis

Podroben opis skupaj stehnikami

Legenda:

EM

RIS

YS

M

STR

AD

IS

ETH

ICS

SS

M

Obseg metodologije

Izbira metodologije…


- 65 -

Življenjski cikel

Kriteriji

Slapovni razvoj

Modificiran slapovni razvoj

Iterativni razvoj

Inkrementalni razvoj

Evolucijsko prototipiranj

e

Kodiraj in popravi

Deluje s slabo razumljenimi zahtevami

Slabo Srednje do odlično Odlično Slabo do

srednje Srednje do

odlično Slabo

Deluje s slabo razumljeno arhitekturo

Slabo Srednje do odlično Odlično Slabo Slabo Slabo

Rezultat je zanesljiv sistem Odlično Odlično Odlično Srednje do

odlično Srednje do

odlično Slabo

Rezultat je nadgradljiv sistem Odlično Odlično Odlično Odlično Odlično Slabo do

srednje Upravlja s tveganji Slabo Srednje Odlično Srednje do

odlično Srednje Slabo

Omogoča predvidljiv razvoj Srednje Srednje Srednje Odlično Srednje Slabo

Potrebuje malo režije Srednje Odlično Srednje Srednje Srednje Odlično

Dovoljuje spremembe med projektom

Slabo Srednje Srednje Slabo do srednje

Srednje do odlično

Slabo do odlično

Stranki omogoča nadzor napredovanja Slabo Srednje Odlično Srednje Odlično Srednje

Vodstvu omogoča nadzor napredovanja Srednje Srednje do

odlično Odlično Odlično Odlično Slabo

Ne zahteva veliko izkušenj Srednje Slabo do

srednje Slabo Slabo do srednje Srednje Odlično

Izbira glede na podprte življenjske cikle

Izbira metodologije Discipliniranost, izkušnje in znanje proti

procesu, formalnosti in dokumentaciji Višja stopnja formalnosti metodologije za

projekte z višjo stopnjo kritičnosti Večje razvojne skupine potrebujejo težje

metodologije


- 66 - Optimiziranost

Pril

agod

ljivo

st

Nizka

Visoka

Nizka Visoka


Izku

šnje

, dis

cipl

inira

nost

, raz

umev

anje

Lahkametodologija

Težkametodologija

Izbira glede natip projekta

Uporaba metodologij v praksi Empirične raziskave kažejo na nizko

uporabo metodologij. Ključni razlogi:

Nizka strukturiranost procesa razvoja (vsak projekt ima svoje lastnosti in specifičnosti; različne zahteve in pogledi uporabnikov,...)

Neprilagodljivost metodologij, Zastarelost metodologij, Sociološka neprimernost, Neosveščenost uporabnikov.


- 67 -

Uporaba metodologij... Povzetek raziskave v slovenskih podjetjih


- 68 -

Poglavje IIStrukturni razvoj


- 69 -

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

Strukturni razvoj

Eden prvih sistematičnih pristopov k razvoju IS

Zgleduje se po standardnih postopkih razvoja tehničnih izdelkov: aktivnosti si sledijo zaporedno.

Izoblikoval se je konec 60 in v začetku 70 let. Razlog: uvedba discipliniranega izvajanja analize in

načrtovanja. Cilj: zmanjšanje stroškov izgradnje in uvajanja IS.

Pristop “iz vrha navzdol”.RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko

- 70 -

Osnovne značilnosti strukturnega pristopa

Primer strukturne metodologije

Informacijski inženiring je primer metodologije, ki opisuje razvoj IS po strukturnem pristopu.

Nastane leta 1981, glavni avtor je James Martin.

Uveljavitev v sredini 80-tih let, uporablja se še danes.

IE je zasnovan na teoretičnih in praktičnih dosežkih 80-tih let iz metodološkega in tehnološkega vidika.


- 71 -

Informacijski inženiring - IE

Informacijski inženiring – IE

Osnovne značilnosti IE so: sloni na povezani množici tehnik za planiranje,

analizo, načrtovanje, razvoj in vzdrževanje IS celotne združbe ali vsaj njenih glavnih delov;

uporablja pristop od vrha navzdol; je podatkovno usmerjen; podpira avtomatizacijo razvoja; uveljavlja strateško planiranje; povečuje produktivnost.


- 72 -

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.


- 73 -

Osnovne značilnosti IE

Podatkovna usmerjenost

Dogodkovna

usmerjenost

Procesna

usmerjenost


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

IE posebej obravnava podatke, posebej aktivnosti


- 74 -

Glavne faze IE

Planiranje

Analiza

Načrtovanje

Izvedba

Strateško planiranje informatike – SP

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


- 75 -

Opredelitev SP

Fidler in Rogerson, 1996

Strateško planiranje informatike je proces izoblikovanja informacijskega sistema, ki organizaciji omogoča uresničitev njenih ciljev in ji s tem posredno zagotavlja konkurenčno prednost.

Strateško planiranje informatike


Cilji strateškega planiranja so: Povezati razvoj IS s poslovno strategijo organizacije. Izboljšati komunikacijo med vodstvom in informatiki. Načrtovati pretok informacij in procesov. Zmanjšati stroške in čas, potreben za razvoj aplikacij. Predlagati optimalno zaporedje nadaljnjih korakov pri

planiranju in razvoju IS. Pripraviti izhodišča za nadaljnje korake

informatizacije. Zagotoviti uporabo standardov za enotne tehnološke

rešitve. Pokazati na organizacijske probleme pri uvajanju

informacijske podpore in predlagati organizacijske rešitve za dosego racionalnejše uporabo informacijske podpore. RAZVOJ INFORMACIJSKIH SISTEMOV

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

- 76 -

Cilji SP


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.


- 77 -

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.


- 78 -

Problemi brez SP


IE priporoča postopek za izdelavo. V LINF razvitih več različic. Osnovna različica temelji na metodologiji

IE. Prilagojene različice za potrebe

posameznih podjetij.


- 79 -

Metodologija IS

Osnovna različicaBody of Knowledge

Prilagojene različicePriročnik

1992

2006



- 80 -

Shema procesa izdelave SP

80

Proces SP zajema 6 postopkov: Pregled in analiza obstoječega stanja; Opredelitev poslovno-informacijske

arhitekture; Opredelitev informacijske vizije; Opredelitev projektov; Izdelava akcijskega načrta; Spremljanje izvajanja in vzdrževanje

strateškega plana.

Pregled in analiza

obstoječega stanja

Opredelitev poslovno-

informacijske arhitekture

Opredelitev informacijske

vizije

Opredelitev projektov

Izdelava letneganačrta

Vprašalniki

Izpolnjeni vprašalniki

Poslovno-informacijska arhitektura

Razna dokumentacija

Razna dokumentacija

Informacijska vizija

Analiza

Prioriteteprojektov

Spremljanje izvajanja in vzdrževanje

strateškega plana

Terminska opredelitev

letnega planaPoročilo o izvajanju

letnega plana

Seznam Projektov

Podrobna opredelitev

izbranih projektov

Izdelava kratkoročnega plana

Izdelava dolgoročnega plana

Legenda

Postopek

Izdelek

Izhod postopka

Vhod postopka

3-4 mesece



- 81 -

Postopki pri strateškem planiranju

Pregled in analiza

obstoječega stanja




vizije




strateškega plana

Pregled in analiza

obstoječega stanja




vizije



Vprašalniki

Izpolnjeni vprašalniki

Poslovno-informacijska arhitektura

Razna dokumentacija

Razna dokumentacija

Informacijska vizija

Analiza

Prioriteteprojektov


strateškega plana

Terminska opredelitev

letnega planaPoročilo o izvajanju

letnega plana

Seznam Projektov

Podrobna opredelitev

izbranih projektov

Izdelava kratkoročnega plana

Izdelava dolgoročnega plana

Legenda

Postopek

Izdelek

Izhod postopka

Vhod postopka

Strateški plan razvoja informatike

Izdelava strateškega plana traja približno od 3 do 6 mesecev.

Pri izdelavi sodelujejo: Zunanji svetovalci Metodologi (informatike izven organizacije) Ključni uporabniki Člani vodstvene skupine organizacije

Strateški plan je potrebno osveževati!


- 82 -

Trajanje izdelave SP in sodelujoči

Razvoj po strukturnem pristopu

Strukturni pristop k razvoju temelji na strukturni izvedbi analize in načrtovanja. podatki se obravnavajo ločeno od aktivnosti

postopkov. ključen element pri strukturnem modelu je

podatkovna baza, ki predstavlja strukturo, okrog katere se razvije programske module.

Strukturni razvoj se z uveljavitvijo objektnih programskih jezikov ukinja.

Danes se uporablja hibriden pristop: temelji na objektni filozofiji, vendar podatkovna baza še vedno ohranja ključen pomen.


- 83 -

Osnovne značilnosti strukturnega pristopa k razvoju


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


- 84 -

Ključni postopki strukturnega razvoja


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


- 85 -

Kje smo?

Zajem in specifikacija zahtev

Zajem in specifikacija zahtev je ena pomembnejših aktivnosti razvoja oziroma nakupa IR.

Osnovni namen zajema in specifikacije zahtev je opredeliti želeno IR na način, ki bo omogočal: Pri nakupu IR izbirati med obstoječimi rešitvami, Pri razvoju IR opredeliti osnovno funkcionalnost ter

tehnološke in druge nefunkcionalne zahteve in omejitve za izgradnjo želene IR.


- 86 -

Opredelitev in namen


Rezultat zajema in specifikacije zahtev je dokument, kjer so zabeležene vse funkcionalne in nefunkcionalne zahteve v zvezi z želeno IR.

V nadaljnjih korakih se dokument lahko uporablja: kot vhod v postopek analize, pri pripravi razpisne dokumentacije za nakup IR

oziroma izbiro zunanjega razvijalca, kot priloga k pogodbi med naročnikom in izvajalcem

sistema.RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko

- 87 -

Končni izdelek e


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


- 88 -

Vloge in koraki



- 89 -

Postopek zajema in specifikacije zahtev


Postopki strukturnega pristopa: Zajem in specifikacija zahtev;

• Zajem zahtev,• Ureditev zahtev in• Potrditev zahtev

Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.


- 90 -

Kje smo?


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


- 91 -

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.


- 92 -

Zajem zahtev






- 93 -

Kje smo?


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.


- 94 -

Ureditev zahtev


Specifikacija zahtev ima navadno naslednjo strukturo:


- 95 -

Specifikacija zahtev

1. Kratek opis namena IR ali njenega podsistema2. Opis funkcionalnih zahtev3. Opis nefunkcionalnih zahtev4. Opis vmesnikov5. Slovar izrazov



- 96 -


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

Funkcionalne zahteve

Odjava iz izpitnega rokaSistem naj študentom omogoča odjavo iz izpitnega roka. Poslovna pravila:• Študent se ne more odjaviti iz izpitnega roka, če je do

roka še manj kot tri dni.• …



- 97 -


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

Nefunkcionalne zahteve

• Sistem naj bo narejen v tri-nivojski arhitekturi z lahkim odjemalcem.

• Podatki naj se hranijo v podatkovni bazi Oracle.• Za avtentikacijo nej se uporabi digitalno potrdilo.• Izdajatelj digitalnega potrdila je lahko CVI RS, NLB, PS.• …






- 98 -

Kje smo?


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.


- 99 -

Potrditev zahtev


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


- 100 -

Kje smo?

Analiza

Glavni namen analize je izdelati razumljiv opis realnega sveta oziroma poslovnega okolja,na katerega se nanaša razvoj IS.

Izdelamo model sistema, ki na formalen način opredeli potrebne podatkovne strukture in funkcije, ki te podatke uporabljajo.


- 101 -


Analiza

Analiza daje odgovor na vprašanje, KAJ naj IS podpira. Kaj se izvaja v poslovnih funkcijah in kakšne podatke te rabijo?

Analiza služi kot: sredstvo za definicijo zahtev, osnova za dogovor med naročnikom in izvajalcem osnova za kasnejše faze razvoja.


- 102 -


Analiza

Rezultat analize je model sistema. Na osnovi modelov se v nadaljnjih korakih

izdela podatkovna baza ter potrebni programski moduli.

Poleg modela sistema v fazi analize izdelamo tudi predlog tehnične arhitekture sistema ter opcijsko prototipe komponent uporabniškega vmesnika.

Med izdelke analize sodi tudi strategija testiranja.


- 103 -

Končni izdelek e

Analiza

Postopek analize izvajajo sistemski analitik, sistemski arhitekt in ključni uporabniki.

Postopek analize tipično zajema naslednje aktivnosti: Izdelava modela sistema; Izdelava prototipov; Izdelava predloga tehnične arhitekture sistema; Opredelitev strategije testiranja; Predstavitev rezultatov analize naročniku.


- 104 -

Vloge in koraki

Analiza


- 105 -

Shema postopka


Postopki strukturnega pristopa: Zajem in specifikacija zahtev; Analiza

• Izdelava modela sistema;• Izdelava prototipov;• Izdelava predloga arhitekture sistema;• Opredelitev strategije testiranja;• Predstavitev rezultatov analize naročniku.;

Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.


- 106 -

Kje smo?

Analiza

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


- 107 -

Splošno o modeliranju

Analiza

Modele razvijamo zato, da bi sisteme bolje razumeli.


- 108 -


Analiza

Model je poenostavitev realnosti, pri čemer je abstrakcija realnosti poljubno natančna.

Pomembno je, da model prikazuje pomembne elemente in izpušča tiste, ki nas ne zanimajo.


- 109 -


Analiza

Modeliranje prinaša naslednje bistvene prednosti: Omogoča vizualizacijo sistema, Prikazuje tako statične kot dinamične lastnosti

sistema, Predstavlja šablono za nadaljnjo gradnjo sistema, Dokumentira sprejete odločitve.


- 110 -


Analiza

Izbira modelov Za modeliranje sistema lahko izberemo različne

modele. Izbira modelov določa, kako bomo pristopili k

reševanju problema ter kako oblikovali rešitev. Modeli morajo podpirati izražanje na različnih ravneh

natančnosti. Najboljši modeli so tesno povezani z realnostjo. En sam model nikoli ni dovolj. Sistem je potrebno

modelirati iz različnih vidikov. Najboljši pristop je izbira nekaj modelov, ki kar najbolje pokrijejo najpomembnejše vidike sistema.

Metodologije razvoja IS predlagajo različne modele.


- 111 -


Analiza

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


- 112 -

Analiza po strukturnem pristopu

Model sistemaPodatkovni model

Procesni model

Model procesne logike

Analiza – Izdelava modela sistema

Podatkovni model: prikazuje sistem s podatkovnega vidika tako, da

opisuje podatkovne strukture, ki so potrebne za delovanje sistema. Poleg podatkovnih struktur zajema tudi vse povezave med njimi.

Procesni model: prikazuje sistem z vidika aktivnosti ali procesov, ki se

v sistemu izvajajo. Definirani so tokovi podatkov med procesi.

Model procesne logike: natančneje definira procese, definirane v procesnem

modelu.


- 113 -

Izdelava modela sistema po strukturnem pristopu


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


- 114 -

Strukturne diagramske tehnike


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.


- 115 -

Podatkovni model


Procesni model




- 116 -

Podatkovni model

svet mentalni model konceptualni model logični model PB

Analiza – Izdelava modela sist.


- 117 -

Podatkovni model – primer

Konceptualni podatkovni modelPredmet

PredmetNazivDodatne obveznostiSemesterKreditne točke…

IzpitZap. št. polaganjaOcena pisnoOcena ustnoDatum ocene

ŠtudentVpisna številkaPriimekImeNaslovTelefonE-mailStatus…

DelavecDelavecPriimekImeE-mailGeslo…

PrijavaDatum prijaveDatum odjaveZap. št. polaganjaKolokvijLetnikPlača izpit…

RokRokDatum izpitaPrijavljenihMaks. prijavljenihMeja pozitivno…

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

?



- 118 -


Primer nerazumljivega podatkovnega modela

NAC_DEL

PRE_DEL

POTRDILO

ZAHTEVA

NACINPOSTA

STAT_IZPITA

IZPRASEVALEC

OBVESTILASTAT_POSSTAT_PR

NAC_IZV

PRIJAVA_U ROK_U

VRSTA_POT

ZAVOD

VSI

VRSTA_OC

VIP SMER

NAC_OC

VSI_F

VPIS

VIP_F

VAJE

STUDENT

SPP

SKUPINA

SKLEPI

ROK

PRIJAVA

PRE_PRE

PRED_PRPRED_OBC

PRED_IZB

PRED_DIFPRED_AT

PREDPOGPREDMET

PP

IZPIT

IZJEME

IZBIRNIEKVIVAL

DELNA_OC

DELAVEC

APP

a

a

a

a

a

a

aa

aa

a

a

a

a

a

a

a

a

a

a

a a

a

a

a

a

a

a

a

b

aa

aaaa

a

a

a

a

a

a

a

a

a

b

a

a

a

a

a

a

ab

a

a

a

a

a

b

a

b

ab

a

ab

b

a

a

bb

c

c

b

b

a

a

r r

a

a

a

a

a

a

aa

a

a

a

a

a

a

a

a

a

a

aa

a

aaa

a

a

a

a

a

a

a

a

a

a

a

a

a

a

aa

a

a

a

a

a

a

a

aa

a

a

a

a

a

a

a

a

a

aa

a a

a

aa

a

a

a a

aa

a

a

a

a

a

a

a

a

a

a

a

a

a

aa

a

a

a

a

a

a

a

a



- 119 -


Entitetne tipe je potrebno dokumentirati Primer dokumentacije:

Naziv entitetnega tipa

Opis Sinonim Število entitet

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

Pedagoški delavec

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

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

Rok, pisni izpit, kolokvij

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

...



- 120 -

Podatkovni model – metoda načrtovanja

Možni koraki konceptualnega načrtovanja: K 1.1: Identificiraj entitetne tipe K 1.2: Identificiraj povezave K 1.3: Identificiraj in z entitetnimi tipi poveži atribute K 1.4: Atributom določi domene K 1.5: Določi kandidate za ključe; izmed kandidatov

izberi primarni ključ

K 1.6: Po potrebi uporabi elemente razširjenega diagrama

entiteta – razmerje K 1.7: Preveri, če v modelu obstajajo odvečni

elementi K 1.8: Preveri, če model “zdrži” transkacije K 1.9: Preveri model z uporabnikom

Analiza – Izdelava modela sistema V postopku identifikacije povezav smo

pazljivi na dvoumne in nepopolne povezave.

- 121 -

Primer dvoumne povezave

1..* 1..1 1..1 1..*Profesor Katedra Laboratorij

je član vključuje

Pr1

Pr2

Pr3

K1

K2

L1

L2

L3

Podatkovni model – metoda načrtovanja – identifikacija povezav

K 1.2


Analiza – Izdelava modela sistema Dvoumno povezavo odpravimo z

restrukturiranjem modela

- 122 -

Profesor Laboratorij Katedraje član vključuje

Pr1

Pr2

Pr3

L1

L2

K1

K2

K3

1..* 1..1 1..* 1.1




- 123 -

Podatkovni model – metoda načrtovanja – Identifikacija povezav

Primer nepopolne povezave

1..1 1..* 0..1 0..*Katedra Član Oprema

ima je skrbnik

K1

K2

K3

Čl1

Čl2

O1

O2

O3Čl3

Kateri katedri pripada oprema O2?


Analiza – Izdelava modela sistema Odpravimo z prestrukturiranjem modela.

- 124 -


1..1 1..* 0..1 0..*Katedra Član Oprema

ima je skrbnik

K1

K3

Čl1

Čl2

O1

O2

Čl3

1..1 1..*pripada

K2


Analiza – Izdelava modela sistema Identifikacija odvečnih povezav

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

Izdelati želimo minimalen podatkovni model odvečne povezave zato odstranimo.

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

- 125 -

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

K 1.7


Analiza – Izdelava modela sistema Ali je kakšna povezava odveč?

- 126 -


Profesor Katedraje predstojnik

1..1 0..1

Laboratorij

pripada

1..1

1..*je član

1..1

1..*


Analiza – Izdelava modela sistema Ali je kakšna povezava odveč?

- 127 -


Profesor Katedrapripada

1..* 1..1

Laboratorij

pripada

1..1

1..*je član

1..1

1..*


Analiza – Izdelava modela sistema Preveriti moramo, če model podpira vse

zahtevane transakcije. Transakcije izvajamo ročno Če neke transakcije ne uspemo izvesti, je model

pomanjkljiv (manjka bodisi entitetni tip, povezava ali atribut)

Možna dva pristopa: Preverjanje prek opisa transakcij Preverjanje prek transakcijskih poti

- 128 -

Podatkovni model – metoda načrtovanja – preverjanje transakcij

K 1.8


Analiza – Izdelava modela sistema Preverjanje prek opisa transakcij

Vsako transakcijo opišemo; Preverimo, če model zajema vse entitetne tipe,

povezave in atribute, ki jih transakcija potrebuje.

- 129 -

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



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


- 130 -

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

Analiza – Izdelava modela sistema Preverjanje prek transakcijskih poti

Transakcije preverimo na modelu – pot transakcije narišemo

Pristop načrtovalcu omogoča: Da identificira pomanjkljivosti modela (če pot za neko

transakcijo ni možna) Da identificira dele modela, ki so transakcijsko kritični Da odkrije odvečne dele modela (deli, ki jih ne potrebuje

nobena transakcija)

- 131 -

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



- 132 -

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

Prijava PredmetpredID

SmersmerID

ProgramprogID

RokrokID

ŠtudentvpisSt

IzpitstPol

ima

0..11..1

se predava na1..*

1..*

za1..10..*

iz

1..1

0..*

se nanaša na1..10..*

pripada

1..1

0..*

je opravljal1..1 0..*

a) Izpiši vse predmete, ki jih je opravil določen študent b) Izpiši vse študente, ki so se vpisali v določen letnik, določene smeri,

določenega programa

a

?b



Procesni model: prikazuje sistem z vidika aktivnosti ali

procesov, ki se v sistemu izvajajo. V procesnem modelu lahko nastopajo tudi podatkovne strukture, ki jih procesi potrebujejo pri svojem delovanju.

Za izdelavo procesnega modela uporabimo dve diagramski tehniki: diagram razgradnje ter diagram podatkovnih tokov. Uporabimo lahko tudi procesni diagram.

- 133 -

Izdelava modela sistema – procesni model


Procesni model




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.


- 134 -

Procesni model – diagram funkcionalne razgradnje – opredelitev



- 135 -

Funkcija 1

Funkcija 1.1 Funkcija 1.2Funkcija

1.2.1

Funkcija 1.2.2

Funkcija 1.3

Procesni model – diagram funkcionalne razgradnje

Funkcija 1Funkcija 1.1

Funkcija 1.2

Funkcija 1.3

Funkcija 1

Funkcija 1.1

Funkcija 1.2

Funkcija 1.3

Funkcija 1Funkcija

1.1Funkcija

1.2Funkcija

1.3


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.


- 136 -

Procesni model – diagram funkcionalne razgradnje – smernice


Študijska Informatika (izpitna evidenca)

Vzdrževanje in

pregled izpitnih rokov

Elektronski indeks/

kartotečni list

Naročanje potrdil

Opravljanje pisnih izpitov

Prijava na izpit

Odjava iz izpita

Pregled števila prijavljenih kandidatov

Vnos rezultatov

Objava rezultatov

Opravljanje ustnih izpitov

Vpis končne ocene


- 137 -

Procesni model – diagram funkcionalne razgradnje - primer


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.


- 138 -

Procesni model – diagram podatkovnih tokov – opredelitev

DFD – Data Flow Diagram


DFD sodi med enostavnejše diagramske tehnike.

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


- 139 -

Procesni model – diagram podatkovnih tokov – osnovni gradniki


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


- 140 -

Procesni model – diagram podatkovnih tokov – proces

Proces sistema

Notranja shramba podatkov

Zunanji prejemnik

Izhodnipodatki

Vhodnipodatki


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


- 141 -


Rave

n po

drob

nosti

Funkcionalna razgradnja

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.


- 142 -


Prijava na izpit

1Vnos

končne ocene

2


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


- 143 -

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


- 144 -


Vnos končne ocene

2Izpitni rok

Prijava

Izpit

Podatki o izpitnem roku

ID prijave

Ocena pisno,Ocena ustno

Podatki o preteklih

polaganjih


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!


- 145 -



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


- 146 -

Procesni model – diagram podatkovnih tokov – podatkovna shramba

Podatkovna baza

Izpit


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)


- 147 -


Vnos izpitnega

roka

2Izpitni rok



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!


- 148 -



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.


- 149 -




- 150 -

Procesni model – diagram podatkovnih tokov – podatkovna shrambaProcesni m

odelPodatkovni m

odel


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.


- 151 -

Procesni model – diagram podatkovnih tokov – zunanja entiteta



- 152 -

Procesni model – diagram podatkovnih tokov – zunanja entiteta

Vnos končne ocene

2Izpitni rok

Prijava

Izpit


ID prijave

Ocena pisno,Ocena ustno

Podatki o preteklih

polaganjih

Študent

indeks

Analiza uspešnosti generacije

3Univerza v Ljubljani

Poročila o uspešnosti generacije

Podatki o izpitih


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.


- 153 -

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.


- 154 -



Kontekstni diagram: razčlenjevanje DFD začnemo na najvišji ravni, kjer

nastopa en sam proces – korenski proces.


- 155 -


kontekst sistema

KOTEKSTNI DIAGRAM

korenski proces


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.


- 156 -




- 157 -

Procesni model – diagram podatkovnih tokov – primer kontekstnega diagrama

e-študent

0

Študent

Univerza v Ljubljani

MŠŠ

Vpisna prijavno-

informacijska služba

Računovodstvo FRI

Podatkovni tokovi brez nazivov ne povedo skoraj nič!!


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.


- 158 -




- 159 -

Procesni model – diagram podatkovnih tokov – kontekstni diagram

Izpitna evidenca

0.1

Diplome

0.2

Vpis

0.3

Podatki o polaganjih

Roki, prijave,Izpiti, ocene

Podatki o diplomah

Teme, ocene

diplom,

kandidati za

diplome,

mentorji

Povprečne ocene

Študent

Univerza v Ljubljani

MŠŠ

Vpisna prijavno-

informacijska služba

Računovodstvo FRI

Osebni podatki,indeks

Podatki za vpis

Poda

tki o

pla

čilih

izp

itov

Podatki o plačilih vpisnine

Sumarni podatki za

podatkovno skladišče

Sumarni podatki za podatkovno skladišče

Sumarni podatki za

podatkovno skladišče Kandidati

za vpis

Omejitev vpisa

Vpisna evidencaVpisni

podatkiVpisni podatki

Napačna raba shrambe


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.


- 160 -



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.


- 161 -

Procesni model – procesni diagram

eEPC – Extended Event-Driven Process Chain


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


- 162 -



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.


- 163 -


Prijava zaključena

Ocena vpisana


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.


- 164 -


Razpis ustnega

roka

Vnos končne ocene


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.


- 165 -



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.


- 166 -


AND


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.


- 167 -




- 168 -

Procesni model – procesni diagram – primer

Priprava razpisa

Obvestilo ULJ o

razpisu

Razpis pripravljen

Objavarazpisa

Razpis objavljen

Zbiranje prijav

Razpis zaključen

Izbira kandidatov

Kandidati določeni

AND

Priprava podatkov

za ULJ

Priprava podatkov

za KŠZ

Podatki pripravljeni

SejaKŠZ


Kandidati zavrnjeni

Kandidati potrjeni

XOR

AND

Obvestilo ULJ o izboru

Obvestilo kandidatov

o izboru

Izbira kandidatov za mednarodne izmenjave



- 169 -

Procesni model – procesni diagram – primer – dodatni gradniki


Kandidati določeni

AND

Priprava podatkov

za ULJ

Priprava podatkov

za KŠZ


SejaKŠZ


Izbira kandidatov

Seznam za KŠZ

IR za izbiro kandidatov

S/Ekoordinator

Seznam za ULJ

S/Ekoordinator

KŠZ

MS Excel



- 170 -

Procesni model – procesni diagram – primer – steze


ULJ S/Ekoordinator

KŠZ

Izdaja obvestila o razpisu

Priprava razpisa

Objava razpisa

Obvestilo ULJ o

razpisu

Razpis pripravljen

Razpis objavljen

Zbiranje prijav


SejaKŠZ


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.


- 171 -

Izdelava modela sistema – model procesne logike


Procesni model



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.


- 172 -

Model procesne logike – strukturiran jezik


Primer opisa: Vnos diplomske teme

Izberi študijski program //izpišejo se vsi študijski programiIzberi študenta //izpišejo se vsi kandidati, ki so pri mentorju dvignili temoVnesi naslov temeVnesi opis temePotrdi ali prekliči temo //če uporabnik vnosa ne potrdi, se podatki ne zabeležijo//prikaži opcije za vnos/spreminjanje/izpis tem diplomskih

nalog


- 173 -

Model procesne logike – strukturiran jezik – primer


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.


- 174 -

Model procesne logike – odločitvene tabele in drevesa


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.


- 175 -

Model procesne logike – odločitvene tabele



- 176 -


Pravilo 1 Pravilo 2 … Pravilo pPogoj 1 V(p1) V(p1) … V(p1)Pogoj 2 V(p2) V(p2) … V(p2)… … … … …Pogoj n V(pn) V(pn) V(pn)Akcija 1 D/N D/N … D/NAkcija 2 D/N D/N … D/N… … … … …Akcija m D/N D/N … D/N

Pravilo – kombinacija vrednosti pogojev.

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

Vrednost pogoja 2v pravilu p


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

Število pravil:

zv: zaloga vrednosti n: število pogojev


- 177 -


Primer:p1 = Pogoj 1: status vpisap2 = Pogoj 2: letnik

p1 = {redno, izredno, ponavlja, pavzira}zv(p1) = 4

p2 = {1, 2, 3, 4, 5, ABS}zv(p2) = 6

Število pravil = 4 * 6 = 24

Prijava na izpitni rok



- 178 -

Model procesne logike – odločitvene tabele – primer

Pravila

Pogoji

Izpitni rok razpisan D D D D D D D N

Dovoljen pristop k izpitu D D D D D D D N

Pravočasna prijava D D D D D D N N

Izpolnjeni vsi predpogoji D D D D D N D D

Število zaporednih polaganj presega 3 N N N D D N N N

Prvo polaganje v izpitnem obdobju D N N D N D D D

Drugo polaganje v jesenskem obdobju N D N N D N N N

Četrto polaganje v šolskem letu N N N N D N N N

Akcije

Sprejmi prijavo × × ×

Zavrni prijavo × × × × ×

Sestavi komisijo ×

Izdaj plačilni nalog ×


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.


- 179 -

Model procesne logike – odločitvena drevesa



- 180 -


Pogoj p1

Pogoj p2

A {a1, a2, …, an} A {a1, a2, …, an}

V(p 1) p 1

V(p1) p1

V(p1 ) p

1

A {a1, a2, …, an} A {a1, a2, …, an}

V(p 2)

p 2 V(p2 ) p

2

Pot od korena do lista: pravilo

List: seznam akcij pravila


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.


- 181 -




- 182 -

Model procesne logike – odločitvena drevesa – primer

Izpitni rok razpisan?

NZavrni prijavo:

Rok ne obstaja!

Dovoljen pristop k izpitu?Zavrni prijavo:

Nima dovoljenja za opravljanje izpita!

Pravočasna prijava?Zavrni prijavo:

Prijava ni bila oddana pravočasno!

Predpogoji izpolnjeni?Zavrni prijavo:

Predpogoji niso izpolnjeni!

Prvo polaganje v izpitnem obdobju?



- 183 -

Model procesne logike – odločitvena drevesa – primer

Prvo polaganje v izpitnem obdobju?

D Je skupno število polaganj > 3?Komisijski izpit:* sestavi komisijo

* izdaj plačilni nalog* sprejmi prijavoSprejmi prijavo

Je to jesensko obdobje?Je skupno število polaganj > 3Komisijski izpit:

* sestavi komisijo* izdaj plačilni nalog

* sprejmi prijavoSprejmi prijavo

Zavrni prijavo:Že opravljal v zimskem/letnem obdobju!

Diagramske tehnike

Z diagramom prehajanja stanj prikažemo stanja, v katerih se lahko nahaja opazovan proces ter odzive oziroma prehajanja med stanji kot odziv na različne dogodke.


- 184 -

Model procesne logike – diagram prehajanja stanj

Stanje S1

Stanje S2

d0 /a

0

Začetno stanje

Končno stanje

d1/a1

dk /a

k

di/ai

{d0, d1, di, dk}: dogodki{a0, a1, ai, ak}: akcije

Diagramske tehnike

Glavni gradniki diagrama prehajanja stanj: Stanje Dogodek Akcija

Stanje: Z vidika dogajanja v sistemu se lahko proces nahaja

v različnih stanjih. Stanja so določena z vrednostjo lastnosti, ki nas v

okviru dogajanja procesa zanimajo. Proces se nahaja v določenem stanju vse dokler se

katera izmed opazovanih vrednosti ne spremeni. Tedaj nastopi novo stanje.


- 185 -


Diagramske tehnike

Dogodek: Prehajanja med stanji povzročajo dogodki. Dogodek vpliva na spremembo ene ali več

opazovanih lastnosti procesa. Z vidika prehajanja med stanji je dogodek nekaj, kar

se pripeti v določenem trenutku in nima časovne razsežnosti.

Akcija: Ob dogodku se lahko zgodijo različne akcije. Kot dogodki tudi akcije niso časovno trajajoče;

zgodijo se v trenutku.


- 186 -


Diagramske tehnike


- 187 -

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

Ponavljalec

Pavzer

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

Pogoji za napredovanje so

izpolnjeni /[Vpis v višji letnik

omogočen]

Pogoji za napredovanje niso izpolnjeni /[Odvzem statusa

študenta]

Redno vpisan



omogočen]

Pogoji za napredovanje niso izpolnjeni, število ponovnih vpisov > 1 /

[Odvzem statusa študenta]



omogočen]

Status študenta

Diagramske tehnike


- 188 -

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

Status študenta

Dogodek Stanje

Redno vpisanS1

Ponovno vpisanS2

PavzerS3


izpolnjeni

S1 /[Vpis v višji letnik

omogočen]


omogočen]


omogočen]

Pogoji za napredovanje niso

izpolnjeni S2 /

[Ponoven vpis s letnik]S3 /

[Odvzem statusa študenta]

Pogoji za napredovanje niso izpolnjeni, število

ponovnih vpisov > 1

S3 /[Odvzem statusa

študenta]

Vaja

Za opisan problem želimo izdelati informacijsko rešitev. Izdelaj model sistema, ki bo problemsko domeno kar najbolje opisal.

Izbiraš lahko med poljubnimi diagramskimi tehnikami.


- 189 -

Vaja – rešitev


- 190 -

Podatkovni model

Strankasifra strankeimepriimekstevilka OD

Hotelski Gostdatum nastanitvedatum odjave

Sobasifra sobestevilo lezisczasedenododatne lastnosti

Tip Sobesifra tipa sobeopis

Hotelska Uslugakolicinacena

Tip Hotelske Uslugesifra tipa hotelske uslugeopisenotacena

Racunletosifra racunadatum

Hotelski Usluzbenecsifra hotelskega usluzbencaimepriimeknaslovtel

Tip Nastanitvesifra tipa nastanitveopis nastanitve

Poraba minibaradatum porabekolicina porabe

Statussifra statusaopis statusa

PritozbaStevilka pritozbeOpis pritozbe

Hotelska stranka

Navadnastranka

Hotelskigost

Vaja – rešitev


- 191 -

Status stranke – frekvenca bivanja v hoteluPrvič v hotelu?

Da

NOV GOST

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

Gre vedno za isto sezono?

SEZONSKI GOST

REDNI GOST

?

Manjka status!Predlog: Navaden gost.

Slabo poimenovanje: sezonski gost je tudi redni gost!Predlog: redni gost letni gost.

Vaja – rešitev


- 192 -

Status stranke – posebni statusi

Status <> NOV GOST

AND

Ne

Da

AND

Ali se je kdaj

pritožil?

Ali spadamed 10%najdono-snejših?

Ima posebne potrebe?

Je znana oseba?

OBČUTLJIV GOST

SUPER GOST

POSEBEN GOST

POMEMBEN GOST

Posebni statusi






- 193 -

Kje smo?

Analiza – Izdelava prototipov

Izdelava prototipov je neobvezna v okviru analize učinkovito sredstvo za prikaz izgleda

ter osnovne funkcionalnosti uporabniškega vmesnika.

Razvita posebna razvojna okolja, ki omogočajo vizualno sestavljanje zaslonskih mask, izpisov in poizvedb ter vsebujejo mehanizme za avtomatsko generiranje kode.


- 194 -

Izdelava prototipov v okviru analize


Prototipi se navadno uporabljajo le kot del specifikacije sistema, za pridobitev jasnejše podobe bodočega sistema in se v nadaljevanju zavržejo.

Obstajajo tudi metode, ki tako izdelane prototipe izkoristijo kot osnovo za izdelavo produkcijskega sistema (Rapid Application Development – RAD).


- 195 -



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


- 196 -



Primer


- 197 -

Izdelava prototipov v okviru analize – Primer MS Visio


Primer


- 198 -

Izdelava prototipov v okviru analize – Primer Delphi






- 199 -

Kje smo?

Analiza – Predlog tehnične arhitekture V okviru analize ne analiziramo zgolj

funkcionalnih zahtev, temveč tudi tehnične in druge nefunkcionalne zahteve.

Na osnovi tega podamo predlog tehnične arhitekture sistema.

Upoštevamo tudi strategijo podjetja oziroma standarde, ki so v podjetju določeni za celoten informacijski sistem.


- 200 -

Izdelava predloga tehnične arhitekture

Analiza – Predlog tehnične arhitekture V okviru predloga tehnične arhitekture

sistema opredelimo strojno, komunikacijsko in programsko opremo, ki je potrebna za vzpostavitev ustreznega razvojnega, testnega in produkcijskega okolja.

V fazi analize navadno izdelamo le predlog, ki služi kot eden pomembnih virov za oceno stroškov razvoja oziroma nakupa IR.

Upoštevati moramo standarde in predpise, ki so določeni za posamezna področja.


- 201 -

Izdelava predloga tehnične arhitekture

Analiza – Predlog tehnične arhitekture


- 202 -

Izdelava predloga tehnične arhitekture – vsebina

1. Arhitektura sistema1.1 Strojna oprema1.2 Sistemska programska oprema1.3 Komunikacijska oprema 1.4 Druga oprema1.5 Postavitveni diagram (opcijsko)

2. Postopki, predpisi in standardi2.1 Zagotavljanje varnosti2.2 Varnostne kopije (Backup)2.3 Vzpostavitev sistema (Recovery)2.4 Obravnava napak






- 203 -

Kje smo?

Analiza – Opredelitev strategije testiranja Način testiranja je s standardi kakovosti

podrobno določen. Njegova izvedba vseeno odvisna od vrste projekta.

V okviru opredelitve strategije testiranja se odločimo: Kaj je predmet testiranja? Npr. programske enote,

programski sklopi, integracija, tehnične zahteve… Kdo bo izvajal testiranje, kje in kako bo testiranje

potekalo? Npr. teste programskih enot izvajajo programerji sami v okviru razvojnega okolja.

Kje bo nameščeno testno okolje (pri izvajalcu ali pri uporabniku)?


- 204 -

Strategija testiranja

Analiza – Opredelitev strategije testiranja Opredelitev strategije testiranja

(nadaljevanje): Na kakšni strojni opremi bo nameščeno testno

okolje? V kateri točki projekta se bo namestilo testno okolje? Bo testiranje v testnem okolju potekalo v več

iteracijah ali v celoti? Kakšna orodja se bo uporabljalo za pripravo testov? Kakšna orodja se bo uporabljalo za izvajanje testov? …


- 205 -

Strategija testiranja

Analiza – Opredelitev strategije testiranja


- 206 -

Strategija testiranja – prva aktivnost v okviru postopka testiranja



• Izdelava modela sistema;• Izdelava prototipov;• Izdelava predloga arhitekture sistema;• Opredelitev strategije testiranja;• Predstavitev rezultatov analize naročniku;



- 207 -

Kje smo?

Analiza – Predstavitev rezultatov

Ko izdelamo vse izdelke, ki jih predvideva faza analize, pripravimo predstavitev za naročnika.

Osnovni namen predstavitve je pridobitev potrdila s strani naročnika o pravilnosti razumevanja problema, ki ga rešujemo z IR.

Potrebno upoštevati, da naročnik morda nima strokovnih znanj za poglobljeno razumevanje rezultatov analize; predstavitev mora biti temu primerna. RAZVOJ INFORMACIJSKIH SISTEMOV


- 208 -

Predstavitev rezultatov analize uporabniku

Analiza – Predstavitev rezultatov

Predstavitev se zaključi s potrditvijo naročnika, da rezultati analize ustrezajo zahtevam.

Potrditev se izvede s podpisom dokumenta, ki pogosto predstavlja eno izmed kontrolnih točk v okviru projektnega vodenja.


- 209 -

Predstavitev rezultatov analize uporabniku


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


- 210 -

Kje smo?

Načrtovanje

Glavni namen načrtovanja je izdelati načrt zgradbe sistema glede na specifikacije, ki so bile zbrane v fazi analize.

Načrt daje odgovor na vprašanje, KAKO izdelatisistem, da bo ustrezal zahtevam, ki smo jihevidentirali v fazi analize.


- 211 -


Načrtovanje

Cilji načrtovanja so: Izdelati načrt IR, ki ustreza ugotovitvam iz analize in

upošteva tehnološke omejitve sistema; Dokumentirati specifikacije načrta na način, ki bo

omogočal vzdrževanje sistema; Zasnovati strategijo prehoda iz obstoječe na novo

aplikacijo.


- 212 -

Cilji načrtovanja

Načrtovanje

Osnovna rezultata načrtovanja sta načrt podatkovne baze in načrt programskih modulov, s katerima pripravimo vse potrebno za izdelavo podatkovnih in programskih komponent IR.

V fazi načrtovanja izdelamo tudi: načrt dokumentacije, načrt testiranja in načrt namestitve in uvedbe.


- 213 -

Končni izdelek e

Načrtovanje

Pri načrtovanju sodelujejo načrtovalec podatkovne baze, načrtovalec aplikacije, skrbnik podatkovne baze, izdelovalec dokumentacije, uvajalec, poslovni lastnik in končni uporabnik.

Tipične aktivnosti načrtovanja so: Izdelava načrta podatkovne baze, Izdelava načrta programskih modulov, Izdelava načrta dokumentacije, Izdelava načrta testiranja, Izdelava načrta namestitve in uvedbe in Predstavitev načrta naročniku.


- 214 -

Vloge in koraki

Načrtovanje


- 215 -

Shema postopka

Načrtovanje


- 216 -

Shema postopka

Načrtovanje – Izdelava načrta PB

Namen aktivnosti je na podlagi konceptualnega modela iz analize izdelati logični podatkovni model in izvesti ostale korake, potrebne za vzpostavitev učinkovite fizične podatkovne baze.

V sklopu faze načrtovanja izdelamo logični podatkovni model in določimo sistem pravic za uporabo podatkov in programskih modulov.


- 217 -

Namen aktivnosti


- 218 -

Načrtovanje – Izdelava načrta PB Logično modeliranje podatkovne baze

nastopi za konceptualnim modeliranjem. Osnova logičnega modela je jezik, ki je

razumljiv ciljnemu SUPB. Če izberemo relacijski SUPB, potem

govorimo o relacijskem modelu.

svet mentalni model konceptualni model logični model PB

Izdelava logičnega podatkovnega modela


- 219 -

SUPB

Konceptualni PM

Logični PM

Fizični PM(skripta)

Podatkovna baza

i-CASE

ODBC

Reverse Engineering

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

Logično načrtovanje

Podpora CASE orodij



Načrtovanje – Izdelava načrta PB Prehod iz konceptualnega v logični model

je navadno avtomatiziran s strani CASE orodij.

- 220 -

Primer: vrsta baze: relacijskaSUPB: Oracle

NAČRTOVANJEANALIZA

Konceptualni model

Entitetni tip

Atribut

Enolični identifikator

Povezava 1:n

Povezava m:n

Atribut / Stolpec

Relacija / Tabela

Vmesna tabelaTuji ključ

Ključ

Relacijski model

Prehod iz konceptualnega v logični model

Načrtovanje – Izdelava načrta PB Tipični koraki:

Za entitetne tipe kreiraj relacije Preveri relacije z normalizacijo Preveri relacije s pregledom uporabniških transakcij Preveri omejitve integritete Preveri model z uporabnikom Združi lokalne modele v globalni model (opcijsko) Preveri zmožnosti modela za razširitve

V nadaljevanju si bomo pogledali nekaj osnov o relacijskem modelu.

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

Tipični koraki pri izdelavi relacijskega modela

Načrtovanje – Izdelava načrta PB Pri relacijskem modeliranju se srečamo z

naslednjimi koncepti: Relacija Atribut Domena n-terica Funkcionalna odvisnost Ključ Pogled Normalizacija …


Osnovni koncepti relacijskega modela

Načrtovanje – Izdelava načrta PB Relacijo si lahko predstavljamo kot

dvodimenzionalno tabelo s stolpci in vrsticami. Velja za logično strukturo podatkovne baze in ne za

fizično.


- 223 -

Ime Starost (v letih)

Teža (v kg)

Tine 15 50

Meta 20 45

Jure 40 80

Ana 5 10

Relacija

Predstava relacije

Načrtovanje – Izdelava načrta PB Atribut je poimenovani stolpec relacije.


- 224 -


Teža (v kg)

Tine 15 50

Meta 20 45

Jure 40 80

Ana 5 10

Atribut relacije

Atribut relacije

Načrtovanje – Izdelava načrta PB Domena je množica dovoljenih vrednosti

enega ali več atributov, ki so vključeni v to domeno.

Primeri domen:


- 225 -

Domena relacije

Načrtovanje – Izdelava načrta PB N-terica je ena vrstica v relaciji. Števnost relacije je število n-teric relacije. Stopnja relacije je število atributov v

relaciji.


- 226 -


Teža (v kg)

Tine 15 50

Meta 20 45

Jure 40 80

Ana 5 10

n-terica relacijeŠtevnost relacije

Stopnja relacije

Osnovne karakteristike relacije

Načrtovanje – Izdelava načrta PB Relacijska podatkovna baza je množica

normaliziranih relacij z enoličnimi imeni.

Normalizirane relacije so relacije, ki ustrezajo normalnim oblikam. Te določajo pravila, ki jim morajo relacije zadoščati, da pri vnašanju, spreminjanju in brisanju podatkov ne prihaja do anomalij.


- 227 -

Relacijska podatkovna baza in normalizacija

Načrtovanje – Izdelava načrta PB Relacijo matematično definiramo kot

podmnožico kartezičnega produkta množic, ki predstavljajo domeno vrednosti atributov relacije.


- 228 -

Matematična definicija relacije

nDDDr ...21

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

Načrtovanje – Izdelava načrta PB Vsaki relaciji pripada relacijska shema. Relacijsko shemo sestavlja oznaka sheme

R ter lista oznak atributov Ai s pripadajočimi oznakami domen Di:

R (A1: D1, A2: D2, ..., An: Dn)

Relacijska shema predstavlja semantiko ali pomen relacije.


- 229 -

Relacijska shema



- 230 -


Teža (v kg)

Tine 15 50

Meta 20 45

Jure 40 80

Ana 5 10

Sh(r) = Oseba(Ime: I, Starost: C, Teža: C)

Domena, ki obsega imena: I {Tine, Meta, Jure, Ana}Domena, ki obsega interval celih števil: C 1, 2,... 200

Relacija, predstavljena kot tabela

Shema relacije

Domene atributov relacije

Shema relacije

Relacijska shema

Načrtovanje – Izdelava načrta PB Enoličnost:

Ime relacije je enolično. V relacijski shemi podatkovne baze ni dveh relacij z enakim imenom;

Vsak atribut relacije ima enolično ime. V isti relaciji ni dveh atributov, ki bi imela isto ime;

Vsaka n-terica relacije je enolična v relaciji ni dveh enakih n-teric.


- 231 -

Lastnosti relacij

Načrtovanje – Izdelava načrta PB Atomarnost:

Vsaka celica tabele, ki predstavlja relacijo, vsebuje natančno eno atomarno vrednost.

Zaloga vrednosti: Vrednosti nekega atributa so vse iz iste domene.

Nepomembnost vrstnega reda: Vrstni red atributov v relaciji je nepomemben. Vrstni red n-teric v relaciji je nepomemben.


- 232 -

Lastnosti relacij



- 233 -

Lastnosti relacij – primer

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

Tine S15_T50

Meta S20_T45

Jure S40_T80Ana S5_T10

Zakonca Leto poroke (celo število)

Tine,Meta

1995

Ana,Jure

1980

Celice ne vsebujejo atomarnih vrednosti

Celice vsebujejo več vrednosti

Načrtovanje – Izdelava načrta PB Predpostavimo, da obstaja relacijska

shema R z množico atributov, katere podmnožici sta X in Y.

V relacijski shemi R velja X Y (X funkcionalno določa Y oziroma Y je funkcionalno odvisen od X), če v nobeni relaciji, ki pripada shemi R, ne obstajata dve n-terici, ki bi se ujemali v vrednostih atributov X in se ne bi ujemali v vrednostih atributov Y.


- 234 -

Funkcionalne odvisnosti

Načrtovanje – Izdelava načrta PB Imamo relacijo s shemo

Izpit( VpŠt, Priimek, Ime, ŠifraPredmeta, DatumIzpita, OcenaPisno, OcenaUstno)

z naslednjim pomenom: Študent z vpisno številko VpŠt ter priimkom Priimek

in imenom Ime je na DatumIzpita opravljal izpit iz predmeta s šifro ŠifraPredmeta. Dobil je oceno OcenaPisno in OcenaUstno.

Funkcionalne odvisnosti sheme Izpit so: F { VpŠt (Priimek, Ime), (VpŠt, ŠifraPredmeta,

DatumIzpita) (OcenaPisno, OcenaUstno) }


- 235 -

Funkcionalne odvisnosti - primer

Načrtovanje – Izdelava načrta PB Ker je relacija množica n-teric, so v njej vse

n-terice ločene med seboj. Za sklicevanje na posamezno n-terico ni

potrebno poznati vseh vrednosti atributov n-terice, če v shemi nastopajo funkcionalne odvisnosti.

Množici atributov, ki določajo vsako n-terico, pravimo ključ relacije oziroma ključ relacijske sheme.


- 236 -

Ključi relacije

Načrtovanje – Izdelava načrta PB Predpostavimo, da obstaja relacijska

shema z atributi A1 A2, ... An, katere podmnožica je množica atributov X.

Atributi X so ključ relacijske sheme oziroma pripadajočih relacij, če sta izpolnjena naslednja dva pogoja: X A1 A2 ... An ne obstaja X’, ki bi bila prava podmnožica od X in ki

bi tudi funkcionalno določala A1 A2 ... An


- 237 -

Ključi relacije

Načrtovanje – Izdelava načrta PB Poznamo več vrst ključev:

Kandidat za ključ (a key candidate) Primarni ključ (primary key) Superključ (superkey) Tuji ključ (foreign key)

Kandidat za ključ je vsaka podmnožica atributov relacije, ki relacijo enolično določa.


- 238 -

Ključi relacije

Načrtovanje – Izdelava načrta PB Primarni ključ je tisti kandidat za ključ, ki

ga izberemo za shranjevanje relacij v fizični podatkovni bazi.

Superključ je vsaka množica atributov, v kateri je vsebovan ključ ključ je podmnožica superključa.

Tuji ključ je množica atributov, v okviru ene relacije, ki je enaka kandidatu za ključ neke druge ali iste relacije.


- 239 -

Ključi relacije



- 240 -

Ključi relacije primer

Šifra Naziv Zaloga

A10 Telovadni copati Nike 10

A12 Trenerka Bali 4

BC80 Moška jakna QuickSilver 1

X12 Ženska jakna QuickSilver 0

Račun Šifra artikla Količina

15/05 A10 1

15/05 X12 1

Primarni ključ v tabeli Artikel

Primarni ključ v tabeli Račun

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

ARTIKEL

RAČUN

Načrtovanje – Izdelava načrta PB Za celovitost ter skladnost podatkov v

podatkovni bazi skrbimo s pomočjo omejitev.

Poznamo več vrst omejitev: Omejitve domene (Domain constraints) Pravila za celovitost podatkov (Integrity constraints)

Celovitost entitet (Entity Integrity) Celovitost povezav (Referential Integrity)

Števnost (Multyplicity) Splošne omejitve (General constraints)


- 241 -

Omejitve nad podatki

Načrtovanje – Izdelava načrta PB Omejitev entitete

V osnovni relaciji ne sme biti noben atribut, ki je del ključa, enak Null.

Omejitve povezav Če v relaciji obstajajo tuji ključi, potem morajo:

(a) njihove vrednosti ustrezati tistim, ki so v obliki ključa zapisane v eni izmed n-teric neke druge ali iste relacije

(b) ali pa mora biti tuji ključ v celoti enak Null.


- 242 -


Načrtovanje – Izdelava načrta PB Splošne omejitve

Dodatna pravila, ki jih določi uporabnik ali skrbnik podatkovne baze, ki definirajo ali omejujejo nek vidik področja, za katerega je narejena podatkovna baza.


- 243 -




- 244 -

PedagogEMŠO N13 <pk>DavcnaSt C9 not nullIme C20 Priimek C20DtmRoj DKatedra N3 <fk>

Primarni ključ ne sme biti NULL

Zahtevamo obveznost podatka

KatedraKatedra N3 <pk>Naziv C20 not nullStLab N2 Vodja N3 <fk>

Omejitev povezave

Omejitve nad podatki – primeri omejitev

Načrtovanje – Izdelava načrta PB Pogled je navidezna relacija, ki ne obstaja v

relacijski bazi, temveč se dinamično kreira takrat, ko nekdo po njej povprašuje.

Vsebina pogleda je definirana kot poizvedba nad eno ali več osnovnimi relacijami.

Pogledi so dinamični spremembe nad osnovnimi relacijami, katerih atributi so zajeti tudi v pogledu, so v pogledu takoj vidne.


- 245 -

Pogledi

Načrtovanje – Izdelava načrta PB Zakaj uporabljamo poglede:

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

Prilagojenost uporabnikom: uporabnikom dajejo možnost, da do podatkov dostopajo na prilagojen način isti podatki so lahko s strani različnih uporabnikov v istem času vidni na različne načine.

Poenostavitev: poenostavljajo kompleksne operacije nad osnovnimi relacijami.


- 246 -

Namen uporabe pogledov

Načrtovanje – Izdelava načrta PB Vse spremembe nad osnovnimi relacijami

morajo biti takoj vidne tudi v pogledih nad temi relacijami.

Če spremenimo podatke v pogledu, se morajo spremembe poznati tudi v osnovnih relacijah, na katere se te spremembe nanašajo.


- 247 -

Spreminjanje pogledov

Načrtovanje – Izdelava načrta PB V pogledih niso možne vse spremembe.

Veljajo naslednje omejitve: Nad pogledom so možne spremembe, če pogled

zajema eno samo osnovno relacijo ter vključuje atribute, ki so kandidat za ključ relacije.

Če pogled zajema več relacij, spremembe niso možne.

Če je pogled pridobljen z agregacijo ali grupiranjem n-teric, spremembe niso možne.


- 248 -

Spreminjanje pogledov



- 249 -

Šifra Naziv Zaloga


A12 Trenerka Bali 4

BC80 Moška jakna QuickSilver 1


Račun Šifra artikla Količina

15/05 A10 1

15/05 X12 1

16/05 A10 3

17/05 A10 1

RAČUNARTIKEL

SELECT A.sifra, A.naziv, sum(R.kolicina) AS ProdanihFROM artikel A, racun RWHERE A.sifra = R.sifraGROUP BY A.sifra, A.naziv

Šifra Naziv Prodanih



...

Primer pogleda

Načrtovanje – Izdelava načrta PB Normalizacija je postopek, s katerem

pridemo do množice primernih relacij, ki ustrezajo potrebam poslovne domene.

Nekaj lastnosti primernih relacij: Relacije imajo minimalen nabor atributov zgolj

tiste, ki so potrebni za pokritje potreb poslovnega sistema;

Atributi, ki so logično povezani, so zajeti v isti relaciji; Med atributi relacij je minimalna redundanca vsak

atribut (razen tujih ključev) je predstavljen samo enkrat.


- 250 -

Normalizacija

Načrtovanje – Izdelava načrta PB Prednosti uporabe podatkovnih baz, ki jih

sestavljajo množice primernih relacij, so: Enostavnejša dostop do podatkov ter vzdrževanje

podatkov; Večja učinkovitost; Boljša izraba diskovnih kapacitet.


- 251 -

Normalizacija

Načrtovanje – Izdelava načrta PB Relacije, ki vsebujejo odvečne podatke

lahko povzročajo anomalije pri spreminjanju podatkov govorimo o ažurnih anomalijah.

Poznamo več vrst anomalij: Anomalije pri dodajanju n-teric v relacijo Anomalije pri brisanju n-teric iz relacije Anomalije pri spreminjanju n-teric


- 252 -

Normalizacija – ažurne anomalije

Načrtovanje – Izdelava načrta PB Primeri anomalij:

Če želimo dodati podatke o novih članih (staff) za neko organizacijsko enoto (branch) moramo vpisati tudi vse podrobnosti o organizacijski enoti.

Če želimo dodati podatke o novi organizacijski enoti, ki še nima nobenega člana, moramo v vsa polja , ki člane opisujejo, vpisati Null.


- 253 -

Normalizacija – ažurne anomalije pri dodajanju


Če iz relacije zbrišemo n-terico, ki predstavlja zadnjega člana v neki organizacijski enoti, zgubimo tudi podatke o tej organizacijski enoti.


- 254 -

Normalizacija – ažurne anomalije pri brisanju


Če želimo spremeniti vrednost nekega atributa določene organizacijske enote (npr. naslov), moramo popraviti vse n-terice, v katerih takšna vrednost atributa nastopa.


- 255 -

Normalizacija – ažurne anomalije pri spreminjanju

Načrtovanje – Izdelava načrta PB Postopku preoblikovanja relacij v obliko, pri

kateri do ažurnih anomalij ne more priti, pravimo normalizacija.

Obstaja več stopenj normalnih oblik: 1NO – Prva normalna oblika 2NO – Druga normalna oblika 3NO – Tretja normalna oblika in 4PNO – Četrta poslovna normalna oblika BCNO – Boyce Codova normalna oblika 4NO – Četrta normalna oblika 5NO – Peta normalna oblika


- 256 -

Normalne oblike

Načrtovanje – Izdelava načrta PB Relacija je v prvi normalni obliki, če:

Nima ponavljajočih atributov ne obstajajo atributi ali skupine atributov, ki bi imele več vrednosti pri isti vrednosti ostalih atributov (na presečišču ene vrstice in enega stolpca je več vrednosti)

Ima definiran primarni ključ in določene funkcionalne odvisnosti

Koraki: Odstranimo ponavljajoče atribute Določimo funkcionalne odvisnosti Določimo primarni ključ


- 257 -

Normalizacija – prva normalna oblika



- 258 -

VŠ priimek ime pošta kraj šifra predmeta naziv ocena64010632 Bratina Simon 4100 Kranj 20020

2002120033

ISTPOIPI

1088

64016209 Bizjak Tadeja 2250 Ptuj 2006020033

E1IPI

96

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

Skupina ponavljajočih se atributov.



- 259 -

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

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

Odpravimo ponavljajoče atribute

Identificiramo funkcionalne odvisnosti

F { VŠ (priimek, ime, pošta, kraj), šifra predmeta naziv, pošta kraj, (VŠ, šifra predmeta) ocena }

Določimo primarni ključ

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



- 260 -

VŠ priimek ime pošta kraj šifra predmeta naziv ocena64010632 Bratina Simon 4100 Kranj 20020 IS 1064010632 Bratina Simon 4100 Kranj 20021 TPO 864010632 Bratina Simon 4100 Kranj 20033 IPI 864016209 Bizjak Tadeja 2250 Ptuj 20060 E1 964016209 Bizjak Tadeja 2250 Ptuj 20033 IPI 6

VŠ priimek ime pošta kraj šifra predmeta naziv ocena64010632 Bratina Simon 4100 Kranj 20020

2002120033

ISTPOIPI

1088

64016209 Bizjak Tadeja 2250 Ptuj 2006020033

E1IPI

96

Načrtovanje – Izdelava načrta PB Relacija je v drugi normalni obliki:

Če je v prvi normalni obliki in Ne vsebuje parcialnih odvisnosti noben atribut, ki

ni del ključa, ni funkcionalno odvisen le od dela primarnega ključa, temveč od celotnega ključa


- 261 -

Normalizacija – druga normalna oblika



- 262 -

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

!

Relacijo razbijemo

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

!

Načrtovanje – Izdelava načrta PBVŠ priimek ime pošta kraj šifra predmeta naziv ocena64010632 Bratina Simon 4100 Kranj 20020 IS 1064010632 Bratina Simon 4100 Kranj 20021 TPO 864010632 Bratina Simon 4100 Kranj 20033 IPI 864016209 Bizjak Tadeja 2250 Ptuj 20060 E1 964016209 Bizjak Tadeja 2250 Ptuj 20033 IPI 6


- 263 -

VŠ priimek ime pošta kraj64010632 Bratina Simon 4100 Kranj64016209 Bizjak Tadeja 2250 Ptuj

šifra predmeta

naziv

20020 IS20021 TPO20033 IPI20060 E120033 IPI

VŠ šifra predmeta

ocena

64010632 20020 1064010632 20021 864010632 20033 864016209 20060 964016209 20033 6

Načrtovanje – Izdelava načrta PB Relacija je v tretji normalni obliki:

Če je v drugi normalni obliki in Če ne vsebuje tranzitivnih funkcionalnih odvisnosti

med atributi, ki niso del primarnega ključa, ni odvisnosti.


- 264 -

Normalizacija – tretja normalna oblika



- 265 -

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

!

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

Relacijo razbijemo



- 266 -

VŠ priimek ime pošta kraj64010632 Bratina Simon 4100 Kranj64016209 Bizjak Tadeja 2250 Ptuj

VŠ priimek ime pošta64010632 Bratina Simon 410064016209 Bizjak Tadeja 2250

pošta kraj4100 Kranj2250 Ptuj

Načrtovanje – Izdelava načrta PB Relacija je v četrti poslovni normalni obliki,

če: je v tretji normalni obliki in v relaciji ne obstajajo atributi, ki bi bili odvisni od

vrednosti primarnega ključa.


- 267 -

Normalizacija – četrta poslovna normalna oblika



- 268 -

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

Za izredne študenta Za redne študenta

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



- 269 -

VŠ Priimek Ime Datum plačila šolnine Rok diplome64010632 Bratina Simon 15.3.200564016209 Bizjak Tadeja 19.4.200264010670 Berce Marjan 12.4.200464620010 Mele Silvana 1.4.200565120987 Leban Tibor 15.7.2005

VŠ Priimek Ime64010632 Bratina Simon64016209 Bizjak Tadeja64010670 Berce Marjan64620010 Mele Silvana65120987 Leban Tibor

VŠ Datum plačila šolnine64016209 19.4.200264010670 12.4.2004

VŠ Rok diplome64010632 15.3.200564620010 1.4.200565120987 15.7.2005

Načrtovanje – Izdelava načrta PB Tipični koraki:

Za entitetne tipe kreiraj relacije Preveri relacije z normalizacijo Preveri relacije s pregledom uporabniških transakcij Preveri omejitve integritete Preveri model z uporabnikom Združi lokalne modele v globalni model (opcijsko) Preveri zmožnosti modela za razširitve


Tipični koraki pri izdelavi relacijskega modela Ponovitev



Primer pretvorbe konceptualnega v relacijski model

IzpitZap. št. polaganjaOcena pisnoOcena ustnoDatum ocene

ŠtudentVpisna številkaPriimekImeNaslovTelefonE-mailStatus…

StudentVpisSt N8 <pk>Priimek C20Ime C20Ulica C25Posta N4Drzava C20GSM N15Tel N15Email C25 nullStatus N1…

IzpitZapStPol N2 <pk>VpisSt N8 <pk, fk>OcPisno N2,2OcUstno N2,2DatumOc D

VpisSt = VpisSt



Primer pretvorbe konceptualnega v relacijski model

StudentVpisSt N8 <pk>Priimek C20Ime C20Ulica C25Posta N4Drzava C20GSM N15Tel N15Email C25 nullStatus N1…

IzpitZapStPol N2 <pk>VpisSt N8 <pk, fk>OcPisno N2,2OcUstno N2,2DatumOc D

VpisSt = VpisSt

Dodatno poskrbimo za: Indekse Integriteto povezav Druge omejitve Poglede …

Razvoj po strukturnem pristopu Postopki strukturnega pristopa:

Zajem in specifikacija zahtev; Analiza Načrtovanje

• Izdelava načrta podatkovne baze,• Izdelava načrta programskih modulov,• Izdelava načrta dokumentacije,• Izdelava načrta testiranja,• Izdelava načrta namestitve in uvedbe in• Predstavitev načrta naročniku.

Izvedba; Testiranje; Namestitev in uvedba.


- 273 -

Kje smo?

Načrtovanje – izdelava načrta modulov Namen aktivnosti je prikazati, kako bodo

posamezne funkcije in procesi, identificirani v sklopu analize, realizirani v okviru rešitve.


- 274 -

Namen aktivnosti

Analiza

Proces FunkcijaProces

ProcesFunkcija

FunkcijaFunkcija

Funkcija

Načrt

Programski modulProgramski modulProgramski modul

Programski modul

Programski modul

Programski modulProgramski modul

Načrtovanje – izdelava načrta modulov Funkcije in procesi iz analize predstavljajo

logične sklope sistema. V fazi načrtovanja jih pretvorimo v fizične oziroma programske sklope ali module.

Pretvorba ni nujno 1:1 Implementacija enega logičnega sklopa je lahko

izvedena z več programskimi sklopi. En programski sklop lahko implementira več logičnih

enot.


- 275 -

Namen aktivnosti

Fizična enota1..n 1..n

Logična enota

Načrtovanje – izdelava načrta modulov Tipi programskih modulov:

Zaslonska maska Obdelava Poročilo ali izpis


- 276 -

Programski modul

Zaslonska maska

Izpis/ poročilo

Paketna obdelava

Programski moduli

Načrtovanje – izdelava načrta modulov Strukturo programskih modulov prikažemo

s pomočjo strukturnega diagrama.

Lastnosti strukturnih diagramov: Prikazuje programske module, s katerih bo

sestavljena informacijska rešitev; Prikazuje odvisnost med programskimi moduli ter

podatke, ki se med moduli prenašajo; Omogoča prikaz zaporedja, izbire in ponavljanja.


- 277 -

Strukturni diagram

Načrtovanje – izdelava načrta modulov Lastnosti strukturnih diagramov:

Moduli so organizirani v hierarhijo, podobno kot funkcije v funkcionalni razgradnji.

Na najvišjem mestu je vseobsegajoč modul ali koren. Na naslednjem nivoju so moduli, ki jih koren lahko kliče (analogno kot izbire v meniju).

Moduli komunicirajo med seboj s pomočjo parametrov:

• nosilci podatkov• kontrolne zastavice


- 278 -

Strukturni diagram

Načrtovanje – izdelava načrta modulov


- 279 -

Strukturni diagram – primer

Dodajizpitni rok

Izračunajdan roka

Preveriposlovna

praviladan roka pravilaOK

številkakršenegapravila

kontrolna zastavicapodatek






- 280 -

Kje smo?

Načrtovanje – načrt dokumentacije Namen aktivnosti je določiti obseg in

strukturo dokumentacije ter izbrati ustrezne standarde in vzorce za dokumentacijo.

Upoštevamo zahteve naročnika iz zajema in specifikacije zahtev.

Določimo tudi vire za dokumentacijo.


- 281 -

Izdelava načrta dokumentacije

Načrtovanje – načrt dokumentacije Potrebno upoštevati, da lahko nekatere

dele dokumentacije izdelamo šele, ko je del sistema, ki ga dokumentiramo, izdelan: Npr. posnetke zaslonov za uporabniško

dokumentacijo lahko izdelamo šele, ko je uporabniški vmesnik izdelan in smo prepričani, da se ne bo več spreminjal.

V grobem lahko dokumentacijo razdelimo na: uporabniško dokumentacijo, sistemsko-tehnično dokumentacijo ter navodila za operativno skrbništvo.


- 282 -


Načrtovanje – načrt dokumentacije Uporabniška dokumentacija je osnovna

pomoč za uporabnike oziroma uporabo rešitve.

Možne različne oblike…


- 283 -


Vir: ERP sistem Pantheon

Načrtovanje – načrt dokumentacije Sistemsko-tehnična dokumentacija

dokumentira informacijsko rešitev s sistemsko-tehničnega vidika. Npr.: Podatkovni model; Arhitektura sistema; Komponente sistema; Opis testnega, produkcijska in razvojnega okolja; Opis sistemske programske opreme in druge

infrastrukture, ki je potrebna za delovanje sistema; …


- 284 -


Načrtovanje – načrt dokumentacije Navodila za operativno skrbništvo zajemajo

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


- 285 -


Načrtovanje – načrt dokumentacije V okviru načrta dokumentacije izdelamo

vzorce dokumentacije in jih predstaviti naročniku ter uporabniku.

Cilj je uskladitev o obliki dokumentacije.

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


- 286 -







- 287 -

Kje smo?

Načrtovanje – načrt testiranja Testiranje, ki intenzivno poteka v fazi

izvedbe ter v okviru namestitve in uvedbe sistema, je nujno predhodno načrtovati.

Načrt testiranja zajema: Načrt poteka testiranja Načrte za izvedbo posameznih testov


- 288 -

Izdelava načrta testiranja

Načrtovanje – načrt testiranja Osnovni potek testiranja, vrste testov in

vsebino testiranja določa postopek testiranja.

Z načrtom poteka testiranja, ki ga izdelamo v sklopu načrtovanja, podrobneje določimo zaporedje izvajanja posameznih testov po sklopih informacijske rešitve in po okoljih.

Načrt poteka testiranja je odvisen od načrta programskih modulov.


- 289 -

Načrt poteka testiranja

Načrtovanje – načrt testiranja Z načrti za izvedbo posameznih testov

podrobneje določimo, kaj bomo v okviru posameznega testa, ki je predviden v načrtu poteka testiranja, testirali.

V odvisnosti od namena testiranja, faze testiranja in okolja testiranja podrobneje določimo vsebino testiranja npr. testiranje funkcionalnosti, testiranje GUI,

testiranje vmesnikov, testiranje prevedbe podatkov, testiranje drugih nefunkcionalnih zahtev IR ipd.


- 290 -

Načrt za izvedbo testa

Načrtovanje – načrt testiranja Načrt za izvedbo testa mora opredeliti vsaj:

Namen testiranja: čemu je namenjena izvedba testa? (npr. testiranje programske enote »Prijava na izpit«)

Faza testiranja: v kateri fazi izvajamo testiranje? (npr. testiranje v fazi razvoja ali testiranje v fazi namestitve in uvedbe)

Okolje testiranja: v katerem okolju je potrebno test izvesti? (npr. v testnem okolju)

Področje testiranja: kaj se s testom testira? (npr. funkcionalnost sklopa, integracija sklopa, GUI,...)

Način izvedbe testiranja: podroben opis, ki pove, kako se izvede test. Opis je odvisen od področja testiranja.


- 291 -

Načrt za izvedbo testa

Načrtovanje – načrt testiranja Pri izdelavi načrtov za izvedbo posameznih

testov si pomagamo s testnimi scenariji. Testni scenariji opisujejo postopke uporabe

sistema in so zato dobro vodilo za testiranje funkcionalnosti IR.

V okviru testiranja po izbranem scenariju spremljamo uporabo in spreminjanje izbranih podatkov, na osnovi česar lahko ob zaključku testa bodisi potrdimo ali ovržemo pravilnost delovanja modulov/ sklopov, ki so bili v testu vključeni.


- 292 -

Uporaba scenarijev

Načrtovanje – načrt testiranja

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


- 293 -

Uporaba scenarijev



- 294 -

Opredelitev scenarija

Testno oklolje

Razvojno okolje

T1 T2 T3 T4 T5 T6

T7

T8

Produkcijsko okolje

Tn-1

Tn

Načrt poteka testiranja

Test T3

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


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.


- 295 -

Načrt testiranja – izdelek



- 296 -

Načrt testiranja – primer načrta poteka testiranja

Načrt poteka testiranjaT1: sklop: prijava na izpit

okolje: razvojT2: sklop: odjava iz izpita

okolje: razvojT3: sklop: pregled števila prijavljenih kandidatov

okolje: razvoj T4: sklop: Izpis seznama prijavljenih kandidatov

okolje: razvoj T5: sklop: Vnos rezultatov

okolje: razvoj T6: sklop: Objava rezultatov

okolje: razvoj T7: sklop: Opravljanje pisnih izpitov (integracijski test)

okolje: testnoT8: sklop: Vnos obvestil

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

okolje: testnoTn: sklop: celoten sistem (končni test)

okolje: produkcijsko

Testno oklolje

Razvojno okolje

T1 T2 T3 T4 T5 T6

T7

T8

Produkcijsko okolje

Tn-1

Tn



- 297 -

Načrt testiranja – primer načrta za izvedbo testa

NAČRT TESTIRANJA ZA TEST T2

Namen testiranja: testiranje sklopa odjava iz izpitaFaza testiranja: testiranje v fazi razvojaOkolje testiranja: razvojno okoljePodročje testiranja: funkcionalnost sklopa, GUI

Način izvedbe testiranja:

1. Testiranje funkcionalnosti: testirati po scenarijih S1, S3, S4, S82. Testiranje GUI: preveriti skladnost elementov GUI z načrtom

programskega modula/podsistema PM3



- 298 -

Načrt testiranja – primer scenarija

OZNAKA SCENARIJA: S3

Kratek opis: odjava iz izpitnega roka, če je rok za odjavo že potekel

Koraki scenarija: 1. v sistem se prijaviti kot študent [Š]2. prijaviti se na razpisan rok za izbran datum in predmet [I]3. na strežniku spremeniti sistemski datum na trenutni datum [D]4. poskusiti se odjaviti iz izpita [I]

Vhodni podatki: Š, I, D

Pričakovani rezultati: sistem ne dovoli odjave iz izpita [I]. Če študent izbere opcijo Odjava iz izpita, dobi sporočilo »Iz izpita se ne morete odjaviti. Rok za odjavo je že potekel!«.






- 299 -

Kje smo?

Načrtovanje – načrt namestitve in uvedbe Naloga aktivnosti je izdelati načrt

namestitve in uvedbe IR v razvojno, testno in produkcijsko okolje ter uvedbo uporabnikov in skrbnikov za delo z IR.

Načrt namestitve in uvedbe v razvojnem okolju pripravijo člani projektne skupine razvijalca, pri izdelavi načrta namestitve in uvedbe v testnem oz. produkcijskem okolju pa sodelujejo tudi predstavniki končnih uporabnikov.


- 300 -

Načrt namestitve in uvedbe

Načrtovanje – načrt namestitve in uvedbe V načrtu potrebno opredeliti:

namen in cilj namestitve in uvedbe, zahteve okolja za namestitev in uvedbo (pogoji za

izvedbo namestitve in uvedbe, potrebna strojna oprema, potrebna sistemska programska oprema, povezovanje z ostalo aplikativno opremo, potrebna dokumentacija),

naloge namestitve in uvedbe (funkcionalne naloge, administrativne naloge),

udeležence namestitve in uvedbe, njihove odgovornosti ter vključitev uporabnikov in skrbnikov,

opis sestave paketa za namestitev IR (določitev in označitev distribucijskih medijev - CD-ROM, diskete, spletne strežniške datoteke, priložena dokumentacija),RAZVOJ INFORMACIJSKIH SISTEMOV


- 301 -


Načrtovanje – načrt namestitve in uvedbe V načrtu potrebno opredeliti

(nadaljevanje): opis procesa namestitve in uvedbe (način izvedbe

faz namestitve, dodelitev pravic za delo, opis prevedbe podatkov, opis načina uvajanja uporabnikov in skrbnikov, opis izvedbe potrditvenega testa IR, opis prehoda na nov sistem),

merila za uspešno namestitev in uvedbo (ključne točke za uspešno opravljeno namestitev, seznam ali opis pričakovanih rezultatov namestitve in uvedbe in dovoljenih odstopanj),

vrednotenje ugotovljenih napak ali pomanjkljivosti pri postopku namestitve in uvedbe,

potrditev oz. odobritev rezultatov namestitve in uvedbe.RAZVOJ INFORMACIJSKIH SISTEMOV


- 302 -


Načrtovanje – načrt namestitve in uvedbe Načrt namestitve in uvedbe se sestoji iz:

načrta namestitve IR; načrta dodelitve pravic; načrta prevedbe podatkov; načrta uvajanja načrta za izvedbo potrditvenega ter končnega testa

IR načrta prehoda na nov sistem


- 303 -





Izvedba; Testiranje; Namestitev in uvedba


- 304 -

Kje smo?

Načrtovanje – predstavitev načrta

Osnovni namen predstavitve je pridobitev potrditve s strani naročnika o ustreznosti načrta.

Pri predstavitvi je potrebno upoštevati, da naročnik navadno nima strokovnih znanj, ki bi mu omogočala poglobljeno razumevanje načrta, hkrati pa to tudi ni njegova naloga.

Naročniku predstavimo le osnovne elemente načrta.


- 305 -

Predstavitev načrta naročniku

Načrtovanje – predstavitev načrta

Primeren za podrobno predstavitev je načrt uporabniškega vmesnika posredno razkriva tudi druge elemente načrta.

Na osnovi predstavitve lahko naročnik opozori na pomanjkljivosti oz. izrazi dodatne želje.

Aktivnost se zaključi s potrditvijo naročnika (navadno podpis dokumenta), da načrt ustreza zahtevam.


- 306 -

Predstavitev načrta naročniku


Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.


- 307 -

Kje smo?

Testiranje

Glavni namen testiranja jezagotoviti, da IR deluje tako, kot smo načrtovali.

Postopek testiranja se prepleta skozi ves življenjski cikel razvoja IR: analiza, načrtovanje, izvedba inuvedba.


- 308 -


Podroben opis aktivnosti testiranja je podan po posameznih postopkih.

Testiranje

Končen izdelek testiranja je preverjena in delujoča IR.

Skozi potek testiranja nastane tudi več drugih izdelkov. Opisani so pri aktivnostih, kjer nastanejo (glej

postopke analiza, načrtovanje in uvedba).


- 309 -

Končni izdelek e

Testiranje

Testiranje se izvaja na različnih ravneh. Prvo testiranje izvaja že sam razvijalec

neposredno ob razvoju. Sledi sistematično testiranje s strani preizkuševalca, zatem pa še testiranje s strani končnega uporabnika.


- 310 -

Vloge

Testiranje

Za zagotovitev ustrezne ravni varnosti potrebno za testiranje in produkcijo zagotoviti ločena okolja.

Ločena okolja pogosto težko (drago) zagotoviti.

Najboljši pristop je uporaba ločene strojne opreme.

Produkcijsko okolje vedno namestimo na ločeno strojno opremo.


- 311 -

Okolje za testiranje

Testiranje


- 312 -

Primer okolja za testiranje

Razvojni AS Razvojni PS

Testni AS in PS

Produkcijski AS

Produkcijski PS

Razvoj in vmesnotestiranje

Končno testiranje in produkcija

Testiranje


- 313 -

Shema postopka

Testiranje

Testiranje poteka na različnih ravneh, v različnih okoljih in s strani različnih vlog.

Vrste testov: Test programskih enot Test integracije Sistemski test Test sprejemljivosti - Potrditveni test Test sprejemljivosti - Končni test


- 314 -

Vrste in potek testiranja

Testiranje


- 315 -


Vrsta testa Vsebina testiranja Okolje testiranja

Vloge

Test programskih enot

Uporabniški vmesnik, funkcionalnost programske enote, skladnost z zahtevami in standardi

Razvojno okolje,Testno okolje

Razvijalec, Preizkuševalec

Test integracije Test integracije programskih enot, test integracije v okolje (vmesniki)

Testno okolje

Integrator, Preizkuševalec,Ključni uporabnik

Sistemski test Obnašanje v okolju, zmogljivosti, dostopnost, nefunkcionalne zahteve

Testno okolje

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

Test sprejemljivosti - Potrditveni test

Preverjanje delovanja celotne funkcionalnosti, preverjanje nefunkcionalnih zahtev

Testno okolje

Ključni uporabnik

Test sprejemljivosti - Končni test

Test funkcionalnosti v omejenem obsegu v produkcijskem okolju

Produkcijsko okolje

Ključni uporabnik

Testiranje

Testiranje programski enot Testiranje programskih enot je osnovno testiranje,

osredotočeno na ustreznost uporabniškega vmesnika in funkcionalnosti programske enote glede na podane zahteve in standarde.

Izvaja v razvojnem okolju. Najprej se s testiranjem ukvarjajo razvijalci, ko sami testirajo module oziroma programske enote, ki so jih razvili.

Testiranje s strani razvijalcev je navadno nesistematično in se ne izvaja po načrtu.


- 316 -


Testiranje

Testiranje programski enot (nadaljevanje) Ko razvitih več programskih enot (funkcionalni

sklop), testiranje prevzame preizkuševalec. Skladno z načrtom testiranja preveri pravilnost funkcionalnega sklopa, preden se le-ta namesti v testno okolje.

Testiranje programskih enot se izvaja tudi v testnem okolju. Sodelujeta preizkuševalec in ključni uporabnik. Ustreznost sklopa potrdi ključni uporabnik.

Če je moč testiranje v testnem in razvojnem okolju izvajamo vzporedno.


- 317 -


Testiranje

Testiranje integracije Testiranje integracije namenjeno testiranju povezav

med programskimi enotami ter testiranju vmesnikov - povezav IR z okoljem.

Testiranje integracije poteka v več korakih, vzporedno z razvojem. Testiranje vmesnikov z okoljem navadno izvedemo na koncu za celoten sistem.

Testiranje integracije poteka v testnem okolju. Pri tem sodelujejo integrator, preizkuševalec in ključni uporabniki.

Testiranje se izvaja po pripravljenem načrtu in se zaključi z ustrezno potrditvijo.


- 318 -


Testiranje

Testiranje sistema Testiranje sistema namenjeno testiranju obnašanja

sistema kot celote ter njegovega delovanja v okolju. Poudarek na testiranju nefunkcionalnih zahtev kot na primer: zmogljivost, dostopnost, test pod obremenitvijo ipd.

Test se izvaja v testnem okolju. Izvede se enkrat, in sicer takrat, ko je v testnem okolju nameščen celoten sistem in povezan z okoljem. Pri izvedbi testa sodelujejo: skrbnik podatkovne baze, sistemski administrator, skrbnik aplikacije, preizkuševalec in ključni uporabniki.


- 319 -


Testiranje

Testiranje sprejemljivosti Test sprejemljivosti se deli na potrditveni test in

končni test.

Potrditveni test namenjen testiranju celotne IR, tako z vidika funkcionalnih kot nefunkcionalnih zahtev, z namenom pridobitve potrdila o njegovi ustreznosti. Test se izvaja v testnem okolju v sklopu postopka namestitve in uvedbe IR. Test izvaja ključni uporabnik po pripravljenem načrtu.

Končni test je zadnji test IR. Izvedemo ga v produkcijskem okolju z namenom, da se prepričamo, da pri postopku namestitve ni prišlo do kakršnihkoli napak. Končni test izvedemo s pomočjo produkcijskih oziroma pravih primerov. Izvaja ga ključni uporabnik.RAZVOJ INFORMACIJSKIH SISTEMOV


- 320 -



Zajem in specifikacija zahtev; Analiza; Načrtovanje; Izvedba; Testiranje; Namestitev in uvedba.


- 321 -

Kje smo?

Namestitev in uvedba

Glavni namen namestitve in uvedbe je namestitev izbrane IR ali njenih delov v testno ali

produkcijsko okolje ter; izvedba potrditvenega in končnega testa IR; uvedba uporabnikov, skrbnikov in drugih, ki

bodo z IR delali, za delo z novo IR.

Z izvedbo postopka zagotovimo, da lahko uporabniki nemoteno uporabljajo novo IR.


- 322 -



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.


- 323 -

Končni izdelek e


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.


- 324 -

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.


- 325 -

Vloge in koraki



- 326 -

Shema postopka



- 327 -

Shema postopka


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.


- 328 -

Kje smo?

Namestitev in uvedba – Namestitev IR Naloga namestitve je vključitev nove IR v

testno ali produkcijsko okolje. V okviru tega je potrebno namestiti: strojno opremo, sistemsko programsko opremo in aplikativno programsko opremo - programske

module.

Namestitev poteka na podlagi načrta namestitve IR, postopki nameščanja opreme pa morajo biti v čim večji meri avtomatizirani.


- 329 -

Namestitev IR

Namestitev in uvedba – Namestitev IR Namestitev IR v testno okolje poteka v več

fazah (med razvojem) ali v celoti (ob zaključku).

Namestitev IR v produkcijsko okolje se izvede, ko je aplikacija razvita in potrjena s potrditvenim testom v testnem okolju.


- 330 -

Namestitev IR





- 331 -

Kje smo?

Namestitev in uvedba – Dodelitev pravic V skladu z načrtom namestitve in uvedbe –

načrt dodelitve pravic definiramo vloge, izvedemo vključitev oseb – uporabnikov v ustrezne vloge in jim dodelimo gesla.

Upoštevamo tudi varnostno politiko. Pravice za dostop do podatkov in uporabo programskih modulov dodelimo naenkrat celotni posamezni skupini uporabnikov, ki izvajajo določeno vlogo.


- 332 -

Dodelitev pravic za delo z IR





- 333 -

Kje smo?

Namestitev in uvedba – Prevedba

Prevedba podatkov pomeni vzpostavitev začetnega stanja podatkov.

Prevedba podatkov je lahko zelo kompleksen proces, saj se poleg prenosa podatkov pogosto izvaja tudi čiščenje, agregacija, reorganizacija podatkovnih struktur itd.

Podatki v obstoječih sistemih so pogosto pomanjkljivi ali nepopolni, zapisani v obliki, ki je razumljiva zgolj programerjem itd.


- 334 -

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.


- 335 -

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.


- 336 -

Prevedba podatkov





- 337 -

Kje smo?

Namestitev in uvedba – Potrditveni test Potrditveni test izvedemo v testnem okolju. Predstavlja zaključni test pravilnega

delovanja celotne IR v testnem okolju in zajema vse funkcionalnosti sistema, potrebne za delovanje v testnem okolju.

Poteka na osnovi načrta testiranja in se zaključi s potrdilom o ustreznosti IR za namestitev v produkcijsko okolje.


- 338 -

Izvedba potrditvenega testa





- 339 -

Kje smo?

Namestitev in uvedba – Končni test

Končni test izvedemo v produkcijskem okolju.

Predstavlja končni test pravilnega delovanja IR v produkcijskem okolju in poteka na produkcijskih primerih - na "živih" oz. produkcijskih podatkih v produkcijskem okolju.

V končni test običajno ne moremo zajeti vse funkcionalnosti sistema. Poteka na osnovi načrta testiranja in se zaključi s potrdilom o ustreznosti IR za uporabo v produkcijskem okolju.


- 340 -

Izvedba končnega testa





- 341 -

Kje smo?

Namestitev in uvedba – Uvajanje

Naloga uvajanja je naučiti uporabnike uporabljati in skrbeti za IR.

Uvajanje izvaja uvajalec, ki je v primeru razvoja IR običajno član razvojne ekipe, v primeru nakupa IR pa predstavnik proizvajalca.

Osnovni cilj uvajanja je vsako skupino uporabnikov naučiti uporabljati tiste sklope IR, ki jih uporabniki pri svojem delu potrebujejo.


- 342 -

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.


- 343 -

Uvajanje uporabnikov in skrbnikov za delo z IR


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;


- 344 -

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.


- 345 -

Uvajanje uporabnikov in skrbnikov za delo z IR – Smernice





- 346 -

Kje smo?

Namestitev in uvedba – Prehod

Prehod na nov sistem predstavlja trenutek, ko je IR primerna za uporabo v produkcijskem okolju.

O trenutku začetka uporabe nove IR mora biti vnaprej obveščena vsa organizacija.

Najprimernejši termini za začetek uporabe nove IR so delovno neintenzivna obdobja. Pogoj, ki mora biti izpolnjen za možnost začetka uporabe, so uspešno opravljene aktivnosti namestitve, testiranja, prevedbe podatkov in uvajanja. RAZVOJ INFORMACIJSKIH SISTEMOV


- 347 -

Prehod na nov sistem


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

BigBang); Vzporedno delovanje (Parallel strategy).

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


- 348 -

Strategije uvedbe


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.


- 349 -

Strategije uvedbe – Fazni pristop



- 350 -

Strategije uvedbe – Fazni pristop – problem začasnih vmesnikov

Zunanji sistemi

Star sistem

Uvedba celotnega sistema naenkrat

Zunanji sistemiZunanji sistemi

Star sistem

Uvedba po delihI faza.


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.


- 351 -

Strategije uvedbe – Zamenjava ali vse naenkrat


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.


- 352 -

Strategije uvedbe – Vzporedno delovanje



- 353 -

Strategije uvedbe

Možni pristopi

Vse naenkrat

Postopoma

Zamenjava

Vzporedno

Po področjih

Po lokacijah

Po modulih

Po starih aplikacijah

V celoti vzporedno

Delno vzporedno

V celoti zamenjava

Poglavje IIIObjektni razvoj


- 354 -

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

Objektni pristop

Objektni pristop k razvoju IR se pojavi kot posledica uveljavitve objektnih programskih jezikov in objektnih tehnologij…

V 90-ih letih nastane več deset metod objektne analize in načrtovanja IR.

Objektna analiza in načrtovanje se od strukturnega ločuje predvsem v predstavitvi realnega sveta: ne ločuje med podatki in aktivnostmi temveč vse modelira z objekti.RAZVOJ INFORMACIJSKIH SISTEMOV


- 355 -

Osnovne značilnosti objektnega pristopa

Objektni pristop


- 356 -


Profesor

Študent

Učilnica Strukturni pristop1. Podatki

Študent Profesor Učilnica Predmet …

2. Procesi Vzdrževanje izpitnih rokov Opravljanje izpita Vodenje izpitne evidence …

Podatkovna baza

Programski modul

Programski modul

Programski modul

Programski modul

Programski modul

Programski modul

Programski modulProgramski modul:

Pregled zasedenosti učilnice

Podatkovna baza

Objektni pristop


- 357 -


Profesor

Študent

UčilnicaObjektni pristop

Objekt tipa ŠTUDENTLastnosti:

– Priimek, – Ime, – Vpisna številka,– …

Funkcije:– Prijava na izpit – Odjava iz izpita– Pregled elektronskega indeksa– …

Objekt tipa UČILNICALastnosti:

– Velikost, – Število sedežev, – …

Funkcije:– Pregled predavanj v učilnici po dnevih– Izpis naziva profesorja P, ki na določen dan D

predava v učilnici– …

Objekt Marko: PROFESOR

Objekt NP15: UČILNICA

Ali je učilnica NP15 15.5.07 prosta?

Objektni pristop


- 358 -

Primerjava postopkov strukturnega in objektnega razvoja IR

Zajem zahtev

Analiza

Načrtovanje

Izvedba

Uvajanje

Vzdrževanje

Testiranje

Življenjski cikel razvoja IR

Objektni pristop

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


- 359 -

Vsebina

Razvoj po objektnem pristopu Objektni pristop:

Osnovni principi objektne usmerjenosti;• Objekt in razred• Enkapsulacija ali skrivanje podatkov• Dedovanje in hierarhija

Jezik UML in proces RUP; Objekta analiza in načrtovanje;


- 360 -

Kje smo?

Osnovni principi objektne usmerjenosti Objekt lahko predstavlja fizično entiteto ali

konceptualni pojem. Učitelj, učenec,… Predmet, test,…

S stališča razvoja IR je objekt koncept, abstrakcija ali stvar z natančno določenimi mejami in pomenom za IR.


- 361 -

Definicija objekta

Osnovni principi objektne usmerjenosti Objekti lahko predstavljajo tudi konkretne

koncepte s področja računalniških jezikov in rešitev: Seznam Indeks …


- 362 -

Definicija objekta

Osnovni principi objektne usmerjenosti Objekt je abstrakcija neke entitete, ki je

pomembna za IR…


- 363 -

Abstrakcija

Vesna: ProfesorIme: Vesna JugTelefon: 01/4768 814

Prijavi (int pid): boolean

Osnovni principi objektne usmerjenosti Objekt ima svoje stanje, obnašanje in

identiteto.

Stanje objekta določajo njegove lastnosti: Flomaster ima barvo, proizvajalca, debelino,… Knjiga ima vsebino, število strani,

založnika,…


- 364 -

Stanje, obnašanje in identiteta objekta

Osnovni principi objektne usmerjenosti Objekt se zaveda svojega stanja! Ve

kakšne vrednost imajo lastnosti, ki ga opisujejo. Flomaster je rumene barve, debeline 3mm,

proizvajalca Pilot,… Knjiga opisuje razvoj IS, ima 432

strani, izdaja jo založba Pasadena,…

Vsakokrat ko se spremeni vrednost neke lastnosti, ki nas o objektu zanima, rečemo se je spremenilo stanje objekta.


- 365 -


Osnovni principi objektne usmerjenosti Objekti imajo svoje obnašanje.

Študent študira, se prijavi na izpit, opravlja izpit, posluša predavanja,…

Pisalo piše??? Kdo v resnici piše?

Objekt se zaveda, kajlahko počne in kaj selahko z njim počne!


- 366 -


Osnovni principi objektne usmerjenosti Objekte istega tipa združujemo v razrede. Razred je

opis skupine objektov z enakimi lastnostmi, enakim obnašanjem, povezavami in semantiko.

abstrakcija, ki poudarja pomembne karakteristike in izpusti ostale nepomembne karakteristike.

Objekt je primerek razreda.


- 367 -

Razred

Osnovni principi objektne usmerjenosti Odnos med objektom in razredom je

podoben odnosu med entiteto in entitetnim tipom.


- 368 -

Razred

Objekti Razred

Ime razreda: ProfesorLastnosti:• Ime• Priimek• …Obnašanje• …

Osnovni principi objektne usmerjenosti Koliko razredov je na sliki?


- 369 -

Razred





- 370 -

Kje smo?

Osnovni principi objektne usmerjenosti Enkapsulacija govori o organizaciji

podatkov, ki jih vemo o objektih, na način, da jih bo moč učinkovito uporabljati in vzdrževati?

Kar vemo o objektu, razdelimo v dve skupini: Kar moramo vedeti, da objekt lahko uporabimo, Kar moramo vedeti, da bo objekt pravilno deloval.


- 371 -

Enkapsulacija ali skrivanje podatkov

Osnovni principi objektne usmerjenosti Želimo se naučiti voziti avtomobil. Kaj

moramo o avtomobilu vedeti? Kako se upravlja z volanom, kako se

zavira in p pospešuje,… Potrebno vedeti, kako deluje

motor? Kako pride do vžiga?Kaj natančno se zgodi, kopritisnemo na plin?

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


- 372 -


Osnovni principi objektne usmerjenosti Kaj mora veljati, da objekt deluje pravilno?

Vmesnik nam omogoča uporabo objekta. Za njegovo pravilno delovanje pa morajo biti vse funkcije, ki jih vmesnik daje na voljo, tudi dejansko implementirane!

Za delovanje objekta moramo priskrbeti mehanizem, ki sezna odzivati na vmesnik…


- 373 -


Osnovni principi objektne usmerjenosti Enkapsulacija objekta zahteva, da

skrijemo: Implementacijo obnašanja, ki je na voljo prek

vmesnika; Podatke znotraj objekta, ki so potrebni za

implementacijo obnašanja in beležijo stanje objekta v vsakem trenutku njegovega obstoja.


- 374 -






- 375 -

Kje smo?

Osnovni principi objektne usmerjenosti Dedovanje je ključen koncept objektnega

razvoja. Pove, da ima objekt v času svojega kreiranja dostop

tudi do lastnosti drugih razredov poleg dostopa do razreda, kateremu pripada.

Podedovan razred združi vse lastnosti (lastne in podedovane) v svojo definicijo.

Primer: Profesor je poseben primer pedagoškega delavca. Objekt tipa profesor ima lastnosti pedagoškega

delavca ter svoje lastne lastnosti.


- 376 -

Hierarhija in dedovanje

Osnovni principi objektne usmerjenosti Primer razreda Profesor in Pedagoški delavec

Opis: P ima enake lastnosti

kot PD. Za P nas zanima tudi

akademski naziv teršt. predmetov, ki jihpoučuje.

P lahko razpisuje tuditeme za diplome.

P ima pri vnašanju ocen več pravic kot PD. Lahko vpisuje tudi ocene ustno…


- 377 -


Pedagoški delavecImePriimekEMŠOTelefonDelovno mestoDatum rojstvaNaslov…Razpiši izpitni rokVnesi oceno

ProfesorAkademski nazivŠtevilo predmetov…

Vnesi ocenoRazpiši temo diplome

Osnovni principi objektne usmerjenosti Razrede lahko zapišemo v hierarhijo.


- 378 -


Pedagoški delavec

Delavec

Oseba

Profesor

Redni profesor

Asistent

Strokovni sodelavecRaziskovalec

Osnovni principi objektne usmerjenosti Hierarhija razredov v Delphi razvojnem

okolju…


- 379 -


Osnovni principi objektne usmerjenosti Delček

razredne hierarhije java.awt…


- 380 -



Osnovni principi objektne usmerjenosti; Jezik UML in proces RUP:

• O jeziku UML• Osnove procesa objektnega razvoja RUP;

Objekta analiza in načrtovanje;


- 381 -

Kje smo?

Jezik UML in proces RUP


- 382 -

Zakaj UML?

Jezik za modeliranje

Poenotenproces

Skupinski razvoj



- 383 -

UML – univerzalni modelirni jezik

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

Univerzalni modelirni jezik



- 384 -

Razlogi za nastanek UML

V začetku 90-ih več kot 50 OO metod! Fusion, Shlaer-Mellor, ROOM, Wirfs-Brock, Coad-

Yourdon, MOSES, BOOM, OOSD, OSA, BON, Catalysis, HOOD, Ooram, DOORS …

Problem: Presek in konflikti v meta-modelih… Različne grafične notacije… Procesi različni ali manjkajo Gospodarstvo potrebuje standard!!!



- 385 -

UML – Zgodovina do 1997



- 386 -

Drugi viri in prispevki

Fusion

opisi operacij,oštevilčenje sporočil

Meyer

predpogoji inpopogoji

Harel

diagrami stanj

Wirfs-Brock

odgovornostiOdell

klasifikacija

Shlaer - Mellor

življenjski cikli objekta

Gamma, et.al

ogrodja, vzorci,opombe

BoochJacobsonRumbaugh


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…


- 387 -

UML danes



- 388 -

UML diagrami

Diagrami primerov uporabe

Razredni diagrami

Diagrami zapore-dja

Diagrami sodelova-njaKompo-

nentni diagrami

Diagrami stanj

Diagrami impleme-

ntacije

Diagrami aktivnosti

Objektni diagramiUML diagramske tehnike



- 389 -

UML diagramske tehnike – enostavnost

profesorizbira predmetov

za poučevanje

študent

seznam predavanj

prijava na izbirni predmet

vnos podatkov o študentih

vnos podatkov o profesorjih

Referent

sistem za pripravo urnikazaključitev prijave

?



- 390 -

UML diagramske tehnike – kompleksnost



- 391 -

UML diagramske tehnike – hrbtenica razvoja

Actor A

Use-Case 1

Use-Case 2

Actor B

user : »ç¿ëÀÚ

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repositorydocument : Document

gFile : GrpFile

9: sortByName ( )

L1: Doc vi ew request ( )

2: fetchDoc( )

5: readDoc ( )

7: readFile ( )

3: create ( )

6: fi llDocument ( )

4: create ( )

8: fil lFile ( )

GrpFile

read( )open( )create( )fillFile( )

rep

Repository

name : char * = 0

readDoc( )readFile( )

(from Persistence)

FileMgr

fetchDoc( )sortByName( )

Docum entList

add( )delete( )

Document

name : intdocid : intnumField : int

get( )open( )close( )read( )sortFileList( )create( )fillDocument( )

fList

1

FileList

add( )delete( )

1

File

read( )

read( ) fill the code..

UI

MFC

RogueWave

global

DocumentApp

Persistence W indow95

¹®¼ °ü¸ ® Å¬ ¶óÀÌ¾ ðÆ® .EXE

W indowsNT

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

W indowsNT

W indows95

Solaris

ÀÀ¿ë¼ ¹ö.EXE

AlphaUNIX

IBM Mainframe

µ¥ÀÌÅ¸º£ÀÌ½ º¼ ¹ö

W indows95

¹®¼ °ü¸® ¾ ÖÇÃ¸´

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

Document

FileManager

GraphicFileFile

Repository DocumentList

FileList

usermainWnd fileMgr :

FileMgrrepositorydocument :

DocumentgFile

1 : Doc v iew re ques t ( )

2: fetch Doc( )

3: cr eate ( )

4: creat e ( )

5 : readD oc ( )

6: f il lDocum ent ( )

7: readFi l e ( )

8: f ill Fi l e ( )

9: sortByNam e ( )

Æ¯ Á¤¹®¼ ¿ ¡ ´ëÇÑ º ±̧â ¦̧ »ç¿ëÀÚ°¡ ¿ äÃ»ÇÑ ´Ù.

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

È ̧é °´Ã ¼ ´Â ÀÐ ¾îµéÀ Î ° ´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î Á ¤·ÄÀ» ½ÃÄÑ È ̧é ¿¡ º ¸¿©ÁØ´Ù.

Customernameaddr

withdraw()fetch()send()

receive()

<<entity>>

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

Razvijalec

Poznavalecobravnavanega

področja

Openning

Writing

ReadingClosing

add file [ numberOffile==M AX ] / flag OFF

add file

close file

close file

Use-Case 3

urejanje izvorne kode, prevajanje, razhroščevanje, povezovanje

diagram primera uporabe razredni diagram

diagram sodelovanja

diagram zaporedja

diagramkomponent

diagram stanj

diagrampaketov

diagram implementacijerazred


Osnovni principi objektne usmerjenosti; Jezik UML in proces RUP:

• O jeziku UML• Osnove procesa objektnega razvoja RUP;

Objekta analiza in načrtovanje;


- 392 -

Kje smo?


Proces določa kdo dela kaj, kdaj in kako za doseganje določenega cilja.

Cilj razvoja IR je njena izgradnja ali izboljšava.


- 393 -

Proces razvoja

Nove ali spremenjenezahteve

Nov ali spremenjensistem

Proces razvoja IR


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


- 394 -

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


- 395 -

RUP – glavne lastnosti


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


- 396 -

RUP – šest poglavitnih dobrih praks

Iterativni razvoj

Nadzorovanje sprememb

Uporaba komponentne

arhitekture

Obvladovanje zahtev

Vizualno modeliranje

Preverjanjekakovosti


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


- 397 -

RUP – primeri uporabe kot osnova drugim aktivnostim


Primeri uporabe so hrbtenica procesa RUP.


- 398 -

RUP – primeri uporabe so hrbtenica procesa RUP

Zajem zahtev

Analiza

Načrtovanje

Implementacija

Testiranje


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


- 399 -

RUP – arhitekturna usmerjenost



- 400 -

RUP – arhitekturna usmerjenost – 4+1 pogledi na arhitekturo

Procesnipogled

Postavitveni pogled

Logičnipogled

Izvedbenipogled

ProgramerUpravljanje s prog. op.

ZmogljivostPrilagodljivostThroughput

System IntegratorsSystem topology

Delivery, installationcommunication

***System Engineering

Primer uporabe

Zgradba

Analitik/Razvijalec Končni upor.

Funkcionalnost

Procesnipogled

Postavitveni pogled

Logičnipogled

Izvedbenipogled

ProgramerUpravljanje z IR

ZmogljivostRazširljivostPrepustnost

Sistemski povezovalecTopologija sistema

Predaja v uporabo, namestitevkomunikacije

Sistemski inženir

Primer uporabe

ZgradbaAnalitik/Razvijalec

Končniuporabnik

Funkcionalnost


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.


- 401 -

RUP – prednosti arhitekturno usmerjenega pristopa


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.


- 402 -

RUP – faze življenjskega cikla razvoja po RUP



- 403 -

RUP – makro mejniki

MejnikDoločeni cilji

projekta/naloge

MejnikStabilna

arhitektura

MejnikUporabnik zadovoljen

MejnikIzdelek

delujoč/ ustrezen



- 404 -

RUP – mikro mejniki

Začetna fazaZbiranje

informacij Konstrukcija Prevzem

čas

I1 I2 I3 I4 I5 I6 I7 I8

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

Iteracija



- 405 -

RUP – gradnja modela sistema prek postopkov RUP

Poslovno modeliranje Primeri uporabe

poslovnega okoljaKonceptualni

model poslovnega okolja

Modelira poslovno okolje

Zajem zahtev

Model primerov uporabe

Prikazuje tiste primere uporabe iz poslovnega okolja,

za katere se bo razvijala IR

Analiza in načrtovanje Model

načrta

Prikazuje načrt za implementacijo rešitve

Modelizvedbe

Izvedba Prikazuje dejansko Izvedbo rešitve

Modeltestiranja

Prikazuje načrt testiranjaTestiranje

Objektni razvoj – RUP


- 406 -

RUP – prednosti arhitekturno usmerjenega pristopa

Osnovni postopki

Podporni postopki

V vsaki iteraciji gremo čez vse postopke

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


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


- 407 -

RUP – osnovni in podporni postopki


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


- 408 -

Kje smo?

RUP – Zajem zahtev

Namen zajema zahtev je: Doseči soglasje s stranko oz. uporabniki, kaj naj sistem

dela. Omogočiti razvijalcem boljše razumevanje zahtev sistema. Določiti meje sistema. Zagotoviti osnovo za načrtovanje tehnične vsebine. Definirati uporabniški vmesnik sistema.


- 409 -

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)


- 410 -

RUP – zajem zahtev


Diagrami primerov uporabe Ključna elementa diagramov primerov uporabe sta

akter in primer uporabe Med seboj jih povezujemo


- 411 -

RUP – zajem zahtev – primeri uporabe

Akter


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


- 412 -


Stranka

Primer 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


- 413 -


Kupi vstopnico

Tok dogodkov


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


- 414 -


RUP – Zajem zahtev Primer osnovnega toka dogodkov – Kupi vstopnico preko

interneta:1. Sistem prikaže seznam prireditev2. Kupec izbere prireditev3. Sistem vrne kupcu seznam terminov, kjer so še prosti sedeži za izbrano

prireditev in podrobne podatke o prireditvi.4. Kupec izbere termin5. Sistem prikaže kupcu matriko sedežev z označenimi zasedenimi in

rezerviranimi sedeži.6. Kupec izbere enega ali več prostih sedežev7. Sistem označi izbrane sedeže kot rezervirane8. Sistem zahteva vnos imena in št. kreditne kartice9. Kupec vnese ime in št. kreditne kartice10.Sistem komunicira z zunanjim sistemom ponudnika kreditnih kartic11.Zunanji sistem vrne sporočilo o uspešni transakciji12.Sistem označi sedeže kot prodane13.Sistem prikaže zaslon z vstopnico/cami, ki vsebuje tudi referenčne št.

vstopnic14.Sistem pošlje e-pošto stranki z enakimi podatki kot v točki 12RAZVOJ INFORMACIJSKIH SISTEMOV


- 415 -


RUP – Zajem zahtev Primer alternativnega toka dogodkov – Kupi vstopnico preko

interneta:1. Sistem prikaže seznam prireditev2. Kupec izbere prireditev3. Sistem vrne kupcu sporočilo, da so vse vstopnice na vseh terminih

prodane.


- 416 -


RUP – Zajem zahtev Podtokovi

Pri obsežnejših oz. ponavljajočih tokovih dogodkov si pogosto pomagamo s podtokovi

Podtokovi omogočajo ponovno uporabo dela toka dogodkov Primer podtokov:

1. Sistem prikaže uporabniku seznam oseb2. Uporabnik iz seznama izbere določeno osebo3. Sistem prikaže podrobnosti osebe4. Uporabnik lahko izbere brisanje osebe (glej Podtok A) ali

ažuriranje podatkov o osebi (glej Podtok B).5. Sistem osveži prikaz

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

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


- 417 -


Podtok A

Podtok B

RUP – Zajem zahtev Komunikacija

Komunikacija je povezava, ki prikazuje, da akter uporablja sistem na nek način (primer uporabe) oz. da je v okviru primera uporabe uporabljen nek zunanji sistem.


- 418 -


Komunikacija

Stranka Kupi vstopnico Bančni sistem

RUP – Zajem zahtev UML ne predpisuje usmerjanja

komunikacij, usmerjanje je razširitev, ki je opredeljena v RUP

Komunikacija in usmerjenost kadar gre puščica iz akterja proti primeru uporabe

to pomeni, da je akter začetnik primera uporabe (uporablja določeno funkcionalnost sistema)

kadar gre puščica iz primera uporabe proti akterju (ali pa puščic ni) to pomeni, da ti akterji sodelujejo pri določenem primeru uporabe

vsak primer uporabe mora imeti povezavo, ki je usmerjena od akterja proti primeru uporabe


- 419 -


RUP – Zajem zahtev Odvisnost “vključuje” - <<include>>:

Vedno poteka le med dvema primeroma uporabe in sicer od “izhodiščnega” primera uporabe, ki vključuje tudi drug primer uporabe

Omogoča ponovno uporabo primera uporabe


- 420 -


Odvisnost “vključuje”

Stranka

Kupi vstopnico

<<include>>

Rezervirajvstopnico

Plačaj s kartico<<include>>

RUP – Zajem zahtev Odvisnost “razširja” - <<extend>>:

Vedno poteka le med dvema primeroma uporabe in sicer od primera uporabe, ki razširja “izhodiščni” primer uporabe

Omogoča, da se primer uporabe izvede pod določenim pogojem (razširitvena točka - “extension point”).


- 421 -


Odvisnost “razširja”

StrankaKupi vstopnico

<<extend>>

Pridobi dodatenračun

RUP – Zajem zahtev Generalizacija med

akterji Prikazuje, da določen

akter lahko sistem uporablja tudi na tak način kot določen drugi akter.


- 422 -


Generalizacija med akterji

Stranka

Kupi vstopnico

Rezervirajvstopnico

Stranka “VIP”

Prijavi bonus

Preglej bonus

RUP – Zajem zahtev Generalizacija med

primeri uporabe Omogoča, da določen

primer uporabe “razbijemo” na bolj podrobne primere uporabe


- 423 -


Generalizacija med primeri uporabe

Plačaj s kartico

Plačaj z bančno kartico

Plačaj s kreditno kartico

Meja sistema

RUP – Zajem zahtev Meja sistema

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


- 424 -


Stranka

Kupi vstopnico

Rezervirajvstopnico

Stranka “VIP”

Prijavi bonus

Preglej bonus


Možen pristop pri načrtovanju diagrama primerov uporabe:1. Identificiraj akterje2. Identificiraj primere uporabe sistema3. Poveži akterje in primere uporabe (ugotovi na

kakšne načine različni akterji uporabljajo sistem)4. Odstrani odvečne primere uporabe (npr.

neuporabljeni primeri uporabe)5. Odstrani odvečne akterje (npr. podvojeni akterji;

akterji, ki to niso ipd.)6. Preveri in popravi morebitne napake


- 425 -



Pogoste napake pri načrtovanju primerov uporabe:1. Nejasno/nepravilno opredeljene meje sistema2. Veliko število primerov uporabe na enem diagramu3. Križanje povezav, nepreglednost diagrama4. Primeri uporabe niso napisani s stališča akterja oz.

uporabnika (npr. “Kupi vstopnico” vs. “Prodaj vstopnico”)

5. Model primerov uporabe je podoben diagramu podatkovnih tokov


- 426 -


Primer


- 427 -


Stranka

Kupi vstopnico preko spleta

Rezervirajvstopnico

Stranka “VIP”

Prijavi bonus

Preglej bonus

Referent

Uredi prireditve

Dodeli stranki status“VIP”

Plačaj preko spleta

<<include>>

<<include>>

Unovči bonus

<<extend>>

Spletniplačilnisistem



- 428 -

RUP – zajem zahtev – pomembni izdelki

Dodatnespecifikacije

Slovar

Opisi primerov uporabe

...


AkterjiPrimeri uporabe



- 429 -

RUP – zajem zahtev – Model primerov uporabe

Opisi primerov uporabe

...


AkterjiPrimeri uporabe

Ime Kratek opis Tokovi dogodkov Diagrami aktivnosti

in diagrami stanj Diagrami primerov

uporabe Posebne zahteve Pred-pogoji Po-pogoji Razširitvene točke



- 430 -

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

Register for Courses Use Case 1. Brief Description

This use case allows a Student to register for course offerings in the current semester. The Student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Course Catalog System provides a list of all the course offerings for the current semester.

The main actor of this use case is the Student. The Course Catalog System is an actor within the use case.

2. Flow of Events

The use case begins when the Student selects the "maintain schedule" activity from the Main Form.

2.1 Basic Flow - Create a Schedule

1. The Student selects "create schedule." 2. The system displays a blank schedule form. 3. The system retrieves a list of available course offerings from the Course Catalog System. 4. The Student selects 4 primary course offerings and 2 alternate course offerings from the list of

available offerings. Once the selections are complete the Student selects "submit." 5. The "Add Course Offering" sub-flow is performed at this step for each selected course

offering. 6. The system saves the schedule.

2.2 Alternative Flows

2.2.1 Modify a Schedule

1. The Student selects "modify schedule." 2. The system retrieves and displays the Student's current schedule (e.g., the schedule

for the current semester). 3. The system retrieves a list of all the course offerings available for the current

semester from the Course Catalog System. The system displays the list to the Student.

4. The Student can then modify the course selections by deleting and adding new courses. The Student selects the courses to add from the list of available courses. The Student also selects any course offerings to delete from the existing schedule. Once the edits are complete the Student selects "submit".

5. The "Add Course Offering" sub-flow is performed at this step for each selected course offering.

6. The system saves the schedule.

2.2.2 Delete a Schedule

1. The Student selects the "delete schedule" activity. 2. The system retrieves and displays the Student current schedule. 3. The Student selects "delete." 4. The system prompts the Student to verify the deletion. 5. The Student verifies the deletion. 6. The system deletes the schedule.

2.2.3 Save a Schedule

Namesto alternativnega toka bi lahko za nekatere tokove uporabili tudi podtokove.



- 431 -

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

2.2.3 Save a Schedule

At any point, the Student may choose to save a schedule without submitting it by selecting "save". The current schedule is saved, but the student is not added to any of the selected course offerings. The course offerings are marked as "selected" in the schedule.

2.2.4 Add Course Offering

The system verifies that the Student has the necessary prerequisites and that the course offering is open. The system then adds the Student to the selected course offering. The course offering is marked as "enrolled in" in the schedule.

2.2.5 Unfulfilled Prerequisites or Course Full

If in the "Add Course" sub-flow the system determines that the Student has not satisfied the necessary prerequisites or that the selected course offering is full, an error message is displayed. The Student can either select a different course offering or cancel the operation, at which point the use case is restarted.

2.2.6 No Schedule Found

If in the "Modify a Schedule" or "Delete a Schedule" sub-flows the system is unable to retrieve the Student's schedule, an error message is displayed. The Student acknowledges the error and the use case is restarted.

2.2.7 Course Catalog System Unavailable

If, the system is unable to communicate with the Course Catalog System after a specified number of tries, the system will display an error message to the Student. The Student acknowledges the error message and the use case terminates.

2.2.8 Course Registration Closed

If, when the student selects "maintain schedule", registration for the current semester has been closed, a message is displayed to the Student and the use case terminates. Students cannot register for courses after registration for the current semester has been closed.

3. Special Requirements

There are no special requirements associated with this use case.

4. Preconditions

4.1 Login

Before this use case begins the Student has logged onto the system.

5. Postconditions

There are no postconditions associated with this use case.

6. Extension Points

There are no extension points associated with this use case.


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


- 432 -

RUP – zajem zahtev – dodatne specifikacije


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


- 433 -

Kje smo?

Objekta analiza in načrtovanje

Namen analize in načrtovanja je: Pretvoriti zahteve v načrt sistema; Razviti robustno arhitekturo sistema; Prilagoditi načrt izvedbenemu okolju.

Povezava z drugimi postopki: Poslovno modeliranje postavi organizacijski kontekst

sistema. Postopek zajema zahtev je primarni vhod v postopek

analize in načrtovanja. Postopek izvedbe realizira sistem na osnovi načrta, …


- 434 -

RUP – namen analize in načrtovanja



- 435 -

RUP – Analiza in načrtovanje – primerjava analize in načrtovanja

Analiza

Se osredotoča na razumevanje problema

Idealizirano načrtovanje Obnašanje Struktura sistema Funkcijske zahteve Majhen model

Načrtovanje

Se osredotoči na razumevanje rešitve

Operacije in atributi Zmogljivost rešitve Blizu programski kodi Življenjski cikel objektov Nefunkcionalne zahteve Velik model

Objekta analiza in načrtovanjeRUP – Analiza in načrtovanje – vhodni in izhodni izdelki

Končen izdelek analize in načrtovanja


- 436 -

Analiza in načrtovanje


Model primerovuporabe

Slovar

Arhitekturasistema

Model načrta

Podatkovni model

e



- 437 -

RUP – Analiza in načrtovanje – vloge

Arhitekt

Arhitekturasistema

Model načrta

Podatkovni modelNačrtovalec PB

Realizacijaprimera uporabe

Paket/Podsistem

Razred

Načrtovalec

Pregledovalecarhitekture

Pregledovalecnačrta



- 438 -

RUP – Analiza in načrtovanje – koraki

Arhitekt Analizaarhitekture

Načrtarhitekture

Analiza sočasnostiin porazdeljenosti

Pregledarhitekture

Načrtovalec Analizaprimerovuporabe Načrtovanje

primerovuporabe

Načrtovanjepodsistemov

Načrtovanjerazredov

Preglednačrta

Pregledovalec arhitekture

Pregledovalec načrta


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


- 439 -

Kje smo?



- 440 -

Analiza arhitekture

Analiza arhitekture

Smernice za načrtovanje

Slovar


Arhitekturasistema


Poslovni model

Model načrta

Izbrani primeri uporabe za realizacijo


Osnovni koraki aktivnosti analiza arhitekture sistema:

Identifikacija ključnih abstrakcij Analiza potreb po sistemskih storitvah Opredelitev arhitekturnih ravni


- 441 -

RUP – Koraki analize arhitekture


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


- 442 -

RUP – Koraki analize arhitekture – Identifikacija ključnih abstrakcij

Razredi analize ali ključne abstrakcije



- 443 -

RUP – Od razredov analize do izvedbenih elementov – komponent

Analiza Načrt Izvedba



- 444 -

Primer ključnih abstrakcij

Študent

Predmet

Izpitni rokPrijava

Vpis

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

Študijski program



- 445 -

Primer ključnih abstrakcij

Povezave med identificiranimi abstrakcijami…

Predmet

Izpitni rokPrijava

VpisŠtudijski program

Študent



- 446 -

RUP – Koraki analize arhitekture – analiza potreb po sistemskih storitvah



Želena funkcionalnost Okolje implementacije

Arhitekt

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


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 …


- 447 -

RUP – Koraki analize arhitekture – analiza potreb po sistemskih storitvah


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.


- 448 -

RUP – Koraki analize arhitekture – opredelitev arhitekturnih ravni


Primeri arhitekturnih vzorcev: Model-view-controller: aplikacija je razdeljena na tri

dele: Model, ki vsebuje poslovna pravila in pripadajoče podatke, View, ki prikazuje, kako je informacija izpisana uporabniku in Controller-je, ki procesirajo uporabniške vhode.

Pipes and Filters: tok podatkov potuje skozi cevi od filtra do filtra. Vsak filter je korak procesiranja.

Blackboard: je vzorec sodelovanja neodvisnih specializiranih aplikacij nad skupno podatkovno strukturo za doseganje skupne rešitve.

… Aplikacija lahko uporablja več arhitekturnih

vzorcev…RAZVOJ INFORMACIJSKIH SISTEMOVVisokošolski strokovni študij, Smer Informatika©Laboratorij za informatiko

- 449 -




- 450 -


Poslovni podsistemi(Business specific)

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

Aplikacijski podsistemi(Application subsystems)

Ločeni aplikacijski podsistemi, ki skupaj tvorijo aplikacijski sistem. Specifične aplikacije organizacije.

Vmesni nivo(Middleware)

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

Sistemska programska oprema(System software)

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


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


- 451 -



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.


- 452 -




- 453 -


Ciklične odvisnosti so nezaželene…

A

B

A

B

C

A

B

C

A’


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


- 454 -


<<layer>>

Ime ravni

<<layer>>

Business Services

<<layer>>

Application


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


- 455 -

Kje smo?

Objektna analiza in načrtovanje


- 456 -

Analiza arhitekture

Analiza primerov uporabe

Smernice za načrtovanje

Slovar


Arhitekturasistema


Izbrani primeri uporabe za realizacijo

Model načrta(dopolnjen)

Analizirani primeri uporabe

Razredi analize


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


- 457 -

RUP – Koraki analize primerov uporabe


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


- 458 -

RUP – Koraki analize primerov uporabe – dopolnitev opisov primerov uporabe

Sistem preveri veljavnost kreditne kartice.

Sistem preveri veljavnost kreditne kartice. Pri tem se poveže s sistemom “SKK” in uporabi njegovo spletno storitev “CardCheck”.






- 459 -




- 460 -

Model Primerov Uporabe Model Načrta

Primer Uporabe Realizacija Primera Uporabe

Diagrami Razredov

Diagrami Zaporedja

Primer Uporabe

Diagrami sodelovanja

RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…



- 461 -

<<entity>>

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

<<entity>>

<<boundary>><<boundary>>

<<control>>


Objektna analiza in načrtovanje Razredi analize:


- 462 -


<<entity>>

<<boundary>>

<<control>>

<<entity>>

<<boundary>>

Meja sistem

a


Ikonski prikaz razredov analize:


- 463 -



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


- 464 -



Mejni razredi modelirajo interakcijo med okoljem in sistemom


- 465 -


<<entity>>

<<boundary>>

<<control>>

<<entity>>

<<entity>>

<<boundary>>

<<boundary>>


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

Primer:


- 466 -


Kupi vstopnico Stranka Bančni sistem

<<boundary>>ZMStrankaKupiVstopnico

<<boundary>>SVBančniSistem


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.


- 467 -



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


- 468 -



Poslovni razredi hranijo in upravljajo ključne podatke sistema


- 469 -


<<entity>>

<<boundary>>

<<control>>

<<entity>>

<<entity>>

<<boundary>>

<<boundary>>


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


- 470 -



Primer:


- 471 -


Kupi vstopnico

<<entity>>Sedež <<entity>>

Vstopnica

<<entity>>Prireditev <<entity>>

Termin

Ključne abstrakcije

Slovar

<<entity>>Stranka

“Zastopnik”akterja Stranka

ImeRazreda<<stereotip>>

atribut : tip = začVrednostatribut : tip = začVrednostatribut : tip = začVrednost

IzbirniPredmet<<entity>>

predmetID :String=“100”začetek : Timekonec: TimešteviloDni: Enum

atribut

V analizi se na ukvarjaj s podpisi (signaturami) atributov

Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…



- 473 -


Pri identifikaciji poslovnih razredov si lahko pomagamo z generalizacijo

Generalizacijo uporabimo, ko en razred predstavlja isto strukturo in obnašanja kot več drugih razredov

V analizi uporabljamo le med poslovnimi razredi

Računstanjeimeštevilka

Dvigni()Položi()

Osebni

Dvigni()

Varčevalni

VrniObresti()Dvigni()



- 474 -


<<entity>>Prireditev

<<entity>>Dogodek

<<entity>>Trening

<<entity>>Tekma

<<entity>>Koncert

<<entity>>Film

Primer:

<<entity>>Zborovanje


Sledi identifikacija povezav med poslovnimi razredi: V analizi iščemo povezave tipa asociacija Asociacija je strukturna povezava, ki modelira

pomensko povezavo med primerki razredov


- 475 -


Objektna analiza in načrtovanje Modelira pomensko povezavo med primerki

razredov

Enostavna povezava

<<entity>>Študent

<<entity>>Urnik

<<entity>>IzbirniPredmet

Rekurzivna povezava

je predpogoj za

<<entity>>Predmet

Asociacija je strukturna povezava


Objektna analiza in načrtovanje Vloga, ki jo igra razred v povezavi

Predpogoj

Nosilec predmeta


Vodja katedre

<<entity>>Profesor

<<entity>>Katedra

<<entity>>Predmet

Ime vloge



Urnik<<entity>>

glavniPredmet

dodatniPredmet


Urnik<<entity>> dodaj študenta

odstrani študenta

Vsaka povezava igra svojo vlogo



2..4

0..1

1..*

0..*

1

*

Nedoločeno Točno ena Nič ali več (več,

neomejeno)

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

intervalov2, 4..6

Števnost:RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Števnost

0..4

0..2glavniPredmet

dodatniPredmet

0..*

0..*0..*1<<entity>>

Študent<<entity>>

Urnik <<entity>>IzbirniPredmet


Neusmerjena

Usmerjena

Razred1 Razred2

Razred1 Razred2


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

Razred1 vidi Razred2, Razred2 pa Razreda1 ne vidi. Razred1 je odvisen od Razreda2,Razred2 pa od Razreda1 ni odvisen.

Navigacijo podrobneje določimo v fazi načrtovanja in ima pomembno vlogo pri implementaciji

Navigacija – usmerjenost povezave:RUP – Koraki analize primerov uporabe – identifikacija potrebnih razredov…

Neusmerjena povezava

0..4

0..2glavniPredmet

dodatniPredmet

0..*

0..*

<<entity>>Urnik


Usmerjena povezava

1 1<<boundary>>ZMVpišiPredmet

<<control>>KVpišiPredmet




- 483 -


<<entity>>Sedež

<<entity>>Vstopnica

<<entity>>Prireditev <<entity>>

TerminŠtevilkaVrstaTribuna

ImeOpis ZačetekTrajanje Status

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

1**11 1..*

Primer:<<entity>>

Stranka

1

*

ImePriimek


Kontrolni razred - <<control>>: Kontrolni razred koordinira dogajanje znotraj primera

uporabe. Sistem lahko izvaja nekatere primere uporabe tudi brez

kontrolnih razredov, vendar le takšne, ki obsegajo le enostavno rokovanje s shranjenimi podatki (npr. zapiši/ preberi atribut).

Bolj kompleksni primeri uporabe navadno zahtevajo enega ali več kontrolnih razredov, ki koordinirajo obnašanje objektov drugih razredov v sistemu.

Kontrolni razredi učinkovito ločijo mejne in poslovne razrede in s tem naredijo sistem še bolj odporen na spremembe v okolju.

Ločijo tudi obnašanje, ki je specifično za primer uporabe od poslovnih razredov, s čimer omogočijo ponovno uporabo poslovnih razredov v več primerih uporabe in celo različnih sistemih.RAZVOJ INFORMACIJSKIH SISTEMOV


- 484 -



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


- 485 -



Kontrolni razred koordinira obnašanje primera uporabe


- 486 -


<<entity>>

<<boundary>>

<<control>>

<<entity>>

<<entity>>

<<boundary>>

<<boundary>>


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

Primer:


- 487 -



<<control>>KKupiVstopnico

Kupi vstopnico


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


- 488 -




<<boundary>>ZMStrankaKupiVstopnico

<<boundary>>SVBančniSistem<<control>>

KKupiVstopnico

<<entity>>Sedež

ŠtevilkaVrstaTribuna

<<entity>>Termin

Začetek

<<entity>>Prireditev

ImeOpisTrajanje

<<entity>>Vstopnica

Status

1

*11

1..*1

* *<<entity>>Stranka

ImePriimek


- 489 -

*


Model načrta


Vaja: Identificirajte razrede analize, ki nastopajo v okviru

določenega primera uporabe iz podane problemske domene.


- 490 -







- 491 -



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


- 492 -

Diagrami ZaporedjaPrimer Uporabe

Diagrami sodelovanja

Realizacija primerov uporabe

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


- 493 -



Dodeljevanje odgovornosti na podlagi lokacije podatkov (tipično vprašanje pri poslovnih razredih): Če so vsi podatki v enem razredu - dodeli

odgovornost temu razredu (načelo OO – podatki in operacije skupaj).

Če so podatki razpršeni po več razredih:• Odgovornost dodeli enemu razredu ter vzpostavi

povezave z razredi, ki posedujejo podatke.• Kreiraj nov (kontrolni) razred in mu dodeli

odgovornost. Dodaj povezave na razrede s podatki.

• Odgovornost dodeli obstoječemu kontrolnemu razredu. Dodaj povezave na razrede s podatki.RAZVOJ INFORMACIJSKIH SISTEMOV


- 494 -


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


- 495 -

Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

Alternativni tok 4 Alternativni tok 5 Alternativni tok n

Alternativni tok 1 Alternativni tok 2 Alternativni tok 3

AF1

AF2

AF3

Osnovni tok


Potrebnih je več diagramov interakcije

Diagrami sodelovanja– Poleg interakcije

kažejo tudi povezave– Boljši za prikaz

vzorcev sodelovanja– Boljši za prikaz vseh

učinkov na posamezen objekt

– Lažji za uporabo v fazi brainstorminga

Diagrami zaporedja– Eksplicitno kažejo

zaporedje sporočil– Boljši za prikaz

celotnega toka dogodkov

– Boljši za specifikacijo dogodkov, ki potekajo v realnem času ter zapletenih scenarijev




- 498 -

1: IzvediOdgovornost

Objekt, ki uporablja storitev(predaja odgovornost)

Objekt, ki zagotavlja storitev(izvaja odgovornost)

Sporočilo

:Odjemalec

Fokus(aktivnost objekta)

Rekurzivno sporočilo

Življenjska črta objekta

1.1: IzvediDrugo Odgornost

Hierarhično številčenje

sporočil

:Ponudnik

DIAGRAMI ZAPOREDJA - UML

ČAS



- 499 -

Ponavljaj za vse izbrane

sedeže

Ponavljaj za vse izbrane

sedeže

1: PričniNakup( )2: VrniSeznamPredstav( )

3: VrniSeznamPredstav( )4: PrikažiSeznamPredstav( )

5: IzberiPredstavo( )6: VrniPodrobnostiPredstave( )

7: VrniPodrobnePodatekOPredstavi( )

8: VrniSeznamterminovZaPredstavo( )9: PrikažiPodrobnostiInTerminePredstave( )

10: IzberiTermin( )11: VrniSeznamSedeževZaIzbranTermin( )

12: VrniSeznamSedeževInNjihovStatusZaTermin( )

13: VrniStatusZaTermin( )

14: PrikažiMatrikoProstihSedežev( )

15: IzberiSedeže( )16: RezervirajIzbraneSedeže( )

17: PreveriStatus( )


19: RezervirajSedežZaTermin( )

20: KreirajRezervacijoZaTermin( )21: ZahtevajVnosKKInImena( )

22: VnesiImeInKK( )23: ZaključiNakup( )

25: IzvediTransakcijo( )

24: IzračunajCeno( )

26: IzvediTransakcijo

27: ProdajSedežZaTermin( )

28: OznačiRezervacijoKotProdano( )

29: VrniŠtevilkoKarte( )

32: PrikažiSporočiloOUspešnemNakupuZRefŠt( )

:ZMStrankaKupiVstopnico :KKupiVstopnico :Prireditev

Kupec

:Termin :Vstopnica :Sedež

SKK

:SVBančniSistem

1: PričniNakup( )2: VrniSeznamPredstav( )

3: VrniSeznamPredstav( )4: PrikažiSeznamPredstav( )

5: IzberiPredstavo( )6: VrniPodrobnostiPredstave( )

7: VrniPodrobnePodatekOPredstavi( )

8: VrniSeznamterminovZaPredstavo( )9: PrikažiPodrobnostiInTerminePredstave( )

10: IzberiTermin( )11: VrniSeznamSedeževZaIzbranTermin( )

12: VrniSeznamSedeževInNjihovStatusZaTermin( )


14: PrikažiMatrikoProstihSedežev( )

15: IzberiSedeže( )16: RezervirajIzbraneSedeže( )

17: PreveriStatus( )


19: RezervirajSedežZaTermin( )

20: KreirajRezervacijoZaTermin( )21: ZahtevajVnosKKInImena( )

22: VnesiImeInKK( )23: ZaključiNakup( )

25: IzvediTransakcijo( )

24: IzračunajCeno( )


27: ProdajSedežZaTermin( )

28: OznačiRezervacijoKotProdano( )

29: VrniŠtevilkoKarte( )

32: PrikažiSporočiloOUspešnemNakupuZRefŠt( )




- 500 -

Fragmenti za prikazovanje podtokov, alternativnih tokov, zank na skupnem diagramu



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


- 501 -


1: IzvediOdgovornost

Sporočilo

Povezava

:Odjemalec

:Ponudnik


Smer

Objekt, ki uporablja storitev(predaja odgovornost)

Objekt, ki zagotavlja storitev(izvaja odgovornost)


DIAGRAMI SODELOVANJA - UML


- 503 -


22: VnesiImeInKK( )15: IzberiSedeže( )

10: IzberiTermin( )5: IzberiPredstavo( )

1: PričniNakup( )

23: ZaključiNakup( )16: RezervirajIzbraneSedeže( )

11: VrniSeznamSedeževZaIzbranTermin( )6: VrniPodrobnostiPredstave( )

2: VrniSeznamPredstav( )

7: VrniPodrobnePodatekOPredstavi( )3: VrniSeznamPredstav( )

32: PrikažiSporočiloOUspešnemNakupuZRefŠt( )21: ZahtevajVnosKKInImena( )

14: PrikažiMatrikoProstihSedežev( )9: PrikažiPodrobnostiInTerminePredstave( )

4: PrikažiSeznamPredstav( )

8: VrniSeznamterminovZaPredstavo( )

27: ProdajSedežZaTermin( )19: RezervirajSedežZaTermin( )

17: PreveriStatus( )12: VrniSeznamSedeževInNjihovStatusZaTermin( )

29: VrniŠtevilkoKarte( )28: OznačiRezervacijoKotProdano( )

20: KreirajRezervacijoZaTermin( )18: VrniStatusZaTermin( )


24: IzračunajCeno( )25: IzvediTransakcijo( )


Kupec

:ZMStrankaKupiVstopnico

:KKupiVstopnico

:Prireditev

:Termin

:Sedež

:Vstopnica

:SVBančniSistem

SKK


Na podlagi diagrama sodelovanja razdelimo odgovornosti


- 504 -


// IzvediOdgovornost

:Odjemalec :Ponudnik

Ponudnik

// IzvediOdgovornost

Diagram sodelovanja

Diagram razredov



- 505 -


1..1

0..*

1..1

0..*

1..1

0..*

1..1

0..*

<<boundary>>

ZMStrankaKupiVstopnico

PričniNakup ()PrikažiSeznamPredstav ()IzberiPredstavo ()PrikažiPodrobnostiInTerminePredstave ()IzberiTermin ()PrikažiMatrikoProstihSedežev ()IzberiSedeže ()ZahtevajVnosKKInImena ()VnesiImeInKK ()PrikažiSporočiloOUspešnemNakupuZRefŠt ()

<<boundary>>

SVBančniSistem

IzvediTransakcijo ()

<<control>>

KKupiVstopnico

VrniSeznamPredstav ()VrniPodrobnostiPredstave ()VrniSeznamSedeževZaIzbranTermin ()RezervirajIzbraneSedeže ()ZaključiNakup ()IzračunajCeno ()

<<entity>>

PrireditevImeOpisTrajanje

VrniSeznamPredstav ()VrniPodrobnePodatekOPredstavi ()

<<entity>>

TerminZačetek

VrniSeznamterminovZaPredstavo ()

<<entity>>

StrankaImePriimek

<<entity>>

SedežŠtevilkaVrstaTribuna

VrniSeznamSedeževInNjihovStatusZaTermin ()PreveriStatus ()RezervirajSedežZaTermin ()

<<entity>>

VstopnicaStatus

VrniStatusZaTermin ()KreirajRezervacijoZaTermin ()OznačiRezervacijoKotProdano ()VrniŠtevilkoKarte ()


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


- 506 -




- 507 -


1..1

0..*

1..1

0..*

1..1

0..*

1..1

0..*

<<boundary>>



<<boundary>>

SVBančniSistem


<<control>>

KKupiVstopnico


<<entity>>



<<entity>>

TerminZačetek


<<entity>>

StrankaImePriimek

<<entity>>



<<entity>>

VstopnicaStatus


? razred brez odgovornosti


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


- 508 -


Celota/agregat del

0..4

0..2glavniPredmet

dodatniPredmet

0..*

0..*0..*1<<entity>>

Študent<<entity>>

Urnik <<entity>>IzbirniPredmet


Agregacija: modelira odnos celota - delRUP – Koraki analize primerov uporabe – razdelitev odgovor. in ident. povezav

Ko si v dvomih, uporabi asociacijo

asociacija

agragacija

Razred1 Razred2

Razred1 Razred2

Objektna analiza in načrtovanje Premislek

Kontekst, neodvisnost delov od celote?



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.


- 511 -



Kompozicija:

Diskusija - kompozicija ali agregacija?


- 512 -


kompozicijaRazred1 Razred2

0..*1<<entity>>Študent

<<entity>>Urnik

?


Primera:

Kakšna je števnost?

Objektna analiza in načrtovanje Asociacijski razred:

Razred, povezan s povezavo

Vsebuje lastnosti povezave

En primerek na povezavo

UrnikIzbirniInfostatus

// označi kot izbran()// označi kot neizbran()// ali je izbran?()

<<entity>>


Urnik<<entity>>

0..*0..4

glavniPredmet

dodatniPredmet0..* 0..2

UrnikGlavniIzbirniInfoocena

// ali je izdelal?()// vnesi oceno()// vrni oceno()

<<entity>>


Diskusija: Ali bi kje postavili kompozicijo/asociacijo?


- 515 -


1..1

0..*

1..1

0..*

1..1

0..*

<<entity>>



<<entity>>

TerminZačetek


<<entity>>



<<entity>>

Vstopnica

Status


1: izvediOdgovornost

Povezava

0..*

Osnovni ponudniki0..*

:Odjemalec :Ponudnik

Odejmalec Ponudnik

izvediOdgovornost()

Povezava v diagramu sodelovanja pomeni povezavo v razrednem diagramu !


Navigacija (pogojno!)

Diagram sodelovanja

Razredni diagram



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!


- 517 -




- 518 -


Dia

gram

VO

PC –

Vie

w o

f par

tici

pati

on c

lass

esPo

gled

na

razr

ede,

ki s

odel

ujej

o v

prim

eru

upor

abe

1..1

0..*

1..1

0..*

1..1

0..*

0..1

0..*

0..1

0..*

0..1

0..*

1..1

0..11..1

1..1

<<boundary>>



<<boundary>>

SVBančniSistem


<<control>>

KKupiVstopnico


<<entity>>

Prireditev

ImeOpisTrajanje


<<entity>>

Termin

Začetek


<<entity>>



<<entity>>

VstopnicaStatus







- 519 -

RUP – Koraki analize primerov uporabe – sistemske storitve

Razred analize Sistemska storitev


Sestavi seznam vseh potrebnih sistemskih storitev

Sestavi seznam razredov, ki potrebujejo sistemske storitve

Opiši lastnosti sistemskih storitev


Razred Sistemska storitev

PrireditevTermin

Vstopnica

Sedež

KKupiVstopnico

Trajnost

Trajnost, Varnost?

Trajnost

Porazdelitev

Trajnost


Preslikava med razredi in sistemskimi storitvami


Objektna analiza in načrtovanje Lastnosti sistemskih storitev Trajnost za razred Vstopnica:

Granulacija: od 15 do 25 bajtov Kapaciteta: do 10.000.000 vstopnic Pogostost dostopa

Kreiranje: do 10.000 na dan Branje: do 50.000 na uro Spreminjanje: do 500 na dan Brisanje: do 50 na dan

Itd.



Kakšne bi bile lahko lastnosti trajnosti za razred Predstava? Granulacija? Kapaciteta? Pogostost dostopa?


- 523 -







- 524 -


Pono

vim

o za

vsa

k pr

imer

upo

rabe


- 525 -

Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe






- 526 -

RUP – Koraki analize primerov uporabe – poenotenje

<<control>>

<<boundary>>

<<entity>><<entity>>

Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – poenotenje


- 528 -

Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe - poenotenje

Rezultat poenotenja razredov je enoten načrt. Pogledi VOPC še

vedno ostanejo, vendar uporabljajo skupne razrede.

Dodatne Specifikacije

Slovar

Model Primerov Uporabe

Model Načrta

Razredi Analize

Objektna analiza in načrtovanjeRUP – Koraki analize primerov uporabe – poenotenje


Razredne diagrame lahko pretvorimo v kodo


- 530 -

Od razreda do kode

1..1

0..*

1..1

0..*

1..1

0..*

0..1

0..*

0..1

0..*

0..1

0..*

1..1

0..11..1

1..1

<<boundary>>



<<boundary>>

SVBančniSistem


<<control>>

KKupiVstopnico


<<entity>>

Prireditev

ImeOpisTrajanje


<<entity>>

TerminZačetek


<<entity>>



<<entity>>

Vstopnica

Status

VrniStatusZaTermin ()KreirajRezervacijoZaTermin ()OznačiRezervacijoKotProdano ()VrniŠtevi lkoKarte ()

nit main;

interface

uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, Grids, ExtCtrls, StdCtrls, Buttons, NxScrollControl, NxCustomGridControl, NxCustomGrid, NxGrid, NxColumns, NxColumnClasses, ComCtrls;

type T1to9 = set of 1..9; TMatrix = array[1..9, 1..9] of T1to9; TRows = array[1..9, 1..9] of byte; TCols = array[1..9, 1..9] of byte;

type Tf_main = class(TForm) Panel1: TPanel; Panel2: TPanel; bb_solve: TBitBtn; sg_Possibilities: TStringGrid; bb_load: TBitBtn; bb_save: TBitBtn; bb_clear: TBitBtn; b_chkrow: TButton; b_chkcol: TButton; ng_TablePlate: TNextGrid; b_SetGrid: TButton; col1: TNxTextColumn; col2: TNxTextColumn; col3: TNxTextColumn; col4: TNxTextColumn; col5: TNxTextColumn; col6: TNxTextColumn; col7: TNxTextColumn; col8: TNxTextColumn; col9: TNxTextColumn; sd_save: TSaveDialog; od_open: TOpenDialog; Button1: TButton; b_solveRest: TButton; sg_steps: TStringGrid; procedure bb_loadClick(Sender: TObject); procedure bb_clearClick(Sender: TObject); procedure b_chkrowClick(Sender: TObject); procedure b_chkcolClick(Sender: TObject); procedure b_SetGridClick(Sender: TObject); procedure bb_saveClick(Sender: TObject); procedure Button1Click(Sender: TObject); procedure b_solveRestClick(Sender: TObject); private { Private declarations } procedure CheckCell( x, y: byte ); procedure CheckRow( x: byte ); procedure CheckCol( y: byte ); …

Razred z atributi in metodami


- 531 -

Student- name: String

+ addSchedule (theSchedule: Schedule, forSemester: Semester)+ hasPrerequisites(forCourseOffering: CourseOffering) : boolean# passed(theCourseOffering: CourseOffering) : boolean

public class Student{

private String name;public void addSchedule (Schedule theSchedule; Semester forSemester) { }public boolean hasPrerequisites(CourseOffering forCourseOffering) { }protected boolean

passed(CourseOffering theCourseOffering) { }}

Podporni in globalni razredi


- 532 -

<<utility>>

MathPack

- randomSeed : long = 0- pi : double = 3.14159265358979

+sin (angle : double) : double+cos (angle : double) : double+random() : double

import java.lang.Math;import java.util.Random;class MathPack { private static randomSeed long = 0; private final static double pi = 3.14159265358979; public static double sin(double angle) { return Math.sin(angle); } public static double cos(double angle) { return Math.cos(angle); } public static double random() {

return new Random(seed).nextDouble(); }}

Asociacija


- 533 -

Schedule

Student

class Schedule{ public Schedule() { } private theStudent;}

class Student{ public Student() { } private Schedule theSchedule;}

Enosmerna asociacija


- 534 -

Student

Schedule

class Student{ public Student() { } private Schedule theSchedule;}

class Schedule{ public Schedule() { }}

Vloge pri asociaciji


- 535 -

class Professor {public Professor() {}private CourseOffering theCourseOffering;}

class CourseOffering{public CourseOffering () {}private Professor instructor;}

Professor

CourseOffering

instructor

Števnost asociacij


- 536 -

class Schedule{public Schedule() {}private CourseOffering[]

primaryCourses =new CourseOffering[4]

}

class CourseOffering{public CourseOffering() {}}

Schedule

CourseOffering

0..4 primaryCourses

Vmesni razred


- 537 -

Schedule CourseOfferingprimaryCourses

alternateCourses0..4

0..20..*0..*

ExaminationInfo- grade: Char = I

Schedule ExaminationInfo CourseOfferingalternateCourses 0..20..*

0..41ExaminationInfo

- grade: Char = I

Realizacija vmesnega razreda je stvar odločitve v načrtovanju

Vmesni razred - realizacija


- 538 -

class ExaminationInfo{ public ExaminationInfo() {}

public CourseOffering get_theCourseOffering(){ return theCourseOffering; } public void set_theCourseOffering(CourseOffering toValue){ theCourseOffering = toValue; } private char get_Grade (){ return grade; } private void set_Grade(char toValue) { grade = toValue; } private char grade = ‘I’; private CourseOffering theCourseOffering;}

Schedule ExaminationInfo CourseOfferingalternateCourses 0..20..*

0..41ExaminationInfo

-grade: Char = I…

…

Rekurzivna asociacija


- 539 -

import java.util.Vector;

class Course { public Course() {} // The unbounded multiple association // is stored in a vector private Vector prerequisites;}

Course

prerequisites

0..*

Agregacija


- 540 -

class Schedule{public Schedule() { }private Student theStudent;}

import java.util.Vector;

class Student{ public Student() { } private Vector theSchedule;}

1

Schedule

Student

0..*

Java nima eksplicitnega konstrukta za agregacijo.

Generalizacija (dedovanje)


- 541 -

class GroundVehicle{ public int licenseNumber; public void register() { }}

class Truck extends GroundVehicle{ public float tonnage; public void getTax() { }}

GroundVehicle

Truck

0..*+ licenceNumber: int+ register()

+ tonnage: float

+ getTax()

1

Abstraktni razredi


- 542 -

abstract class Animal { public abstract void talk();}

Animal{Abstract}

Lion

+ talk () {abstract}

+ talk ()

Tiger+ talk ()

class Tiger extends Animal{ public Tiger() { } public void talk() { }}

Poglavje IVModelno usmerjen razvoj


- 543 -

MDA – Model Driven Architecture in MDD – Model-Driven Development. Razlike med MDA/MDD in klasičnim pristopom k razvoju IS

Razlogi za pojav pristopa Vedno večje število različnih implementacijskih

tehnologij, hiter razvoj, menjava, … Razvijalci se morajo specializirati za ozka

področja, ki se pogosto spreminjajo Že med izdelavo sistema se pojavljajo nove,

boljše različice tehnologij Prehod na drugo tehnologijo pogosto pomeni,

da je potrebno aplikacijo razviti na novo oz. so potrebne obsežne prilagoditve

Možnost za izboljšanje: Razvoj PO na podlagi modelov?

Model Driven Development Dvig nivoja abstrakcije, na katerem nastaja

programska oprema Razvijalci naj se posvetijo predvsem

funkcijam sistema, ne pa tehnološkim podrobnostim

Opis funkcionalnosti na visokem abstraktnem nivoju, neodvisnem od uporabljene platforme in tehnologije

Opis sistema z uporabo vizualnih modelov Ideja MDD ni nova (npr. podat.

modeliranje)

Model Driven Architecture… Model Driven Architecture:

je standardizirano ogrodje za razvoj programske opreme na podlagi modelov, nastal v okviru OMG

predvideva avtomatizirano transformacijo visoko abstraktnih modelov v modele na nižjem nivoju abstrakcije in nato teh v delujočo kodo

ne predpisuje konkretnih tehnik za opis modelov, predlaga uporabo UML + OCL (nova različica za podporo MDA), obstajajo tudi druge možnosti

Model Driven Architecture MDA predvideva tri osnovne vrste modelov

glede na njihovo stopnjo abstrakcije: PIM (platform independent model) je model na

visokem abstraktnem nivoju PSM (platform specific model) je model na nivoju, ki

upošteva konstrukte implementacije Programska koda je model na najnižjem nivoju, ki jo

je mogoče pretvoriti v izvedljivo kodo oziroma jo interpretirati

Predvideva transformacije med modeli, ki naj bi bile avtomatizirane…

Model Driven Architecture - koncept

Tehnologija/platforma yTehnologija/platforma x

PIM

PSM x PSM y

Delujoča izvorna koda sistema

Koda x Koda y

PIM → PSM x PIM → PSM y

PSM y → K yPSM x → K x

Most med PSM x in PSM y

Most med Kodo x in Kodo y

CIM

Kritike MDA Ni učinkovitega jezika za zapis PIM Ni učinkovitih transformacijskih orodij

(delno generiranje ni dovolj) Standardi MDA so v začetni fazi razvoja Z uporabo sodobnih razvojnih orodij,

ogrodij in procesov je moč produktivnost povečati že v okviru klasičnega razvoja

Primerjava klasičnega razvoja in MDD…

MDD

Klasičen razvoj

Zajem zahtev Analiza Načrtovanje Kodiranje

Večinoma besedilo

Diagrami in besedilo

Diagrami in besedilo

Koda

……

Zajem zahtev Načrtovanje – tran. PIM v PSM

Kodiranje – tran. PSM v Kodo

Večinoma besedilo

PIM PSM Koda

……

generiranje

Analiza – izdelava PIM

V MDD je bistvena izdelava PIM in izbira ustreznih implementacijskih tehnologij, precej pa se zmanjša pomen klasičnega kodiranja.

Poveča se pomen analitičnih vlog in hkrati zmanjša pomen vlog implementacije

Nekaj možnih novih vlog: Analitik in načrtovalec PIM na podlagi izdelkov zajema zahtev ter

izdelkov poslovnega modeliranja izdelata model PIM. Izdelovalec PSM s pomočjo orodja za transformiranje PIM pretvori

v enega ali več modelov PSM. Pred transformacijo mora izbrati ciljne platforme, arhitekture, vzorce, tehnologije itd.

Razvijalec definicij transformacij je vloga, ki skrbi za izdelavo definicij transformacij za transformacijska orodja.

Primerjava klasičnega razvoja in MDD…

Razvijalec def. transformacij

Transformacijsko orodje

Orodje za izdelavo / preverjanje definicije

transformacije

PSM

Analitik in načrtovalec PIM

Izdelovalec PSM

Definicija transformacije

Orodje za modeliranje / izdelavo / preverjanje PIM

PIM

izdela

izdela

Izbira platform, arhitektur, vzorcev,

nastavitve orodja itd. izbere, določi z orodjem

generira

Pregled prednosti in slabosti MDA MDD prinaša vrsto prednosti že v današnji

obliki: višja produktivnost zaradi generiranja (celo

do 40%) boljša arhitektura zaradi razvoja na višjem

nivoju abstrakcije višja stopnja skladnosti nastale kode v prihodnosti naj bi MDD potekal tako, kot

danes delujejo prevajalniki programskih jezikov

Pregled prednosti in slabosti MDA Na drugi strani pa ne smemo zanemariti

kritik: Predpogoj za uspeh MDD (MDA) je ustrezen

jezik za zapis PIM. MDD bo uporaben šele s 100%

generiranjem kode. Pravi MDD s trenutnimi tehnologijami ni

izvedljiv, delni MDD pa ne prinaša nobene bistvene prednosti.

Implikacije morebitne uveljavitve MDA Uveljavitev MDA v praksi bi prinesla

vrsto sprememb: Vloge:

nove vloge, nova znanja manjši pomen vlog implementacije večji pomen vlog analize

Proces: več časa za analizo in zajem zahtev velik del klasičnih aktivnosti implementacije bi

izvedla orodja (generiranje) bližje zaporednemu (slapovnemu) razvoju

Osrednji pomen bi dobili izdelki analize, ki bi med drugim predstavljali tudi “izvorno kodo”.

Velik pomen orodij za generiranje.

MDA in podpora orodij… Orodja za razvoj na podlagi MDA:

orodja za preslikavo iz PIM v PSM orodja za preslikavo PSM v kodo orodja za preslikavo PIM v kodo prilagodljiva transformacijska orodja orodja za definiranje transformacij

Današnja orodja dajo dovolj ugodnosti, ki jih ponuja MDA, da bi bila uporabna.

Poln potencial MDA še ni dosežen!

MDA in podpora orodij… Orodja, ki imajo dostopno evaluacijsko

verzijo: Compuware OptimalJ ObjectFrontier FronierSuite professional InnoQ iQgen Interactive Objects Software ArcStyler Objecteering Objecteering/UML Metanology MDE Aonix Ameos Codagen Technologies Codagen Architect 3.2 Rational Software Architect

Uradni seznam zavezanih družb in skupin na uradni strani o razvoju MDA organizacije OMG

MDA in podpora orodij Primeri orodij:

Teleologic TAU Generation2 Sosy OlivaNova Model Execution System Tata Consultancy Services MasterCraft Consyst REP++Studio Borland Delphi 8

Documents

Razvoj informacijskih sistemov