Projektowanie aplikacji — UML, diagram klas, architektura klient-serwer

Zanim napiszesz pierwszą linijkę kodu większej aplikacji, warto zaprojektować jej strukturę na papierze. Podstawa programowa (INF.04.3.6) wymaga umiejętności projektowania aplikacji — analizy wymagań, projektowania interfejsu, doboru architektury. Diagram klas UML to uniwersalny język do rysowania struktury programu obiektowego, zanim napiszesz choć jedną klasę w C#.

Zanim zespół programistów zacznie pisać aplikację bankową, architekt oprogramowania rysuje diagramy UML pokazujące, jakie klasy będą potrzebne (Konto, Klient, Przelew, Historia) i jak się ze sobą łączą — to pozwala wychwycić błędy projektowe (np. brakującą relację) na etapie rysunku, zanim koszt poprawki wzrośnie po napisaniu tysięcy linii kodu.

Wykonaj tę próbę przed dłuższym rozwiązaniem. Diagram ma pokazywać strukturę i odpowiedzialności. + oznacza public, - private. Klient nie powinien samodzielnie zmieniać pliku bazy serwera. Dziedziczenie i zależność to różne relacje.

UML (Unified Modeling Language) to zestaw znormalizowanych diagramów do wizualnego opisu struktury i działania oprogramowania. Najważniejsze dla programisty na tym poziomie są dwa typy:

• diagram klas — pokazuje klasy (jako prostokąty podzielone na trzy części: nazwa, pola, metody) oraz relacje między nimi. Znak - przed polem/metodą oznacza prywatność (private), + oznacza publiczność (public). Trójkąt ze strzałką oznacza dziedziczenie ("jest rodzajem" — Samochod JEST RODZAJEM Pojazdu);

• diagram przypadków użycia (use case) — pokazuje, co różni użytkownicy (aktorzy) mogą robić w systemie, np. "Klient: składa zamówienie, przegląda historię" / "Administrator: zarządza produktami".

Proces projektowania aplikacji typowo obejmuje kilka etapów: analizę wymagań klienta (co dokładnie aplikacja ma robić?), specyfikację techniczną (jakich technologii użyjemy?), projekt interfejsu użytkownika (jak to będzie wyglądać?), a dopiero potem implementację.

Architektura klient-serwer to jeden z najpopularniejszych sposobów organizacji aplikacji: klient (np. przeglądarka, aplikacja mobilna) wysyła żądania, a serwer je przetwarza — najczęściej korzystając z bazy danych — i odsyła odpowiedź. To dokładnie ten model, w którym działają wszystkie aplikacje webowe z działu "Aplikacje internetowe" w tym serwisie.

Podstawa programowa wspomina też o paradygmatach programowania: strukturalnym (program jako sekwencja instrukcji i funkcji operujących na danych z zewnątrz) i obiektowym (dane i operujące na nich metody są połączone w jeden obiekt — dokładnie to, czego uczysz się w lekcjach 9-18 tego działu).

Pomijanie projektowania i przechodzenie od razu do kodu — dla małych programów to nie problem, ale przy większych aplikacjach (wiele współpracujących klas) prowadzi do chaotycznej struktury, którą trudno później rozbudowywać.

Mylenie dziedziczenia z kompozycją na diagramie — trójkąt (dziedziczenie, "jest rodzajem") i romb (kompozycja, "ma w sobie") to dwie różne relacje UML i mają różne znaczenie — Samochod JEST RODZAJEM Pojazdu (dziedziczenie), ale Samochod MA Silnik (kompozycja).

Projektowanie zbyt szczegółowe od razu na starcie — pierwsza wersja diagramu klas nie musi być idealna; to narzędzie do myślenia i komunikacji z zespołem, nie sztywna specyfikacja wyryta w kamieniu.

Narysuj (na kartce albo w dowolnym edytorze) prosty diagram klas dla systemu bibliotecznego: klasy Ksiazka, Czytelnik, Wypozyczenie. Zaznacz pola każdej klasy oraz relacje między nimi.