Prikaži potpunu verziju : UML modelovanje pomoc
Treba mi pomoc oko jednog zadatka. Radi se o klasnom dijagramu.
Treba da napravim sistem u kojem ce korisnik da ima neke svoje podatke i da moze da se loguje i da radi nesto na sajtu. Sajt ima administratora koji moze da doda i izbrise korisnika u bazu i ima jos neke privilegije kao na slici. Postoji baza podataka u kojoj se dodaju user-i i brisu.
Zanima me da li sam ispravno uradio?
http://postimg.org/image/kn1mhfbv1/
Lucic Nemanja
13.6.2013, 17:47
Za početak, kapiram da bi metode sa get prefiksom trebalo da vraćaju nešto :D.
Imaš Visual Paradigm il tako nešto software koji na osnovu kod sam generiše UML xD :)
Slabo baratam sa UML-om pa mozda ima i banalnih gresaka :)
Cek, zar treba da stavim i to sto vraca?
EDIT: Ne pravim program vec projektujem u jednom UML softveru. Nista ozbiljno, samo domaci radim :p
Bitno mi je samo da ispravim ako ima neka fatalna greska.
Imas par slovnih gresaka.
Pored toga, mislim da ne postoji oznaka 1...1 vec kada je u slucaju samo jedna instanca onda stoji samo 1.
Po ovome kako ja citam sistem je sledeci:
- Imas najmanje jednog usera.
- Imas tacno jednog administratora
- Imas tacno jednu bazu kojoj moze da pristupi samo jedan administrator.
Ako je tako onda je ok ali, po meni bi Administrator trebala da bude klasa koja ce da prosiri klasu User (nije pogresno ni ovako kako je, ali je sa nasledjivanje elegantnije resenje).
Sto se metoda tice, ne znam kako radite i da li trebate da pisete ulazne parametre ili samo nazive metoda. Ali nevezano za ulazne parametre to bi mogao malo da sredis.
Sa stanovista UML diagrama OK je, ali sa stanovista programiranja nema bas mnogo smisla.
Prilozio sam nesto najprostije sto sam mogao. U sustini, imao bi klasu user, koju bi nasledjivali administrator i obican korisnik.
-Administrator pristupa bazi podataka, odakle poziva metode add i remove, i prosledjuje im korisnika kog zeli da doda/obrise.
-Baza podataka sadrzi kolekciju obicnih korisnika, odakle ce se traziti i brisati korisnici.
-U slucaju da imas jednu bazu podataka, verovatno bi bilo zgodno da je realizujes po Singleton sablonu.
A zasto ti Regular user ima vezu sa bazom? Po ovome i on moze da dodaje i brise korisnike.
A zasto ti Regular user ima vezu sa bazom? Po ovome i on moze da dodaje i brise korisnike.
Pogledaj smer strelice. Baza moze sadrzati n usera, dok user moze pripadati samo jednoj bazi. User ne sadrzi bazu, vec joj pripada, pa zato nema pristup. Kada bi se generisao kod, u klasi Regular User ne bi postojalo polje tipa Database, dog bi klasa Database sadrzala listu objekata tipa Regular User.
Edit: Da pojasnim, veza izmedju DataBase i RegularUser predstavlja jednosmernu asocijaciju.
"In a uni-directional association, two classes are related, but only one class knows that the relationship exists".
U sustini, ovde bi bolje stajala kompozicija, s obzirom da, kada bi se obrisala baza podataka, obrisali bi se i svi useri sa nje, ali sam ovo stavio kako bih ga manje zbunio. Znaci, ovde je koriscena jednosmerna asocijacija, ne dvosmerna. :)
Edit2: Verovatna greska je to sto nisam ukljucio administratore unutar baze podataka, tako da je dovoljno samo prevezati jednosmernu asocijaciju na User, umesto na Regular User, sa istim kardinalitetima.
Ako je tako onda si u jednom UML dijagramu predstavio i dijagram klasa i usao u dijagram modela baze.
A cak bi mozda bilo da si zasao i u opis logike time sto si naveo da se brisanjem baze brisu useri :D
One UML diagram to rule them all, One UML diagram to find them,
One UML diagram to bring them all and in the darkness bind them.
I dodatak.
Koja je poenta baze ako ce u memoriji da drzi spisak svih usera. Sta ces da radis ako je facebook u pitanju sa svim tolikim userima u memoriji.
Samo sam mu predstavio bazu podataka kao obicnu memoriju u class diagramu, posto cisto sumnjam da je potrebno da izmodeluje citav sistem elektronske kupovine, a sve bazom podataka, jer verovatno i sam znas da to nije posao za jednog studenta. Naravno da u realnosti nesto ovakvo ne bi funkcionisalo.
ja bih dodao komentar na tipove promenljivih, mislim da je broj telefona bolje da bude string koji se nakon toga parsira ukoliko je potrebno automatsko pozivanje ili sta vec. Ovo se radi iz razloga sto brojevi mogu poceti sa 0 ili ako je neka zemlja u pitanju sa npr +381, takodje korisnici ih mogu unositi sa crticama ili slash-ovima samim tim je lakse da im se da "sloboda" pri izboru formata :) Pol moze biti boolean, mada bi se neko mozda pozvao na diskriminaciju, u slucaju da ne mogu da se dogovore dal ce musko ili zensko biti true ili false, takodje ostaje i problem onih koji ne mogu da se definisu :D Salu na stranu, u kojoj btw, ima pola istine po prici prof sa mog fakulteta, za pol je najbolje koristiti char, pa se moze staviti bilo koje slovo. Nije potrebrno da string zauzima memoriju.
Krilcetov dijagram mi svakako deluje bolje i kritike koje je sam sebi naveo mislim da su na mestu, ja trenutno nemam vremena da se detaljnije upustim u ovo, razmisli malo o metodama koje si naveo i slucajevima koriscenja gledaj da stavis ono sto mislis da je najbitnije prvo. Takodje mozda ne bi bilo lose da ih dokumentujes tj. da se zna koja metoda cemu sluzi :)
-U slucaju da imas jednu bazu podataka, verovatno bi bilo zgodno da je realizujes po Singleton sablonu.
Kasnim 14 dana ali bih da napomenem za ubuduće — vidim da ljudi većinski smatraju da je Singleton šablon loš zbog toga što on zapravo "simulira" globalnu promenljivu, koje su takođe zle zbog toga što razbijaju objektnu-orijentisanost. Korišćenje Singleton-a takođe može otežati predviđanje stanja programa u nekom trenutku jer generalno ne postoji način da se Singleton ponovo kreira od nule, on jednostavno stoji kao stalna instanca. Iako imaš jednu bazu podataka možda bi ipak bilo pametnije da i nju vidiš kao posebnu instancu i nad njom vršiš operacije.
Moze li mi reci neko da li je ispravno uradjen ovaj use case http://postimg.org/image/8c61o383l/
Zanima me ovo: Administrator salje artikle post expresu koji ih dostavlja useru.
Da li je ispravno ovo uradjeno sa obzirom da sistem nesmije sadrzati fizicke dijagrame?
Jako je ovo komplikovano napravljeno, a pored toga i ima par gresaka. Nema potrebe da opisujes tok dogadjaja.
1. Sto se tice isporuke proizvoda, mislim da je dovoljno da tu bude jedan slucaj koriscenja i da Administrator, User i PostExpress budu vezani na njega. Logicno je sta se tu desava, a mozes da stavis u komentar sa strane (postoji poseban box za komentare).
2. Some Article presentation - Some je previse, dosta je samo 'article presentation'. I nisam siguran sta si mislio od maintain? Administrator pravi te prezentacije?
3. Ovaj dole deo je zavrzlama.
- Imas Usera koji ti je povezan sa Order i Register. Pored toga Order je povezan sa Registerom. Tako da je User preko 2 veze povezan sa jednom te istom stvari.
- Onda Order incude-uje Cutomer Data a onda to include-uje Register. Sto nema nikakvog smisla.
- Ako si time sto si povezao Administratora sa Agree with terms pokusao da kazes da je on to napisao, to je nepotrebno za ovaj slucaj koriscenja.
- Za Provide informations via email ne mogu ni da naslutim sta si zeleo da kazes.
Tako da probaj da pojednostavis ovo malo, nemoj da opisujes tok dogadjaja i nemoj da opisujes slucajeve koji su za odvojeni dijagram.
2. Some Article presentation - Administrator odrzava te artikle(apdejtuje, vrsi izmjene).
3.Da bi korisnik mogao da pregleda i narucuje artikle mora da se registruje. unosi podatke i administrator tj server mu salje email za potvrdu registracije(provaid information via email). Kad korisnik potvrdi link moze da koristi sve mogucnosti. To je usecase agree with terms.
Korisnik se registruje, zatim uloguje,bira proizvod, naruci neki proizvod i stize mu na email potvrda od administratora.
Mozda sam malo glupo pisao imena use case dijagrama psoto vidim da si pogresno shvatio neke ili sam ja bas promasio :)
Evo ga i klasni dijagram. http://postimg.org/image/ns9ggmxvx/ |
Napravio sam i sajt kako sve to funkcionise ali nije gotov jos uvijek.
- Veza izmedju Narudzbe i Proizvoda je vise na vise (jedan proizvod moze da bude u vise narudzbina i vise proizvoda moze da bude u jednoj narudzbini).
Osim ako jedna narudzbina moze da ima samo jedan proizvod (mada kako ti sistem ima Shopping Cart onda sumnjam da je to slucaj)
- Preduzece ti ima IdPodaci, a u tabeli Podaci imas JMBG i Broj LK. Tako da ili ta dva polja pomeri pod User ili drugacije to organizuj.
Sto se UML-a tice, stavku broj 3 bi trebao da resis drugacije (veza User-a sa slucajom Register). Jer prica koju sada ovo prica je sledece:
- Korisnik pristupa registraciji i onda pod nekim uslovom moze da pristupi logovanju. Takodje, pod nekim uslovom moze i da pristupi slucaju provide informations via email.
Prica za vezu izmedju User-a i Order-a je:
- Korisnik dolazi do strane za narucivanje, i onda to obuhvata customer data i onda to obuhvata register. Include nije opcioni, on MORA da se dogodi, i ovom vezom hoces da kazes da korisnik svaki put kada pristupi narucivanju mora da se registruje.
I onda opet taj Order, pod nekim uslovom moze da pristupi slucaju provide informations via email.
Evo ti objasnjenja za include i extend:
Relacija obuhvatanja između korisničkih funkcija znači da osnovna korisnička funkcija eksplicitno obuhvata ponašanje druge korisničke funkcije. Obuhvaćena korisnička funkcija nikad ne može da stoji sama za sebe, već se javlja kao deo neke veće korisničke funkcije koja je obuhvata.
Relaciju obuhvatanja treba koristiti da bi se izbeglo da se isti tok događaja opisuje više puta, stavljajući zajedničko ponašanje u posebnu korisničku funkciju.
Relacija obuhvatanja označava se kao zavisnost koristeći stereotip include.
Relacija proširivanja znači da osnovna korisnička funkcija indirektno ugrađuje ponašanje druge korisničke funkcije na mestu koje je indirektno definisano proširujućom korisničkom funkcijom. Osnovna korisnička funkcija može stajati sama, ali pod određenim okolnostima, njeno ponašanje može biti prošireno ponašanjem druge korisničke funkcije. Osnovna korisnička funkcija može biti proširena samo na određenim mestima koja se nazivaju tačke proširenja. Proširivanje se može shvatiti kao da proširujuća korisnička funkcija ubacuje ponašanje u osnovnu korisničku funkciju ukuliko su zadovoljeni odredjeni uslovi.
Relacija proširivanja koristi se za modelovanje dela korisničke funkcije koji korisnik može videti kao opciono ponašanje. Na taj način razdvaja se opciono od obaveznoextend.
Hvala ti puno! Nije ti lako objasnjavati ovoliko sigurno :)
Makao sam ovo vezano za dostavu i za email jer shvatih da to nije dio sistema. Malo mi je glupo da opisujem u sistem kako ce kurir da donese proizvod korisniku kad ustvari to u sistem ne moze da bude. Ista stvar i za email.
Evo sad sam izmijenio i dodao neke stvari pa cak lici na online shopping sajt :)
http://postimg.org/image/7f1f35exx/
Ovako je zamisljeno:
User ima mogucnost da se registruje, kad se registruje da bi kupovao proizvode mora da se uloguje i samim tim prodje proces autentifikacije.
Kad odabere prozviod moze da apdejtuje korpu i da izracuna total costs porudzbina, taksu, koliko kosta shipping, i bira da li da plati paypalom ili kreditnom karticom.
Da li je bolje da napravim za placanje jos 2 aktora. Naprimer Aktor Paypal i Bank i povezem ih sa uslugama, zatim narpavim usecase(check details of card) koji extenduje na placanje paypalom i placanje karticom?
Jednom kada ovo ukapiras ukapiraces ga zauvek, samo polako.
Sta je sad ova Autentifikacija (koja je usput i pogresno napisana)?
1. Usvoji nazive, ako je korisnik oznacen kao User onda to neka i ostane. Nemoj negde User negde Customer.
2. Article presentation moze da ostane
3. Kako korisnik nesto narucuje putem kataloga, logicno ce biti da ce prvo biti vezan za to. Znaci vidi katalog pa tek onda daje narudzbinu (samo ga vezi na ArticleCatalog i obrni strelicu sa PlaceOrder)
4. Osobu Autentifikacija, SingleSignon, UserSignIn, remember me obrisi.
- Autentifikacija nema interakciju sa sistemom, ona je deo sistema.
- Korisnik po ovome moze da se Loguje samo ako hoce da stavi narudzbinu. Predpostavljam da to nije slucaj.
- Opet je korisnik dva puta vezan sa Register. Direktno i preko PlaceOrder-CustomerAuthentication. Ne trebaju ti duple veze.
Evo ti jedan primer da ti pomogne kako da resis Login/Register:
http://www.neowin.net/forum/uploads/post-16640-1207250470.jpg
Bitno je da zapamtis da UML dijagram nije specifikacija projekta, da stvari kao sto su RememberMe nisu bitne osim ako ne opisujes skroz usko taj deo sistema koji ih sadrzi.
Makao sam direktnu vezu sa Usera na placeOrder a stavio sa placeOrder na login. Da davanje ponude zavisi od logovanja Usera kao . Dodao sam jos ove 4 opcije koje user moze da radi kad se loguje.
Purchase history
Update Profile
Add Friend
Selling Product
Jos sam dodao Shippping opcije i da admin mzoe da upravlja userima kad se uloguje. Ovo cu u posebni usecase da razradim da moze da banuje, brise, dodaje, mijenja podatke usera itd...
http://postimg.org/image/4xdcnluol/
1. Dupla veza User-a sa UserLogin, direktno i preko articleCatalog-placeorder.
2. Ne znam zasto je UserLogin extendovan, mislim da bi tu trebao include.
Generalno ideja je OK, iskomplikovao si sa ovim dole login delom sto opet opisujes neke stvari koje nisu bitne za order i mozda im je mesto na odvojenom dijagramu, to nije greska samo komplikuje dijagram.
opet preporuka, kao sa one slike sto sam ti dao u prosloj poruci. Prvo login, onda neka se to grana na purchases history, place order i eventualno ove extendove (addfriend, update profile, itd).
Onda odatle neka se grana place order na sta treba.
vBulletin® v3.8.7, Copyright ©2000-2024, vBulletin Solutions, Inc.