Diagram stanów.

0

Witam,

mam problem z przedmiotem Inżynieria Oprogramowania. Nie mogę już 3 raz zaliczyć diagramów stanów. Dodam, że jestem w tym temacie totalnie zielony. Poniżej dodaje przykładowy diagram stanów i diagram klas dla mojego projektu.

user image

A tutaj diagram klas:

user image

Sorki, że zrobione to jest w visio i na diagramie klas średnio cokolwiek widać. Proszę go nie komentować bo mimo, że dostałem za niego 4 to wydaje mi się, że więcej tam jest źle niż dobrze :)

A teraz do rzeczy. Diagram stanów został zrobiony dla klasy Katalog. Profesor stwierdził, że nie może być przejścia do pseudostanu początkowego. Mogę to rozwiązać tworząc nowy stan o nazwie np. "Wybór" i do niego wracać po naciśnięciu klawisza "Enter"? Następnie wykładowca ciągle się mnie pyta o różnicę między akcją, operacją i zdarzeniem. Z przykładowych materiałów dowiedziałem się, że powinienem postępować według schematu: Trigger[Guard]/Effect czyli zdarzenie Trigger wywołuje akcję Effect pod warunkiem Guard. Nie do końca wiem jak to zastosować, mógłby ktoś mnie naprowadzić jak to powinno wyglądać np. dla jakiegoś przykładowego stanu.
Ostatnio nie miałem czasu i na szybko zrobiłem coś żeby zastosować się do tego schematu co widać na przykładzie stanu Dodawanie. Działa to trochę na siłę: zdarzenie dodaj_pozycje() wywołuje tak jakby stan Dodawanie pod warunkiem wyboru dodawania przez klienta (nigdzie tego nie znalazłem ale z przykładów intuicyjnie odczytałem, ze zaznaczając w stanie akcje do/jakaś_akcja jest ona zawsze wykonywana w danym stanie). Nie zaznaczyłem akcji na przejściu bo znalazłem kilka przykładów, w których autorzy tez ich nie zaznaczyli. Widzicie dla mnie cały UML jest tak chaotyczny jak ta wypowiedz, która właśnie czytacie :) Boje się dodać więcej akcji w stanach żeby nie okazało się, że czegoś brakuje na diagramie klas, gorzej jeśli to jest konieczne. Podsumowując, patrząc na ten diagram może ktoś mi powiedzieć co powinno być w tych stanach a co na przejściach dla jakiegoś przykładowego stanu? :)

pozdr
Mofa

0

na pierwszy rzut oka widze jeden podstawowy blad:

-Z kazdego stanu musimy wyjsc do sprzetu wyjsciowego (u Ciebie zawsze wracamy na poczatek, nie ma wyjscia z tego stanu).
-musi byc tylko 1 stan wejsciowy i stan wyjsciowy.

0
HideYoshi napisał(a)

-Z kazdego stanu musimy wyjsc do sprzetu wyjsciowego (u Ciebie zawsze wracamy na poczatek, nie ma wyjscia z tego stanu).

To zinterpretowałbym tak: Brakuje na diagramie stanu początkowego i końcowego. Robimy stan początkowy, czyli jakby wejście w diagram, z którego bezpośrednio przejdzie do naszego głównego węzła, który - jak można się domyślić - reprezentuje menu glowne programu; i oczywiscie stan koncowy, do ktorego warunkiem przejscia bedzie wybor opcji typu "koniec pracy".

HideYoshi napisał(a)

-musi byc tylko 1 stan wejsciowy i stan wyjsciowy.
Czemu? Sytuacja jest dla mnie jak najbardziej logiczna i poprawna: wszystkie funkcje po wykonaniu powodują powrót programu do stanu podstawowego, którym jest oczekiwanie w menu głównym. To zawsze jest ten sam stan. Natomiast z tego menu do innych stanów może być wiele wyjść pod warunkiem - który jest tu spełniony - że każde z nich ma jednoznacznie określone, wykluczające się wzajemnie warunki. Musi być jednoznaczność co do tego, do jakiego stanu przechodzimy w danej sytuacji.

0

Ja też się od zawsze uczyłem, że jest tylko jeden stan początkowy i jeden stań końcowy. Nie wiem dlaczego, może dlatego że piszemy program, czyli coś co ma się faktycznie skończyć.

Być może mnie też uczono, ale maszynę stanów zawsze rozpisywaliśmy tak aby miała szansę się skończyć.

0
yyy napisał(a)

Ja też się od zawsze uczyłem, że jest tylko jeden stan początkowy i jeden stań końcowy.
Początkowy i końcowy - tak :)
Ale tu mówiłęm o wejściach i wyjściach z poszczególnych stanów - tak zrozumiałem cytowany tekst przedmówcy. Początek i koniec rzecz jasna powinien jakiś być (brakło :)) i wskazane jest by były to stany pojedyncze.

Pewnie faktycznie mocno źle zinterpretowałem pojęcie ;)

0

Brakuje bloków decyzyjnych ("czy istnieje", "wybór" powinny być blokami decyzyjnymi).

Diagram powinien się zaczynać tak:Start ----> [menu] -----> <wybór> gdzie [xxx] to blok stanu/czynności, a <xxx> to blok decyzyjny. Wszystkie strzałki które teraz rozchodzą się od startu powinny rozchodzić się od bloku decyzyjnego <wybór>, a te co się schodzą do startu powinny schodzić się do bloku [menu].

Przy strzałkach nie pisze się czynności tylko w blokach - "usuń_xxx", "szukaj_xxx" itp powinny być blokami.
Przy strzałkach pisze się jedynie odpowiedzi na blok decyzyjny.

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