Diagramy powinny wspierać cel pracy#

UML może pomóc w pracy dyplomowej opisać wymagania, architekturę, dane, zachowanie lub projekt badanego systemu. Diagram nie jest ozdobą ani samodzielnym dowodem poprawności rozwiązania. Powinien wspierać pytanie badawcze, cel inżynierski lub decyzję projektową, a jego rola musi być wyjaśniona w tekście.

Przed rysowaniem ustal, co praca ma wykazać: analizę problemu, projekt aplikacji, prototyp, porównanie rozwiązań, model procesu czy ocenę architektury. Wybierz diagramy, które przedstawiają potrzebne aspekty i powiąż je z rozdziałem, wymaganiem lub wynikiem.

Dobierz typ diagramu do treści#

Diagram przypadków użycia może opisać cele aktorów i zakres systemu. Diagram aktywności nadaje się do przepływów pracy, a diagram klas — do struktury pojęć, relacji i ograniczeń. Diagramy sekwencji przedstawiają wybrane interakcje, stany — cykl życia obiektu, komponentów — moduły i interfejsy, a wdrożenia — środowiska oraz rozmieszczenie artefaktów.

Nie wstawiaj całego katalogu UML do pracy. Każdy typ powinien odpowiadać na inne pytanie. Jeśli schemat, tabela, diagram ER, prototyp lub opis tekstowy lepiej pasują do problemu, uzasadnij ich użycie zamiast wymuszać notację UML.

Uzasadnij zakres i założenia#

Opisz, który system modelujesz, gdzie przebiega granica, jaki poziom szczegółowości przyjęto, kim są odbiorcy i jakie elementy pominięto. Odróżnij stan istniejący od projektowanego rozwiązania. Jeśli model przedstawia tylko scenariusz sukcesu, zaznacz to.

Wymagania powinny mieć źródło i kryterium weryfikacji. Zapisz założenia, ograniczenia oraz otwarte kwestie, szczególnie gdy wpływają na wnioski. Nie przedstawiaj hipotetycznego przebiegu jako zachowania potwierdzonego przez użytkowników lub implementację.

Opisuj diagram w tekście#

Każdy diagram powinien mieć numer, tytuł, czytelny podpis i odwołanie w treści. Przedstaw, po co go umieszczono i jak należy go interpretować. Po diagramie wyjaśnij najważniejsze decyzje, relacje, warunki i uproszczenia. Nie powtarzaj w prozie wszystkich etykiet.

W treści pracy zachowaj jednolitą polską terminologię. Przy pierwszym użyciu podaj angielską nazwę, jeśli ułatwia odniesienie do specyfikacji. W legendzie objaśnij niestandardowe kolory, stereotypy i skróty. Używaj tekstu alternatywnego lub opisów, jeśli dokument będzie udostępniany cyfrowo.

Notacja, źródła i własny wkład#

Korzystaj z wiarygodnych materiałów do uzasadnienia semantyki UML. Odróżnij standardowe znaczenie symbolu od konwencji przyjętej w pracy, funkcji konkretnego narzędzia i własnej interpretacji. Bibliografię i sposób cytowania dopasuj do wytycznych uczelni.

Jeśli diagram został opracowany samodzielnie na podstawie analizy, opisz przyjętą metodę i źródła danych. Jeśli adaptujesz cudzy model, podaj źródło i wyjaśnij zmiany. Nie przypisuj UML reguł, które pochodzą z dokumentacji narzędzia, języka programowania lub przyjętego procesu.

Narzędzia i reprodukowalność#

Zachowaj plik źródłowy modelu oraz nazwę i wersję narzędzia, jeśli jest to istotne dla odtworzenia diagramu. Eksportuj grafiki w jakości odpowiedniej do druku i wersji cyfrowej; sprawdź etykiety, szerokość, kontrast i numerację. Sam zrzut ekranu może być trudny do edycji i aktualizacji.

W pracy technicznej możesz dołączyć źródła diagramów jako materiały dodatkowe lub repozytorium, zgodnie z zasadami uczelni. Ustal, czy wynik ma być możliwy do ponownego wygenerowania i jakie pliki są częścią artefaktu pracy.

Powiąż model z implementacją i oceną#

Jeśli praca obejmuje aplikację, wskaż, które diagramy opisują projekt, a które implementacja rzeczywiście realizuje. Zmiany w kodzie mogą odbiegać od planu; opisz różnice i ich przyczyny. Diagram architektury nie jest dowodem działania — weryfikacja wymaga testów, pomiarów, demonstracji lub innej metody odpowiedniej do celu pracy.

W części ewaluacyjnej odnieś się do wymagań i kryteriów. Nie wnioskuj, że system spełnia potrzebę tylko dlatego, że ma przypadek użycia lub komponent na diagramie. Pokaż wyniki sprawdzeń i ich ograniczenia.

Czytelność dokumentu#

Każdy diagram powinien być czytelny w rzeczywistym rozmiarze strony. Ogranicz liczbę elementów, podziel złożony model na widoki i unikaj rozciągania małego obrazka do całej strony. Zachowaj spójne nazwy, styl, grubość linii i sposób podpisywania.

Przed oddaniem sprawdź, czy obrazy są ostre, podpisy nie zostały odłączone od diagramów, numeracja jest poprawna, a każda ilustracja jest przywołana w tekście. Upewnij się, że tekst nie odwołuje się do wersji modelu, która nie została dołączona.

Typowe błędy#

  • Diagramy dodane dla objętości. Powiąż każdą ilustrację z celem pracy.
  • Brak uzasadnienia wyboru UML. Opisz, dlaczego notacja odpowiada problemowi.
  • Pełny model utożsamiony z poprawną implementacją. Dodaj weryfikację i wyniki.
  • Założenie pomylone z faktem. Oznacz status informacji i źródło.
  • Użycie symboli bez definicji. Wyjaśnij niestandardowe konwencje.
  • Diagram bez omówienia. Zinterpretuj najważniejsze relacje i decyzje.
  • Nieczytelny eksport. Sprawdź wydruk, rozdzielczość, kontrast i podpisy.
  • Brak plików źródłowych. Zachowaj model umożliwiający korekty lub odtworzenie.

Podsumowanie#

UML w pracy dyplomowej powinien wspierać cel, wymagania i wnioski, a nie tylko ilustrować rozdziały. Uzasadnij zakres, dobierz niewielki zestaw potrzebnych diagramów, opisz je w tekście i odróżnij projekt od zweryfikowanej implementacji. Zachowaj źródła oraz sprawdź jakość eksportu.