Transcript Procesi_PI

PROCESI PROGRAMSKOG
INŽENJERSTVA
U ovoj prezentaciji razmatraju se strukturirane aktivnosti
kojima je cilj razviti funkcionalni programski produkt.
1
Satish Mishra (1997). “Visual Modeling & Unified Modeling Language (UML) : Introduction to
UML”. Rational Software Corporation
2
PROCESI PROGRAMSKOG
INŽENJERSTVA
Sadržaj ove prezentacije:
• Procesi i modeli procesa programskog inženjerstva.
• Iteracije u modelima procesa programskog
inženjerstva.
• Generičke aktivnosti u procesima programskog
inženjerstva.
• CASE tehnologije za potporu aktivnostima u procesima
programskog inženjerstva.
• Zaključci
3
PROCESI PROGRAMSKOG INŽENJERSTVA
• Procesi i modeli procesa programskog inženjerstva.
• Iteracije u modelima procesa programskog
inženjerstva.
• Generičke aktivnosti u procesima programskog
inženjerstva.
• CASE tehnologije za potporu aktivnostima u procesima
programskog inženjerstva.
• Zaključci
4
Procesi i modeli procesa programskog
inženjerstva
Uvodne definicije:
Proces programskog inženjerstva je strukturirani skup aktivnosti
potreban da se oblikuje i razvija programski produkt.
Generičke aktivnosti u procesima programskog inženjerstva
pojavljuju se u svakom procesu u malo promijenjenom slijedu.
Model procesa programskog inženjerstva je apstraktna
(pojednostavljena) reprezentacija procesa. Predstavlja opis
procesa iz određene perspektive.
5
NAJZNAČAJNIJI MODELI
1. Vodopadni (engl. waterfall)
Odvojene i specifične faze specifikacije i razvoja
2. Evolucijski (engl. evolutionary development)
Specifikacija, razvoj i validacija su isprepleteni
3. Komponentno usmjeren (engl. component-based)
Sustav se gradi od postojećih komponenata
4. RUP (engl. Rational Unified Process)
Temelji se na oblikovanju preko modela
(engl. Model Based Design, MBD)
5. Agilni pristup (engl. Agile software development)
Postoje mnoge varijacije ovih modela (npr. model u kojem se
vodopadni slijed aktivnosti preslikava u formalnu specifikaciju).
6
Zahtjevi
1. Vodopadni model
programskog inženjerstva
Oblikovanje
Implementacija
i ispitivanje
dijelova
Integracija
i ispitivanje
sustava
Održavanje sustava
u radu
7
PROCESNE FAZE U VODOPADNOM MODELU
• Analiza zahtjeva i definicije
• Razvoj i oblikovanje sustava i programske potpore
• Implementacija i ispitivanje (testiranje) modula
• Integracija i testiranje sustava
• Uporaba sustava i održavanje
Temeljna značajka vodopadnog modela:
Pojedina faza se mora dovršiti prije pokretanja nove faze (nema
povratne veze između susjednih faza).
8
PROBLEMI VODOPADNOG MODELA
• Nefleksibilna particija projekta u odvojene dijelove čini
implementaciju promjena koje zahtijeva kupac vrlo teškom
(temeljni nedostatak vodopadnog modela).
• Model je prikladan samo ako su zahtjevi dobro razumljivi i
eventualne promjene svedene na minimum.
• Vrlo malo poslovnih sustava ima stabilne zahtjeve.
• Vodopadni model se uglavnom koristi za velike inženjerske
projekte gdje se sustav razvija na nekoliko odvojenih mjesta.
9
2. EVOLUCIJSKI MODEL RAZVOJA I
OBLIKOVANJA
Dva uobičajena postupka:
• Istraživački razvoj i oblikovanje (engl. exploratory development)
Cilj ovakvog pristupa je kontinuiran rad s kupcem na temelju
inicijalne specifikacije. Započinje se s dobro definiranim
početnim zahtjevima i razumijevanjem kako dijelovi sustava
funkcioniraju, a nove funkcionalnosti se dodaju temeljem
prijedloga kupca.
• Metoda odbacivanja prototipa (engl. throwaway prototyping)
Cilj je bolje razumijevanje zahtjeva sustava. Započinje se sa slabo
definiranim zahtjevima koji se tijekom postupka razjašnjavaju u
smislu što je doista potrebno. Za to se koriste prototipovi.
10
EVOLUCIJSKI MODEL RAZVOJA I OBLIKOVANJA
Ponavljanje
aktivnosti:
specifikacija,
razvoj, validacija
Početna inačica,
među-inačice,
završna inačica
Temeljem
zahtjeva
11
EVOLUCIJSKI MODEL RAZVOJA I
OBLIKOVANJA
Problemi:
• Proces razvoja i oblikovanja nije jasno vidljiv (otežava posao
voditeljima projekta).
• Sustavi su često vrlo loše strukturirani zbog stalnih izmjena.
• Često su potrebne posebne vještine (npr. brzi razvoj prototipa –
engl. Rapid System Prototyping).
Primijenjivost:
• Za male i srednje interaktivne sustave.
• Za dijelove velikih sustava (npr. korisničko sučelje).
• Za sustave s kratkim vijekom trajanja.
12
3. MODEL PROGRAMSKOG INŽENJERSTVA
ZASNOVAN NA KOMPONENTAMA
(engl. Component Based Software Engineering - CBSE)
Sustav se integrira višestrukom uporabom postojećih
komponenata ili uporabom komercijalnih, gotovih komponenata
(COTS: engl. commercial-of-the-shelf).
Stupnjevi procesa:
• Specifikacija i analiza zahtjeva
• Analiza komponenata
• Modifikacija zahtjeva (jer su komponente fiksirane)
• Oblikovanje sustava s višestrukom uporabom
komponenata (engl. reuse)
• Razvoj i integracija
S povećanom standardizacijom komponenata CBSE se sve više
13
prihvaća u razvoju sustava.
MODEL PROGRAMSKOG INŽENJERSTVA
TEMELJEN NA VIŠESTRUKOJ UPORABI
KOMPONENATA
Analiza
knjižnice
komponenata
Promjena
zahtjeva jer su
komp. fiksirane
Oblikovanje sustava
temeljeno na
ponovnoj uporabi
komponenata
Specifikacija
temeljena na
zahtjevima
Razvoj i
integracija
Validacija
sustava
14
4. RATIONAL UNIFIED PROCESS (RUP)
Moderan model procesa programskog inženjerstva izveden na
temelju jezika za modeliranje UML (engl. Unified Modeling
Language) i pridruženih aktivnosti.
Najčešće opisan kroz tri perspektive:
• Dinamička perspektiva koja pokazuje slijed faza procesa kroz
vrijeme.
• Statička perspektiva koja pokazuje aktivnosti u pojedinim fazama
procesa.
• Praktična perspektiva koja sugerira aktivnosti kroz iskustvo i
dobru praksu.
15
Preuzeto iz:
UML i RUP
Ivar Jacobson
Rational Software
email: [email protected]
Prilagodio: N.Bogunović
16
Prije UML-a
 1960-te – 1970-te
programiranje
 COBOL, FORTRAN, C
 Tehnike strukturne analize i oblikovanja
 1980-te – rane 1990-te
 Smalltalk, Ada, C++, Visual Basic
 Rane generacije OO metoda
 Sredina i kasne 1990-te
 Java
 UML
 Unified Process (RUP)
modeliranje
Temelji UML-a




UML je jezik za:
 vizualizaciju
 specifikaciju
 oblikovanje (i konstruiranje)
 dokumentiranje
artefakata programske potpore.
UML je posebice prikladan za specificiranje objektno usmjerene
arhitekture programske potpore.
Dijelovi UML-a pogodni su u specificiranju i drugih arhitektura.
Uvođenje arhitekture programske potpore: to je struktura ili
strukture sustava koji sadrži elemente, njihova izvana vidljiva
obilježja i odnose između njih.
Prednosti UML-a
•
•
•
•
•
Otvoren standard.
Podupire cijeli životni ciklus oblikovanja programske
potpore.
Podupire različite domene primjene.
Temeljen je na iskustvu i potrebama zajednice
oblikovatelja i korisnika programske potpore.
Podržavaju ga mnogi alati.
Mnogo dionika, mnogo pogleda
• Arhitekturu programske potpore različito vidi:
•
•
•
•
•
•
•
Korisnik-kupac
Projekt manager
Inženjer sustava
Osoba koje razvija sustav
Arhitekt
Osoba koja održava sustav (engl. maintainer)
Drugi dionici
• Višedimenzionalna realnost
• Mnogo dionika rezultira u
•
višestrukim pogledima, višestrukim nacrtima
Koliko pogleda ?
•
Pogledi odgovaraju nekom kontekstu.
•
Svi sustavi ne trebaju sve poglede:
•
•
Jedan procesor, nije potreban nacrt razmještaja procesora.
•
Jedan proces, nije potreba nacrt razmještaja procesa.
•
Vrlo mali programi, nije potreban nacrt implementacije.
Neki dodatni pogledi:
•
Pogled podataka, pogled sigurnosti u sustavu
•
Svaki pogled dokumentira se nacrtom – DIJAGRAMOM.
•
•
Više pogleda (dijagrama) u okviru nekog konteksta = MODEL
Model je apstraktan (reduciran, pojednostavljen, smanjen,
ograničen) opis sustava iz određene perspektive.
UML (v1.3) Modeli i Dijagrami
Use Case
Use Case
Diagrams
Sequence
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Collaboration
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Statechart
Diagrams
Diagrams
Use Case
Use Case
Diagrams
Use Case
Diagrams
Diagrams
State
State
Diagrams
Class
Diagrams
Diagrams
State
State
Diagrams
Object
Diagrams
Diagrams
State
State
Diagrams
Component
Diagrams
Diagrams
Models
Component
Component
Diagrams
Deployment
Diagrams
Activity
Diagrams
Diagrams
Dijagrami
• Pojedini dijagram je pogled u model
• Prikazan s aspekta određenog dionika
• Daje određeno predstavljanje sustava
• Semantički je konzistentan s ostalim pogledima
• U okviru UML v1.3 postoji devet standardnih dijagrama:
 Statički pogledi: use case, class, object, component, deployment
 Dinamički pogledi: sequence, collaboration, statechart, activity
 U RUP procesu svakoj aktivnosti pridružen je jedan ili više
modela za opis, koji su dokumentirani s jednim ili više
dijagrama (pogleda, engl. views).
Tim + UML + RUP = dobitna kombinacija
Projektni
tim !
Team-Based
Development
Modeling
Language
Unified
Process
Kako je nastao RUP ?
Rational Unified Process 5.0
1998
Rational Objectory Process 4.1
Uključuje inženjerstvo
poslovnog procesa,
rukovanje zahtjevima,
rukovanje oblikovanjem i
promjenama, funkcijsko
ispitivanje, evaluaciju
performansi, inženjerstvo
podataka, oblikovanje
sučelja
1996-1997
UML
The Rational Approach
Objectory Process 1.0-3.8
1987-1995
The Ericsson Approach
!!!
rane 80'
Prikaz RUP-a
 RUP će se prikazati kroz tri temeljna obilježja:
 Promiče iteracije na pojedinim fazama oblikovanja
programske potpore
 Temelji se na obrascima uporabe (tj. predlošku scenarija)
 U fokusu je arhitektura sustava
Prikaz RUP-a
 RUP
 Promiče iteracije na pojedinim fazama oblikovanja
programske potpore
 Temelji se na obrascima uporabe (tj. predlošku scenarija)
 U fokusu je arhitektura sustava
Faze u životnom ciklusu RUP procesa
Inception
Elaboration
Construction
Transition
vrijeme
 Inception
(početak) Definira doseg projekta, razvoj modela
poslovnog procesa, specifikacija početnih zahtjeva
 Elaboration
(elaboracija) Plan projekta, specifikacija značajki
i temelji arhitekture sustava
 Construction
Izgradnja produkta (oblikovanje, programiranje,
ispitivanje)
 Transition
Prijenos produkta korisnicima (postavljanje u radnu
okolinu)
Glavni “Milestones” (ključne točke i pridruženi dokumenti)
Inception
Elaboration
Construction
Transition
vrijeme
Vizija
Temeljna arhitektura
Početna sposobnost
Izdanje produkta
(engl. release)
Faze i pridružene iteracije
Inception
Prelim
Iteracija
Elaboration
...
Arh
Iteracija
Release
Release
...
Construction
Razvojna
Iteracija
Release
Razvojna
Iteracija
Release
Release
Transition
...
Prijenos
Iteracija
Release
...
Release
Release
Iteracija je sekvenca aktivnosti u okviru prihvaćenog plana i kriterija
evaluacije. Rezultira u dokumentu, a kasnije i jednoj izvršnoj inačici
programa (izdanju, engl. release).
Iteracije i aktivnosti (tijek rada, engl. workflow)
Faze životnog ciklusa
Aktivnosti
Inception
Elaboration
Construction
Transition
Zahtjevi
Iteracija u fazi elaboracije
Analiza
Intenzitet aktivnosti
Oblikovanje
Implementacija
Test
P r e lim in a rne
Ite ra tio n (s )
vrijeme
ite r.
#1
ite r.
#2
ite r.
#n
ite r.
#n+1
iteracije
ite r.
#n+2
ite r.
#m
ite r.
#m +1
Detaljizirana struktura RUP-a
Inicijalna aktivnost
Aktivnosti u RUP-u
Faze životnog ciklusa
Inception Elaboration
Construction
Transition
Mod. poslovnog proc.
Jezgrene
(temeljne)
aktivnosti
(engl. core
workflows)
Zahtjevi
Analiza i oblikovanje
Implementacija
Test
Razmještaj
Potporne aktivnosti
Mgmt. konfiguracije i promjena
Management razvoja projekta
Briga o okolišu
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iteracije
Iter.
#m
Iter.
#m+1
Aktivnosti (tijek rada) i pridruženi modeli
Modeli su
dokumentirani
dijagramima
(pogledima)
Aktivnosti:
Zahtjevi
Analiza
Oblikovanje
Use Case
Model
Analysis
Model
Design
Model
Razmještaj
Model
Implementacija
Model
Implementacija
Test
Model
Test
Svakoj aktivnosti
pridružen je jedan ili
više modela.
Primjer:
(Obrazac
uporabe)
Use Case Model (nije potrebno pamtiti pridruživanje)
Use Case
Diagrams
Use Case
Model
Class
Diagrams
Analysis
Model
Component
Diagrams
Deployment
Diagrams
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Pridruživanje
dijagrama
modelu
Sequence
Diagrams
Collaboration
Diagrams
Statechart
Diagrams
Activity
Diagrams
Object
Diagrams
Primjer:
Test Model
Use Case
Diagrams
Use Case
Model
Class
Diagrams
Analysis
Model
Component
Diagrams
Deployment
Diagrams
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Test model odnosi se
na sve druge modele i
koristi njihove
odgovarajuće
dijagrame
Sequence
Diagrams
Collaboration
Diagrams
Statechart
Diagrams
Activity
Diagrams
Object
Diagrams
Prikaz RUP-a
 RUP
 Promiče iteracije na pojedinim fazama oblikovanja programske
potpore
 Temelji se na obrascima uporabe (tj. predlošku scenarija)
 U fokusu je arhitektura sustava
Što znači: Temelji se na obrascima uporabe
(Use Case)?
Aktivnosti:
Zahtjevi
Analiza
Oblikovanje
Impl.
Obrasci uporabe (use cases) povezuju sve
ove aktivnosti zajedno
Test
Obrasci uporabe kao pokretači iteracija
 Obrasci uporabe pokreću brojne aktivnosti u životnom ciklusu
oblikovanja programske potpore, kao npr.:





Kreiranje i validacija arhitekture sustava
Definicija ispitnih slučajeva, scenarija i procedura
Planiranje pojedinih iteracija
Kreiranje korisničke dokumentacije
Razmještaj (engl. deployment) sustava
 Sinkroniziraju sadržaj različitih modela
Prikaz RUP-a
 RUP
 Promiče iteracije na pojedinim fazama oblikovanja
programske potpore
 Temelji se na obrascima uporabe (tj. predlošku scenarija)
 U fokusu je arhitektura sustava
 Arhitektura programske potpore je struktura ili strukture
sustava koje sadrži elemente, njihova izvana vidljiva
obilježja i odnose između njih.
RUP: u fokusu je arhitektura sustava
 Modeli su prijenosnici za vizualizaciju, specifikaciju,
konstruiranje (oblikovanje, implementacija) i dokumentiranje
arhitekture
 RUP propisuje sukcesivno rafiniranje od grubog modela do
konačne izvršne arhitekture
 RUP promiče oblikovanje programske potpore zasnovano na
modelima (engl. Model Based Design, MBD)
Aktivnosti:
Inception
Elaboration
Construction
vrijeme
Arhitektura
Transition
RUP predstavlja inženjerski pristup
Jedinica posla
Uloga tima ili
individue
Aktivnost
Radnik
TKO
Analitičar
Odgovoran za
Use case
Opiši
Use Case
ŠTO
Artefakt
Dio informacije koji se
proizvede, modificira ili
koristi u procesu
Use case
paket
RUP je samo okvir (engl. framework)
NE POSTOJI UNIVERZALNI PROCES OBLIKOVANJA
PROGRAMSKE POTPORE
•
RUP je predložen imajući u vidu fleksibilnost i proširenje
» omogućuje razne strategije životnog ciklusa projekta
» odabire koje artefakte treba proizvesti
» definira aktivnosti i radnike
» modelira koncepte
RUP ZAKLJUČCI
•
•
•
•
•
•
U središtu RUP procesa su obrasci uporabe sustava koji
semantički povezuju sve aktivnosti.
RUP definira i međusobno povezuje dinamičke faze i statičke
aktivnosti procesa (vidi prikaze iteracija i aktivnosti).
Za opis pojedinih aktivnosti koriste se odgovarajući modeli.
Modeli su dokumentirani s jednim ili više dijagrama (pogleda).
Dijagrami su definirani UML standardom.
Oblikovana arhitektura sustava sadrži skup pogleda u modele
(tj. skup dijagrama).
5. AGILNI PRISTUP RAZVOJU PROGRAMSKE
POTPORE
• Grupa metoda za razvoj programske potpore kojima je zajednički
iterativni razvoj uz male inkremente te koje podržavaju brzi odziv na
korisničke zahtjeve.
• Ovaj model razvoja programske potpore koristi se za brzi razvoj
manjih i srednjih projekata u stalnoj interakciji s klijentima putem
stalnog predočavanja novih poboljšanja, uz relativno slabo
dokumentiranje.
• Najpoznatije metode uključuju:
• Čisti razvoj programske potpore (engl. Lean software
development)
• Ekstremno programiranje (engl. Extreme programming)
• Razvoj zasnovan na ispitivanju (engl. Test-driven development)
44
ČISTI (LEAN) RAZVOJ PROGRAMSKE POTPORE
• Izvorno korištena metoda u industrijskom produkcijskom sustavu
Toyote
• Cilj je razviti u što kraćem vremenu sustav koji će zadovoljiti korisnike
• Koristi se 7 principa oblikovanja:
• Eliminacija svega suvišnoga (koda, nejasnih zahtjeva, birokracije,
spore interne komunikacije)
• Naglašeno učenje (stalna komunikacija s klijentom, stalna
testiranja i brze nadogradnje)
• Odlaganje odluke (predlaganjem opcija klijentu, skupljanjem
činjenica)
• Dostava proizvoda što je brže moguće (niz metoda, uglavnom mali
inkrementi, više timova radi isto)
• Motivacija i suradnja unutar tima
• Ugradnja cjelovitosti u sustav (kupac mora biti zadovoljan sa
sustavom u cjelini: funkcionalnošću, intuitivnošću korištenja,
cijenom)
• Razumjevanje modela (svaki član tima mora znati kako i zašto čisti
razvoj programske potpore treba funkcionirati)
45
EKSTREMNO PROGRAMIRANJE (XP)
• Javlja se (sredinom 1990-tih) kao otpor strukturiranom
(ponajviše vodopadnom) procesu programskog inženjerstva.
• Smatra se da vodopadni model unosi previše birokracije u
proces oblikovanja.
• Jedina mjera napretka je funkcionalni programski produkt.
• Pristup se bazira na razvoju, oblikovanju i isporuci
funkcionalnih dijelova.
• Postupak uključuje kontinuirano poboljšavanje koda.
• Sudjelovanje korisnika u razvojnom timu.
• U razvoju sustava najčešće se programira u paru (jedno
radno mjesto, međusobno provjeravanje (engl. pairwise
programming).
• Nedostatak: nerazumljivost, ne podupire ponovnu uporabu
(engl. reuse) rješenja.
46
PROCESI PROGRAMSKOG INŽENJERSTVA
• Procesi i modeli procesa programskog inženjerstva.
• Iteracije u modelima procesa programskog
inženjerstva.
• Generičke aktivnosti u procesima programskog
inženjerstva.
• CASE tehnologije za potporu aktivnostima u
procesima programskog inženjerstva.
• Zaključci
47
ITERACIJE U MODELIMA PROCESA
PROGRAMSKOG INŽENJERSTVA
• Iteracije u procesu programskog inženjerstva sastavni su dio
velikih projekata jer se pojedini dijelovi moraju ponovno
oblikovati.
• Iteracije se mogu primijeniti na bilo koji generički model procesa
programskog inženjerstva.
• Iteracije se javljaju u svakoj fazi procesa programskog
inženjerstva (vidi npr. RUP).
Postoje dva međuovisna pristupa iteracijama:
• Inkrementalni
• Spiralni
48
INKREMENTALNI PRISTUP
(kao oblik iteracija)
• Sustav se ne isporučuje korisniku u cjelini. Razvoj, oblikovanje i
isporuka razbiju se u inkrementalne dijelove koji predstavljaju
djelomične funkcionalnosti.
• Zahtjevi korisnika se svrstaju u prioritetne cjeline. Dijelovi višega
prioriteta isporučuju se u ranim dijelovima sustava
(inkrementima).
• S početkom razvoja pojedinog inkrementa njegovi zahtjevi se
fiksiraju (zamrzavaju). Zahtjevi na ostale kasnije inkremente
nastavljaju evoluirati.
49
INKREMENTALNI ITERACIJSKI PRISTUP
Definiranje
zahtjeva
Pridruži
zahtjeve
inkrementima
Validiraj inkrement
Razvij
inkrement
sustava
Oblikuj
arhitekturu
sustava
Integriraj inkrement
Sustav
nekompletan
Validiraj
sustav
Konačan
sustav
50
INKREMENTALNI PRISTUP ITERACIJAMA
PREDNOSTI
• Kupac dobiva svoju vrijednost sa svakim inkrementom. Temeljna
funkcionalnost sustava se ostvaruje u ranim fazama projekta.
• Rani inkrementi služe kao prototipovi na temelju kojih se izlučuju
zahtjevi za kasnije inkremente.
• Smanjen je rizik za neuspjeh projekta.
• Prioritetne funkcionalne usluge sustava imaju mogućnost
detaljnijeg ispitivanja (testiranja) jer su implementirane u ranim
fazama projekta.
NEDOSTATCI
• Teško je preslikati korisničke zahtjeve u inkremente odgovarajuće
veličine
• Teško je odrediti koje će zajedničke značajke sustava biti potrebne
za razvoj svih daljnjih inkremenata
51
SPIRALNI PRISTUP
(kao oblik iteracija)
• Proces oblikovanja se predstavlja spiralom umjesto sekvencom
aktivnosti.
• Svaka petlja u spirali predstavlja jednu fazu procesa.
• Nema ranih završenih faza (kao npr. specifikacija, razvoj, …).
• Eksplicitno se određuju i razrješavaju rizici razvoja programskog
produkta.
52
Procjena i smanjivanje rizika
Postavljanje ciljeva
Planiranje
Razvoj i validacija
53
SEKTORI U SPIRALNOM MODELU ITERACIJA
• Postavljanje ciljeva
Temeljem zahtjeva identifikacija specifičnih ciljeva
(opcija/alternativa i ograničenja).
• Procjena i smanjivanje rizika
Analiziraju se rizici u opcijama te preslikavaju u aktivnosti koje
ih reduciraju (poput SWOT analize – snage, slabosti, prilike,
prijetnje). Analiza rizika rezultira u evoluciji prototipova.
• Razvoj i validacija
Analizom prototipa slijedi razvoj produkta. U ranim spiralama
koncept, kasnije spirale nose sve detaljnije aktivnosti
(specifikacija, oblikovanje, razvoj, testiranje, uporaba).
• Planiranje
Planiraju se faze (ciklusi spirale) od izlučivanja zahtjeva do
oblikovanja, razvoja i integracije (od koncepta do produkta).
54
PROCESI PROGRAMSKOG INŽENJERSTVA
• Procesi i modeli procesa programskog inženjerstva.
• Iteracije u modelima procesa programskog
inženjerstva.
• Generičke aktivnosti u procesima programskog
inženjerstva.
• CASE tehnologije za potporu aktivnostima u
procesima programskog inženjerstva.
• Zaključci
55
GENERIČKE AKTIVNOSTI U PROCESU
PROGRAMSKOG INŽENJERSTVA
Pojavljuju se u svakom modelu procesa
programskog inženjerstva:
• Specifikacija programskog produkta temeljem analize i
izlučivanja zahtjeva.
• Oblikovanje i implementacija programskog produkta
• Validacija i verifikacija programskog produkta
• Evolucija programskog produkta
56
Generička aktivnost: SPECIFIKACIJA
PROGRAMSKOG PRODUKTA
• Specifikacija programskog produkta određuje se procesom
inženjerstva zahtjeva (engl. Requirements engineering).
• Proces rezultira dokumentom u kojem se navode potrebne usluge i
ograničenja u radu i razvoju sustava.
Temeljni dio ove aktivnosti čine:
• Studija izvedivosti
• Izlučivanje (otkrivanje) zahtjeva
• Validacija zahtjeva
• Upravljanje promjenama u zahtjevima
Ova aktivnost detaljno je analizirana ranije u sklopu
prikaza inženjerstva zahtjeva !
57
GENERIČKE AKTIVNOSTI U PROCESU
PROGRAMSKOG INŽENJERSTVA
Pojavljuju se u svakom modelu procesa
programskog inženjerstva:
• Specifikacija programskog produkta temeljem analize i
izlučivanje zahtjeva.
• Oblikovanje i implementacija programskog produkta
• Validacija i verifikacija programskog produkta
• Evolucija programskog produkta
58
Generička aktivnost: OBLIKOVANJE I
IMPLEMENTACIJA PROGRAMSKOG
PRODUKTA
To je proces preslikavanja specifikacije u stvarni sustav.
Uključuje:
• Oblikovanje programskog produkta
Oblikovanje strukture sustava koja realizira
specifikaciju (izbor i modeliranje arhitekture).
• Implementaciju (programiranje)
Preslikavanje strukture u izvršni program.
Aktivnosti oblikovanja i implementacije su povezane i mogu biti
isprepletene.
59
PODAKTIVNOSTI UNUTAR OBLIKOVANJA
PROGRAMSKOG PRODUKTA
• Izbor i oblikovanje arhitekture (kriteriji za odabir stila?).
• Apstraktna specifikacija (koncepcijska, ne tehnička).
• Konkretna specifikacija (tehnička).
• Oblikovanje sučelja
• Oblikovanje komponenata
• Oblikovanje struktura podataka
• Oblikovanje algoritama
60
OBLIKOVANJE PROGRAMSKOG PRODUKTA
(podaktivnosti i rezultati – dokumenti)
Podaktivnosti u oblikovanju
Specifikacija
zahtjeva
Izbor i
oblikovanje
arhitekture
Arhitektura
sustava
Oblikovanje Oblikovanje Oblikovanje
sučelja
komponenata struktura
Apstraktna
podataka
specifikacija
Specifikacija
programa
Specifikacija
Specifikacija
sučelja
Specifikacija struktura
komponenata podataka
Produkti oblikovanja
Oblikovanje
algoritama
Specifikacija
algoritama
61
OBLIKOVANJE PROGRAMSKOG PRODUKTA izbor arhitekture
• Prva aktivnost unutar oblikovanja (vidi prethodnu sliku).
• Izbor arhitekture nažalost nije poduprt formalnim postupcima,
već se najčešće temelji na neformalnoj analizi i dobroj
inženjerskoj praksi.
• Na temelju odabrane arhitekture slijedi sistematski pristup
oblikovanja programskog produkta.
• Arhitektura bi trebala biti dokumentirana skupom modela
(najčešće grafičkih dijagrama).
• Neke moguće arhitekture programske potpore:
• Protok podataka (engl. data-flow)
• Objektno usmjerena arhitektura
• Repozitorij podataka
• Arhitektura temeljena na događajima
• …
62
OBLIKOVANJE PROGRAMSKOG PRODUKTA –
Implementacija
(programiranje i otklanjanje pogrešaka)
• Implementacija je preslikavanje dokumentiranog oblikovanja
(odabrane arhitekture) u program i otklanjanje pogrešaka u
dijelu programa za koji su zaduženi.
• Programiranje je osobna aktivnost – ne postoji generički
proces programiranja.
• Programeri tijekom implementacije izvode i neke dodatne
aktivnosti: ispitivanje (testiranje) programskog produkta s
ciljem otkrivanja i otklanjanja pogrešaka (engl. debugging),
oblikovanje i programiranje ispitnih programa.
63
GENERIČKE AKTIVNOSTI U PROCESU
PROGRAMSKOG INŽENJERSTVA
Pojavljuju se u svakom modelu procesa programskog
inženjerstva:
• Specifikacija programskog produkta temeljem analize i
izlučivanje zahtjeva.
• Oblikovanje i implementacija programskog produkta
• Validacija i verifikacija programskog produkta
• Evolucija programskog produkta
64
Generička aktivnost: VALIDACIJA I
VERIFIKACIJA PROGRAMSKOG PRODUKTA
• Validacija i verifikacija treba pokazati da sustav odgovara
specifikaciji i zadovoljava zahtjevima kupca i korisnika.
Validation – “Are we building the right system ?”
Verification – “Are we building the system right ?”
• Validacija se provodi ispitivanjem sustava (testiranjem).
• Ispitivanje se temelji na radu sustava s ispitnim ulaznim
parametrima (podacima) koji se izvode iz specifikacije stvarnih
podataka koje sustav treba prihvatiti. Ispitivanje je složena i vrlo
skupa aktivnost.
• Ispitivanje (testiranje sustava) bit će detaljno obrađeno u
posebnim predavanjima.
• Verifikacija uključuje provjeru odsustva pogrešaka, poželjno
zasnovanu na formalnim (matematičkim i logičkim) metodama.
65
Udio troška ispitivanja u nekim modelima procesa
Wat er fall mo del
programskog inženjerstva
0
25
Specificatio n
VODOPADNI
50
Design
Dev elo pmen t
In teg ratio n and testing
ITERATIVNI
It erative develo pmen t
0
25
Specificatio n
Compo nent-b ased software en g
25
Specificatio n
50
75
Iterativ e d ev elop ment
0
in eerin g
KOMPONENTNI
50
Sy stem dev elop ment
1 00
75
In teg ratio n and testing
Dev elo pmen t and evo lu tio n cos ts for lo ng -lifetime s ys t
10
1 00
Sy stem tes tin g
Dev elo pmen t
0
100
75
DUGOVJEČNI
ems
20 0
30
Sy stem evo lu tio n
400
66
ISPITIVANJE (TESTIRANJE) PROGRAMSKE POTPORE
Što je ispitivanje ?
• Pretpostavka za ispitivanje:
Bez specifikacije nema testiranja !
• Testiranje znači usporedbu stvarnih rezultata s postavljenim i
očekivanim zahtjevima.
• The Institute of Electrical and Electronics Engineers (IEEE)
definira:
test - kao jedan ili više testnih slučajeva (engl. test case)
testiranje - kao proces analize programskog koda sa svrhom
pronalaska razlike između postojećeg i zahtijevanog stanja te
vrednovanja svojstava programa.
67
ISPITIVANJE PROGRAMSKE POTPORE
Terminologija:
Testni podaci (I)
Ulazi odabrani za provođenje određenog testa.
Očekivani izlaz (O)
Zabilježen prije provođenje testa.
Testni slučaj (engl. test case)
Uređeni par (I, O).
Kriterij prolaza testa
Kriterij usporedbe očekivanog i stvarnog izlaza određen prije
provođenja testa.
Stvarni izlaz
Rezultat dobiven provođenjem testa.
68
ISPITIVANJE PROGRAMSKE POTPORE
Proces ispitivanja po integracijskim dijelovima sustava:
(oblikovanje odozgo prema dolje, ispitivanje odozdo prema gore)
• Ispitivanje komponenti, engl. Unit (Component) testing.
• Integracijsko ispitivanje
• Ispitivanje sustava, engl. System/Release testing.
• Test prihvatljivosti, engl. Acceptance Testing.
• Test instalacije, engl. Installation testing.
• Alpha test (interni).
• Beta test (vanjski).
69
AKTIVNOSTI I PRODUKTI TIJEKOM PROCESA
ISPITIVANJA
oblikovanje
Tijek aktivnosti
Spec. zahtjeva
Spec. sustava
Oblikovanje sustava
Produkti
aktivnosti
Plan testa prihvatljivosti
Puštanje u rad
Plan testa integracije Plan testiranja
podsustava
Testiranje
tijekom
oblikovanja
modula
Test prihvatljivosti Test integracije Test podsustava
ispitivanje
70
ISPITIVANJE PROGRMASKE POTPORE
• Ispitivanje je nezaobilazna aktivnost u svakom
procesu programskog inženjerstva.
Međutim:
1972. Dijkstra: “Program testing can be a very effective way to show
the presence of bugs, but it is hopelessly inadequate for showing
their absence.”
(Ispitivanje programa može biti vrlo učinkovit način za pokazati
prisutnost pogrešaka, ali je beznatno neadekvatno za pokazati
njihovu odsutnost)
• Ispitivanje se dopunjuje formalnom
verifikacijom.
71
Formalna verifikacija
To je postupak provjere da formalni model dijela izvedenog
sustava (/), odgovara formalnoj specifikaciji (S) sa matematičkom
izvjesnošću ("odgovara" = logički zadovoljava).
Nije tradicijska aktivnost u programskom inženjerstvu, ali sve se
više uvodi.
Detaljniji prikaz ove aktivnosti u kasnijim predavanjima.
I - formalni
model
Da / Ne
Sustav za
verifikaciju
S - formalna
specifikacija
72
GENERIČKE AKTIVNOSTI U PROCESU
PROGRAMSKOG INŽENJERSTVA
Pojavljuju se u svakom modelu procesa
programskog inženjerstva:
• Specifikacija programskog produkta temeljem analize i
izlučivanje zahtjeva.
• Oblikovanje i implementacija programskog produkta
• Validacija i verifikacija programskog produkta
• Evolucija programskog produkta
73
Generička aktivnost: EVOLUCIJA
PROGRAMSKOG PRODUKTA
• Programski produkt je inherentno fleksibilan i može se
mijenjati.
• Kako se mijenjaju zahtjevi na sustav (zbog promjene
poslovnog procesa), programski produkt koji podupire
poslovni proces također se mora mijenjati.
• Iako postoji granica između razvoja i oblikovanja s jedne
strane i evolucije i održavanja s druge strane, to ona postaje
sve više irelevantna, jer je sve manje programskih sustava
potpuno novo (oblikovano bez uporabe dijelova ranijih
produkata).
74
EVOLUCIJA SUSTAVA
Analiza postojećeg
sustava
Predloži izmjene
Definiraj (nove)
zahtjeve
Postojeći
sustav
Modificiraj sustav
Novi sustav
75
PROCESI PROGRAMSKOG INŽENJERSTVA
• Procesi i modeli procesa programskog inženjerstva.
• Iteracije u modelima procesa programskog
inženjerstva.
• Generičke aktivnosti u procesima programskog
inženjerstva.
• CASE tehnologije za potporu aktivnostima u
procesima programskog inženjerstva.
• Zaključci
76
CASE - Computer-aided software engineering
 To su programski produkti koji podupiru proces programskog
inženjerstva, a posebice aktivnosti specifikacije, oblikovanja,
implementacije i evolucije.
 Iako je CASE tehnologija dovela do značajnog unapređenja
procesa oblikovanja programske potpore, ipak poboljšanja
nisu sukladna očekivanjima (tj. poboljšanje efikasnosti za red
veličine !?).
Zašto?
• Programsko inženjerstvo zahtijeva kreativnost, koju nije lako,
a često ni moguće automatizirati.
• Programsko inženjerstvo je timska aktivnost. U većim
projektima mnogo vremena se utroši na interakcije unutar
tima. CASE tehnologija slabo podupire timski rad.
77
CASE TEHNOLOGIJA
CASE podupire automatizaciju oblikovanja raznim alatima kao npr.:
• Grafički editori za razvoj modela sustava.
• Rječnici i zbirke za upravljanje entitetima u oblikovanju.
• Grafička okruženja za oblikovanje i konstrukciju
korisničkih sučelja.
• Alati za pronalaženje pogrešaka u programu.
• Automatizirani prevoditelji koji generiraju nove inačice
programa.
• ….
Kako izabrati pogodan alat ?
Potrebno poznavanje klasifikacije CASE tehnologije.
78
Klasifikacija CASE alata
Klasifikacija omogućuje razumijevanje različitih tipova CASE alata
i njihovu potporu aktivnostima u procesu programskog
inženjerstva.
• Funkcionalna perspektiva
Alati se klasificiraju prema specifičnoj funkciji.
• Procesna perspektiva
Alati se klasificiraju prema aktivnostima koje podupiru u
procesu.
• Integracijska perspektiva
Alati se klasificiraju prema njihovoj organizaciji u
integrirane cjeline.
79
Funkcionalna perspektiva CASE alata
Tool type
Examples
Planning tools
PERT tools, estimation tools, spreadsheets
Editing tools
Text editors, diagram editors, word processors
Change ma nagement tools
Requirements traceability tools, change control systems
Configuration management tools
Version management systems, system b uilding tools
Prototyping tools
Very high-level languages, user interface generators
Method-support tools
Design editors, data dictionaries, code generators
Language-processing tools
Compilers, interpreters
Program analysis tools
Cross reference generators, static analysers, dynamic analysers
Testing tools
Test data generators, file comp arators
Debugging tools
Interactive debugging systems
Documentation tools
Page layout programs, ima ge editors
Re-engineering tools
Cross-reference systems, program re-structuring systems
80
Procesna perspektiva CASE alata
Alati
Re-eng in eerin g to ols
Testin g to ols
Deb ug g in g too ls
Prog ram an aly sis to ols
Lang u ag e-p ro cessin g
to ols
Meth o d sup po r t too ls
Prototy p ing to ols
Con fig uration
man ag emen t to ols
Chang e man ag emen t too ls
Documen tatio n too ls
Editing too ls
Plan ning to o ls
Specificatio n
Design
Implemen tatio n
Generičke aktivnosti
Verification
an d
Validatio n
81
Integracijska klasifikacija CASE alata
Sveobuhvatnost u procesu
• Alati (u užem smislu)
Podupiru individualne zadatke u procesu (npr.
oblikovanje, provjera konzistencija, editiranje teksta, …)
• Radne klupe (engl. workbenches)
Podupiru pojedine aktivnosti (faze) procesa (npr. specifikaciju)
• Razvojne okoline (engl. environments)
Podupiru cijeli ili značajan dio procesa programskog
inženjerstva. Uključuju nekoliko integriranih radnih klupa.
82
Integracijska klasifikacija: alati, radne klupe, razvojne okoline
CASE
tech no lo g y
Alati
Radne klupe
Wo rk ben ch es
To ols
Uređivači
Razvojne okoline
Env iro nmen ts
Prevoditelji Usporedba datoteka Integrirane Procesno usmjerene
Editors
Compilers
File
co mpar ato rs
In teg rated
en v iro nmen ts
Pro cess-cen tr ed
en v iro nmen ts
(Npr. Rational Rose)
Analiza i oblikovanje
Analy sis an d
d esign
Multi-metho d
wo rk ben ch es
Više metoda
Programiranje
Pro grammin g
Sing le-meth od
wo rk ben ch es
Ispitivanje
Testin g
Gen er al-pu rp os e
wo rk ben ch es
Lang u ag e-specific
wo rk ben ch es
83
Jedna metoda Opće namjene Za jedan prog. jezik
CASE alati i radne klupe u okviru predmeta:
“Oblikovanje programske potpore”
Subversion
– upravljanje konfiguracijama programske potpore.
ArgoUML
– oblikovanje zahtjeva, oblikovanje modela objektno
usmjerene arhitekture i generiranje koda.
Neobvezne radne klupe i razvojne okoline (temeljno usmjerene na dio
procesa programskog inženjerstva tj. implementaciju i ispitivanje):
Visual Studio
– implementacija programske potpore vezana uz
Microsoftove tehnologije
Eclipse
– implementacija programske potpore vezana uz
Java tehnologije (i druge).
84
PROCESI PROGRAMSKOG INŽENJERSTVA
• Procesi i modeli procesa programskog inženjerstva.
• Iteracije u modelima procesa programskog
inženjerstva.
• Generičke aktivnosti u procesima programskog
inženjerstva.
• CASE tehnologije za potporu aktivnostima u
procesima programskog inženjerstva.
• Zaključci
85
ZAKLJUČCI (1 od 2)
• Procesi u programskom inženjerstvu su strukturirane aktivnosti
usmjerene na produkciju i evoluciju programskih proizvoda.
• Modeli procesa programskog inženjerstva su njihova apstraktna
reprezentacija (npr. vodopadni, evolucijski, komponentni, RUP).
• Nema univerzalnog i standardnog modela procesa programskog
inženjerstva.
• Generičke aktivnosti u procesu su specifikacija, oblikovanje i
implementacija, validacija i verifikacija te evolucija.
• Iteracije opisuju ponavljajuće podaktivnosti unutar faza ili
aktivnosti modela procesa.
86
ZAKLJUČCI (2 od 2)
• Generička aktivnost specifikacije generira dokument o zahtjevima
na sustav.
• Generička aktivnost oblikovanja i implementacije preslikava
specifikaciju u arhitekturu i radni (izvršni) program.
• Generička aktivnost validacije i verifikacije provjerava da li sustav
zadovoljava specifikaciju i potrebe korisnika.
• Evolucija se bavi izmjenama sustava tijekom njegove uporabe.
• CASE tehnologije podupiru automatizaciju aktivnosti tijekom
procesa programskog inženjerstva do neke granice.
87