MagazineManager – czas zamodelować cz. 2

Opublikowane przez Piotr Wachulec w dniu

Byenveni! (kreolski)

Niedziela, 06.04, mija szósty tydzień Daj się poznać. Jesteśmy za półmetkiem, ale mimo to spokojnie idziemy z projektem. Ważniejsze jest dla mnie przekazanie treści i dobre zaprojektowanie, niż naklepanie tego bez przemyślenia z niskiej jakości kodem w dwie noce 🙂 Niestety ten tydzień przyniósł za sobą wiele tematów do ogarnięcia i powstał tylko wpis, który aktualnie czytasz, drogi Czytelniku. Ale wiesz co jest najważniejsze dla mnie? Że ciągnęło mnie do napisania kolejnego wpisu i strasznie mnie złościło, że musiałem w tym tygodniu pofolgować… Uważam to za mój mały wielki sukces 🙂 Dlaczego zapytasz? Bo pomału wchodzi mi w krew prowadzenie tego skromnego przybytku. Czuję też, że dzięki temu się rozwijam i żałuję, że nie mogę poświęcić tyle czasu ile bym chciał, ale żeby tak było, to musiałbym poświęcić wszystko inne i siedzieć całe dnie nad tym, a tego się (niestety) nie da 😀 Widzę także, nad czym muszę popracować od strony technicznej bloga (tutaj jest milion rzeczy do zrobienia), ale także od mojej osobowej strony (redukcja obowiązków oraz lepsze zarządzanie czasem). Mógłbym jeszcze wiele pisać, ale o tym powstanie osobny post 🙂 Czas teraz wracać do naszych schematów.

Wstęp

W ostatnim poście powiedzieliśmy sobie w dwóch słowach o modelowaniu i stworzyliśmy sobie szkice tychże diagramów. W momencie gdy to czytasz, uległy one modyfikacjom. Teraz omówimy sobie ogólnie z czego składają się te diagramy, opiszemy krótko notację, a na koniec powiemy w kilku słowach o systemie.

Diagram przypadków użycia (Use Case)

Pierwszym diagramem, który sobie omówimy jest diagram przypadków użycia. Na nim przedstawione są funkcje, których oczekują użytkownicy od naszej aplikacji lub zewnętrze systemy korzystające z tworzonego przez nas systemu. Na diagramie wyróżniamy komponenty takie jak:

  • przypadek użycia – czyli właśnie ta oczekiwana funkcja realizowana przez system, która przynosi jakiś wynik dla aktora; nie zagłębiamy się w wewnętrzne warstwy systemu, tylko traktujemy aplikację jako czarną skrzynkę z guziczkami,
  • aktor – reprezentuje obiekty, ludzi czy inne systemy, które będą współpracować z projektowaną aplikacją, poprzez odpowiednie GUI czy API.

To tak w skrócie, tyle jest potrzebne do zrozumienia całego diagramu. Jeżeli chodzi o symbole, to jak się pewnie domyślasz patrząc na w dymkach opisujemy przypadki użycia, a ludziki reprezentują poszczególnych aktorów. Warto dodać, że jeżeli aktorem jest system zewnętrzny, to możemy zmienić ikonę na inną.

Aktorzy mogą być generalizowani. Przykład? Proszę bardzo. Mamy sklep. W sklepie pracuje kasjer, kierownik, oraz osoba sprzątająca. Każda z nich będzie oczekiwała innych funkcjonalności, dlatego powstanie dla każdej z nich osobny diagram reprezentujący owe przypadki użycia. Ale zauważ, że możemy utworzyć aktora o nazwie Pracownik, który dla którego wyspecyfikujemy funkcjonalności wspólne dla tych trzech typów użytkowników, np. rejestrowanie przyjścia do pracy, rejestrowanie wyjścia z pracy. Relacje generalizacji, oznaczamy przez strzałkę z pustym w środku grotem, jak na poniższym diagramie.

Generalizacja aktorów

Oczywiście to zalążek tego, co można powiedzieć o diagramie przypadków użycia. Po więcej informacji kieruj się w stronę czeluści internetu 🙂 Dodatkowe oznaczenia, krotności oraz pułapki, na które trzeba uważać przy tworzeniu diagramów użycia.

Diagram klas (struktury obiektów)

Modelując program obiektowo szukamy wzorców, czyli klas, stanowiących szablony obiektów, które są ze sobą w jakiś sposób powiązane. I te właśnie powiązania przenosimy “na papier” rysując diagram klas lub diagram struktury obiektów. Dla wyjaśnienia w diagramie klas operujemy tylko na klasach, w diagramie struktury obiektów reprezentujemy relacje pomiędzy konkretnymi instancjami klas, będących w konkretnym stanie.

Klasę (lub obiekt) przedstawiamy w postaci prostokąta podzielonego w pionie na 3 części: w górnej nazwa klasy, w środkowej nazwy pól klasy poprzedzone znakiem + dla dostępu public, – dla private oraz # dla protected oraz po nazwie i dwukropku występującym typie pola, a w ostatniej nazwy metod opisane podobnie jak nazwy pól.

Ponadto wyznaczamy na diagramie relacje zachodzące pomiędzy klasami:

  • asocjacja – prosta zależność pomiędzy klasami (symbol linii prostej),
  • agregacja – relacja część – całość, obiekty jednej klasy są częściami klasy grupującej je w całość (linia prosta z rombem pustym w środku),
  • kompozycja – uściślenie relacji agregacji – obiekt będący częścią całości, bez owej całości istnieć nie może (linia prosta z wypełnionym na czarno rombem).

Więcej informacji o relacjach i sposobie ich oznaczania możecie znaleźć pod tym linkiem.

Podsumowanie diagramów

Starałem się dosłownie w kilku słowach wyjaśnić Ci, co znaczą symbole na powyższych diagramach oraz jak je interpretować. Mam nadzieję, że udało mi się to chociaż w małym stopniu. Temat diagramów jest mega duży i nie sposób w kilkuset słowach w poście powiedzieć wszystkiego, ani nawet wystarczającego minimum. Bardzo ciekawym źródłem informacji jest ta strona. Gdyby miał pisać posty tylko o UML to za jakikolwiek kod wziąłbym się za 2 lata chyba 😛 Dlatego jeśli chcesz wiedzieć więcej (a warto!) to zapraszam Cię do przestudiowania powyższej strony, czy poszukania innych, może jeszcze lepszych źródeł. Jeżeli znajdziesz, podziel się! 🙂

MagazineManager – diagramy, kontynuacja

Teraz kilka słów o diagramach stworzonych do MagazineManager’a.

Diagram przypadków użycia odzwierciedla to co jest zapisane w pliku PDF. Jest jeden aktor, ponieważ każdy użytkownik będzie sobie indywidualnie zarządzał bazą.

Diagram klas przedstawia logiczną hierarchię interakcji kolejnych klas. Zastosowana relacja kompozycji określa zależność, iż na przykład magazyn może istnieć bez egzemplarzy, jednak egzemplarz magazynu nie. Określone również zostały krotności relacji. Zależność pomiędzy klasami jest liniowa, ideowo program jest dość prosty.

Diagram klas odzwierciedla rzeczywiste obiekty. W dalszym kroku przygotowane zostaną diagramy klas, które zostaną zaimplementowane w programie, czyli uwzględnią warstwy widoku, prezentera oraz transferowe. Ale to przyszłość 🙂

Czas kończyć…

Dzisiaj bardzo owocny dzień. Przygotowanie tego posta zajęło mi ok. 6 h. Długo, niedługo, starałem się jak najlepiej to zrobić i jak najwięcej pokazać 🙂 Zachęcam do dyskusji w komentarzach! Chciałbym, żeby ktoś świeżym okiem na to spojrzał i powiedział: “Stary, a może tak będzie lepiej?” Bardzo lubię z kimś rozmawiać w czasie projektowania, ponieważ wtedy mózg pracuje na 500% i rzeczywiście model jest najlepszy 🙂

Nie przeciągając, życzę Ci dobrego przyszłego tygodnia oraz do zobaczenia przy kolejnym wpisie 🙂 Cześć! 🙂