Diagram klas dla expresu do kawy

Odpowiedz Nowy wątek
2015-02-11 22:54
0

Witam, chciałbym co nieco się dowiedzieć o tym jakże uml-u. Mianowicie rozkminiam diagram klas gdzie też potrzebuje kilku wytłumaczeń na "chłopski rozum " czyt. jak dla "debila". Jestem początkujący więc reakcje typu idź poczytaj nie będą na miejscu bo gdybym to rozumiał nie pytał bym o to na forum... Mój diagram dla expresu do kawy wygląda jak na załączniku: nie mam pojęcia czy takie rozwiązanie jest jako tako wykonalne, a już kompletnie nie mam pojęcia jak robić połączenia. Za podejście z dystansem i wytłumaczenie dzięki :).

Pozostało 580 znaków

2015-02-12 02:18
Nooom
0

Postaraj się to wykonać w oparciu o możliwość implementacji. Masz wodę i kawę w kilku klasach. Zrób z tego obiekty które będą w składnikach kawy. Urządzania typu grzałka czy ekspres nic nie mówią o tym co mają robić? Tzn jako obiekty są zbędne.
Poczytaj o wzorcach projektowych. Np. wzorzec dekorator ( obiekt kawa możesz dekorować obiektem mleko itp ), rodzaje kawy nie są atrybutami. Mozesz zrobić ogólną klasę kawa i dziedziczące klasy specjalizujące latte, machiatto.
UML sluzy raczej do pokazywania zaleznosci miedzy klasami itp a nie wjeb... wszystkiego w okienka i danie atrybutów - czesci skladowych. Wypozycz Ulmana, zobacz przykładowe wzorce i przykłady.

Pozostało 580 znaków

2015-02-12 02:20
Nooom
0

Wielkość kawy to obiekt? Czy może atrybut? Pomyśl

Pozostało 580 znaków

2015-02-12 02:51
0
class RodzajKawy {
- latte: int
- macchatto: int
- expresso: int

+ wybierz(): void
}

to nie ma sensu.
Metoda wybierz nie ma żadnych argumentów, więc skąd wiadomo co wybrać?
A i robienie 3 oddzielnych zmiennych latte/machatto/expresso, w dodatku o typie int jest bez sensu (jakiś enum? jakaś agregacja? już więcej sensu by miało).

poza tym ten diagram nic nie robi ani nic nie pokazuje, bo nie ma strzałek/żadnej interakcji między obiektami/klasami.


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 3x, ostatnio: LukeJL, 2015-02-12 02:57

Pozostało 580 znaków

2015-02-12 09:39
0

Klasy powinny mieć:

  • atrybuty
  • funkcje / metody operujące na tych atrybutach

A teraz podchwytliwe pytanie:

  • jak w świetle powyższego będzie wyglądała metoda "wybierz" (np. w RodzajKawy)?

Szacuje się, że w Polsce brakuje 50 tys. programistów
edytowany 1x, ostatnio: vpiotr, 2015-02-12 09:40

Pozostało 580 znaków

2015-02-12 20:12
0

Wedle podpowiedzi Noom zrobiłem to po jego myśli (jak w załączniku) z tym że nie rozumiem rodzaju relacji między nimi chodzi mi o agregacje w tym momęcie może mi ktoś ją inaczej wyłożyć ? No i oczywiście czy aby dobrze się dostosowałem do wzorcu ?

A teraz podchwytliwe pytanie:

  • jak w świetle powyższego będzie wyglądała metoda "wybierz" (np. w RodzajKawy)?

Metoda wybierz wedle mojego zapatrzenia miała być wspólną metodą dla wszystkich klas gdzieś przeczytałem że jest to najlepsze rozwiązanie aby wszystkie klasy miały wspólny "element" więc chciałem z założenia aby metoda wybierz była wszędzie :P
Drug rozkminą była myśl aby zrobić ich dwie sztuki jedna dla wielkości(ilości kawy do zrobienia) a druga dla rodzaju kawy gdzie bliżej miały być określone podstawowe recepty dla danego rodzaju kawy :)
Jednak z tego co widzę oba założenia były błędne ;((

edytowany 1x, ostatnio: Gjemper, 2015-02-12 20:28

Pozostało 580 znaków

2015-02-13 00:28
msm
1

Jeśli dobrze pamiętam, tutaj był bardzo ciekawy case architektury firmwaru ekspresu do kawy:

http://www.amazon.com/Agile-P[...]rns-Practices-C/dp/0131857258

Trochę inna działka niż to co Ty tworzysz, bo klasa reprezentująca rodzaj kawy w programie kontrolującym ekspres nie ma sensu ;)
Ty masz raczej diagram klas zawartości kubka z kawą.

Są jakieś use casy do tego ekspresu, czy to sztuka dla sztuki na poziomie "Sowa dziedziczy z ptaka dziedziczy ze zwierzęcia"? Jeśli to pierwsze, co powinny robić te klasy po zaimplementowaniu (tzn. do czego by służyły? Przykład kodu opcjonalnie)

Co oznaczają strzałki na tym diagramie? Bo tradycyjnie w diagramie klas oznaczają dziedziczenie (tzn. generalizację), a z tego wynika że:

  • Latte, Machatto, Expresso są kawą (to jest ok z punktu widzenia designu, chociaż to czysto akademickie modelowanie rzeczywistości - w praktyce to nie ma sensu. No ale jak to na studia to pewnie takie rozwiązanie jest spodziewane)
  • Kawa jest zbiornikiem (czyli Latte, Machatto i Expresso też są zbiornikami) - ?
  • Zmielkawe (co to w ogóle jest?) jest zbiornikiem - ?
  • Mleko jest zbiornikiem - ?
  • Zbiornik jest zbiornikiem przechowującym inne zbiorniki (będące instancjami zbiornika typu kawa)
  • atrybuty są typu package zamiast private (~ zamiast -) - to celowo?

Jak przy zmielkawe jesteśmy - cóż to w ogóle jest? Może gdyby zmienić nazwę na "Młynek do kawy" miałoby to większy sens (wtedy mamy młynek do kawy będący zbiornikiem).

Ogólnie trochę namieszane.

rzeczywisty ekspres miałby prostą maszynę stanów i kod pisany na pałę bez bawienia się w obiektowość i dziedziczenie... - Azarien 2015-02-13 01:55
pewnie tak, ale tak czy inaczej rozdział warty polecenia. Dziedziczenia nie ma. - msm 2015-02-13 03:43

Pozostało 580 znaków

2015-02-13 02:46
0

Na pewno potrzebujesz klasy sterujące wszystkimi elementami mechanicznymi i grzałkami. Cos do obslugi wyswietlacza i panelu do pisania. Z wyższego poziomu to potrzebujesz to co napisałeś wyżej czyli:
Ekspres - ZrobKaweA, ZrobKaweB...

rozbij sobie proces robienia kawy na etapy i bedziesz wiedzial jakie klasy zrobic. Generalnie wydaje mi sie ze za duzo tutaj kombinowania nie ma. Swoja droga to jakiego uC uzywasz do zrobienia ekspresu?


░█░█░█░█░█░█░█░█░█░█░█░

Pozostało 580 znaków

2015-02-13 13:49
1

W tym diagramie właściwie wszystko jest źle.
Od siebie mogę polecić "Rusz głową. Wzorce projektowania" gdzie jest pokazane jak robić pizze (dość podobne).

Automaty tego typu modeluje się również (lub głównie) przy pomocy diagramów stanu:
http://en.wikipedia.org/wiki/Statediagram%28UML%29
http://en.wikipedia.org/wiki/UML_state_machine


Szacuje się, że w Polsce brakuje 50 tys. programistów

Pozostało 580 znaków

2015-02-17 14:09
0

Od pisze na to na co łatwiej mi udzielić informacji bo dużo materiału do obczajenia mi zadaliscie mianowicie.

krwq napisał(a):

Na pewno potrzebujesz klasy sterujące wszystkimi elementami mechanicznymi i grzałkami. Cos do obslugi wyswietlacza i panelu do pisania. Z wyższego poziomu to potrzebujesz to co napisałeś wyżej czyli:
Ekspres - ZrobKaweA, ZrobKaweB...

rozbij sobie proces robienia kawy na etapy i bedziesz wiedzial jakie klasy zrobic. Generalnie wydaje mi sie ze za duzo tutaj kombinowania nie ma. Swoja droga to jakiego uC uzywasz do zrobienia ekspresu?

Rozbicie na etapy tworzenia kawy w Expresie nie byłoby diagramem czynności juz ? Edytora jako takiego nie używamy jade na NetBeans 6.1 tam UML jest wbudowany nie trzeba ściągać pluginów.
Teraz trochę o UML i diagramie class ma on wyglądać bardziej jak czynności z tym ze ma być bardziej rozbudowany (rozumiem to tak ze mam bazować na diagramie czynności)?? Bo tak trochę zaczynam bladzic wydaje mi się ze ma to trochę inaczej wygladac.

Ja widzę diagram czynności tak jak w załączniku który z nich można określić jako dobry ?
w drugim ma być dodaj składniki zamiast wsyp.

edytowany 3x, ostatnio: Gjemper, 2015-02-17 16:22

Pozostało 580 znaków

2015-02-17 14:16
0
msm napisał(a):

Jeśli dobrze pamiętam, tutaj był bardzo ciekawy case architektury firmwaru ekspresu do kawy:

http://www.amazon.com/Agile-P[...]rns-Practices-C/dp/0131857258

Trochę inna działka niż to co Ty tworzysz, bo klasa reprezentująca rodzaj kawy w programie kontrolującym ekspres nie ma sensu ;)
Ty masz raczej diagram klas zawartości kubka z kawą.

Są jakieś use casy do tego ekspresu, czy to sztuka dla sztuki na poziomie "Sowa dziedziczy z ptaka dziedziczy ze zwierzęcia"? Jeśli to pierwsze, co powinny robić te klasy po zaimplementowaniu (tzn. do czego by służyły? Przykład kodu opcjonalnie)

Co oznaczają strzałki na tym diagramie? Bo tradycyjnie w diagramie klas oznaczają dziedziczenie (tzn. generalizację), a z tego wynika że:

  • Latte, Machatto, Expresso są kawą (to jest ok z punktu widzenia designu, chociaż to czysto akademickie modelowanie rzeczywistości - w praktyce to nie ma sensu. No ale jak to na studia to pewnie takie rozwiązanie jest spodziewane)
  • Kawa jest zbiornikiem (czyli Latte, Machatto i Expresso też są zbiornikami) - ?
  • Zmielkawe (co to w ogóle jest?) jest zbiornikiem - ?
  • Mleko jest zbiornikiem - ?
  • Zbiornik jest zbiornikiem przechowującym inne zbiorniki (będące instancjami zbiornika typu kawa)
  • atrybuty są typu package zamiast private (~ zamiast -) - to celowo?

Jak przy zmielkawe jesteśmy - cóż to w ogóle jest? Może gdyby zmienić nazwę na "Młynek do kawy" miałoby to większy sens (wtedy mamy młynek do kawy będący zbiornikiem).

Ogólnie trochę namieszane.

Jeżeli chodzi o atrybuty przeoczylem fakt iz były zaznaczone jako package i wydaje mi się ze źle zinterpretowałem diagram class bo wydawało mi się ze ma być on dla gotowego produktu a nie dla calej maszyny gdzie chce zaznaczyć ze ma to być domowy prosty express do kawy.

Zbiornikiem jest mleko które się dodaje na końcu w zależności od wyboru kawy natomiast zmiel kawę ma być osobna klasa która przynależy do młynka.
Czy atrybuty muszą być jako typ private nie mogą mieć dostępu jako chronione ?

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0