MagazineManager – czas zamodelować cz. 4

Wëllkomm! (luksemburski)

Jak się trzymasz? Co u Ciebie drogi Czytalniku? Mam nadzieję, że wszystko w porządku 🙂 Pora kontynuować modelowanie naszej aplikacji. Ostatnio omówiliśmy scenariusze przypadków użycia, co to jest i po co, jak się je tworzy. Jak zapewne widzisz, proces modelowania oprogramowania to logiczny ciąg kolejnych czynności, które prowadzą do przygotowania naprawdę dobrego gruntu do kodowania. Przyjrzyjmy się zatem jednemu ze scenariuszy przypadków użycia. Niech będzie ten dotyczący edycji danych o czasopiśmie:

1. Użytkownik naciska przycisk Edytuj.
2. System wyświetla formularz edycji czasopisma z uzupełnionymi aktualnymi danymi.
3. Użytkownik edytuje dane.
4. Użytkownik naciska przycisk Zapisz.
5. System pobiera dane z formularza.
6. System waliduje dane.
7. System aktualizuje dane w bazie.
8. System wyświetla komunikat o poprawnej aktualizacji danych.

Analiza scenariusza przypadku użycia

Spróbujmy teraz wyciągnąć z niego jakieś wnioski. Mam nadzieję, że pamiętasz z poprzedniego wpisu (jeżeli nie to zachęcam do przeczytania) o sposobie budowania zdań w scenariuszu – podmiot, orzeczenie, dopełnienie, krótkie, proste i rzeczowe zdania. Przeanalizujmy zatem co taka koncepcja może za sobą wnieść do tego scenariusza.

Podmiot mówi bezpośrednio o wykonawcy czynności opisanej – jest to aktor danego przypadku lub system. Cały scenariusz można sobie wyobrazić jako rozmowę aktora z systemem, gdzie słowami, które się wypowiada, czyli przekazuje drugiej osobie jest przepływ sterowania (sterowanie rozumiemy jako wykonanie czynności). Ciśnie mi się porównanie tej rozmowy do tańca, który jest jakby nie patrzeć rozmową pomiędzy kobietą a mężczyzną, tylko w takiej formie taniec może przenieść pełny bagaż emocji i odczuć. Taka luźna dygresja, która nie wiem czemu mi tu pasuje 😀

Orzeczenie to oczywiście czynność wykonywana w danym kroku. A co w kodzie determinuje wykonanie czynności? Tak, dokładnie, wywołanie metody! Jak się pewnie już domyślasz, w naszej aplikacji znajdą się metody aktualizujDane() czy walidujDane(), których argumentem będzie… No właśnie co?

Przechodzimy do dopełnienia. W dopełnieniu przemycamy elementy interfejsu użytkownika, np. przycisk, w kodzie zostanie utworzona tego typu klasa, lub klasy bezpośrednio związane z modelowaną aplikacją, np dane (w domyśle myślimy o danych czasopisma, jednak prawidłowo w napisany scenariusz powinien jednoznacznie na to wskazywać). Proste, prawda :)?

Jak widzisz, dobrze napisany scenariusz to skarb, z którego można wiele odczytać. Po przeanalizowaniu scenariusza można narysować diagram klas, który odwzoruje prawdziwą strukturę kodu, pracującą w projektowanej aplikacji.

Systematyzowanie kodu aplikacji

Czy te informacje, które wyciągamy ze scenariusza, da się w jakiś sposób pogrupować, usystematyzować, oprócz oczywistego wyłuskania klas i metod? Jasne, że tak. Chyba najbardziej widoczna grupa klas, to klasy odpowiadające za elementy interfejsu użytkownika. I w tym miejscu stop. Opowiemy sobie o wzorcach projektowych MVP i MVC, które swoją drogą różnią się od siebie niewiele, dlatego czasem ludzie stosują te nazwy wymiennie (co jest oczywiście błędem!).

MVC i MVP

Pomyślmy sobie tak. Na jakie warstwy możemy podzielić aplikację? No oczywiście na pewno warstwa odpowiadająca za wyświetlanie danych i cały interfejs graficzny. I to będziemy nazywać Widokiem, z ang. View. Drugą warstwą jest grupa klas bezpośrednio opisujących elementy naszego problemu, u nas czasopisma, egzemplarze etc. Tę warstwę nazywamy Model. No i teraz to musimy jedno z drugim połączyć. A gdzie występuje to połączenie? No… W scenariuszu. I za tę realizację scenariusza odpowiadają klasy Presentera. To własnie on odpowiada za wywołanie odpowiedniego widoku, pobranie z niego danych i przekazanie ich do modelu. Potem model po otrzymaniu danych i ich obrobieniu zwraca informację do prezentera i prezenter odpowiednio aktualizuje widok.

Czym zatem różni się MVP od MVC? Otóż jak w MVP to prezenter otrzymywał informację zwrotną od modelu i aktualizował widok, tak tutaj to już nie prezenter a kontroler odpowiednio wywołuje akcje na modelu i model sam bezpośrednio aktualizuje widoki.

Warto w Google wpisać mvp vs mvc i wtedy można dokładnie wczytać się w oby dwa podejścia. Polecam też zajrzeć do Wikipedii: MVP oraz MVC.

Podsumowanie

W najbliższym czasie, dziś już nie zdążę, biorę się za rozrysowanie diagramów klas na podstawie scenariuszy przypadków użycia. W swojej aplikacji wykorzystam architekturę MVP. Taki plan na najbliższe kilka dni. Zachęcam do wyszukiwania informacji na temat MVP i MVC, bo to jest bardzo aktualny i świeży temat. Tymczasem życzę Ci drogi Czytelniku miłego popołudnia, wieczoru lub dnia w zależności od tego, kiedy to czytasz. 🙂 Jeżeli podoba Ci się mój wpis, to udostępnij go proszę swoim znajomym, kliknij łapkę w górę na Facebooku i obserwuj mnie na Twitterze. Do zobaczenia! 🙂

Czytaj również:
« »