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

Po co się tego uczymy?

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#.

Teoria

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).

Schemat

Diagram klas UML - relacja dziedziczenia i kompozycji:

  ┌───────────────────┐
  │     Pojazd         │  <- klasa bazowa (abstrakcyjna)
  ├───────────────────┤
  │ - marka: string     │  <- pola prywatne (znak "-")
  │ - predkosc: int      │
  ├───────────────────┤
  │ + Jedz(): void       │  <- metody publiczne (znak "+")
  └─────────┬──────────┘
            △  (trójkąt = dziedziczenie, "jest rodzajem")
   ┌────────┴─────────┐
   │                   │
┌──┴─────────┐   ┌─────┴──────┐
│  Samochod   │   │  Motocykl   │
├────────────┤   ├────────────┤
│ - liczbaDrzwi│   │ - typRamy   │
└────────────┘   └────────────┘

Architektura klient-serwer:

  [Klient / przeglądarka] ──żądanie HTTP──► [Serwer aplikacji]
         ▲                                        │
         │                                        ▼
         └──────────odpowiedź (dane)────── [Baza danych]

Przykład z życia

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.

Komentarz i wyjaśnienie kodu

Ta lekcja ma charakter projektowy, nie programistyczny — nie ma tu bloku kodu C#, bo diagram klas UML z sekcji "Schemat" to właśnie ten "kod" na poziomie projektu. Warto porównać go z rzeczywistymi klasami z lekcji 13 (Dziedziczenie) — zobaczysz, że relacja z diagramu (trójkąt = dziedziczenie) to dokładnie to samo, co słowo kluczowe : KlasaBazowa w C#.

Ćwiczenie samodzielne

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.

Zadania do pracy własnej

Narysuj diagram przypadków użycia dla aplikacji sklepu internetowego z dwoma aktorami: Klient i Administrator. Wypisz przynajmniej 4 akcje dla każdego z nich.
Zaprojektuj (diagram klas) strukturę systemu do zarządzania wypożyczalnią sprzętu sportowego — nawiąż do projektu końcowego z lekcji 19 (wypożyczalnia) i narysuj diagram klas, ZANIM sprawdzisz, jak faktycznie wygląda tam kod. Porównaj swój projekt z gotowym rozwiązaniem.
Opisz (tekstowo, w kilku zdaniach) architekturę klient-serwer dla aplikacji mobilnej sprawdzającej pogodę: co robi aplikacja na telefonie (klient), co robi serwer, gdzie przechowywane są dane pogodowe, i co się dzieje, gdy telefon nie ma dostępu do internetu.

Typowe błędy

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.

Nawiązanie do egzaminu zawodowego

To realizacja INF.04.3.6 — "projektuje aplikację: analiza wymagań klienta, specyfikacja techniczna, elementy UI, projektowanie interfejsu, architektura klient-serwer" oraz częściowo INF.04.3.2 (struktury danych). Diagram klas to też praktyczne odniesienie do paradygmatu obiektowego z lekcji 10-18.