RPA_P2_OOAD_MVC (.docx) - Ekonomski fakultet u Osijeku

Ekonomski fakultet u Osijeku, Razvoj poslovnih aplikacija Marijana Zekid-Sušac, Saša Mitrovid

2. Objektno orjentirana analiza i dizajn poslovnih aplikacija, MVC model

Evolucija – kako je nastao objektno orjentirani pristup aplikacijama Objektno orjentirani (OO) pristup razvoju aplikacija pojavio se 1970-tih godina, i donio radikalnu promjenu u metodologiji i pristupu u odnosu na staru paradigmu algoritamskog pristupa. Za razliku od starog „bottom-up“ pristupa, objektno orjentirani pristup je „topdown“ i uvodi velike promjene u načinu dizajniranja aplikacija i pristupa problemu razvoja softvera. (Quillin, 2001) U čemu je razlika? OO dizajn omogudava razvoj velikih aplikacija u obliku nezavisnih modula. Pri tome se koristi objektno orjentirana dekompozicija na način da se složeni problem rastavi na primarne objekte koji se pojavljuju u sustavu. Nakon što se definiraju objekti i funkcionalnost sustava (što sustav treba raditi), nezavisno se razvijaju glavne kompomente sustava. Da bi se takav paraleni razvoj i testiranje komponenti mogli izvesti, traži se striktno pridržavanje specifikacija zahtjeva. Quillin (2001) navodi primjer koji zorno ilustrira razliku između objektnog i algoritamskog pristupa izgradnji aplikacija.

Zamislite da sjedite za dugačkim stolom za objedom, a soljenka sa solju se nalazi baš na suprotnoj strani stola daleko od Vas. Želite zamoliti prijatelja koji sjedi na suprotnoj strani stola da Vam doda sol. Što biste mu rekli?

Photo by: Fotolia, http://eu.fotolia.com/id/15052709, 20013.

1. Pristup: „Molim te, dodaj mi sol!“ 2. Pristup: „Molim te, odmakni svoju desnu ruku od čaše s vinom, pomakni je ulijevo dok ne dotakneš soljenku, zatim uzmi soljenku rukom, podigni je sa stola, nosi je u mom smjeru, stani kad dotakneš moju ruku, pričekaj da moja ruka obuhvati soljenku, zatim je pusti.“ 1


Što mislite, koji pristup je objektni, a koji algoritamski? Koji je čovjeku prirodniji? Naravno, prvi pristup je OBJEKTNI, jer izdaje naredbu bez da su u njoj navedeni detalji kako de se postupak izvesti. Sam postupak se ostavlja objektu (u ovom slučaju našem prijatelju) da ga učini na način kako on to želi ili smatra ispravnim. Ovakav način pozivanja radnje bez da je poznat postupak kako de se ta radnja izvesti u objektnom programiranju naziva se ENKAPSULACIJA (učahurivanje). Drugi, algoritamski ili proceduralni pristup, specificira način i svaki korak kako de se radnja izvesti. U objektnom pristupu je nasuprot tome, objekt taj koji je odgovoran za svoje postupke, i to je pristup tzv. „crne kutije“ (eng. „black box“). Ako se pravilno koristi, OO dizajn može unaprijediti ne samo razvoj, nego i održavanje, ponovnu upotrebu i modifikacije softvera.

Objektno orjentirana analiza i dizajn (OOAD) softvera „Object-oriented

analysis and design (OOAD) is the principal industry-proven methodology for developing high-quality object-oriented systems. „ (Softerra, 2013) Dakle, to je osnovna, u praksi provjerena metodologija za razvoj visokovalitetnih objektno orjentiranih sustava. OOAD uključuje 3 aspekta ili dijela (Softerra, 2013), a to su:

1. Objektno orjentirana analiza (OOA) – vrsta sistemske analize koja se bavi zahtjevima za dizajn i ukupnu arhitekturu sustava, a orjentirana je na opisivanje što sustav treba raditi tako da definira ključne objekte u problemskom području 2. Objektno orjentirani dizajn (OOD) – prevodi arhitekturu sustava u programske konstrukte, kao što su sučelja, klase, opisi metoda 3. Objektno orjentirano programiranje (OOP) – bavi se implementacijom programskih konstrukata i izradom same aplikacije u nekom objektnom programskom jeziku OOAD se temelji na dekompoziciji objekata, razdvajanju složenog sustava na različite objekte, u okviru kojih djeluju podaci i funkcije na tim podacima.

Objekti u objektnom programiranju predstavljaju modele instanci stvarnog svijeta. Instance su primjerci određenog objekta, npr. 

ako je objekt Student, tada je instanca tog objekta npr. Pero Perid (ako je ta osoba student)

2


  

ako je objekt Knjiga, tada je instanca tog objekta npr. „Vlak u snijegu“, ili „Lovac u žitu“ ako je objekt Pas, tada je instanca tog objekta npr. Rex ako je objekt Dugme (u programu), tada je instanca tog objekta npr. Button1

Klasa je tip koji ima svoje objekte i instance (Object Management Group, 2011). Dakle, instanca je uvijek konkretni primjerak neke vrste, odnosno tipa objekta. Objekti mogu međusobno surađivati kako bi napravili neki zadatak za korisnika. Objekti imaju svojstva, koja se nasljeđuju – instance nasljeđuju svojstva objekta kojem pripadaju, npr. ako objekt (klasa) Student ima svojstva: ime, prezime, spol, godinaRodjenja, tada i instanca Pero Perid klase Student također ima ta svojstva. Na taj način, glavni posao objektnog programiranja nije pisanje novog koda, nego spajanje postojedih objekata u nove inovativne načine kako bi se riješio problem. OOP tako smanjuje vrijeme razvoja softvera i troškove, omoguduje bržu isporuku softvera na tržište, te proizvodi fleksibilnije i lakše održive sustave. (Softerra, http://www.softerra.com/skillset_ooad.htm, 2013) Da bi se napravila OO analiza i dizajn, potrebno je koristiti:   

notaciju – grafičko predstavljanje klasa, njhovih veza i interakcija proces – sugerirani skup koraka koje treba napraviti da bi se zahtjevi pretvorili u sustav alat – softver koji de se koristiti za crtanje i predstavljanje OOAD

Problem se kod OOAD predstavlja na sljededi način: klase i objekti + nasljeđivanje + komunikacija porukama. Najčešdi oblik notacije je UML dijagram.

UML jezik za modeliranje UML (Unified Modelling Language) je standardni jezik za grafičko predstavljanje objektno orjentirani dizajn sustava. Iako je nastao ranije, njegova prva službena verzija 1997. godine (v.1) prihvadena je od strane Object Management Group kao standardna grafička notacija za OO software dizajn (/Training/etc Inc, 2007). UML se sastoji od više vrsta dijagrama kojima je cilj predstaviti arhitekturu sustava. Dijagrami UML-a podijeljeni su u dvije skupine (OMG,2011): (1) dijagrami koji prikazuju strukturu sustava (dijagrami klasa, objekata, dijagrami komponenti i dijagrami rasporeda) (2) dijagrami koji prikazuju ponašanje sustava (dijagrami stanja, aktivnosti, slijeda, kolaboracijski i dr.) Sve ove vrste dijagrama prikazane su na Slici 2.1.

3


Slika 2.1. Tipovi UML dijagrama (Creately.com, 2013). Neki od simbola koji se koriste kod UML dijagrama su:  Class-name: - oznaka neke klase (npr. Student)  : Class-name - oznaka bilo kojeg objekta neke klase (npr. :Student)  Object-name: Class-name - oznaka određenog objekta neke klase (npr. Pero : Student) Grafičkim simbolom u UML-u se klasa označava u pravokutniku, s upisanim nazivom klase, ili dodanim stereotipom (koji prilagođava klasu tako da joj proširuje značenje), npr: Prozor za unos podataka

Simbol za klasu

Prozor za unos podataka

Simbol za klasu sa stereotipom

Primjer simbola za klasu Address, instancu myAddress (Object Management Group, 2011):

Osim ovih simbola, u UML dijagramima koriste se i linije i strelice koje povezuju elemente, te zabilješke.

4


Prema OMG specifikaciji (Object Management Group, 2011), ovako izgleda notacija za dijagram klasa u UML-u:

Slika 2.2. Dijagram klasa (Object Management Group, 2011) Konkretni primjer dijagrama klasa za naručivanje proizvoda prikazan je na Slici 2.3.

Slika 2.3. Dijagram klasa sa vezama(Creately.com, 2013) 5


Primjer dijagrama komponenti koji prikazuje strukturne veze dijelova jednog sustava dan je na Slici 2.4. On se koristi kod složenih sustava koji se dijele u komponente, pojedine komponente su povezane putem sučelja, a sučelja su povezana putem konektora (prikazanih linijama na slici).

Slika 2.4. Dijagram komponenti (Creately.com, 2013)

Za više praktičnih primjera UML dijagrama vidi: Jovid, A., Horvat, M., Grudenid, I., UML dijagrami – zbirka riješenih zadataka, Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva, 2012., http://www.fer.unizg.hr/_download/repository/Zbirka.pdf, [09.10.2013]

6


Model-View-Controller arhitektura sustava Kako se razvijalo objektno programiranje, sve se više ukazala potreba razdvajanja dizajniranja sučelja od ostalih dijelova sustava. Zašto? Sučelja su dijelovi pomodu kojih komponente sustava međusobno komuniciraju. Česte su komunikacije dijelova programa međusobno, ali i između dijelova programa i ljudi. Za očekivati je da de se dizajn sučelja često mijenjati i prilagođavati i ljudima i tehnologiji, i to puno češde nego što de se mijenjati sama obrada podataka koja je u pozadini sustava. Zbog toga se odvajanje ova dva dijela sustava pokazalo vrlo praktičnim i ubrzalo je razvoj i održavanje softvera. Još u 1970-tim godinama, prof. Trygve Reenskaug predložio je za upotrebu SmallTalk objektnog jezika arhitekturu Model-View-Controller, koja je omogudavala razdvajanje sučelja (GUI) od ostalog dijela programa, a od 2009. godine Microsoft prihvatio taj koncept i razvio MVC okvir kako bi „zaustavio miješanje programske logike i prezentacijske logike“ (Deacon, 2013).

Slika 2.5. MVC okvir (adaptirano prema http://cupsofcocoa.files.wordpress.com/2011/08/mvc-diagram1.png, 2011)

Model u MVC arhitekturi Prvi dio MVC arhitekture – Model – čini samu bit aplikacije, a sastoji se od skupa klasa koje modeliraju i podržavaju rješavanje problema kojim se aplikacija bavi, i taj dio je obično stabilan i trajan koliko i sam problem. Primjeri informacija koje pripadaju u Model:

7


   

Informacije o računanju neto plade djelatnika (ako je to aplikacija koja obračunava plade) Informacije o računanju iznosa poreza na dodanu vrijednost (ako je to aplikacija koja obračunava PDV) Informacije o postupku za izdavanje računa (ako je to aplikacija koja izdaje izlazne račune) itd.

Ove se informacije pohranjuju u Modelu u obliku programskog koda na način da se definiraju klase i njihova svojstva, npr. u C# programskom jeziku klasa za šifrarnik cvijeda za neku cvjedarnicu bi izgledala ovako: public class SifarnikCvijeca { public Guid SifarnikCvijecaID { get; set; } public string Vrsta { get; set; } public string PodVrsta { get; set; } public string Sifra { get; set; } public string Naziv { get; set; } }

Pri tome su: SifarnikCvijecaID, Vrsta, PodVrsta, Sifra i Naziv, svojstva klase SifarnikCvijeca koje u programu mogu poprimiti određene vrijednosti. Veze (eng. Relationships)

Kada se identificiraju klase modela koje de se implementirati u web aplikaciju, potrebno je uzeti u obzir i veze između njih. Na primjer, u slučaju korištenja aplikacije za pradenje narudžbi, svaka narudžba de biti vezana za jednog, i samo jednog, korisnika koji je kreirao narudžbu. Takva veza je poznata kao jedan-na-jedan odnos (1:1). Svaki korisnik, međutim, može kreirati više narudžbi. Takva veza je poznata kao jedan-na-više odnos (1:N). Model u MVC arhitekturi obično se sastoji od Modela područja (Domain Model) i Modela aplikacije (Application Model). Domain Model sadrži glavne objekte koji opisuju problem (npr. Klijent, Narudžba, Račun, itd.), dok se Application Model sastoji od tehničkih objekata potrebnih za izradu aplikacije (npr. Kolekcija klijenata, Sučelje za unos podataka o klijentima itd.). Domain Model obično se povezuje s bazom podataka jer se objekti iz Domain Modela prikazuju u bazi i o njima se podaci pohranjuju u bazi. Za projektiranje baze podataka koristi se: (1) Konceptualni, (2) Logički i (3) Fizički model podataka. Konceptualni model sadrži samo prikaz naziva entiteta (tj. tablica) u bazi i njihovih veza. Logički model sadrži i nazive atributa u tablicama, primarnih i stranih ključeva, dok Fizički model sadrži sve stupce u tablicama i tipove podataka u pojedinim stupcima. Razlike među tim modelima baze podataka prikazane su Slikama 2.6., 2.7. i 2.8.

8


Slika 2.6. Primjer dijagrama za konceptualni model podataka

Slika 2.7. Primjer dijagrama za logički model podataka

9


Slika 2.8. Primjer dijagrama za fizički model podataka Kao što je vidljivo na slikama, fizički model je detaljniji od prva dva, i sadrži podatke na temelju kojih su vidljivi detalji o tablicama u bazi podataka i njihovim vezama. Domain Model dijagrami i Logical Data Model dijagrami uključuju objekte i poveznice između objekata. Simboli tzv. Vraninih stopala (Crow's feet) na krajevima veza pokazuju je li odnos nulaprema-više (0, N), nula-na-jedan (0, N), jedan-na-više (1, N), više-prema-više (M, N) ili jedan-na-jedan (1, 1).

Slika 2.9. Usporedba vraninih stopala i odnosa

U nastavku prikazan je malo detaljniji dio dijagrama fizičkog modela baze podataka (Physical Database Model) - oznake u boji su dodane samo radi preglednosti zajedničkih polja u tablicama:

10

Ekonomski fakultet u Osijeku, Razvoj poslovnih aplikacija Marijana Zekid-Sušac, Saša Mitrovid NarStavke PK

NarStavkeID

uniqueidentifier

FK1 FK2

SifarnikCvijecaID NarZaglavljeID Kolicina Placeno Isporuceno

uniqueidentifier uniqueidentifier decimal(18;2) bit decimal(18;2)

SifarnikCvijeca PK

SifarnikCvijecaID uniqueidentifier Vrsta Podvrsta Sifra Naziv

varchar(10) varchar(10) varchar(10) varchar(256)

SifarnikPotrosaca NarZaglavlje

PK

PK

NarZaglavljeID

uniqueidentifier

FK1

SifarnikPotrosacaID UkupnaKolicina Placeno Isporuceno KorisnikID DatumVrijeme

uniqueidentifier decimal(18;2) bit bit uniqueidentifier datetime

SifarnikPotrosacaID uniqueidentifier Ime Prezime DrugiNaziv Adresa PostanskiBroj Zupanija Mjesto Telefon DrugiKontakt

varchar(256) varchar(256) varchar(256) varchar(256) varchar(5) varchar(256) varchar(256) varchar(256) varchar(256)

Slika 2.10. Dio dijagrama fizičkog modela baze podataka na primjeru cvjedarnice

Dijagram fizičkog modela baze podataka predstavlja konačnu strukturu baze podataka u konceptualnom modeliranju, a s time i klasa modela do kojih se došlo s Domain Model i Logical Data Model dijagramima. Entity Framework

Entity Framework je Object Relational Mapping (ORM) kostur (eng. Framework) za .NET aplikacije. Entity Framework mapira tablice iz baze i promatra ih kao klase koje programer može koristiti u programiranju stvaranjem instanci tih klasa ili izvršavajudi metode na tim klasama. Kada se koristi Entity Framework u MVC web aplikaciji, on mapira tablice ili poglede na klase modela koji su kreirani. Ne treba se pisati SQL kod za upit ili ažuriranje podataka u tablicama, jer Entity Framework to odrađuje. Entity Framework je u potpunosti integriran s Language Integrated Query (LINQ) upitnim jezikom. Ako se planira koristiti Entity Framework za pristup podacima, treba se, još u fazi planiranja razvoja, odlučiti o tome kako de se kreirati baza podataka s jednim od navedenih pristupa:  

Database-First – kada se izvan aplikacije najprije kreira baza podataka u nekom od DBMS sustavu (npr. SQL server) a zatim se ta baza koristi iz aplikacije s pomodu programskog koda Model-First - kada se želi dizajnirati model baze pomodu ORM dizajnera za oblikovanje baza podataka u Visual Studio-u. Kreirani model dobije .edmx ekstenziju datoteke, te dizajner u kojemu se je kreirao sam generira kod klasa modela. Prilikom 11




pokretanja aplikacije Entity Framework stvara bazu podataku kako bi podržao kreirani model. Code-First: Entity Framework Code-First pristup se koristi kad nema postojede baze podataka i kada se želi radije dizajnirati modele u cijelosti u C# kodu. Takav kod mora sadržavati DBContext i DBSet objekte, koji mapiraju bazu podataka i njezine tablice. Kada se aplikacija pokrene prvi puta, EntityFramework stvara bazu podataka za nju.

Ovo je zasada najbitnije što trebamo znati o Model dijelu MVC arhitekture. Dakle, u njemu se nalaze informacije o objektima (klasama, svojstvima, entitetima u bazi podataka i vezama), te sve ostalo što ulazi u Model područja (Domain Model) i Model aplikacije (Application Model). Što se ne nalazi u ovom dijelu arhitekture sustava? – Znanje o vezama s vanjskim svijetom. Ovaj dio se ne bavi vezama s okolinom.

View (pogled) u MVC arhitekturi Ovaj dio aplikacije bavi se načinom prikaza informacija korisniku ili aplikaciji, tj. odgovara na pitanje „Kako de se nešto prikazati korisniku ili drugoj aplikaciji?“ a sadrži sučelja koja su veza s modelom (s prvim dijelom arhitekture sustava). S obzirom da u aplikaciji obično postoji više sučelja, ovaj dio se često naziva u množini: Views (pogledi). Ti pogledi se obično odnose na prozore za komunikaciju, a mogu biti (Deacon, 2012):   

Pogled na grafičko korisničko sučelje (GUI view) Pogled na komandnu liniju (Command line view) Pogled na aplikacijsko programsko sučelje (API view)

Dakle, sučelja ne moraju nužno biti grafička.

Controller (kontroler) u MVC arhitekturi Kontroler u osnovi zaprima zahtjeve korisnika. Kontroler je objekt koji upravlja Pogledima. Pojednostavljeno se može redi da Kontroler kontrolira input, dok Pogledi (Views) kontroliraju output (kako de nešto izgledati u prozoru). Da bi mogli upravljati inputom, kontroleri moraju poznavati na kojoj se platformi, tj. operativnom sustavu i bazi radi u aplikaciji. Pogledi (Views) nasuprot tome ne moraju to poznavati. Primjeri zahtjeva koji pripadaju u Kontroler: 

Kada korisnik u preglednik upiše adresu: http://www.efos.hr/About, želimo da se prikaže stranica s osnovnim informacijama o fakultetu.

12




Ako koristimo web obrazac za kontaktiranje neke tvrtke, kada kliknemo na dugme „Pošalji“, želimo da se naša poruka pošalje na e-mail adresu primatelja ili spremi u datoteku.

MVC okvir ima osnovni cilj pružiti alate i metode za dizajniranje Modela, Pogleda i Kontrolera. Dodatni ciljevo MVC okvira su (Pluralsight, 2012):    

Prigliti web (povezati aplikaciju sa HTML, CSS i Javascript tehnologijama, čije se naredbe automatski generiraju prilikom izrade aplikacije) Izgraditi i pokretati aplikacije u ASP .NET okolini, koja omoguduje izgradnju, debuggiranje i generiranje izvršnog koda aplikacije Omoguditi proširive (eng. extensible) aplikacije Omoguditi testabilne (eng. testable) aplikacije, koje de se lako modi testirati

Primjer MVC: Dijelovi MVC aplikacije koja de na web stranici prikazivati kulinarske recepte:   

Popis recepata i sadržaj recepata = Model Zahtjev korisnika da se na web stranici prikaže popis recepata = Controller Zahtjev korisnika da na web stranici taj popis recepata prikaže u obliku tablice = View

Microsoft Visual Studio for Web i MVC Jedna od platformi za razvoj objektnih aplikacija koja koristi MVC arhitekturu aplikacija je i Microsoft Visual Studio for Web. Prilikom instalacije na vlastito računalo, cijeli paket de instalirati 3 komponente ove platforme. To su: 

 

Visual Studio – razvojni alat koji podržava razvoj MVC aplikacija, web formi, biblioteke klasa, Silverlight aplikacija i drugih vrsta aplikacija u programskim jezicima C# ili Visual Basic. SQL server – baza podataka IIS Express – Internet Information Server Express – besplatna verzija Microsoft web poslužitelja, koji omogudava hosting za naše aplikacije na lokalnom računalu (na način da se aplikacija može pokrenuti u pregledniku, a kao adresa aplikacija postavljen je lokalni host, npr. http://localhost:5657/...

Ove tri komponente prikazane su na donjoj slici.

13


Slika 2.11. Tri komponente paketa Visual Studio Express for Web Nakon pokretanja programa, u okviru ovog kolegija bavit demo se izgradnjom MVC web aplikacija (koje su temeljene na MVC arhitekturi), pa je u prozoru za izbor vrste aplikacija potrebno izabrati: „ASP .NET MVC 4 Web Application“

14


Slika 2.12. Izbor vrste web aplikacije u alatu Visual Studio Express for Web Nakon izbora vrste aplikacije slijedi izbor programskog jezika (Visual Basic ili C#) i izgradnja aplikacije može započeti.

15


Literatura:

1. /Training/etc Inc., OOAD Using the Unified Modelling Language, Chapter 1: ObjectOriented Analysis and Design, http://www.trainingetc.com/PDF/TE1802eval.pdf, 2007, [04.10.2013]. 2. Booch, G., Object-Oriented Analysis and Design With Applications, Second Edition, Addison Wesley, USA and Canada, 1998. [ 03.10.2013] 3. Creately.com, The Complete Guide to UML Diagrams With Examples, http://creately.com/blog/diagrams/uml-diagram-types-examples/, [ 03.10.2013] 4. Deacon, J., Model-View-Controller Arhitecture, http://www.jdl.co.uk/briefings/MVC.pdf, September, 2013, [04.10.2013] 5. Jovid, A., Horvat, M., Grudenid, I., UML dijagrami – zbirka riješenih zadataka, Sveučilište u Zagrebu, Fakultet elektrotehnike i računarstva, 2012., http://www.fer.unizg.hr/_download/repository/Zbirka.pdf, [09.10.2013] 6. Microsoft, ASP.NET MVC Overview, http://www.asp.net/mvc/tutorials/olderversions/overview/asp-net-mvc-overview, , [09.10.2013] 7. Object Management Group, OMG Unified Modeling LanguageTM (OMG UML), Infrastructure, http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF/, v. 2.4.1, August, 2011, [08.10.2013] 8. Pluralsight, Building Applications with ASP.NET MVC 4, http://pluralsight.com/training/Player?author=scott-allen&name=mvc4-building-m1intro&mode=live&clip=0&course=mvc4-building, 2012.

9. Quillin, M.J., Object Oriented Analysis and Design:What is it? How Does it Work? Why is it used?, http://www.umsl.edu/~sauterv/analysis/488_f01_papers/quillin.htm, 2001, [05.10.2013] 10. Feifan Zhou, Design Patterns: Model-View-Controller, http://cupsofcocoa.com/2011/08/13/design-patterns-model-view-controller/ , 2011, [8.10.2013.]

16