Diagram klas dla expresu do kawy

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 :).

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.

0

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

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.

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)?
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 ;((

1

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

http://www.amazon.com/Agile-Principles-Patterns-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.

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?

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/State_diagram_%28UML%29
http://en.wikipedia.org/wiki/UML_state_machine

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.

0
msm napisał(a):

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

http://www.amazon.com/Agile-Principles-Patterns-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 ?

0
vpiotr napisał(a):

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/State_diagram_%28UML%29
http://en.wikipedia.org/wiki/UML_state_machine

Dzięki za dodatkowe informacje biorę pod uwagę wszystko tylko muszę to jako tako poukladac sobie w całość w dodatku te materiały zawierają inne pod tematy które tez wypadało by chociaż przeczytać żeby mniej więcej wiedzieć co jest piec.

0

Może ktoś oblukać moje najnowsze wypociny ?
Z góry dzięki :)

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