Software Engineering

Published on May 2016 | Categories: Documents | Downloads: 35 | Comments: 0 | Views: 1021
of 217
Download PDF   Embed   Report

Software Engineering

Comments

Content

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

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close