Domain Model: Model Domena

Summary

This document introduces the domain model and conceptual model for object-oriented analysis. It explains the concepts, procedures, and UML diagrams used for software design. The document includes details about classes, attributes, and relationships, featuring an online shop example.

Full Transcript

Politehnički fakultet Univerzitet u Zenici Domain model Model domena doc.dr. Mujo Hodžić Analiza i dizaj softvera 1 Domen model: Zašto, kada i smjernice ...

Politehnički fakultet Univerzitet u Zenici Domain model Model domena doc.dr. Mujo Hodžić Analiza i dizaj softvera 1 Domen model: Zašto, kada i smjernice  Zašto: -Modeliranje domena pomaže nam identificirati relevantni koncept i ideje domena-domen ideje.  Kada: - Modeliranje primjenom domen modela, vrši se tokom objektno orijentirane analize.  Smjernice: Stvara se model domene uglavnom za zadatke kada pravimo ručni koncept u papirnoj formi. Analiza i dizaj softvera 2 Domen model/konceptualni model - procedura(slijed koraka)  Domen model ilustrira bitne koncepte u domenu za koji je predstavljen zahtjev ili specifikacija zahtjeva.  Domen model naziva se i konceptualni model ili domen objektnog modela ili objektni model analize.  Domen model stvara se tokom objektno orijentirane analize za raščlanjivanje domena na koncepte ili objekte u stvarnom svijetu.  Model bi trebao identificirati skup konceptualnih klasa (Model domene je iterativno dovršen.)  Ovaj model može biti osnova za dizajn softvera (Između dizajna i specifikacije/zahtjeva). Analiza i dizaj softvera 3 Zahtjev Vizuelizacija modela u UML-u -Vizualni prikaz konceptualnih klasa ili objekta stvarne situacije u domenu 3 -U UML-u Domen model je predstavljen sa skupom 1 dijagrama klasa bez metoda Dva pristupa do konačnog rješenja 2 1. Na osnovu Use case dijagrama kreira se domain model te na osnovu njega se kreira dizajn model, ili 1 3 2. Na osnovu Use case dijagrama kreiramo Domain model, a na osnovu njega dalje se kreira sekvencijalni dijagram te onda se kreira Dizaj modela 3. Use case-sec dijagram-dizajn model Analiza i dizaj softvera 4 Korištenje koncepta klase u Domen modelu  Koncept Klase Ideja Prodaja Stvari Objekti Koncept- simbol  Riječi ili slike koje predstavljaju konceptualnu klasu Vizuelni prikaz Koncept- namjera Dijagram  Namjera Sveobuhvatna definicija  Proširenje Koncept- proširenje Skup primjera koje konceptualna klasa primjenjuje Analiza i dizaj softvera 5 Skiciranje Domen modela  U Domen modelu(Koncept) nisu definirane nikakve operacije. Samo su definisani;  objekti domena - konceptualne klase,  veze između njih  atributi konceptualne klase mogu biti predstaljeni  UML - Specifikacija slučaja upotrebe, nam omogućava da dođemo do domen modela.  Model domena, kao i dijagram slučaja upotrebe, kreiraju se u početnoj fazi razvoja softvera. Pretpostavka je da će naš sistem biti programiran na objektno orijentirani način i prema tome dizajniran pomoću objektno orijentiranog pristupa. Analiza i dizaj softvera 6 - Osnovni entitet je u tom slučaju klasa. Prototip(skica) na papiru kao domen model(Konceptualni model)- primjer Analiza i dizaj softvera 7 Skiciranje Domen modela- primjer rasprodaje Rasprodaja Prijava Ime asocijacije Mnoštvo ili višestrukost Analiza i dizaj softvera 8 Skiciranje Domen modela- vrste veza Asocijacija Konceptualne klase N Konceptualne klase T N  Asocijacije trebaju imati isto ime kao klase  Mnogobrojnost ili višestrukost treba biti N jednostavna u ovoj fazi razmišljanja:  Konceptualno modeliranje ne mora biti precizno N N N Analiza i dizaj softvera 9 Skiciranje Domen modela  Pristup baziran na konceptualnim klasama  Klase(konceptualne) takođe uključuju atribute neohodne za domen (djelokrug aktivnosti)  Atributi trebaju imati jednostavne tipove ( broj, tekst, binary....) Ovo nije bitno kod ovog stanja, što znači da se o njima može zaključiti, pomoću formule, od ostalih atributa ili asocijacija KLASE-PRIMJER Analiza i dizaj softvera 10 Primjer1 mogućeg scenarija - procesno opisan 1. Kupac dolazi do blagajne s robom / ili uslugama koje koristi. 2. Blagajnica započinje novu prodaju 3. Blagajnica ulazi u identifikator predmeta 4. Sistem bilježi stavku prodaje i prikazuje opis predmeta, ukupnu trenutnu cijenu – iznos Prodavac ponavlja korake 2 -3 dok ne završi sve 5. Sistem prezentuje konačnu cijenu nakon uključenja svih taxi –porez 17% 6. Kasirka prezentuje račun korisniku i traži da plati 7. Korisnik plaća a sistem obrađuje plaćanje 8. Sistem bilježi kompletnu prodaju i plaćanje te šalje info u centralni obračunski centar 9. Sistem izdaje račun 10. Korisnik odlazi sa računom, zadovoljan ili ne Analiza i dizaj softvera 11 Primjer mogućeg scenarija 1. Kupac odlazi do blagajne s robom / ili uslugama koje koristi da odjavi. 2. Blagajnica započinje novu prodaju 3. Blagajnica ulazi u identifikator artikla 4. Sistem bilježi stavku retka prodaje i prikazuje opis artikla, ukupnu trenutnu cijenu – iznos Prodavac ponavlja korake 2 -3 dok ne završi sve artikle 5. Sistem prezentuje konačnu cijenu nakon uključenja svih taxi -porez 6. Kasirka prezentuje račun korisniku i traži da plati 7. Korisnik plaća a sistem obrađuje plaćanje 8. Sistem bilježi kompletnu prodaju i plaćanje te šalje informacije u centralni obračunski centar 9. Sistem izdaje račun 10. Korisnik odlazi sa računom, zadovoljan ili ne Analiza i dizaj softvera 12 Primjer- 2 moguća scenarija -Product Description opis na dva načina -Store opis na dva načina 2) 1) Identičan opis Identičan opis 2a) 1a) 1=1a 2=2a - Klasa (Naziv, atribut, operacije) Analiza i dizaj softvera 13 Domen model–objektni pristup  Domen model je bitan proizvod objektno- orijentirane analize  Use-case model je veoma bitan, ali ne spada u proizvode objektno orijentsane analize.  Proces "objektno orijentirane analize" fokusiran je na pronalaženje i opis objekata ili koncepata iz domene problema.  Domen model podrazumijeva specifikaciju najvažnijih osobina-atributa objekata i interakcija između objekata.  Objektno orjentisana analiza ima naglasak na pronalaženju i opisivanju objekata ili koncepata u domenu problema Analiza i dizaj softvera 14 Domain model- konceptualne klase - Domen model predstavlja konceptualne klase iz stvarnog svijeta. - Domen model NE predstavlja softverske komponente. - Domen model nije skup dijagrama koji opisuje softverske klase ili softverske objekte U UML notaciji za izradu domain modela koristi se notacija dijagrama klasa na kojem se ne prikazuju operacije Analiza i dizaj softvera 15 Domen model-sadržaj objekta  Domen model može sadržavati: – objekte ili konceptualne klase iz domena problema, – veze između konceptualnih klasa i – atribute konceptualnih klasa.  Domain model predstavlja pojave iz realnog svijeta, a ne softverske komponente (C#, C++ ili Java klasa),  Slijedeće stvari nisu prikladne za domain model: – softverski pojmovi: window, database, itd – zaduženja (metode ili operacije) DOMEN MODEL-Koristi se u komunikaciji sa ne tehničkim zaiteresiranim stranama u procesu usaglašavanja prijedloga konceptualnog rješenja Analiza i dizaj softvera 16 Konceptualna klasa- element dijagrama u domen modelu  Klasa u implementaciji – element dijagrama klasa Klasa u implementacijji Konceptualna klasa Atributi Atributi Operacije 17 Koncept klase Konceptualne klase su: - Ideje i - stvari ili predmeti u domenu objekata.  Konceptualna klasa ima simbol koji predstavlja intenciju klase i proširenje koje definiše skup primjera za koje se primjenjuje konceptualna klasa.  intension = značenje  extension = izlaz  Konceptni domen / konceptualne klase nisu softverski objekti kao npr. u Javi, C #, Rubyu,...! Analiza i dizaj softvera 18 Identifikacija konceptualnih klasa Za identifikaciju konceptualnih klasa mogu se koristiti dvije tehnike: 1.korištenje liste kategorija konceptualnih klasa i/ili, 2.identifikacija imenica. Analiza i dizaj softvera 19 Oblasti u kojima se koristi UML-domen model  UML je u glavnom namijenjen sistemima koji se oslanjaju na programsku podršku. On se efikasno koristi u sledećim područjima: Transport Poslovni informacijski sistemi Finansijske usluge Sistemi odbrane/avio nautika Telekomunikacije Distribuirane mrežne usluge Medicinska elektronika -telemedicina Svera nauke i obrazovanja Prodaja....  UML nema ograničenje na modelovanje programske podrške.  Dovoljno je primjenljiv i za modelovanje ostalih sistema, npr: - Modelovanje ponašanja zdravstvenog sistema pacijenata - Protokol dokumenata i podataka u pravnom sistemu, - Dizajn različitih sklopova-elektronika,modelovanje Analiza i dizaj softvera čipova 20 Korištenje liste kategorija konceptualnih klasa–prijava ispita studenata Kategorija koncept. klasa Primjeri za sistem studentskih službi fizičke ili opipljive stvari Indeks, Prijava opisi ili specifikacije stvari mjesta Studentska služba, dekanat transakcije Prijava ispita, upis godine, ovjera semestra uloge osoba Referent studentske službe, Nastavno osoblje, Student stvari koji sadrže druge objekte Nastavni Plan (sadržaj predmete) ("containers") objekti unutar drugih objekata Predmet (dio nastavnog plana) drugi računari ili eksterni sistemi Računovodstveni software apstraktne imenice organizacije, dijelovi Fakultet, Univerzitet, Odsjek, Studijska grupa organizacije događaji Ispit, upis pravila UslovZaIspit, UslovZaUpis katalozi MaticnaKnjiga (kao katalog studenata) zapisi o nekom događaju IzvjestajSaIspita finansijski instrumenti i usluge Analiza i dizaj softvera IzvodIzBanke, Uplatnica 21 Kako kreirati domain model?  Pri izradi domain modela mogu se primijeniti slijedeći koraci: – Napraviti listu kandidatskih konceptualnih klasa korištenjem kategorija ili: – identifikacijom imenica iz "use-case" opisa; – Ucrtati konceptualne klase u domain model; – Dodati veze koje je neophodno "pamtiti" u memoriji; – Dodati atribute koji su neophodni za zadovoljavanje zahtjeva iz "use-case" dokumenata  Izbjegavati način razmišljanja koji je karakterističan za sekvencijalni razvojni proces.  Ne treba pokušavati napraviti detaljan ili "pravilan" model!  Domain model nikad neće biti savršen, jer predstavlja „skicu“.  Takvo razmišljanje vodi stanju koje je poznato kao "analysis paralysis" (paraliza u analizi).  Najčešća pogreška pri kreiranju domain modela je kada se jedna konceptualna klasa predstavi kao atribut. Primjenom slijedećeg pravila može se izbjeći takva greška: – Ako o nekom objektu X ne razmišljamo kao o običnom broju ili tekstu onda je to najvjerojatnije konceptualna klasa X, a ne atribut. Analiza i dizaj softvera 22 Konceptualne klase „klase bez metoda”- tj klasa bez atributa Analiza i dizaj softvera 23 Konceptualne klase sa atributom  klasa sa atributom, bez metoda  Nije neophodno deklarirati vidljivost atributa (privatni, javni …) Atributi Analiza i dizaj softvera 24 Identifikacija veza u domen modelu Kategorija veze A je transakcija povezana sa drugom transakcijom B A je artikl ili usluga koja pripada transakciji B A je fizički ili logički dio od B A B 1 1 A je fizički ili logički sadržan u okviru B A je opis ili specifikacija za B A se zapisuje u B A je član od B A je organizacijska jedinica od B A koristi, upravlja ili posjeduje B Analiza i dizaj softvera 25 Identifikacija veza u domen modelu-primjer  Zajedničke veze Asocijacije:  A je poddio / člana B. (Predmet prodaje - prodaja)  A koristi ili upravlja B. (Blagajna - Registrirajte se, pilot- avion)  A komunicira s B. (student-profesor)  A je transakcija vezana za B. (Plaćanje -Prodaja)  A je pored B. (Vrijeme rasprodaje - Raspored rasprodaje)  A je u vlasništvu B. (avion-aviokompanija)  A je događaj vezan za B. (Prodaja-trgovina) Analiza i dizaj softvera 26 Veza asocijacije  Primjer funkcionalnosti jednog dijela procesa (podproces) naručivanja jela Naziv veze asocijacije Atributi Brojnost veze- Višestrukost Objekti Konceptualne klase (Multiplicity) Ako je veza usmjerena predstavlja smjer čitanja veze (Navigability) Uloga konceptualne klase (role) se navodi na vezi pored konceptualne klase Analiza i dizaj softvera 27 Atributi - konceptualna predstava klase - Primjer korištenjem alata- Visual Paradigm Analiza i dizaj softvera 28 Atributi-konceptualna predstava Analiza i dizaj softvera 29 Atributi sa "/" su "izvedeni atributi Analiza i dizaj softvera 30 Atributi sa "/" su "izvedeni atributi Analiza i dizaj softvera 31 Kako kreirati koncept domen modela-procedure. Analiza i dizaj softvera 32 Kako kreirati koncept domen modela-procedure  Utvrđivanje imeničkih fraza kako bismo pronašli pojmovne za definiciju konceptualnih klasa. Analiza i dizaj softvera 33 Kako kreirati koncept domen modela-procedure  Definisane imenične fraze te definišemo kandidate zakonceptualne klase. Analiza i dizaj softvera 34 Kako kreirati koncept domen modela-procedure  Potvrda kandidata za domen model Analiza i dizaj softvera 35 Smjernice kada uključiti kandidata konceptualnih klasa koja izvještava o podacima u model domene.  Općenito, nije korisno ako su sve informacije izvedene ili duplicirane iz drugih izvora  Ako ima određenu semantiku w.r.t. posao, pa onda ih treba uključiti Analiza i dizaj softvera 36 Smjernice kada uključiti kandidate konceptualnih klasa koje daju podatke u domenu model-prethodni primjer  “Činjenice”:  Identificirani kandidatski konceptualni razredi:... Potvrda,...  Račun je samo izvještaj o prodaji i plaćanju...  Treba li potvrda biti u modelu domene? Pa, ovisi…. ... ako samo uzmemo u obzir trenutni scenarij, onda račun ne bi trebao biti dio modela domene; potvrda je samo izvještaj; ... ako uzmemo u obzir i kako postupati s povratima novca, onda račun predstavlja važan koncept sam po sebi; Zahtjevi Domen modela  Što možemo reći na zakonska ograničenja...? Analiza i dizaj softvera 37 Smjernice kada uključiti klasu opisa u model domene  Klasa opisa sadrži informacije koje opisuju nešto drugo. Primjeri:  opis proizvoda bilježi cijenu, sliku i tekst proizvoda artikal;  opis avio leta sadrži informacije o letu (broj), izvornom polazištu i ciljno odredište Analiza i dizaj softvera 38 Smjernice kada uključiti klasu u opis model domena  Modelu domene treba dodati klasu opisa kada: 1. Mora postojati opis predmeta ili usluge, neovisno o trenutnom postojanju bilo kakvih primjera te stavke ili usluge. 2. Kada brisanje slučajeva stvari koje opisuju, rezultira gubitkom informacije koje treba čuvati, ali su bile netačno povezane s izbrisanom stvari. 3. Kada se smanjuju suvišne ili duplicirane informacije Analiza i dizaj softvera 39 1. Primjer – online shop Identificirane konceptualne klase modela za on-line shop Nazivi objekata koji se mogu koristiti tokom online trgovine Analiza i dizaj softvera 40 2. Domen model– Primjer-online trgovina Identificirane veze i mnogostrukost veza (višestrukost veza), bez atributa Analiza i dizaj softvera 41 3.Primjer Domen modela-SKICA SISTEMA – online shop Identificirani atributi konceptualnih klasa Analiza i dizaj softvera 42 Konceptualna klasa i Klasa specifikacije Klasa spesifikacija Konceptualna Klasa Analiza i dizaj softvera 43 Dijagram KLASA-Primjer Dizajna sistema Analiza i dizaj softvera 44 Pitanja - Da li su elementi konceptualne klase ujedno i elementi klase - Na koji način se u UML-u Domen model predstavlja - Na koji način se predstavljaju softverske komponente u Domen modelu - Šta koncept klase treba da sadrži -Da li onceptualno predstavljanje-modelovanje treba biti detaljno - Skicirati sve moguće pojave višestrukosti kod asocijacije - Koje su karakteristike domain modela Analiza i dizaj softvera 45 Primjeri https://www.uml- diagrams.org/examples/hospital-domain- diagram.html https://www.uml- diagrams.org/examples/hospital- management-example.html Analiza i dizaj softvera 46