MagazineManager – czas zamodelować cz. 1

Opublikowane przez Piotr Wachulec w dniu

Xush kelibsiz! (uzbecki)

Niedzielne popołudnie, a ja już drugi tydzień wyrabiam normę trzech postów w tygodniu. I… dobrze mi z tym! Mam nadzieję, że uda się utrzymać tę passę, ponieważ prowadzenie tego małego dobytku sprawia mi naprawdę dużo frajdy 🙂 Dokładniej sobie o tym porozmawiamy już niedługo, więc na ten temat na razie się nie będę rozpisywał 🙂

Za to dzisiaj rozpiszę się o czymś innym. Mianowicie o modelowaniu i narzędziach do niego wykorzystywanych. Znów to troszkę potrwa, ponieważ wiele zagadnień chcę poruszyć dla Ciebie, drogi Czytelniku, ale również dla siebie, żeby usystematyzować swoją wiedzę na ten temat. Sposób nauki poprzez tłumaczenie komuś, tego co się nauczyło, bardzo pomaga w dokładnym zrozumieniu tematu i utrwalaniu wiadomości (o czym, np. ostatnio słyszałem we vlogu Mirosława Burnejki oraz o czym też mówi Mirosław Kardaś – drugiego Mirosława polecam, jeżeli ktoś chce zacząć zabawę z mikroprocesorami rodziny AVR). Dlatego też rozwój projektu jest dosyć powolny, ponieważ traktuje go tylko jako dodatek oraz podkładkę do nauki i przykład praktycznego zastosowania teorii. 🙂

Co to jest modelowanie i po co ono jest?

Jak widzisz, bardzo dużą wagę przykładam do projektowania aplikacji. Czy to dobrze, czy źle… Ja uważam, że dobrze. Za kilka tygodni zobaczycie, że zakodzenie dobrze zaprojektowanej aplikacji trwa moment. Dlatego bardzo ważnym etapem projektowania jest modelowanie. A co to w ogóle jest? Modelowanie jest narzędziem pozwalającym na zobrazowanie potencjalnie trudnych i skomplikowanych zagadnień, które będziemy chcieli rozwiązać przy pomocy tworzonego przez nas oprogramowania. Brzmi trudno, jednak w rzeczywistości jest odwrotnie! Modelowanie pozwala na pokazanie obiektów i interakcji między nimi oraz pozwala zrozumieć architekturę tworzonego systemu nawet przez osoby nie będące programistami (ale to dzięki zapisowi o którym zaraz).

Jak i czym modelować?

Oczywiście powstało wiele narzędzi do tego. Jednym z nich, powszechnie używanym jest język UML. Ustandaryzowana struktura diagramów i symboli umożliwia opisanie rzeczywistości, obiektów w niej się znajdujących wraz z ich stanami oraz powiązaniami. Po dokonaniu tego opisu możemy zamodelować kod, który powinien być zgodny z tym, co odnajdujemy w świecie rzeczywistym. Warto może tutaj dodać, że skupiam się na modelowaniu obiektowym, bo i w takim paradygmacie tworzę swoje oprogramowanie oraz paradygmat ten jest najbardziej popularny dzisiaj na świecie (jeżeli się mylę poprawcie mnie!). Więcej o samym języku UML możecie poczytać na Wikipedii lub w książce profesora Michała Śmiałka Zrozumieć UML 2.0, z którym miałem przyjemność mieć zajęcia własnie z przedmiotu Modelowanie oprogramowania w języku UML. Serdecznie pozdrawiam! 🙂

Narzędzia

Do modelowania w języku UML oczywiście jest programów. Ja miałem okazję skorzystać z programu Enterprise Architect, a do tworzenia diagramów dla MagazinManagera wykorzystam darmowe narzędzie UMLet. Po pierwszym użytkowaniu mogę stwierdzić, że bardzo przyjemnie się z niego korzysta. Prostota narzędzia nie zaciemnia obrazu podczas tworzenia diagramu.

O samym języku będziemy sobie opowiadać przy okazji kreowania kolejnych diagramów – najlepiej tłumaczyć na praktycznym przykładzie.

Modelowanie struktury obiektów/klas

Cechą paradygmatu obiektowego jest tworzenie oprogramowania zgodnego z naturalną, rzeczywistą strukturą zagadnienia. W świecie istnieją pojedyncze obiekty, byty, każdy z inną tożsamością, posiadające cechy oraz zdolności wykonywania pewnych czynności. Obiekty są konkretnymi egzemplarzami schematu zwanego klasą. Klasa definiuje zestaw cech oraz czynności, które obiekty będące egzemplarzami klasy posiadają. Dlatego w pierwszym kroku stworzę diagram z wykorzystaniem języka UML przedstawiający, jakie rzeczywiste klasy obiektów będę wykorzystywał w swoim oprogramowaniu.

Modelowanie funkcjonalności aplikacji

Następnym diagramem opisującym system jest diagram przypadków użycia. Ma on za zadanie zobrazować, jakie funkcje system ma dostarczać funkcje, ze względu na zdefiniowanych użytkowników. Użytkownika określamy mianem aktora.

Podsumowanie

W kilku zdaniach opisałem Ci, co będę robił w najbliższym czasie. W repozytorium projektu znajdują się dwa diagramy opisane powyżej. Przejrzyj je, zobacz, czy są one zrozumiałe. W następnym odcinku omówimy sobie ich budowę oraz porozmawiamy o kolejnych diagramach, które powstaną. Zachęcam do komentowania i wspólnej nauki! 🙂 Cześć! 🙂