rpa_p2_ooad_mvc (.docx)

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

1

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 „top-down“ 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.“

http://eu.fotolia.com/id/15052709


2

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


3

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.

http://www.softerra.com/skillset_ooad.htm


4

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: Simbol za klasu 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.

Prozor za unos

podataka

<<user interface>>

Prozor za unos

podataka


5

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)


6

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]

http://www.fer.unizg.hr/_download/repository/Zbirka.pdf


7

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:


8

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.


9

Slika 2.6. Primjer dijagrama za konceptualni model podataka

Slika 2.7. Primjer dijagrama za logički model podataka


10

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 nula-prema-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:


11

NarZaglavlje

PK NarZaglavljeID uniqueidentifier

FK1 SifarnikPotrosacaID uniqueidentifier UkupnaKolicina decimal(18;2) Placeno bit Isporuceno bit KorisnikID uniqueidentifier DatumVrijeme datetime

NarStavke

PK NarStavkeID uniqueidentifier

FK1 SifarnikCvijecaID uniqueidentifierFK2 NarZaglavljeID uniqueidentifier Kolicina decimal(18;2) Placeno bit Isporuceno decimal(18;2)

SifarnikCvijeca

PK SifarnikCvijecaID uniqueidentifier

Vrsta varchar(10) Podvrsta varchar(10) Sifra varchar(10) Naziv varchar(256)

SifarnikPotrosaca

PK SifarnikPotrosacaID uniqueidentifier

Ime varchar(256) Prezime varchar(256) DrugiNaziv varchar(256) Adresa varchar(256) PostanskiBroj varchar(5) Zupanija varchar(256) Mjesto varchar(256) Telefon varchar(256) DrugiKontakt 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


12

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.

http://www.efos.hr/About


13

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.


14

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“


15

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.


16

Literatura:

1. /Training/etc Inc., OOAD Using the Unified Modelling Language, Chapter 1: Object-

Oriented 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/older-versions/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-m1-

intro&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.]

http://www.trainingetc.com/PDF/TE1802eval.pdf

http://creately.com/blog/diagrams/uml-diagram-types-examples/

http://www.jdl.co.uk/briefings/MVC.pdf

http://www.fer.unizg.hr/_download/repository/Zbirka.pdf

http://www.asp.net/mvc/tutorials/older-versions/overview/asp-net-mvc-overview

http://www.asp.net/mvc/tutorials/older-versions/overview/asp-net-mvc-overview

http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF/

http://pluralsight.com/training/Player?author=scott-allen&name=mvc4-building-m1-intro&mode=live&clip=0&course=mvc4-building

http://pluralsight.com/training/Player?author=scott-allen&name=mvc4-building-m1-intro&mode=live&clip=0&course=mvc4-building

http://www.umsl.edu/~sauterv/analysis/488_f01_papers/quillin.htm#I. What

http://www.umsl.edu/~sauterv/analysis/488_f01_papers/quillin.htm#II. Tools and approaches involved in OO Analysis and OO Design

http://www.umsl.edu/~sauterv/analysis/488_f01_papers/quillin.htm#III. Object-Oriented Analysis vs. Traditional Methods

http://www.umsl.edu/~sauterv/analysis/488_f01_papers/quillin.htm#III. Object-Oriented Analysis vs. Traditional Methods

http://www.umsl.edu/~sauterv/analysis/488_f01_papers/quillin.htm

http://cupsofcocoa.com/2011/08/13/design-patterns-model-view-controller/

rpa_p2_ooad_mvc (.docx)

Documents