Objektno orijentisani dizajn: definicija, principi i primjeri

Objektno orijentisani dizajn je proces planiranja sistema interaktivnih objekata u cilju rešavanja softverskog problema. Ovo je jedan od pristupa razvoju softvera.

Stavka sadrži inkapsulirane podatke i procedure grupisane zajedno da predstavljaju objekat. Interfejs definiše kako može koegzistirati, a program opisuje interakciju skupova. Objektno orijentisani dizajn je disciplina definisanja objekata i njihovih procesa za rešavanje problema koji je identifikovan i dokumentovan tokom analize.

Slijedi opis podskupa zasnovanog na klasi koji ne uključuje pristupe zasnovane na prototipovima objekata, kada se obično ne dobijaju stvaranjem instanci klasa, već kloniranjem drugih. Dizajn je objektno orijentisana metodologija dizajna. Obuhvata proces dekompozicije i notacije za predstavljanje logičkog i fizičkog stanja, kao i dinamičke modele projektovanog sistema.

Teme Dizajna

Ulaz za objektno orijentisani dizajn obezbeđuje izlaz analize. Mora se shvatiti da artefakt ne mora biti u potpunosti dizajniran da služi kao referentna tačka. Analiza i dizajn mogu se desiti paralelno. U praksi, rezultati jedne akcije mogu podstaći drugu u kratkoj povratnoj sprezi kroz iterativni proces. I prva i druga radnja mogu se izvoditi u fazama, artefakti se mogu stalno povećavati, a ne razvijati u potpunosti u jednom trenutku.

Neki tipični predmeti

Smatrajte najvažnijim.

1. Idejni model.

Rezultati objektno orijentisane analize i dizajna obuhvaćeni su konceptom u domeni. Konceptualni model je eksplicitno izabran da bude nezavisan od detalja implementacije kao što su istovremenost ili čuvanje podataka.

2. Koristi slučaj.

Opis sekvenci događaja koji zajedno dovode do toga da sistem uradi nešto korisno. Svaki slučaj upotrebe pruža jedan ili više scenarija koji prenose objektno orijentisani dizajn sistema. To je ono što mora da komunicira sa korisnicima, zvanim akteri, da bi se postigao određeni poslovni cilj ili funkcija.

Izvršioci slučajeva korišćenja mogu biti krajnji korisnici ili ostali sistemi. U mnogim slučajevima, opcije aplikacije za ovu metodu dodatno su razvijene u obliku dijagrama. Dijagrami slučaja upotrebe koriste se za identifikaciju aktera i procesa koje izvode. Više možete pročitati u knjizi Gradi Butcha "objektno orijentirani dizajn".

3. Dijagram sekvence sistema.

To je slika koja za određeni scenario prikazuje slučajeve upotrebe događaja koje generišu eksterni učesnici, njihov redosled i moguće međusistemske radnje.

4. Dokumentacija Korisničkog Interfejsa.

Papir koji prikazuje i opisuje izgled konačnog proizvoda. Ova stavka nije obavezna, ali pomaže u vizualizaciji, što dizajneru olakšava.

kreirajte relacijski model podataka

Ovo je apstraktni prototip koji opisuje kako su informacije predstavljene i korištene. Ako se Objektna baza podataka ne koristi, relacijski model podataka obično bi trebao biti kreiran prije radnje, budući da je strategija odabrana za prihvaćanje objektno orijentiranog dizajna izlaz procesa.

Međutim, moguće je paralelno razviti relacijski model podataka, a rast artefakta može stimulirati profinjenost drugih komponenti. Više o tome piše i u Butchovoj knjizi "objektno orijentisana analiza i dizajn". Imajte na umu da ćete u ovom novom izdanju Gradi Bucha pronaći mnogo praktičnih savjeta vezanih za analizu, implementaciju, dizajn i upravljanje projektima.

Koncepti

Pet osnova objektno orijentisanog dizajna su funkcije na nivou implementacije ugrađene u programski jezik. Često se nazivaju sljedećim uobičajenim imenima:

1. Object class.

Šta je to?? Klasa je bliska veza ili tangencija struktura podataka sa metodama ili funkcijama koje utiču na njih (objekat se kreira na osnovu njega). Svaka stavka obavlja funkciju. Definiše se njegovim svojstvima. Objekat može biti deo klase koja je zbirka sličnih predmeta.

2. Prikrivanje objektno orijentisanog dizajna informacionih sistema je sposobnost zaštite nekih komponenti od spoljašnjih uticaja.

3. Nasljedstvo.

Ovo je prilika za klasu da proširi ili redefiniše funkcionalnost druge grupe. Takozvana podklasa ima čitav odjeljak koji je izveden (naslijeđen) iz superklase, a također ima svoj skup funkcija i podataka.

. Interfejs (među tehnikama objektno orijentisanog dizajna postoje takozvani obrasci. Apstraktni fabrički interfejs je jedan od njih).

Sposobnost odgađanja implementacije metode, kao i sposobnost definiranja funkcija bez njihove implementacije.

5. Polimorfizam (posebno podtip) - sposobnost zamjene objekta njegovim subobjektima. Kao i mogućnost varijabilnog objekta da sadrži ne samo ovaj objekt, već i sve njegove komponente.

Razvoj koncepata

Definiranje objekata, stvaranje dijagrama klase iz konceptualnog oblika obično prikazuje entitet.

Identifikacija atributa.

Neophodno je koristiti gama obrasce objektno orijentisanih tehnika dizajna. Ovo nije Goto proiz od, eć opis rješenja zajedničkog problema u kontekstu. Glavni prednost korištenja obrazac dizajna je da se može ponovo koristiti u više aplikacija. Takođe se smatra riješite probleme, to može nastati u mnogim različitim situacijama. Gama objektno orijentisani obrasci dizajna obično pokazuju odnose i interakcije između klasa ili objekata bez specificiranja krajnjih sistema aplikacija ili objekata koji u njima učestvuju.

Definicija strukture.

Ovo je obično skup biblioteka ili klasa koje se koriste za implementaciju standardne strukture aplikacije za određenu operativni sistem. Kombinacijom velike količine koda za višekratnu upotrebu u platformu, programer štedi mnogo vremena, jer rješava zadatak prepisivanja velike količine standardnog koda za svaku novu aplikaciju koja se razvija.

Zaključak (rezultati) objektno orijentisanog dizajna

Dijagram redoslijeda mora biti riješen kako bi se dodali određeni objekti koji obrađuju sistemske događaje. Prikazuje u obliku paralelnih vertikalnih linija različite procese koji žive istovremeno, a u obliku horizontalnih strelica — razmjenu poruka između njih po redoslijedu njihovog pojavljivanja.

Dijagram klasa - je tip statičke UML strukture koja opisuje sisteme pokazujući njihove atribute i odnose između njih. Poruke i klase identifikovane kroz razvoj dijagrama sekvenci mogu poslužiti kao ulazni podaci za automatski generacija globalnog sistema.

Neki principi i strategije dizajna

Često se koristi injekcija zavisnosti. Šta je glavna ideja? Ako stavka ovisi o prisutnosti bilo koje druge instance, tada je potrebna ugrađena u zavisnu. Primjer objektno orijentiranog dizajna: prosljeđivanje veze baze podataka kao argumenta konstruktoru, umjesto da je stvara interno. Još jedan primjer koji koristi obrazac mosta: odvajanje apstrakcije od njegove implementacije tako da se oba subjekta mogu mijenjati nezavisno.

Razmotrimo principe objektno orijentisanog dizajna acikličkih zavisnosti. Imajte na umu da grafikon komponenti (stepen detalja zavisi od količine posla) ne bi trebao imati cikluse. Ovo se također naziva usmjereni aciklični grafikon. Primjer objektno orijentisane analize i dizajna: recimo C zavisi od B, koji je podređen subjektu A. Ako je ovo drugo takođe povezano sa C, tada će postojati petlja.

Koji je princip ponovne upotrebe jedinjenja? Prednost se daje polimorfnom sastavu nasljeđivanja. Nakon faze analize, konceptualni model se dalje razvija u objektno orijentisani IP dizajn. Ovdje se tehnološki nezavisni koncepti analize mapiraju na implementaciju klasa, identifikuju ograničenja i razvijaju interfejsi, što rezultira modelom za domen rješenja.

Faze za objektno orijentisani IC dizajn mogu se definirati na sljedeći način:

• Pronalaženje konteksta sistema.
• Projektovanje njegove arhitekture.
• Identifikacija objekata u sistemu.
• Izgled dizajna zgrada.
• Specifikacija objektnih interfejsa.
• Dizajn.

Objektno orijentisani dizajn sistema uključuje definisanje konteksta, a zatim kreiranje arhitekture.

Prvi koncept

Kontekst sistema ima statičke i dinamičke dijelove. Prvi je kreiran zahvaljujući objektno orijentisanom dizajnu koristeći jednostavan dijagram toka, koji je proširen u hijerarhiju podsistema. Ovaj model je predstavljen UML paketima. Dinamički kontekst opisuje kako sistem komunicira sa svojim okruženjem. Modeliran je pomoću dijagrama slučajeva upotrebe.

Arhitektura sistema razvijena je na osnovu konteksta i u skladu sa principima dizajna, kao i uzimajući u obzir predmetnu oblast. Po pravilu, sistem je podeljen na slojeve, a oni se razlažu u podsisteme.

Šta je objektno orijentisana dekompozicija?? Dekompozicija znači podjelu velikog složenog sistema na hijerarhiju manjih komponenti manje složenosti. Svaki glavni deo se zove podsistem. Objektno orijentisana dekompozicija identifikuje pojedinačne autonomne objekte u sistemu i odnos između njih.

Prednosti raspadanja:

• Pojedine komponente imaju manje složenosti i stoga su razumljivije i upravljivije.
• Postoji podjela radne snage sa specijalizovanim vještinama.
• Ovo omogućava zamjenu ili modificiranje podsistema bez uticaja na druge dijelove.

Prepoznavanje paralelizma

Omogućava više objekata da primaju događaje i izvode više radnji u isto vrijeme. Paralelizam je identifikovan i predstavljen u dinamičkom modelu.

Da bi se to omogućilo, svakom paralelnom elementu se dodjeljuje poseban tok kontrole. Ako je paralelizam na nivou objekta, tada su dva simetrična objekta dodijeljena dva različita upravljačka toka. Ako su dvije operacije jedne od njih paralelne prirode, tada se raspoređuje između različitih niti.

Paralelizam je povezan sa problemima integriteta podataka i zastojima. Odnosno, treba razviti jasnu strategiju kad god je potrebna istovremenost. Osim toga, mora se identificirati u samoj fazi razvoja i ne može se napustiti u fazi implementacije.

Objektno orijentisane tehnike dizajna, dizajn šare

Prilikom izrade aplikacija usvajaju se neka općeprihvaćena rješenja za određene kategorije problema. To su, na primjer, predlošci dizajna. Može se definisati kao dokumentovani skup gradivnih blokova koji se mogu koristiti u određenim vrstama zadataka razvoja aplikacija.

Neke uobičajene tehnike objektno orijentisanog dizajna (dizajn šeme) mogu se naći u dizajnerskim obrascima:

• Fasadni crtež.
• Pogledajte model razdvajanja.
• Uzorak posmatrača.
• Model kontrolera pogleda modela.
• Šablon Za Proxy.
• Event Management.

Tokom projektovanja šara objektno orijentisanog sistema, događaji koji se mogu desiti u objektima moraju se identifikovati i obraditi u skladu sa tim.

Događaj je specifikacija značajnog događaja koji ima lokaciju u vrijeme i prostor. Postoje četiri tipa koji se mogu modelirati, a to su:

• Objekt nazvan signalom bačen od strane jednog, a zarobljen od strane drugog.
• Pozivni događaj je sinhroni događaj koji predstavlja slanje operacije.
• Proces vremena je predstavljen tokom vremena.
• Promjena događaja-događaj koji predstavlja modifikaciju države.

Obrada graničnih uslova

Faza projektovanja treba da uzme u obzir inicijalizaciju i završetak sistema u celini, kao i svakog podsistema. Različiti aspekti:

• Startup,. tj. prelazak iz neinicijalizovanog stanja u stabilno.
• Gašenje sistema, t. e. zatvaranje svih pokrenutih niti, brisanje resursa i slanje poruka.
• Početna Konfiguracija i rekonfiguracija ako je potrebno.
• Predviđanje kvarova sistema ili neželjenih isključenja.
• Granični uslovi se modeliraju koristeći slične slučajeve upotrebe.

Dizajn objekta

Nakon što je razvijena hijerarhija podsistema, stavke u sistemu se identifikuju i dizajniraju njihovi detalji. Na ovome faza , dizajner radi. Naglasak se prebacuje sa predmetne oblasti na kompjuterske koncepte. Objekti identifikovani tokom perioda analize su potisnuti za implementaciju kako bi se minimiziralo vreme izvršenja, potrošnja memorije i ukupni troškovi.

Dizajn objekta uključuje sljedeće faze:

• Identifikacija.
• Performanse. Modeli za Projektovanje zgrada.
• Klasifikacija operacija.
• Algoritam dizajna.
• Dizajn odnosa.
• Kontrola vanjskih interakcija.
• Grupne klase i asocijacije u module.

Identifikacija objekta

Ovo je prva faza dizajna. Objekti identifikovani tokom perioda objektno orijentisane analize grupišu se u klase i usavršavaju na način da budu pogodni za stvarnu implementaciju.

Funkcije ove faze:

• Identifikacija i usavršavanje klasa u svakom podsistemu ili paketu.
• Definiranje odnosa i asocijacija između skupova.
• Razvoj hijerarhije (generalizacija, specijalizacija i nasljeđivanje).
• Dizajn jedinica.

Predstavljanje Objekta

Kada se klase identifikuju, treba ih prikazati tehnikama modeliranja. Ova faza, zapravo, uključuje izgradnju UML dijagrama.

Postoje dve vrste dizajnerskih modela koje treba proizvesti:

Statički. Za njegovo opisivanje koriste se dijagrami klasa i objekata.

Dinamički modeli. Dijagrami interakcije i stanja koriste se za opisivanje i prikazivanje odnosa između klasa.

Klasifikacija operacija

U ovoj fazi, zadaci koji se obavljaju na subjektima određuju se kombinovanjem tri modela: objektnog, dinamičkog i funkcionalnog. Operacija određuje, šta bi trebalo uradi se, a ne kako.

U tom pogledu treba izvršiti sljedeće zadatke:

• Razvijen je prijelazni dijagram stanja svakog objekta u sistemu.
• Operacije su definirane za događaje primljene po stavkama.
• Identificirani slučajevi kada jedan događaj uzrokuje druge u istom ili drugom objektu.
• Definisane su podoperacije u akcijama.
• Osnovne radnje proširene na dijagrame toka podataka.

Razvoj algoritma

Operacije u objektima definirane su nizom. Algoritam je postupak korak po korak koji rješava problem opisan u operaciji. Fokusirani su na to kako to treba da se uradi.

Možda postoji više od jednog algoritma koji odgovara operaciji. Čim se utvrde alternativne sekvence, bira se optimalni za problematično područje. Metrika za odabir algoritma:

• Složenost kalkulacija. Određuje efikasnost algoritma, u smislu računarskih zahtjeva za vremenom i memorijom.
• Fleksibilnost. Ovaj koncept određuje da li se odabrani algoritam može pravilno implementirati i bez gubitka usklađenosti u različitim okruženjima.
• Jasnoća. Pokazuje da li je odabrani algoritam lako razumjeti i implementirati.

Dizajn odnosa

Ova strategija treba evidentirati u fazi projektovanja objekta. Glavni odnosi uključuju udruženja, agregacije i nasljeđe.

Što se tiče pridruživanja, dizajner treba da uradi sledeće:

• Utvrdite da li je odnos jednosmjeran ili dvosmjeran.
• Analizirajte puteve udruživanja i ažurirajte ih ako je potrebno.

Što se tiče nasljeđivanja, dizajner bi trebao učiniti sljedeće:

• Konfigurirajte klase i njihove asocijacije.
• Definirajte apstraktne sisteme.
• Stvorite uslove tako da je, ako je potrebno, moguće razmijeniti ponašanje.

Implementacija kontrole

Programer objekta može uključiti poboljšanja u strategiju modela državnog dijagrama. Prilikom projektovanja sistema definiše se osnovna politika dinamičkog subjekta.

Pristupi za implementaciju dinamičkog modela:

1. Predstavljaju državu kao lokaciju u programu.

Ovo je tradicionalni pristup zasnovan na procedurama, u kojoj lokacija kontrole određuje državu. Konačna državna mašina može se implementirati kao program. Prelaz formira operator ulaza, glavna kontrolna putanja generiše niz instrukcija, grane stvaraju uslove, a povratne staze formiraju cikluse ili iteracije.

2. Mehanizam mašine za konačno stanje.

Ovaj pristup direktno predstavlja pojam kroz svoju klasu. Izvršava konačni automat kroz skup prijelaza i radnji koje obezbjeđuje aplikacija.

3. Upravljanje-paralelni zadaci.

Ovim pristupom, objekat se implementira kao pitanje u programskom jeziku ili u operativnom sistemu. Ovdje se događaj implementira kao poziv među zadacima, čuva inherentni paralelizam stvarnih objekata.

Klase pakovanja

U svakom velikom projektu važno je pažljivo rasporediti implementaciju u module ili pakete. Prilikom kreiranja objekata grupišu se klase, što omogućava nekoliko društava da rade zajedno.

Različiti aspekti pakovanja:

1. Sakrivanje internih informacija od izgleda. Ovo vam omogućava da tretirate klasu kao" crnu kutiju " i promenite implementaciju bez potrebe za klijentima da modifikuju kod.

2. Konzistentnost elemenata. Dio (kao što je klasa, operacija ili modul) je povezan ako je organizovan prema dogovorenom planu, a svi njegovi dijelovi su neodvojivi, odnosno služe zajedničkoj svrsi.

Osnove izgradnje fizičkih modula:

1. Klase treba da predstavljaju slične stvari ili komponente u istom kompozitnom objektu.

2. Usko povezane klase treba da budu u jednom modulu, a nepovezane ili labavo grupisane klase treba da budu smeštene u zasebne delove.

3. Moduli moraju imati visok nivo interakcije između svojih komponenti.

Optimizacija dizajna

Model analize prikuplja logičke informacije o sistemu, a komponenta projekta dodaje detalje koji podržavaju efikasan pristup njemu. Prije implementacije, program treba optimizirati kako bi izlaz bio efikasniji. Cilj poboljšanja je minimiziranje troškova u pogledu vremena, prostora i drugih pokazatelja.

Međutim, optimizacija dizajna ne bi trebala biti pretjerana, jer su jednostavnost implementacije, mogućnost održavanja i proširivost također važna pitanja. U praksi je to jasno vidljivo. Programeri znaju da je savršeno optimiziran dizajn efikasniji, ali manje za višekratnu upotrebu. Dakle, majstor mora pronaći ravnotežu između njih.

Razne stvari koje se mogu učiniti za poboljšanje:

• Dodajte suvišne asocijacije.
• Izostavite neiskorištene spojeve.
• Optimizirajte algoritme.
• Sačuvajte izvedene atribute da biste izbjegli ponovnu procjenu složenih izraza.

Pogledajmo neke tačke detaljnije.

Dodavanje suvišnih asocijacija.

Tokom optimizacije projekta provjerava se može li stvaranje novih sindikata smanjiti troškove pristupa. Iako ove suvišne asocijacije možda ne dodaju nikakve informacije, one mogu poboljšati efikasnost cjelokupnog modela.

Isključenje neiskorištenih sindikata.

Previše asocijacija može učiniti sistem nerazumljivim i smanjiti ukupnu efikasnost. Odnosno, tokom optimizacije, svi neiskorišteni sindikati se brišu.

Algoritmi za poboljšanje.

U objektno orijentisanim sistemima optimizacija strukture podataka vrši se na osnovu saradnje. Kada je projekat klase kreiran, operacije i algoritme treba poboljšati.

Optimizacija se postiže sa:

• Permutacije redoslijeda računarskih problema.
• Promjene u redoslijedu izvršenja ciklusa.
• Uklanjanje mrtvih putanja u algoritmu.
• Spremanje izvedenih atributa.