Software Engineering
Ne kete prezantim ka materjale dhe figura te marra nga libri Ian Sommerville, Software Engineering, Addison Wesley;
Per Lenden
Profesor: Armend Bilalli
[email protected]
Literatura
Libri kryesor: Ian Sommerville, Software Engineering,
Addison Wesley; 8 edition (May 25, 2006). -UML 2 for Dummies by Michael Jesse Chonoles and James A. Schardt -.The Unified Modeling Language User Guide SECOND EDITION By Grady Booch, James Rumbaugh, Ivar Jacobson
2
Per Lenden
Detyra e Kursit:
Grupe nga 4-5 studente max. Grupet krijohen vullnetarisht. Prezantime ne faza te projektit. Evaluimi behet gjate gjithe kohes se kursit. Mund te gjeni edhe projekte konkrete reale. nga kompani te ndryshme. Anetaret e grupeve te dergohen me e-mail ne
[email protected]
Kollokviumi: (Java e 5-te)
3
Per Lenden
Notimi:
Detyra e Kursit (Projekti) 20% Kollokviumi 20% Provimi Final 60%
Shenim:
Pjesmarrja si anetar ne nje grup eshte i detyruar. Pjesmarrja ne kollokvium eshte i detyruar. (Mungesa nenkupton 20% me pak te notes perfundimtare) Nuk lejohet paraqitja e provimit pa kaluar detyren e kursit(Projektin).
4
Qellimi
Te mesoni hapat kryesor te zhvillimit te nje software. Te mesoni dhe praktikoni punen ne grup ne projekte te zhvillimit te nje software perfshire menaxhimin. Te jeni ne gjendje ne menyre efektive te analizoni nje ‘problem’ dhe te gjeni zgjidhjen me te mire. Te jeni ne gjendje te perktheni kerkesat e klientit dhe biznesit ne gjuhen e kompjuterit. Te jeni ne gjendje te krijoni class, object, use case, data flow, sequence diagrams, activity diagram ne UML. Te jeni ne gjendje te gjeni nje zgjidhje dizajni dhe implementimi me te mire per nje problem programimi. Te jeni ne gjendje te identifikoni burimet potenciale te rreziqeve qe do te mund te conin ne deshtimin e nje projekti softverik.
5
Software Engineering
Software engineering merret me teorite, metodat dhe veglat e punes (tools) per nje zhvillim profesional te nje software dhe cka eshte me e rendesishme; me nje kosto efektive te zhvillimit te tij. Shumica e sistemeve ne diten e sotme kontrollohen nga software. Shpenzimet ne software, reprezantojne nje pjese te mire te prodhimit te brendshem bruto ne ekonomite e shteteve te zhvilluara. Ekonimia e nje vendi te zhvilluar eshte e VARUR nga software
6
Pyetjet e Shpeshta-FAQs
Ç’ka eshte software? Ç’ka eshte software engineering? Cili eshte dallimi mes shkencave kompjuterike dhe software engineering? Cili eshte dallimi ne mes software engineering dhe system engineering? Cilat jane atributet kryesore te nje software te mire? Ç’ka nenkuptojme me Proces Softwerik dhe Model te procesit? Etj
7
Ç’ka eshte Software?
Kod Programimi se bashku me dokumentacionin percjelles si kerkesa, dizajni, manuali teknik dhe i perdoruesit etj. Software Gjenerik Photoshop Word SQL Server Software specifik (customized) Programe te Ndryshme financiare Programi per regjistrimin e popullsise Dallimi esencial eshte-? “Specifikacioni”. Kohet e fundit te dy keto tipe soft. jane bashkuar, ku kompanite zhvillojne nje software i cili me pas mund te 8 pershtatet per nevoja te klientit(p.sh SAP)
Ç’ka eshte Inxhinjerimi i softuare?
Eshte nje discipline inxhinjerike e cila merret me te gjitha aspektet e prodhimit te nje software, nga faza fillestare e specifikacionit deri tek mirembajta e sistemit pasi te kete shkuar ne perdorim. “Inxhinjerike”. -Nje Inxhinier softueri, duhet te adoptoje ne menyre sistematike metodat dhe teknikat me te pershtateshme per zgjidhjen e nje problemi duke patur parasysh kufizimet operacionale dhe buxhetore. “Te gjitha aspektet e prodhimit te nje software”(menaxhimi i projektit, veglat e zhvillimit, metodat dhe teorite,
9
Procesi Softuerik (Software process)
Temat Kresore
Modelet e procesit softuerik Perseritja e Proceseve Aktivitetet e Procesit The Rational Unified Process Computer-aided software engineering-CASE
10
Procesi Softuerik
Me proces softuerik kuptojme një grup te aktiviteteve qe kryhen per te zhvilluar nje software.
Aktivitet kryesore te nje procesi softuerik jane:
Specifikacioni i softuare; Dizajni dhe implementimi; Validimi i software; Evoluimi i software (Evolution)
11
Specifikacioni i Softuare
Specifikacioni I softuare eshte nje proces I kuptimit dhe percaktimit te sherbimeve qe duhet te ofroje sistemi si dhe percaktimit te kufizimeve te sistemit. Fazat e detajuara te specifikacionit te software jane:
Analiza e fizibilitetit; Analiza dhe percaktimi kerkesave; Specifikimi I kerkesave; Validimi I kerkesave;
12
Specifikacioni I Softuare
Analiza e fizibilitetit
Analiza dhe percaktimi kerkesave
Klasifikimi Kerkesave
Validimi I Kerkesave
Raporti I Fizibilitetit
13
Dokumenti i Kerkesave te software
Dizajni dhe implementimi
Eshte nje proces i konvertimit te specifkacionit te sistemit ne sistem te egzekutueshem. Software design
Dizajnimi i software ne baze te specifikacionit;
Implementimi
Perkthimi i struktures se dizajnit ne program te egzekutueshem;
14
Procesi I dizajnimit te software
15
Verifikimi dhe Validimi i Software
Verifikimi dhe Validimi (V & V) sherben per te vertetuar se sistemi eshte konform specifikacionit dhe permbush kerkesat e klientit. Perfshin kontrollin dhe rishikimin e sistemit me metoda te ndryshme testimi. Testimi i sistemit behet me shembuj testimi, zakonisht me te dhena reale qe procesohen nga sistemi.
16
Procesi i Testimit
Testimi i Komponenteve
Testimi i Sistemit
Pranimi i Testimit
17
Evoluimi i software
Software ne vetevete duhet te jete fleksibil dhe te kete mundesi per ndryshime. Ashtu Sic ndryshojne kerkesat, me ndryshimin e kerkesave te biznesit, software i cili suporton kete biznes duhet te evoluoje dhe te jete ne gjendje te ndryshoje. Jane rritur rastet kur vendoset te blihet software i ri, ne vend qe te ndryshohet apo pershatet ai ekzistues. PSE?
18
Evoluimi i Sitemit
19
Generic software process models
Ç’ka eshte nje model i procesit softuerik? Eshte nej prezantim I thjeshtesuar (apstrakt) I nje procesi softuerik. Nje menyre formale e prezantimit si operon biznesi
The Waterfall model Secila faze e procesit startohet ne menyre sekuenciale. Nuk mund te filloje nje faze pa mbaruar ajo paraprake. Evolutionary development Ne kete model mund te punohet paralelisht ne fazat e procesit. Component-based software engineering Sistemi ndertohet nga komponentet ekzistuese.
20
Waterfall model
21
Mangesite e Waterfall Model
Gjate procesit softuerik eshte veshtire te behen ndryshime te parametrave nese eshte duke u punuar ne nje faze te procesit. Nje faze duhet te perfundoje para se te kalohet ne fazen tjeter. Ky model eshte i perdorshem vetem atehere kur kerkesat jane kuptuar dhe percaktuar ne fillim dhe ndryshimet gjate zhvillimit jane te vogla(shume rralle ndodh kjo) Ky model zakonisht perdoret ne sisteme te medha, ku zakonisht zhvillimi behet ne vende te ndryshme ne te njejten kohe.
22
Modeli Evolutiv
Ne kete model objektivi eshte qe te punohet se bashku me klientin derisa te arrihet versioni perfundimtar i sistemit nga nje pershkrim fillestar specifikacionit.
23
Zhvillimi Evolutiv
24
Zhvillimi Evolutiv
Perparesite: Shume shpejte i akseptueshem nga klienti, sepse zhvillohet duke qene klienti aktiv me sistemin gjate tere kohes. Me efektiv ne prodhimin e nje software ne kohe me te shpejte. I aplikueshem per sisteme te vogla dhe te mesme, per pjese te sistemeve te medha si dhe per sisteme me jetegjatesi te shkurter. Mangesite Sistemet zakonisht jane te strukturuar dobet. Mungon dokumentacioni i zhvillimit te proceseve
25
CBSE- Component-based SE
Ne kete model perdoren sistemet ekzistuese dhe integrimi i tyre
26
Cilat jane Metodat e Soft Eng?
Nje metode e inxjinjerimit te software eshte nje qasje e strukturuar e zhvillimit te software, qellimi i se ciles eshte lehtesimi i zhvillimit te nje software.
Metoda Structured Analysis(DeMarco 1978) OO, Object Oriented (Booch 1994) UML-unified modeling language (Booch and Rumbaught 1999)
27
Cka eshte CASE?
Shkurtesa CASE qendron per Computer-Aided Software Engineering. Mbulon programe te ndryshme, qe perdoren per te suportuar aktivitetet e zhvillimit te procesit softwerik(analiz kerkesave,modelimi, debugging, testimi) Veglat CASE mund te perfshijne edhe gjenerimin e kodit, gjenerimin e dokumentacionit, gjenerimin e dizajneve te ndryshme etj. Per me teper lexoni www.case-tools.org
28
Cilat jane atributet kryesore te nje software te mire?
Nje Software duhet te ofroje funksionalitetin dhe performancen e kerkuar tek perdoruesi dhe duhet te jete i mirembajtshem, i besueshem dhe i pranueshem Mirembajtshmeria Software duhet te zhvillohet per te plotesuar kerkesat dhe nevojat qe ndryshojne me kohen Besueshmeria Software duhet te jete I besueshem; Efikasiteti Software nuk duhet te perdori resurset e sistemit pa nevoje Pranueshmeria Software duhet te jete i pranueshem dhe i kuptueshem nga perdoruesit per te cilte eshte zhvilluar.
29
Detyre Shtepie
Cili eshte dallimi ne mes shkencave kompjuterike dhe software engineering? Cili eshte dallimi ne mes software engineering dhe system engineering? Lexoni kapitullin 1,2,3 te librit kryesor.
30
Intentionally left blank
31
Procesi Softuerik
Cilat ishin aktivitetet kryesore te nje procesi softuerik?
Specifikacioni i softuare; Dizajni dhe implementimi; Validimi i software; Evoluimi i software (Evolution)
32
Specifikacioni i Softuare
Analiza e fizibilitetit
Analiza dhe percaktimi kerkesave
Klasifikimi I Kerkesave
Validimi I Kerkesave
Raporti I Fizibilitetit
33
Dokumeti Kerkesave te software
Analiza e Fizibilitetit
Nepermjet analizes se Fizibilitetit percaktohet/vendoset nese duhet te zhvillohet nje software. Analiza e fizibilitetit duhet te jepe pergjigje ne disa pyetje kryesore.
A duhet te zhvillohet ky softuer?Pse? Cili eshte plani kohore?A mund te realizohet ne kohe? Sa eshte profiti? A duhet te investohet? ROI(return on investment) Cilat jane perfitimet e organizates? A mund te implementohet Projekti? A ka specifikacion te mirefillt te kerkesave?
Kush duhet te beje Analizen e Fizibiliteti????
34
Analiza dhe percaktimi Kerkesave
Nepermjet analizes dhe percaktimit te kerkesave behet IDENTIFIKIMI I KERKESAVE Inxhinjeri/at softuerik se bashku me klientin dhe perdoruesit e sistemit duhet te punojne per identifikimin e kerkesave. Nepermjet Analiza se kerkesave te software percaktohen
Sherbimet/detyrat qe duhet te kryhen nga sistemi. Qellimi dhe caku qe duhet te arrihet nga sistemi. Kufizimet operacionale, funksionale dhe teknike te sistemit.
Ne kete proces perfshihen te gjithe palet e interesuara(stakeholders) sic jane: perdoruesit, menaxheret, ekspertet e fushave specifike etj.
35
Veshtiresite e analizes se kerkesave
Zakonisht palet e interesuara nuk e dine realisht se qka deshirojne. Kerkesat e paleve te ndryshme bien ne kundershtim me njera tjetren. Politikat sociale dhe organizative mund te ndikojne ne analizen e kerkesave. Ndryshimi dinamik i kerkesave gjate fazes se analizes.
36
Aktivitetet gjate analizes se kerkesave
Identifikimi I kerkesave
Bashkebisedimi me palet e interesuara per te identifikuar kerkesat e tyre. Behet mbledhja e informacionit per sistemin qe diskutohet dhe sistemet ekzistuese Mblidhen te gjitha burimet e informacionit, sic mund te jene;dokumente te ndryshme, specifikacione te sistemeve ekzistuese, manualet e ndryshme operative etj.
Klasifikimi dhe organizimi i kerkesave Caktimi i Prioriteteve dhe Negociimi
Caktohen kerkesat sipas prioriteteve dhe negociohen kerkesat qe kane konflikt njera me tjetren
Dokumentimi I Kerkesave
Dokumentohet dhe percaktohet sakte cka deshiron klienti
37
Takimet me klientin-Intervistat
Identifikimi I kerkesave arrihet nepermjet pyetjeve qe I behen paleve te interesuara. Intervistat me pyetjet e parapregaditura dhe Diskutimet e hapura ne takime te zgjeruara – Brainstorming Intervistuesit duhet “te dijne” te degjojne palet e interesuara. Intervistuesit duhet te jene ne gjendje te kuptojne kerkesen dhe te japin propozime te ndryshme dhe jo te presim pergjigje ne pyetjet “Qka deshiron” Gjithmone mbaj shenime
38
Skenaret
Skenaret jane shembuj real se si mund te perdoret sistemi. Nepermjet nje skenari pershkruhet nje interaksion i caktuar ne sistem. Skenaret duhet te pershkruajne
Nje pershkrim te gjendjes se fillimit; Nje pershkrim te rrjedhes normale te ngjarjeve; Nje pershkrim se cfare mund te shkoje keq; Nje pershkrim te gjendjes se skenarit ne fund;
39
Shembull Skenari
Skenari: Terheqja e mjeteve me Visa card Pershkrimi Nepermjet ketij skenari paraqitet interaksioni ne mes klientit dhe bankomatit. Klienti realizon terheqjen e mjeteve me nje kartele Visa Card; Terheqja realizohet pas verifikimit te karteles si dhe limitit ditor te lejuar per terheqje.
1. 2. 3. 4. 5. 6. 7.
40
Poseduesi i karteles VISA vendos kartelen ne lexuesin e karteles. ATM verifikon nese kartela e futur eshte VISA ATM kerkon nga poseduesi I karteles te jape numrin PIN. Poseduesi I karteles shtyp numrin PIN ATM kontrollon numrin e dhene PIN me ate qe eshte I ruajtur ne kartele. ATM kerkon nje autorizim nga sistemi qendror VISA per autorizim. Sistemi I autorizimit VISA konfirmon validitetin e karteles dhe njofton per limitin maksimal ditor te lejuar per terheqje
Shembull Skenari (vazhdim)
8. 9. 10. 11. 12. 13. 14. 15. 16.
ATM kerkon nga poseduesi I karteles shumen qe ai/ajo deshiron te terheqe Poseduesi I karteles zgjedh shumen qe deshiron te terheqe. ATM kontrollon vleren kundrejt shumes maksimale te lejuar ATM pyet poseduesin e karteles nese ai deshiron fature Poseduesi I karteles kerkon fature. ATM I kthen kartelen poseduesit Poseduesi I karteles merr kartelen ATM I jep parate e kerkuara dhe faturen Poseduesi merr parate dhe faturen
41
Modelimi i skenareve UML Use Case
Vetem pikat kryesore te detajuara me nje shembull
Why UML Use Case?
USE Case
Nje grup skenaresh te nderlidhura nga aktor dhe qellime te njejta. Nje pershkrim sekuencial i aksioneve qe performohen nga nje sistem per te prodhuar nje rezultat per nje aktor.
43
Use case pershkruajne sjelljen e pritur “WHAT” dhe jo metoden egzakte si behet “HOW” Use case krijohen bazuar ne kerkesat funksionale te identifikuara. Perdoren ne fazen fillestare per identifikimin e kerkesave
Use Case Diagrams
Use Case Actors Relationships Use Case Diagrams
44
Use Case (UC)
Definicioni
Use case pershkruan punen(task) qe nje perdorues mund te kryej duke perdorur sistemin
Pershkrimi
Pershkruan kerkesat e sistemit Nje pune e pershkruar nga UC perbehet nga aktivitetet (activities) UC mund te kete disa variacione qe quhen Skenare (scenarios) Nuk duhet te perdoren per te nxjerre funksionalitete nga UC
45
Hapi i pare
Identifiko aktoret Identifiko Use Case! UC me se lehte identifikohen duke percaktuar qka duhet te bejne aktoret Krijo listen e Use case, duke specifikuar edhe prioritetin
Use C ase UC-1 UC-2 De scription K ontrollo Bila ncin Nu k ka rrjet/siste m i nuk p uno n Priorit y: 2 Priorit y: 1
Shembull I use case list I gjeneruar nga CASE tool, Case Complete
46
Use case pershkrimet
Numri i UC Emri i Use Case Pershkrim i shkurter Parakushtet Kufizimet Paskushtet Pershkrimi i rrjedhes se sakte( success scenarios) Efektet Verejtje
47
48
Aktoret-Actors
Definicioni
Aktori eshte nje entitet I jashtem I cili eshte I perfshire ne bashkeveprim me sistemin e pershkruar ne UC
Pershkrimi
Aktoret=rolet Aktoret mund te jene edhe sisteme te jashtme
Simboli
Klienti
49
VISA Sistemi I Autorizimeve
Gjeneralizimi I aktoreve
Gjeneralizimi: Nenpunesi mund te kryeje gjithcka cka mund te kryeje nje nenpunes administrativ
Nenpunes
Nenpunes Adminsitrativ
Nenpunes operativ
50
Use Case Diagram
Definicioni
Tregon nderlidhjen ne mes disa use case-ve dhe aktoreve te involvuar me keto use case
Pershkrimi
Vegel per percaktimin e kerkesave UC diagrami pershkruan ato aktivitete te cilat duhet te suportohen gjate fazes se zhvillimit te software.
51
Use Case Diagram(2)
Simboli
Emri I Diagramit
UC 1 UC 2
Aktori 1
Aktori 2
UC 3
52
Shembull – Bankomati(ATM)
ATM ofron sherbimet e meposhtme:
1.
Ofron terheqjen e te hollave per te gjithe poseduesit e kartelave nepermejt lexuesit te karteles dhe makines automatike me monedhe
2. Raport per gjendjen e llogarise, keshit dhe sherbimit te deponimit ne bankomat per klientet e bankes qe posedojne nje kartele bankare. 3. Te gjitha transaksionet jane te procesuara
53
4. ATM duhet te rimbushet me monedha kohe pas kohe
Diagrami fillestar per ATM
54
Diagrami i permiresuar per ATM
55
Me shume Aktore
Nese poseduesi I karteles eshte VISA athere SA VISA duhet te kontaktohet Nese poseduesi I karteles eshte I bankes(qe I takon bankomati) athere SA bankes thirret
56
Relationship ne mes UC
<<Include>> UC baze perfshine funksionalitetet e “Included” Use case <<extend>> Nje UC e shtuar(extension) ne menyre opsionale e zgjeron sjelljen e nje UC tjeter(UC baze).
Relacioni <<extend>> tregon se inkorporimi I UC te zgjeruar varet se cfare ndodh kur UC baze ekzekutohet.
Gjeneralizimi: Sub UC trashegon sjelljen nga Super Use Case
Gjeneralizmi mund te perdoret ne mes aktoreve ose UC dhe jo ne mes nje aktori dhe UC
Included
UC <<Include>>
UC Baze
57
UC Baze
Super UC
<<extend>>
UC e zgjeruar
Gjeneralizimi
SUB UC
Shembull i nje INCLUDE Relationship
Te gjitha llojet e transaksioneve duhet te autorizohen
58
Shembull i nje <<EXTEND>> Relationship
uc Use Case Model
«extend» Verifiko Shumen
Nuk ka rrjet
……. 8. ATM kerkon nga poseduesi I karteles shumen qe ai/ajo deshiron te terheqe Extension Point: Nuk Ka rrjet/nuk punon sistemi 9. Poseduesi I karteles zgjedh shumen qe deshiron te terheqe. 10. ATM kontrollon vleren kundrejt shumes maksimale te lejuar ……
59
Shembull i nje Gjeneralizimi Relationship te UC
60
ATM, UCD i Zgjeruar
61
Ushtrim- “Drive Test”
Pershkrimi i problemit: Nje kompani e cila merret me shitjen e autoveturave iu jep mundesi klienteve qe te kene mundesine te provojne automjete qe jane te interesuar t’i blejne. Meqenese interesimi i klienteve eshte i madh kompanise iu eshte dashur qe tju kerkoje klienteve qe paraprakisht te bejne rezervimet. Perpara se te behet nje rezervim per ‘drive test’ klienti duhet te regjistrohet. Kompania nepermjet sistemit te saj dhe administratorit merret me te gjithe menaxhimin e automjeteve, si datat e lejimit per “drive test”, konfirmimin e rezervimit etj
62
Te plotesohet UC diagrami i meposhtemUshtrim ne Klase
63
Sistemi i Administrimit te kurseve
Student: update te dhenat personale, shef rezultatet e provimit, shfleton detajet mbi kurset, zgjedh kursin e preferuar Mesuesi: shfleton rezultatet e provimeve, update informacionin e kurseve, shfleton regjistrimet e bera Stafi admin: hedh rezultatet e provimeve, update te dhenat personale te studenteve, shfleton regjistrimet e bera per per kurse.
64
UCD per sistemin e admin. kurseve
65
Shmebull 1-POS
Keni shembulli e nje dyqani apo te nje pike te shitjes (point of sale –POS Terminal) . Nje pike shitje zakonisht ka nje kompjuter, barcode, peshore, printer, POS terminal qe eshte i lidhur me sistemin e procesimit te kartes se kreditit etj. Nje klient ben pagesen per mallrat e blere me kartele nepermjet POS terminalit. Identifikoni aktoret? Identifikoni Use case? Vizatoni nje Use Case Diagram? Pershkruani nje skenar sukesi?
66
Shembull 2: Online Shopping
Aktoret: Klienti Online, pay pal, credit autorizimi,serveri Use case: shfleto artikull, bej pagese, CHECKOUT, authentikimi I klientit, kalkulimi I takses dhe transporti, pagesa(kredit ose pagese pay pal) Vizatoni nje Use case diagram?
67
Intentionally left blank
68
Nga ora e kaluar….
Analiza e kerkesave te software Percaktimi i kerkesave dhe veshtersite qe hasen gjate percaktimit te tyre. Aktivitetet (identifikimi, klasifikimi, caktimi i prioriteteve..) Takimi me klientet(intervistat) Analiza e skenareve (use case) Use case Diagramet dhe shembuj Vazhdojme me analizen e kerkesave…
69
Tipet e Kerkesave
Kerkesat e Perdoruesve (user requirements) Deklarata ne gjuhen natyrale plus diagrame te sherbimeve qe ofron sistemi si dhe kufizimet operative. Shkruhen per konsumator. Kerkesat e Sistemit (system requirements) Nje dokument i strukturuar qe percakaton ne menyre te hollesishme pershkrimin e funksioneve te sistemit, sherbimet dhe kufizimet operacionale. Percakton se cfare duhet te implementohet dhe mund te jete pjese e kontrates ne mes klientit dhe kontraktorit
70
Definimi dhe Specifikimi
Definimi i kerkeses se perdoruesit (User Requirement Definition)
Nje Software i cili i mundeson klienteteve qe te nderrojne PIN te karteles ne ATM.
Specifikimi i kerkesave te sistemit ( System requirement specification)
1.1 Klienti duhet te jete klient i bankes qe posedon ATM 1.2 Klienti duhet te kete kartele valide 1.3 Klienti duhet te dije PIN e vjeter, para nderrimit te tij. 1.4 Pas ndryshim te Pin nuk lejohet transaksion tjeter pa u validuar PIN i ri. …………..
71
Klasifikimi I Kerkesave
Kerkesat Funksionale
Deklarata(statements) te sherbimeve qe duhet te ofroje sistemi. Si duhet te reagoje sistemi Si duhet te sillet sistemi ne situata te vecanta
Kerkesat jo-funksionale
Siguria dhe performanca Kufizimet e ndryshme te sherbimeve(p.sh kufizimi ne kohe) Standardet e ndryshme etj
Kerkesat e fushes (domain requirements)
Kalkulimi i tatimit ne rroge duhet te behet sipas rregullores XX te Administrates tatimore te Kosoves.
72
Kerkesat Funksionale
Kerkesat Funksionale pershkruajne funksionalitetin ose sherbimet e sistemit. Kerkesat Funksionale te perdoruesve jane kerkesa globale qe tregojne ne vija te trasha cfare duhet te beje sistemi. Kerkesat Funksionale te sistemit duhet te pershkruajne sherbimet dhe funksionet e sistemit ne detaje. Dokumentimi i kerkesave funksionale duhet me qene konsistent dhe i kompletuar.
73
Shembuj te kerkesave funksionale
Perdoruesi duhet te kete mundesi te kerkoje klientat ekzistues ne database. Sistemi nuk duhet te shfaqe detajet e klienteve qe jane te kategorizuar si VIP (perveq emrit). Ç’do porosi duhet te identifikohet me Porosia_Id, nepermjet se ciles perdoruesi mund te kontrolloje statusin e porosise.
74
Kerkesat Jo-funksionale
Kerkesat Jo-funksionale zakonisht nuk varen nga perdoruesi. Perdoren per te definuar kufizimet dhe vetite (properties) e sistemit p.sh besueshmeria, cilesia, pergjigja ne kohe, IO devices etj. Mund te jene kufizime si percaktimi i gjuhes se programimit dhe CASE metodave. Kerkesat jo-funksionale mund te jene me kritike se ato funksionale.
75
Kerkesat Jo-Funksionale
76
Klasifikimi i kerkesave Jofunksionale
Kerkesat e Produktit
Kerkese e cila specifikon qe produkti i kryer duhet te sillet ne nje menyre te caktuar p.sh koha e ekzekutimit, besueshmeria etj
Kerkesat organizative
Kerkesa qe dalin si rezultat i politikave dhe procedurave organizative p.sh standardet e proceseve qe perdoren, implementimi i kerkesave etj
Kerkesat e jashtme
Kerkesa qe dalin si rezultat I faktoreve te jashtem. P.sh Nderveprimi(interoperability), kerkesat legjislative, etike etj
77
Shembuj kerkesash jofunksionale
Kerkesat e produktit
Interface duhet te implementohet me HTML te thjeshte, pa frames dhe Java applets.
Kerkesat organizative
Sistemi dhe dokumentimi i tij duhet te jete konform standardit ISO XXX
Kerkesat e jashtme
Sistemi nuk duhet te lejoje asnje rrjedhje te inormacionit personal te klienteve, perveq emrit dhe numrit te references.
78
Kerkesat e Sistemit
Kane per qellim te jene nje baze per dizajnimin e sistemit (software design) Mund te inkorporohen ne kontraten e sistemit, Mund te ilustrohen apo definohet duket perdorur modelet e sistemit (Use case, Data flow digrams, activity diagram etj)
79
Kerkesat dhe Dizajni
Kerkesat – Ç’ka duhet te beje sistemi Dizajni – Si duhet te realizohet(behet) kerkesa. Ne praktike Kerkesa dhe Dizajni jane zakonisht te pandara.
80
Specifikacioni i Nderfaqesit ( Interface Specification)
Shumica e sistemeve duhet te operojne me sisteme te tjere, specifikacioni i nderfaqesit duhet te jete gjithashtu pjese e kerkesave.
Nderfaqesit procedural; Struktura e te dhenave qe shkembehet; Riprezantimi i te dhenave
81
Dokumenti i kerkesave te perdoruesit
82
Struktura e dokumentit te Kerkesave
Hyrje Fjalori(Glossary) Definimi I kerkesave te perdoruesit Arkitektura e sistemit Specifikacioni I kerkesave te sistemit Modeli I sistemit Evoluimi I Sitemit Anekset (Appendices) Shikoni shembullin e SRS ne word.
83
Intentionally left blank
84
Modelimi i Procesit
Ç’ka eshte nje model i procesit softuerik? Eshte nej prezantim i thjeshtesuar (apstrakt) i nje procesi softuerik. Nje menyre formale prezantimi si operon biznesi.
Data flow diagramet perdoren per te treguar proceset e biznesit dhe te dhenat qe kalojne ne mes tyre.(proceseve) Meqenese data flow diagramet tregojne levizjen e te dhenave ne mes proceseve, keta diagram quhen zakonisht “Process model”.
85
Physical vs Logical Model
Modelet logjike te proceseve pershkrujne proceset pa treguar se si ato kryhen Modelete Fizike (physical model) perfshijne edhe informacione si implementohet nje proces.
86
Data Flow Diagrams
Process
Data Store
Source/Sink or External
Data Flow De Marco & Yurdon
87
Gain & Sarson
Context Diagram
Nje pamje gjenerale e nje Sistemi. Tregon procesin e pergjithshem te biznesit vetem si nje proces i vetem Qellimi i nje sistemi organizativ qe tregon kufijte e sistemit, entitetet e jashtme qe nderveprojne me sistemin dhe te dhenat kryesore qe shkembejne
88
Context diagram Order system
89
DFD Rregullat- Context Diagram
Vetem nje process, me numer 0. Entitetet e jashtme te vizatuara ne forme drejtekendeshi Vetem rrjedha e te dhenave kryesore. Data store nuk shfaqen ne kete faze
90
Level 0(zerro) DFD
Tregon te gjitha proceset kryesore qe e perbejne sistemin. Tregon si rrjedh informacioni(te dhenat) ne mes proceseve. Shtohen ne diagram “data stores” Kur zgjerohet context diagrami ne DFD level-0, te gjitha lidhjet qe hyne dhe dalin duhet te ruhen (Balancimi)
91
Level 1 -DFD
Tregon te gjitha proceset qe perbejne nje proces te vetem ne diagramin e nivelit 0. Sherben per te treguar ne detaje permbajtjen e procesit te nje niveli me te larte. Diagrami i nevelit 1, mund te mos duhet per te gjitha proceset e nivelit 0
92
Order CUSTOMER 1.0
Picking List WAREHOUSE
Order Reject Notice
Fill Order
Level-0 DFD Order system
Payment
Invoice 2.0 Completed Order
Invoice Accounts Receivable
Create Invoice
D1
Payment Detail
Invoice Detail
3.0
Apply Payment Commission Bank Deposit Cash Receipts Entry
93
SALES REP
BANK
ACCOUNTING
Dekompozimi dhe Balancimi
Dekompozimi
Nje process iterativ i ndarjes se pershkrimit te sistemit ne detaje me te vogla. Niveli me i ulet quhet DFD primitive.
Balancimi
Gjate dekompozimit te DFD nga nje nivel ne tjetrin duhet te ruhen “hyrjet ne” dhe “daljet nga” nje proces Sigurohuni qe numri i hyrjeve/daljeve te rrjedhes se te dhenave eshte i njejte gjate kalimit nga nje nivel dekompozimi ne tjetrin
94
Shembull balancimi
Shembull: Hoosier Burgers
Ne figuren 1, vini re se eshte vetem nje “input” ne sistem (customer order) Tre outpute: Customer receipt, Food order dhe Management reports
95
Figure 1, Context diagram of Hoosier Burger’s Food ordering, Marre nga libri “Modern System analysis and design”, jeffrey a.Hoffer
Vini re: Kemi te njejtat hyrje dhe dalje me diagramin e meparshem. Mund te themi se context diagrami dhe DFD niveli-0 jane te balancuar. 96
Krijimi i Data flow diagrameve
1. 2. 3. 4. 5. 6. 7.
Hapat gjeneral Krijo “context” diagramin preliminar Identifiko use cases, p.sh menyrat se si predoruesit e perdorin sistemin Krijo DFD fragmente per cdo Use case Krijo Level 0 diagramin nga fragmentet. Dekompozo ne Level 1,2.. Kthehu ne hapin e pare dhe rishiko per gabime. Valido DFD me perdoruesit
97
DFD- Rregullat
Te pergjitheshme:
Hyrjet ne nje process duhet te jene te ndryshme nga daljet e atij procesi Te gjitha Objektet ne DFD duhet te kene emra unik
Process:
Nje proces nuk mund te kete vetem dalje. Asnje proces nuk mund te kete vetem hyrje Proceset duhet te emrohen me folje
Data store:
Te dhenat nuk mund te rrjedhin nga nje data store ne tjeter Te dhenat nuk mund te rrjedhin nga nje entitet I jashtem ne data store Data store emerohen me emra
External Entities:
Te dhenat nuk mund te rrjedhin me mes dy entiteteve te jashtme Entitetet e jashtme emerohen me emra
Data flow:
E njejta Rrjedhe e te dhenave nuk mund te kthehet ne te njejtin proces Data flow duhet te emerohen me emra.
98
DF-Gabimet e Zakonshme
a b
a Duhet nje proces qe te kete kalim te dhenash ne mes dy entiteteve te jashtme
b
a
DataStore1
a
Duhet nje proces per te updatuar apo perdorur nje Data Store
DataStore1
DataStore2
DataStore3
DataStore2
Duhet nje proces per te levizur te dhenat nga nje Datastore ne Tjetren
DataStore3
99
Shembull 1:
Kur klienti ben nje porosi nepermjet website, sistemi kontrollon nese artikulli eshte ne stok, njofton klientin me statusin e artikullit dhe gjeneron kerkesen per porosi ne magazine e cila mbush porosine. Kur porosia eshte derguar(nisur) klienti faturohet. Sistemi gjithastu prodhon raporte te ndryshme si raporte te inventarit per kontabilitet.
1. 2.
VIzato nje context diagram per kete sistem porosie nepermjet website Vizato DFD-0 per te njejtin sistem.
100
Context diagrami
101
DFD level 0
102
Ushtrim 2: ATM- Context Diagrami
T astiera
D.SH. Te ndertohet DFD Niveli 0
komandat nga klienti
dhensi i parave
para ne cash Te dhenat e karteles Lexuaesi i Karteles ATM Sistemi fatura e klientit ATM Printer
menu/mesazhe
103
ATM Screen
Ushtrime ne Laborator
1.
Ne EA, te vizatohet shembulli 1 i sistemit te porosive. Te ndertohet nje DFD, nepermjet te cilit paraqitet aplikimi per pune ne nje organizate per nje pozite te caktuar. Sistemi njofton aplikantin mbi pranimin e dokumenteve. Aplikanti i pranuar regjistrohet ne Payroll pas evaluimit te te gjitha aplikanteve. Detajet mbi poziten merren nga menaxheri, te cilit i nevoitet punetori.
104
2.
Intentionally left blank
105
Procesi Softuerik
Cilat ishin aktivitetet kryesore te nje procesi softuerik?
Specifikacioni i softuare; Dizajni dhe implementimi; Validimi i software; Evoluimi i software (Evolution)
106
DESIGN
Pas perfundimit te analizes se kerkesave/specifikacionit duhet te percaktojme si keto kerkesa duhet te implementohen - Design.
107
Temat qe do te mbulohen
Software Architecture Design. Application architectures. Object-Oriented Analysis (OOA) Object-Oriented Design (OOD)
Static OOD Dynamic OOD
User Interface Design
108
Pse na duhet Dizajni
Tashme i kemi kerkesat/specifikacionin Kerkesat jane ne forme shume Abstrakte per ndertimin e kodit… Na duhen detajet per: Menyren si pjeset e nje sistemi bashkohen (“Architecture”) Si grupohen funksionet/te dhenat (“System structure”) Si reprezantohen te dhenat (“data structure”) Si procesohen te dhenat (“Algorithms”) Si do te perdoren API (“services”) Si do ta perdorin perdoruesit sistemin (“user interface”) Si do te bashkeveproje sistemi me te tjeret(system interface)
109
Software Architecture
C’ka duhet te konsiderojme: Programet dhe proceset te cilat e perbejne sistemin. PC/Servers ku programet ekzekutohen(lloji, app. existuese, sistemet operative etj) Networking Ku do te ruhen te dhenat, si do te aksesohen/transferohen Arkitekura e centralizuar apo decentralizuar. Kualiteti i sherbimit, performanca, siguria etj Rezultati I procesit te dizajnit eshte: Pershkrimi i arkitektures se software Client Server Architecure eshte arkitektura e software me e perdorur.
110
Arkitektura Client-Server
Zakonisht ndahet ne 3 nivele (3 tiers)
Interface (nje pjese ne client nje pjese ne server) Processing (pak klient, shumica ne server) Data storage (zakonisht vetem server)
Menyra te ndryshme per te ndare te dhenat/funkisonet. P.sh. E-commerce Website tipik (browser + http server + Database Server). Thin & Thick Clients. Disa modele client-server
Multiple server, single server, decentralized/centrelized systems etj 111
“Thin” Clients
Procesimi ne ‘client side’ eshte shume i limituar Puna me e madhe kryhet ne server, perfshi ketu edhe nje pjese te formatimit te UI (p.sh JSP, ASP) Ndonjehere ka nevoje per bandwidth me te larte ne rrjet. Shembuj: Web browser, telnet
112
“Thick” Client
UI dhe nje pjese e procesimit behet ne “Client side”. Nje pjese e procesimit kryhet ne server. I pershtatshme per volum te vogel ne rrjet (bandwidth te vogel) Shembuj:java applets, ATM machine, virtual environment client.
113
Dizajni i Arkitektures
Identifikimi i programeve/proceseve qe nevojiten. Identifiko pjesen hardwerike (PC,server, networking etj). Percakto cili program exekutohet ne cilen makine. Kontrollo nese arkitektura suporton kerkesat jofunksionale dhe ato funksionale.
Keni kerkese jofunksionale si me poshte:
• koha e regjistrimit transaksioni <=2 sec • koha e maximale e gjenerimit te nje raporti eshte 10 sec. (si te behet validimi/kontrollimi?)
114
Video Library System UML deployment diagram
115
Application Architecture
Data processing Application
Applikacione qe procesojne te dhenat ne grup( in batches), ndonjehere edhe pa nderhyrjen e perdoruesit.
Transaction processing application
“Data centered application” qe procesojne kerkesat e perdoruesve dhe update-ojne informacionin ne DB te sistemit.
Event processing application
Aplikacione ku aktivitetet e sistemin varen nga interpretimi i ngjarjeve qe vijne nga mjedisi i sistemit.
116
Tipet e applikacioneve – shembuj
Data processing systems Sistemi i faturimit; Sistemi i rrogave. Transaction processing systems E-commerce systems; Sistemi i rezervimeve; Sistemi i financave(kontabiliteti) Event processing systems Word processors; Real-time systems;
117
Input/output Data processing
118
Transaction processing system
119
Object-Oriented
Object Oriented Analysis OOA Object Oriented Design-OOD Object Oriented Programming –OOP OOA, OOD dhe OOP jane te nderlidhura me njera tjetren por ndryshojne.
120
Object Oriented Analysis
Modelimi i kerkesave ne kuptimin e objekteve dhe sherbimeve qe ato ofrojne OOA eshte (pretendon te jete) me ‘natyral’
Me evoluimin e sistemit, funksionet (proceset) kane tendence te ndryshojne ndersa Objektet kane tendence te mbeten te pandryshuar. Modeli i strukturuar i analizes (DFD) do te dale jashte perdorimit, ndersa OO model JO
Ne OOA theksohet rendesia e mire definuar e lidhjes se objekteve (ku ne DFD kemi mungese te ketij informacioni)
121
Object Oriented Design
Objected jane nje forme abstrakte e jetes se perditshme ose entitete te sistemit.(p.sh person,student, karrige etj) Objektet jane te pavaruara dhe perfaqesojne nje instance te prezantimit te informacionit Funksionaliteti i sistemit shprehet ne termin sherbimet e objektit (Object services) Objektet komunikojne nepermjet te mesazheve Objektet mund te jene te distribuara dhe mund te egzekutohen ne menyre sekuenciale apo paralele
122
OO Design
Pse behet dizajn i Software?
Pse dizajnohet projekti i nje ndertese para se ajo te ndertohet? Cka eshte OO Design?
OO design eshte nje nga metodologjite me te perdorura per software dizajn!?! (pretendohet) Ne OOD fillohet me analizimin e entiteteve te botes reale qe ekzistojne. Pastaj shtohen atributet dhe sjellja per cdo entitet.
Hapat kryesor ne OO Design
Shpreh entitetet ne Klasa dhe objekte Bej lidhjen e klasave Analizo te gjitha veprimet qe nje objekt mund te kryeje me nje objekt tjeter
123
Cka eshte nje Object?
Nje objekt eshte nje entitet qe ka gjendje (state), atribute dhe funksionalitete(services)
P.sh Nje person ka emer dhe numer personal
Atributet ruhen ne variabla Funksionaliteti ruhet ne metoda
Attributes
class System
PERSON # + + # Adressa: char Emri: T EXT Nr_perosnal: int han() : boolean vrapon() : float
Functionality (method)
124
Classes (Klasat)
Nje pershkrim i nje Objekti quhet Class Person eshte nje class e cila mund te kete atributet
Emri Adresa
class System
Dhe mund te kete funksionalitet
Vrapon Ha (ushqim)
# + + #
PERSON Adressa: char Emri: T EXT Nr_perosnal: int han() : boolean vrapon() : float
Ne slide paraprak ne tham qe Person eshte Object?????
Objekti eshte nje instance e nje klase
125
Identifikimi i Objekteve
Pjesa me e veshtire gjate dizajnit OO eshte identifikimi i objekteve Nuk ka nje “formule magjike” per identifikimin e Objekteve. Ajo mbeshtetet ne aftesi dhe eksperience si dhe ekperiencen e fushes nga dizajneret e sistemit. Identifikimi i Objekteve eshte nje proces iterativ.
126
Qasjet ne identifikimin e objekteve
Perdor metoden gramatikore te gjuhes natyrale te pershkrimit te problemit.
Emrat Foljet Objekte Metoda
Bazo identifikimin ne gjerat e prekshme ne “application domain”. Perdor qasjen “sjellje” (cka ben) per te identifikuar objektet bazuar ne sjellje. Perdor analizen e bazuar ne skenare. Objektet, atributet dhe metodat ne cdo skenar identifikohen.
127
Weather station description
weather station is a package of software controlled instruments which collects data, performs some data processing and transmits this data for further processing. The instruments include air and ground thermometers, an anemometer, a wind vane, a barometer and a rain gauge. Data is collected periodically. When a command is issued to transmit the weather data, the weather station processes and summarises the collected data. The summarised data is transmitted to the mapping computer when a request is received.
128
Weather station-USE Case
Lexo me shume ne liber fq. 324 Pershkrimin e plote dhe skenaret
129
Objektet klasa
130
Per te mbajtur mend…
Ç’ka eshte nje objekt? Ç’ka eshte nje klase? Differenca ne mes klases dhe Objektit Ç’ka eshte OOA, OOD.
131
Class Diagrams
Diagrami i Klasave pershkruan tipet e objekteve ne sistem dhe lloje te ndryshme te lidhjeve statike (static relationship) ne mes tyre. Permbledhje
Perspectives: Conceptual, Specification, Implementation Attributes, Operations and Methods. Associations, Navigability, Aggregation, Composition, Association Classes. Generalization, Interfaces, Abstract Classes
132
133
Nga Use cases ne Class Diagram
u c U s e C a s e V ie w P o r o s ia
K lie n ti p o r o s ia N e ke m i kl i e n te q e p o ro si si n p ro d u kte t to n a . N e i d a l l o j m e kl i e n te t fi rm a n g a kl i e n te t p ri va t, se p se fi rm a t p a g u a j n e n j e h e re n e m u a j n d e rsa kl i e n te t p ri va t d u h e t te p a ra p a g u a j n e p o ro si te . N e d e sh i ro j m e q e p o ro si te te ra d h i te n si p a s p ro d u kte v e C d o l i n j e d u h e t te ke te sa si n e d h e cm i m i n p e r cd o p ro d u kt.
134
Shembull: Porosia -Association
class Class M odel P orosia * 1 Klienti
Association
u c U s e C a s e V ie w
Multiplicity
p o r o s ia N e k e m i k l i e n te q e p o r o s i s i n p r o d u k te t to n a . • N e i d a l l o j m e kl i e n t e t f i rm a n g a kl i e n t e t p ri v a t , se p se f i rm a t p a g u a j n e n j e h e re n e m u a j n d e rsa kl i e n t e t p ri v a t d u h e t t e p a ra p a g u a j n e p o ro si t e . N e d e sh i ro j m e q e p o ro si t e t e ra d h i t e n si p a s p ro d u kt e v e C d o l i n j e d u h e t t e ke t e sa si n e d h e c m i m i n p e r c d o p ro d u kt .
135
Shembull:Porosia-Generalization
c la s s C la s s M o d e l P o ro s i a * 1 K lie n ti
Generalization
K li e n t F I R M K lie n t P ri v a t
u c U s e C a s e V ie w
p o ro s ia N e ke m i kl i e n te q e p o ro si si n p ro d u kt e t to n a . N e i d a llo j m e k l ie n te t fir m a n g a k li e n te t p riv a t, s e p s e fi rm a t p a g u a j n e n j e h e re n e m u a j n d e rs a k lie n te t p r iv a t d u h e t te p a ra p a g u a j n e p o r o s i te . N e d e sh i ro j m e q e p o ro si t e te ra d h i te n si p a s p ro d u kte v e C d o l i n j e d u h e t te ke t e sa si n e d h e c m i m i n p e r c d o p ro d u kt.
136
More association
Porosia Klienti
*
1
1
*
Linj a e porosiv e Produkt Klient FIRM Klient Priv at
*
1
p o ro s ia N e ke m i kl i e n t e q e p o ro si si n p ro d u kt e t t o n a . N e i d a l l o j m e kl i e n t e t f i rm a n g a kl i e n t e t p ri v a t , se p se f i rm a t p a g u a j n e n j e h e re n e m u a j n d e rsa kl i e n t e t p ri v a t d u h e t t e p a ra p a g u a j n e p o ro si t e . N e d e s h i r o j m e q e p o r o s i te te r a d h i te n s i p a s p r o d u k te v e C d o l i n j e d u h e t te k e te s a s i n e d h e c m i m i n p e r c d o p r o d u k t.
137
Porosia–Attributes & Operations
Porosia + + Cmimi: Currency Data e pranimit EshtePpregaditur number: String Close() Dergoj() + Klienti Adresa Emri Klasifikimi_kredise()
Attributes
Operations
porosia Ne kemi kliente qe porosisin produktet tona. Ne i dallojme klientet firma nga klientet privat, sepse firmat paguajne njehere ne muaj ndersa klientet privat duhet te parapaguajne porosite me credit card Ne deshirojme qe porosite te radhiten sipas produkteve 138 Cdo linje duhet te kete sasine dhe cmimin per cdo produkt.
Porosia-DIagrami i klases
«Pre-condition» {Nese Porosia.klienti.kalsifikimi_kredise eshte i "KEQ" atehehere Porosia.Eshte_parapaguar duhet te jete "TRUE"} Porosia Cmimi: Currency Data e pranimit EshteParapaguarr number: String Klienti Adresa Emri
*
1
+ Klasifikimi_kredise() + Close() + Dergoj() 1 * Linja e porosive Cmimi: float * Sasia: int 1 Produkt Klient FIRM Klasifikimi_kredise: int Kontak_Person: char Limiti_kredise: int Klient Privat Credit_card: int
+ Fatura_muajit() : int
139
Perspektivat
Jane tre perspektiva qe mund t’i perdorni gjate vizatimit te Class Diagrams; Conceptual
Ne menyre konceptuale paraqitet klasa. Ofron gjuhe indipendente te implementimit
Specification
Reprezanton interface te software Implementimi eshte I fshehur
Implementation
Klasat reale te perdorura ne gjuhe programimi Lidhet direkt me implementimin
140
Class - Vizibiliteti
+ public, mund te shifet nga cdo
klase tjeter
Porosia + + # Cmimi: Currency Data e pranimit EshteParapaguarr /number: String TEST: Boolean
# protected, mund te shifet
vetem nga nen-clasat
- private, shifet vetem nga kjo
klase
+ Close() + Dergoj() + test() : Integer
141
Relacionet ne mes Klasave
Association Aggregation Composition Association Classes Generalization
142
Associations
Associations reprezentojne lidhjen ne mes instancave te klasave. C’do Asociacion ka dy role qe mund te emerohen. Multipliciteti: 1; *;2..4; 2,4;24
Personi * +Punesohet +Puneson 1 Kompania
Roli
143
Associations-Navigability
Asociacionet binare
Te dy klasat e njofin njera tjetren
Personi * +Punesohet +Puneson 1 Kompania
Asociacionet unare
Klienti nuk mund te tregoje cfare porosie ka bere
Porosia * 1 Klienti
144
Aggregation
Agregation eshte PJES E (part of) Relacionit.
P.sh. “Regjioni eshte pjese e shtetit” A eshte nje kompani aggregation per punetoret e vet apo eshte nje asociacion ne mes punetoreve te tij?
S h te ti R e g j io n i
D ye rt
A u to m j e ti
Specifikohet me nje diamant te zbrazet nga ana e pjeses permbajtese
D r i ta r e t
145
Composition
Kompozicioni eshte nje version me i forte i agregacionit Klasa perberese varet nga klasa permbajtese. Nese vdes klasa permbajtese vdes edhe klasa perberese.
S h te p i a Dhom a
Specifikohet me nje diamant te ZI nga ana e pjeses permbajtese
146
K lie n ti
L L og a ria
Association Classes
Penetoret punesohen nga kompania per nje periudhe te caktuar. Pyetje: Atributi Periudhe ne cilen klase vendoset. Associtions classes ju lejojne te modeloni asociacionet me klasa.
P e rs oni * 1 Kom pa nia
P una + P e ri u d h a : i n t
147
Generalization
Inheritance/Trashigimia Superklasa -Gjerat e perbashketa qe kane disa klasa. Sub klasa – diferencat ndahen ne nenklasa
Klienti + Adresa Emri Klasifikimi_kredise()
Super klasa
Klient FIRM + Klasifikimi_kredise: int Kontak_Person: char Limiti_kredise: int Fatura_muajit() : int -
Klient Priv at Credit_card: int
Nen Klasat
148
UML Class diagram
Multiplicity Customer Class
1
Simple Aggregation
Abstract Class Rental Item
Rental Invoice
1..* 1
Composition
0..1
Simple Association
Generalization
DVD Movie
VHS Movie
Video Game
Checkout Screen
149
Source: University of Washington
Ushtrime
Nga ciftet e meposhtme dallo klasen nga objekti i nje klase? Superhero, superman klas: superhero, objekt: superman Hashim, Person Gazete, Koha Bajram, Feste
150
1. 2.
3.
4.
Ushtrim 2
Listo disa atribute dhe operacione te cilat mund te definohen per klasen e quajtur “Takim” qe reprezanton nje takim biznesi? Atributet: data, koha,lokacioni,qellimi Operacionet: cakto, cancel, “setters & getters” per cdo atribut{p.sh set_time(), get time() }
151
Ushtrim 3
Nje kompani ka departamente. Departamentet mund te gjenden ne nje ose disa zyra te kompanise(lokacione). Nje zyre luan rolin e zyres Qendrore. C’do departament ka menaxherin e vet i cili njekohesisht eshte edhe punetor. Detyra juaj eshte te ndertoni nje diagram klasave duke perfshire te gjithe elementet qe ju duhen.
152
Kompania + + Em ri: char Get_nam e() : void set_nam e() : void
Departamenti + + +m enaxhohet nga Em ri _Dep: stri ng get() : void set() : voi d 1 1 +gjindet ne * +i takon * -
ZYRA Adresa: i nt
+M enaxhon
1 Punetori + +
1..*
Zyra Qendrore
Em ri: stri ng T itulli : char get() : voi d set() : void
153
Ushtrim 4
Movie Shop
Te dizajnohet nje diagram klase per sistemin "movie shop" nepermejt te cilit perdoruesit mund te bejne porosine e filmave ne dyqan, te kerkoje/shfletoje ne katalogun e dyqanit dhe te anetarsohen/regjistrohen. Cdo anetar qe regjistrohet merr edhe karten e tij rimbushese. Vetem anetaret e regjistruar lejohen te marrin filma me qera me karten e tyre. Vlera ne karte update-ohet gjate qiramarrjes se filmave. Filmat mund te blihen nga perdoruesit dhe anetaret. Filmat porositen edhe kur nuk jane ne ne dispozicion.
154
Perdoruesi Emri : char Mbiemri: char Ben 1 1..* + + -
Porosia Data: int Titulli: char * Get_credit() : void Set_Credit() : void 1 1 Behet 1 SHOP Emri_Dyqanit: int
+ Anetaresohu() : void
leshohet Shfleton Anetari zoteron + C'antaresohu() : void 1 1 + + get() : void set() : void CARD number: int * Filmi *
1..* Kataogu total_filma: int
1..
0..1
Titulli: int
FIlm Qera Cmimi: int Gjendja: byte I_Kthyer() : void I_marre_me Qera() : void
Blej FILM - Cmimi: int + gjendja: int + Blej() : void + Porosit() : void
155
Merr me qera 0..* + +
Ushtrim 5
Te krijohet nje diagram i klases i thjeshtesuar per regjistrin e klaseve shkollore. (pa atribute dhe metoda) Çdo klas e shkolles perbehet prej jo me shume se 25 studenteve. Ç’do klase ka kujdestarin e klases qe eshte njeri prej mesuesve. Gjithashtu ç’do klase ka nje nxenes kryesor qe perfaqeson klasen- kryetari i klases. E gjithe klasa meson lendet e njejta(brenda kohes se caktuar te javes) perveq gjuheve te huaja(disa mesojne frengjisht, disa anglisht) Mesuesi mund te mbaje disa lende. Nxenesi gjate semestrit merr note parciale dhe note finale nga cdo lende, per me teper nxenesi notohet edhe per sjelllje.
156
Klasa 0..*
kryetari i klases 1 1..25 -
Nxenes Emri: string Mbiemri: string
1
Merr note Nota 0..*
0..*
0..* mesojne 1..* Lendet lenda: string ore_ne_jave: string 1..* 1 0..1 mesojne Grupet e Gjueve
Kujdestar klase
nota per lenden
Nota per sjellj en
1 Mesuesi
0..* 1 1 Gjuet e Huaja Nota Parciale Nota Finale
157
Detyre Shtepie 6
Nga Diagrami i Klases ne slide-in Pasues (“Universe of Discourse: UNN Information System (UNN-IS)”) te pershkruhet Problemi i kerkesave duke lexuar diagramin.
158
Class Diagram
159
Ref: Advanced Database (CM036) –Lecture, Object Oriented Database(I)
Intentionally left Blank
160
ERD
Entity relationship Diagram
161
Entity Relationship Diagram ERD
Introduction Dizajnimi Konceptual I DB Cka eshte ERD? Chen and crow’s foot simbolet Entity, relationships,attributes Identifikuesit, kardinaliteti Lidhjet binare 1:M, 1:1,M:N te ilustruara me shembuj Modality – Optional Vs Mandatory Detyre shtepie
Cka eshte dizajnim konceptual bazes se te dhenave?
Process I pershkrimit te te dhenave, lidhjeve ne mes te dhenave dhe ‘konstraints’(kufizimet) qe kane te dhenat. Pas analizes- Merr te gjitha informacionet e detajuara dhe mundohu te kuptosh si jane te lidhura te dhenat Fokusi duhet te jete ne te dhenat dhe jo ne proceset. Rezultati i nje dizajnimi konceptual te nje DB eshte ‘Conceptual Data Model’
163
Mbledhja e informacionit per modelim konceptual te te dhenave
Dy perspektiva
Top-down (Nga larte-poshte)
• Modeli perfitohet nga nje njohje e thelle dhe e detajuar e biznesit.
Bottom-up (Nga poshte-larte)
• Modeli perftohet duke rishikuar specifikacionet e biznesit dhe dokumentet.(p.sh duke shikuar Indexin si dokument modelojme nje entitet INDEX me te gjitha detajet qe ka indexi)
164
Entity-Relationship (ER) Modeling
ER Modeling eshte nje qasje nga larte-poshte ne dizajnimin e database. Entity Relationship (ER) Diagram
Prezantim I detajuar logjik i entiteve, lidhjeve dhe te dhenave te krijuara, ruajtura dhe te perdoruara nga nje organizate apo biznes. Entitetet zakonisht pasqyrojne te dhena te ngjajshme te informacionit. P.sh Entitetit student(ID, emer, mbiemer,ditelindje..)
Tre konsrtuktet kryesore te nje ERD Diagram
Entitiy Relationships Attributes
Perdoren disa lloje simbolesh per ER modeling
Chen Model Crow’s Foot Model Information Enginering(IE) Etj
165
Chen Notation
Lidhja ne mes instancave te nje apo me shume entiteteve
Emri Entitetit
Shprehje foljore qe tregon lidhjen
Emri Atributit
Person, vend, objekt, ngjarje per te cilat te dhenat duhet te mirembahen
Pasqyron nje grup objektesh ne boten reale qe ndajne karakteristikat e njejta 166
Emri I Atributit ose karakteristikat e nje entiteti
Crow’s Foot Notation
Entity Entity
Attribute Attribute
Relationship Relationship
Emri Entitetit
Emri entitetit Lista e atributeve
Shprehje foljore qe tregon lidhjen ne mes entiteve
Fakulteti
dega Emri fak Adresa tel …
Student
ID Emer Mbiemer Ditelinja … 167
Ndjek/ Regjistron
Entity
Person, vend apo ngjarje per te cilat duhet te ruhen te dhenat. Shembuj entitetesh:
Person: PUNETOR, STUDENT, PACIENT Vend: DYQAN, MAGAZINE Objekt: MAKINE, PRODUKT, AUTOMJET Ngjarje: SHITJE,REGJISTRIM, NDRYSHIM Koncept: LLOGARI, DREJTIM FAKULTETI
‘Must be multiple occurrences’
Nese nje firme ka vetem nje magazine a eshte magazina Entitet? Mjeku duhet te ekziston ne menyre qe te caktohet nje termin.
168
Attributes
Informacioni qe ruhet per nje entitet Shembull i atributeve te nje intiteti:
STUDENT: Student_ID, Student_Name, Home_Address, Phone_Number
169
Identifiers-Identifikuesit
Nje ose me shume atribute mund te sherbejne si identifikues te nje Entiteti.
Shembull: studenti mund te identifikohet nga student_ID. Gjithashtu studenti mund te identifikohej nga kombinimi i emrit dhe mbiemrit. Candidate key
Nje Identifikues mund te jete “artificial’, siq eshte krijimi i ID number.
170
Relationships
Relacioni apo lidhja ne mes entiteteve Entiteti i pare ne Lidhje eshte parent entity; entiteti i dyte ne Lidhje quhet child entity Lidhjet duhet te emrohen me emra foljor(active verb names) Lidhja eshte gjithmone e dyanshme
171
Shembull
Shenim: Autor dhe Liber jane EMRA(noun)
Emri Relacionit: Shkruan/shkruhet
Shkruan eshte folje(verb)
Autori
Libri
Nje autor Shkruan nje ose me shume libra Nje liber mund te shkruhet nga nje ose me shume autor
172
Cardinality
Kardinaliteti Numri minimal apo maksimal i instancave te nje entiteti A qe mund te lidhet me cdo instance te entitetit B.
• one – to – one (1:1) • one – to – many(1:M) • many – to –many(M:N)
173
Modality-Optionality
Modality Specifikon nese nje instance duhet te egzistoje apo mund te mungoje ne nje lidhje te entiteteve NOT NULL (mandatory) Optionality NULL (optional)
174
Cardinality
Shembull Cardinality(1)
Profesor ligjeron Lenda
Profesor
ligjeron
Lenda
Profesori Ligjeron lenden OSE Lenda Ligjerohet nga Profesori
Sa? Sa lende? Sa Sa? Sa lende? Sa profesor? profesor?
175
Shembull Cardinality(1)
ligjeron Profesor Lenda
(1,1)
(1,4)
Cardinality
176
Simbolet ne Lidhje
Chen Model simbolet
1 pasqyron one. M pasqyron many
1 M
Crow’s Foot simbolet
One many One or many Zero or many
177
Mandatory one , nenkupton (1,1)
Lidhja Binare(1:M)
Piktor Pikturon Piktur
One to many :Relacioni One to many ne mes Piktorit dhe piktures
178
Lidhja Binare(1:1)
Nje instance e vetme ne nje entitet eshte e lidhur me vetem nje instance te nje entiteti tjeter Ka indikacione qe te dy entitetet mund te shkrihen (jo gjithmone) Ndodh shume rralle ne nje ER model
Professor Udheheq Department
179
Lidhja ne mes profesorit dhe departamentit
180
Lidhja Binare(M:N)
Kur nje instance e nje entitetit lidhet me shume instanca te entitetit tjeter dhe anasjelltas. Duhet te ‘shmangen’ keto lloj lidhje sepse cojne ne te dhena te teperta (data redundancy ) M:N lidhja nuk mund te perkthehet ne menyre direkte ne DB relacionale. Mund te implementohet duke shkeputur lidhjen M:N ne dy lidhje 1:M Bridge Entity
• • Perdoret per te lidhur entitetet(tabelat) qe jane ne lidhje M:N Struktura Bridge entity perfshin TE PAKTEN identifikuesit (PK) te entiteteve qe lidhen nepermjet bridge entity.
181
Ndjek/ndiqet Student Lenda
M:N Lidhja ne mes Studentit dhe lendeve Hashim Soft Engineering Programim ne WWW Analize Funksionale
Luan
182
Implementim i Gabuar
Student ID 999 888 777 888 ST_nam e Hashim Luan prakash Luan Kodi Lendes prog001 ing082 ing082 prog001
PK(student_id dhe kodi I Lendes)
K di L de tu t ID K s o en sS den la a K ha P sori o rofe pro 0 1 g0 99 9 1 03 1 2:00 7 3 65 ing 2 08 88 8 2 02 1 6:00 3 4 29 ing 2 08 77 7 2 02 1 3:00 3 4 29
183
PK(kodi I Lendes dhe student ID)
Bridge Entity
Ndjek Student Lenda
Student
Regjistron
Lenda
184
Bridge Entity: Nga M:N lidhje ne DY 1:M Lidhje
Student ID 999 888 777 888
ST_name Hashim Luan prakash Luan
PK(kodi lendes student Id)
K od i L e nd esS tud en t ID N o ta p rog 00 1 999 in g0 82 888 in g0 82 777
7 6 10
K od i L e nd esK la s a p rog 00 1 in g 0 8 2 185in g 0 8 2
Koha P r o fe s or i 103 1 2 :00 7 6 53 202 1 6 :00 3 2 94 202 1 3 :00 3 2 94
Mandatory VS Optional/ NULL VS Not NULL
Mandatory Mandatory Optional Optional
Ligjeron Profesori
(1,1) (0,N) M
Landa
1
Profesori
(0,N)
Ligjeron
(1,1)
Lenda
Nje profesor mund te ligjeron 0 ose me shume Lende.
Lenda mund te ligjerohen nga nje dhe vetem nje profesor 186
Gabim I zakonshem
Modelimi I proceseve apo funksioneve ne vend te modelimit te te dhenave
Cfare te dhene deshirojme te ruajme ??
Ne jemi te interesuar te modelojme te dhenat dhe JO proceset apo funksionet qe perdorin apo gjenerojne keto te dhena.
187
Ushtrim
Jeni punesuar nga nje menaxher I nje dyqani qe shet ski. Detyra juaj eshte qe te modeloni nje ERD qe sherben per inventarizimin e artikujve, Klienteve dhe Qerave te produkteve. Dyqani i skive jep me qera SKI dhe SAJA klienteve te vet. Cdo artikull ka kodin e vet unik inventarit qe e identifikon artikullin. Menaxheri deshiron te dije madhesine e artikullit si dhe cmimin e qerase per cdo artikull. Cdo artikull ne inventar klasifikohet ne baze te modelit. Cdo artikull i takon ekzaktesiht vetem nje modeli. Dyqani i skive mund te kete shume artikuj qe i takojne nje modeli te caktuar. Perveq invertarit menaxheri i dyqanit deshiron te ruaje informacione rreth Modeleve si numri I modelit, ngjyren e modelit, vitin e modelit. Cdo model klasifikohet sipas stilit(JUMP, Freestyle). Gjithashtu menaxheri deshiron te ruaj edhe te dhenat per klientet si emrin, mbiemrin, adresen, qytetin shtetin dhe e-mail. Klienti mund te marre me qera cdo artikull nese eshte ne inventar(ne dyqan). Nje artikull gjithashtu mund e merret me qera vetem nga nje klient ne te njejten kohe. Punetoreve te Dyqanit te skive do te ju duhet nje forme e qerase e cila do tregon emrin e klientit dhe adresen, daten e kthimit te artikullit, cmimin e qerase
188
Intentionally left blank
189
Zhvillimi i Software
Rapid Software Development –RSD Agile methods Programimi Ekstrem –XP Reuse Development Programimi Gjenerik COTS (commercial of the shelf) Evoluimi i software
190
Rapid software development
Zhvillimi bazohet ne ate menyre ku specifikacioni i kerkesave dhe dizajni eshte nje proces Iterativ. Zhvillimi behet ne menyre incrementale deri sa te arrihet ne nje version stabil. Perdoruesit evaluojne cdo zhvillim te ri (cdo increment) the bejne propozime per ndryshimet te reja. Kerkesat jane dinamike, zhvillimi eshte dinamik dhe dorezimi i soft. eshte i shpejte dhe dinamik.
191
Nje proces iterativ zhvillimi
Define system deli verables
Design system architectur e
Specify system increment NO
Build system increment
Validate increment
Deliver final system YES
System complete?
Validate system
Integrate increment
192
Avantazhed e zhvillimit Iterativ(perserites)
Sherbim i shpejte ndaj klientit. C’do shvillim i ri (increment) ka ne vetevete funksionalitetet prioritare te klientit. Angazhimi i perdoruesit me sistemin. Perdoruesit duhet te jene patjeter te involvuar gjate tere kohes, qe d.m.th sistemi ne shumicen e rasteve i ploteson kerkesat e perdoruesit si dhe perdoruesit jane me shume te perkushtuar ndaj sistemit.
193
Disavantazhet e Zhvillimit Iterativ
Problemet e menaxhimit Eshte e veshtire te gjykohet Progresi dhe Problemet sepse nuk ka dokumentacion qe demostron se cka eshte bere. Qeshtjet kontraktuale me klient Probleme me validimin/testimin Pa nje specifikacion, kundrejt cilit specifikacion/kerkese te validohet sistemi? Problemet e Mirembajtjes Ndryshimet e vazhdueshme e bejne te veshtire mirembajtjen e software .
194
Metodat Agile (shkathet)
Nje qasje e zhvillimit iterativ(RAD) Pakenaqesite me zhpenzimet e teperta qe perfshihen gjate fazes se dizajnit çuan ne krijimin e metodave Agile. Keto meda:
Fokusohen me shume ne KOD se ne dizajn. Bazohen ne qasjen iterative te zhvillimit te software Jane te destinuara per nje dorezim te shpejt te nje software qe punon.
Metodat Agile ndoshta jane me te mira per biznese te vogla apo te mesme.
195
Programimi Ekstrem -XP
XP - Extreme Programming Metoda me e njohur dhe me e perdorur Agile Metoda ekstreme ka nje qasje ‘ekstreme’ te zhvillimit iterativ
Versionet e reja mund te zhvillohen disa here ne dite. ‘Increments’ dorezohen tek klienti c’do 1 apo 2 jave; Te gjitha testet duhet te behen ne cdo version, dhe nje version pranohet vete nese te gjitha testet kane qene te sukseseshem.
Klienti duhet te jete i involvuar me orar te plote. 196
Skenaret e kerkesave ne XP
Ne XP, kerkesat e perdoruesve jane te shprehura si skenare apo tregime te perdoruesve. Keta skenare shkruhen ne ‘karta’ dhe grupi i zhvilluesve i ndan ato ne aktivitete(pune) per implementim.
Downloadimi i nje artikulli me pagese Fillimisht e zgjedh artikullin qe deshiron nga lista e artikujve. Pastaj ju I thoni sistemit se si do te paguani per kete artikull, kjo mund Te jete nepermjet anetaresimit, llogarise se kompanise apo credit card.
197
Cikli i leshimit ne pune te nje software ne XP
Select user stories for this release Break down stories to tasks Plan release
Evaluate system
Release software
Develop/integrate/ test software
198
RAD- rapid application development
Edhe pse metodat Agile kane marre shume vemendje vitet e fundit, Sistemet e Biznesit jane zhvilluar ne menyre iterative per shume vite duke perdorur tekniken RAD. Keto sisteme biznesi jane dizajnuar qe te zhvillojne “data-intensive” aplikacione biznesi dhe mbeshteten ne programimin dhe paraqitjen e informacionit nga baza e te dhenave.
199
Veglat RAD-rapid application development
Database programming language Interface Generator Links to office applications Report generators
200
Mjedisi RAD
Interface generator DB prog ramming language Database management system Office systems Report generator
Rapid application development environment
201
Software Reuse Ripordorimi i software
Ne shumicen e disciplinave inxhinjerike, sistemet dizajnohen duke kompozuar komponente ekzistuese te cilat jane perdorur ne sisteme te tjera. Inxhinjerimi i software ka qene me shume i fokusuar ne nje zhvillim origjinal. Viteve te fundit eshte vene re se per te arritur nje software me te mire, me shpejte dhe me kosto me te ulet duhet te adaptohen procese dizajni qe jane bazuar ne riperdorimin sistematik te software.
202
Baza e Riperdorimit
Application system reuse
Nje applikacion i tere, i plote mund te riperdoret, ose duke e inkorporuar pa asnje ndryshim ne nje sistem tjeter (COTS commercial off-the-shelf reuse) ose duke zhvilluar aplikacion te te njejtes familje.
Component reuse
Komponentet e nje aplikacioni nga nen-sistemet deri tek nje objekt mund te riperdoren (CBSE*)
Object and function reuse
Komponentet softuerike qe implementojne nje objekt te definuar mire ose nje funksion mund te riperdoren
*CBSE- component based software engineering
203
Faktoret qe duhet konsideruar para Riperdorimit te Soft.
Orari dhe koha e zhvillimit te software Jetegjatesia e pritshme e software. Njohurite dhe eksperienca e grupit te zhvillimit. Rendesia e software dhe kerkesat e tij jofunksionale. Platforma e ekzekutimit te software. Domain i aplikacionit
204
Koncepti Riperdorim
Kur riperdoret nje program apo nje komponent ju duhet te ndiqni vendimet qe jane marre nga zhvilluesi origjinal. Kjo mund te kufizoje mundesine per riperdorim Megjithate, nje forme me abstrakte e riperdorimit eshte vete koncepti ‘riperdorim’ ku nje qasje e vecante e nje problemi eshte i pershkruar per nje implementim te pavarur dhe pastaj behet implementimi. Dy qasjet kryesore te konceptit Riperdorim jane:
Mostra Dizajni (design patterns) Programimi Gjenerik/prodhues. (Generative programming)
205
Mostra Dizajni- Design Patterns
Moster dizajni eshte nje zgjidhje e pergjithshme qe perseritet per nje problem qe ndodh shpesh ne soft. Dizajn. Nuk eshte nje dizajn i perfunduar qe mund te transformohet direkt ne kod. Eshte nje pershkrim ose template se si te zgjidhet nje problem i cili mund te perdoret ne shume situata.
206
Programimi Gjenerik
Programi gjenerik perfshine riperdorimin e mostrave standarde dhe algoritmeve. Keta jane te perfshire ne Gjenerator the te parametrizuar nga komandat e perdoruesit. Programi pastaj gjenerohet Riperdorimi gjenerik eshte i mundur kur domaini abstrakt dhe lidhja e tyre ne kod te ekzekutueshem mund te identifikohen. Per krijimin dhe kontrollin e ketij abstraksioni perdoren Gjuhe specifike te domain.
207
Llojet e Programeve Gjenerik
Llojet e programeve gjenerik Gjenerator aplikacionesh per procesim te te dhenave per biznese. Gjeneratoret e kodit ne CASE tools. Riperdorimi i programeve gjenerik eshte shume i shpejte dhe me kosto shume te ulet, por zbatueshmeria eshte shume e limituar. Bug Free!!?? Provoni nje shembull programimi gjenerik - Iron Speed (www.ironspeed.com)
208
Riperdorimi gjate Gjenerimit te programit
209
MVC-Model View Controller
MVC eshte nje moster dizajni(design pattern) shume e perdorur per GUI. E njejta e dhene e shfaqur ne forma te ndryshme. models per mirembajtjen e te dhenave views per shfaqjen e te dhenave controllers per trajtimin(handling) e ngjarjeve te cilat afektojne modelin apo views
210
MVC- Si punon
211
COTS- Commercial Off-TheShelf systems
Sistemet COTS jane sisteme te kompletuara te cilat ofrojne API per integrim. (API -Application Programming Interface). Ndertimi i sistemeve te medha duke integruar sisteme COTS eshte nje strategji e zbatueshme dhe me benefit per disa sisteme sic jane p.sh E-Comerce applicionet.
212
E-procurement system
Client Web browser E-mail system
Server E-commerce system Adaptor Ordering and invoicing system
E-mail system
Adaptor
213
Software -Linja Produkti
Software ne formen e linjave te produktit jane aplikacione me funksionalitet gjenerik te cilat mund te adaptohen dhe konfigurohen per perdorim. Adaptimet mund te jene:
Konfigurimi i komponenteve dhe sistemit Shtimi i nje komponenti ne sistem Zgjedhja e komponenteve ekzistues nga librarija e komponenteve Modifikimi i nje komponenti per te permbushur kerkesat e reja.
214
Evolucioni I Software
Ndryshimet ne software jane te paevitueshme
Dalin kerkesa te reja duke u perdorur sistemi Mjedisi i biznesit ndryshon Gabimet (errors) duhet te rregullohen Paisje te reja shtohen ne sistem Performanca ose besueshmeria duhet te permiresohet etj.
Problemi kryesor i organizatave eshte implementimi dhe menaxhimi I ndryshimeve ne softuerat ekzistues. Te analizohet procesi I evoluimit te software gjate procesit te zhvillimit.
215
Kosto zhvillimit/mirembajtjes
System 1
System 2 $
0
50
100
150
200
250
300
350
400
450
500
Development costs
Maintenance costs
216
Procesi i evoluimit te software
Change requests
Impact analysis
Release planning
Change implementa tion
System release
Fault repair
Platform adaptation
System enhancement
217