
W nowoczesnej inżynierii oprogramowania, szczególnie w technologii edukacyjnej i systemach przedsiębiorstw, UML (Język modelowania zintegrowanego) odgrywa kluczową rolę w zbieraniu wymagań funkcyjnych za pomocą Diagramów przypadków użycia. Te diagramy zapewniają wizualne przedstawienie interakcji między aktorami (użytkownikami) a systemem, podkreślając podstawowe i opcjonalne funkcjonalności, które użytkownicy mogą wykonywać.
To studium przypadku skupia się na Systemie zarządzania studentami uczelni (USMS), kompleksnym platformie cyfrowej przeznaczonej do ułatwienia działań akademickich, w tym rejestracji kursów, oceniania, konsultacji, przetwarzania płatności oraz integracji z szerokimi systemami instytucjonalnymi, takimi jak ERP (Planowanie zasobów przedsiębiorstwa).
Przedstawimy, przeanalizujemy i rozszyfrujemy diagram przypadków użycia UML systemu USMS, wyjaśniając jego składniki, relacje i konsekwencje w świecie rzeczywistym. Dodatkowo przeanalizujemy, jak ten diagram wspiera projektowanie systemu, komunikację z zaangażowanymi stronami i rozwój oprogramowania.
Zrozumienie i wyjaśnienie struktury i semantyki UML diagramu przypadków użycia.
Zidentyfikowanie kluczowych aktorów, przypadków użycia i ich relacji (powiązanie, zawieranie, rozszerzanie).
Analiza sposobu, w jaki system wspiera różne role użytkowników z różnymi poziomami dostępu i odpowiedzialności.
Ocena skalowalności, modułowości i możliwości integracji systemu.
Ocena, jak model przypadków użycia wspiera zbieranie wymagań i projektowanie systemu.
System zarządzania studentami uczelni (USMS) to zintegrowana platforma cyfrowa, która umożliwia studentom, wykładowcom, konsultantom i personelowi administracyjnemu efektywne zarządzanie działalnością akademicką. Zastępuje papierowe zapisy interaktywnym, bezpiecznym i zintegrowanym systemem cyfrowym.
Rejestracja kursów i planowanie
Przesyłanie zadań i ocenianie
Generowanie wypisów akademickich i raportów ocen
Umówienia konsultacyjne i planowanie akademickie
Transakcje finansowe (opłaty, płatności, rozliczenia)
Synchronizacja danych z systemami zewnętrznych (ERP, bramki płatności)
System został zaprojektowany w celu zapewnienia spójności danych, aktualizacji w czasie rzeczywistym oraz zgodności z politykami akademickimi.
| Aktor | Rola | Główna odpowiedzialność |
|---|---|---|
| Student | Główny | Rejestruje się na kursy, przegląda transkrypty, przesyła zadania, sprawdza oceny oraz planuje spotkania konsultacyjne. |
| Pracownik naukowy | Główny | Oceni zadania, analizuje wyniki studentów, uzyskuje dostęp do ocen oraz generuje raporty. |
| Konsultant akademicki | Główny | Planuje spotkania konsultacyjne, analizuje postępy studentów, aktualizuje rekordy oraz wspiera planowanie akademickie. |
| Urzędnik administracyjny | Pomocniczy | Aktualizuje rekordy studentów, zarządza danymi administracyjnymi (np. status rekrutacji). |
| Bramka płatności | Pomocniczy | Zarządza transakcjami finansowymi (opłaty, koszty nauki). |
| System ERP | Pomocniczy | Synchronizuje dane akademickie i finansowe z systemami korporacyjnymi (np. płace, magazyn). |
Uwaga:Użycie aktorów „Głównych” i „Pomocniczych” odzwierciedla stopień bezpośredniego współdziałania z systemem. Aktorzy główni korzystają z USMS bezpośrednio; aktorzy pomocniczy są zintegrowanymi partnerami.
| Przypadek użycia | Opis |
|---|---|
| UC1 – Rejestracja do kursów | Studenci i wykładowcy inicjują proces rejestracji do kursów akademickich na podstawie wymagań wstępnych i dostępności. |
| UC2 – Wyświetlanie transcriptu akademickiego | Studenci i doradcy mają dostęp do szczegółowego rekordu ukończonych kursów, ocen i punktów. |
| UC3 – Przesyłanie zadania | Studenci przesyłają zadania przez platformę; wykładowcy je przeglądują i oceniają. |
| UC4 – Sprawdzanie ocen | Studenci i wykładowcy mogą w czasie rzeczywistym przeglądać aktualne i poprzednie oceny. |
| UC5 – Planowanie spotkania doradczy | Studenci rezerwują spotkania z doradcami akademickimi w celu omówienia planów akademickich. |
| UC6 – Przetwarzanie rejestracji | Centralizowany proces rejestracji uruchamiany przez rejestrację kursu i jego zatwierdzenie. |
| UC7 – Generowanie raportu ocen | Wykładowcy lub urzędnicy tworzą oficjalny podsumowanie ocen dla studentów lub celów raportowania. |
| UC8 – Płatność | Studenci płacą za opłatę za studia i koszty przez zintegrowany portal płatności. |
| UC9 – Aktualizacja rekordów studentów | Doradcy lub urzędnicy zmieniają status studenta (np. porzucenie studiów, probation, przekazanie). |
| UC10 – Synchronizacja danych z ERP | System udostępnia dane studentów i finansowe systemowi ERP uczelni w celu wypłat, planowania finansowego i raportowania. |
Powiązania reprezentująbezpośrednie oddziaływaniemiędzy aktorami a przypadkami użycia. Są kolorowane w celu odzwierciedlenia ról użytkowników:
| Powiązanie | Kolor | Znaczenie |
|---|---|---|
student - UC1 |
Czarny | Student inicjuje rejestrację kursu. |
student - UC2, UC3, UC4 |
Czarny | Student korzysta z podstawowych funkcji akademickich. |
pracownicy naukowi - UC3, UC4, UC7 |
Czerwony | Pracownicy naukowi zarządzają zadaniami i ocenianiem. |
konsultant - UC5, UC6, UC9 |
Złoty | Konsultanci zarządzają konsultacjami i aktualizacjami rekordów. |
UC8 - płatność |
Ciemny turkus | Brama płatności przetwarza opłaty. |
UC9 - admin |
Ciemny turkus | Administrator aktualizuje rekordy. |
UC10 - ERP |
Ciemny turkus | ERP otrzymuje zsynchronizowane dane. |
Te powiązania pokazująkto wykonuje jaką funkcję, pomagając zdefiniować role i odpowiedzialności użytkowników.
Powiązania Includereprezentująobowiązkowa, ponownie używalna zachowaniektóre jest zintegrowane w innych przypadkach użycia.
UC1 ..> UC6 : <<include>>
UC2 ..> UC6 : <<include>>
UC4 ..> UC6 : <<include>>
Wszyscy studenci, którzy rejestrują się na kursy (UC1)muszą przejść przezproces rejestracji (UC6).
Studenci przeglądający transkrypty (UC2)muszą również wyzwolićproces rejestracji (UC6)— prawdopodobnie w celu weryfikacji punktów.
Studenci sprawdzający oceny (UC4)są domyślnie częściąprocesu rejestracji— oceny są dostępne tylko po potwierdzeniu rejestracji.
✅ Te relacje zapewniająintegralność danych i spójność przepływu.
🔍 Na przykład, student nie może sprawdzić swoich ocen, dopóki nie zostanie zarejestrowany na kursie.
To zapobiega nieprawidłowemu lub przedwczesnemu dostępowi do danych.
UC8 <.. UC10 : <<rozszerz>>
Gdy studentzapłaci (UC8), systemopcjonalnie rozszerzapoprzezsynchronizację danych z systemem ERP (UC10).
Oznacza to:Zapłata → Opcjonalna synchronizacja z ERP
Nie każda płatność wyzwala synchronizację z ERP — może zależeć od warunków (np. opłaty za studia, początek semestru).
🚀 Wspieraelastyczne integrowanie— system nie wymaga synchronizacji z ERP przy każdej transakcji, zmniejszając obciążenie.
💡 Pozwala instytucjom wybrać, kiedy synchronizować dane (np. po potwierdzeniu płatności lub na końcu semestru).
To jestprzykład z rzeczywistego świataprzykładopcjonalnego rozszerzenia przepływu pracy, w którym podstawowa czynność (płatność) może wyzwalać dodatkowe, wtórne zachowania.
Studenci: Mogą przeglądać oceny, przesyłać zadania, rejestrować się na kursy.
Pracownicy naukowi: Mogą oceniać, przeglądać oceny, generować raporty.
Poradnicy: Mogą planować spotkania, aktualizować rekordy.
Administratorzy: Pełny dostęp CRUD do rekordów studentów.
Systemy zewnętrzne: Brak bezpośredniego interfejsu — tylko poprzez interfejsy API (np. ERP, brama płatności).
To zapewnia bezpieczeństwo i prywatność danych poprzez ograniczenie dostępu do odpowiednich uczestników.
Rejestracja (UC6) działa jako brama do wszystkich funkcji akademickich.
Wszystkie rekordy akademickie (wypisy, oceny) pochodzą z rejestracji kursów i oceny zadań.
Raporty ocen (UC7) i wypisy (UC2) są generowane wyłącznie po weryfikacji danych poprzez rejestrację i ocenę.
To tworzy cykl życia danych który zapewnia dokładność i śledzenie.
| System | Cel | Wyzwalacz |
|---|---|---|
| Brama płatności | Przyjmowanie płatności | Wyzwalane poprzez UC8 |
| System ERP | Wyrównaj dane | Wyzwolony przez UC10 (rozszerzony z UC8) |
Użycie aktorów pomocniczych pokazuje, że USMS nie jest izolowany — jestzintegrowany w większym ekosystemienarzędzi instytucjonalnych.
To podkreśla znaczenieprojektowania interfejsów API, uwierzytelniania, orazstandardów formatów danych (np. XML, JSON) w takich integracjach.
| Interesariusz | Potrzeby | Przypadki użycia |
|---|---|---|
| Student | Zrozumienie obciążenia zajęciowego, ocen, opłat i postępów akademickich | UC1, UC2, UC3, UC4, UC5, UC8 |
| Pracownicy naukowi | Ocena prac, monitorowanie wyników | UC3, UC4, UC7 |
| Konsultant | Wsparcie studentów, śledzenie postępów | UC5, UC6, UC9 |
| Urzędnik administracyjny | Utrzymywanie rekordów studentów, zarządzanie danymi | UC9 |
| Administrator uczelni | Monitoruj finanse, zgodność | UC8, UC10 |
| Systemy zewnętrzne | Odbieraj dane standardowe | UC8, UC10 |
Ten diagram pełni funkcję narzędzia komunikacji dla stakeholderów w celu zrozumienia wspólnych celów i odpowiedzialności.
| Ograniczenie | Zalecenie |
|---|---|
| Brak jasno określonych ograniczeń (np. terminy, wymagania wstępne) | Dodaj zasady walidacji w wymaganiach lub diagramach sekwencji |
| Brak obsługi błędów | Dodaj przypadki wyjątkowe (np. „Niepowodzenie rejestracji”) |
| Brak wyzwalaczy opartych na czasie | Zdefiniuj, kiedy działa UC10 (np. po potwierdzeniu płatności) |
| Brak wymagań niiefunkcjonalnych | Dodaj uwagi dotyczące bezpieczeństwa, wydajności i skalowalności |
| Brak interfejsu użytkownika | Przyszłe iteracje mogą zawierać szkice interfejsu użytkownika lub diagramy działań |
🔍 Zalecenie: Rozszerz diagram przypadków użycia o przypadki wyjątkowe (np. „Przeciążenie kursu”, „Niepowodzenie płatności”) i diagramy sekwencji w celu pokazania interakcji krok po kroku.
| Faza | Rola diagramu przypadków użycia |
|---|---|
| Zbieranie wymagań | Pomaga zidentyfikować potrzeby funkcjonalne od stron zainteresowanych. |
| Projekt systemu | Kieruje projektowaniem modułów (np. moduł rejestracji, moduł płatności). |
| Komunikacja w zespole | Zapewnia wspólny język wizualny między programistami, testerami i menedżerami. |
| Planowanie testów | Przypadki użycia stają się przypadkami testowymi (np. „Student przesyła zadanie → pojawia się ocena”). |
| Szkolenie użytkowników | Służy jako pomoc szkoleniowa do wyjaśnienia możliwości systemu. |
Ten diagram przypadków użycia jest podstawą dalszego modelowania (np. diagramy sekwencji, aktywności, klas).
Scenariusz: Student o imieniu Maya chce się zarejestrować na nowy kurs.
Maya loguje się → wywołuje UC1 (Rejestracja do kursów).
System sprawdza wymagania wstępne → jeśli są poprawne, przechodzi do UC6 (Przetwarzanie rejestracji).
Maya przesyła zadanie → wywołuje UC3 (Przesyłanie zadania).
Oceny wykładowców → wywołujeUC4 (Sprawdź oceny).
Maya umawia wizytę → wywołujeUC5 (Zaplanuj wizytę konsultacyjną).
Maya płaci za studia → wywołujeUC8 (Zapłać) → którerozszerzadoUC10 (Synchronizuj z ERP) w celu uaktualnienia rekordów finansowych.
✅ Wszystkie kroki są zgodne z modelem przypadków użycia.
Ten przepływ zapewniaśledzenie od końca do końcaizgodnośćz politykami akademickimi.
Poniższydiagram przypadków użycia UMLdla systemu zarządzania studentami uczelni to więcej niż tylko narzędzie wizualne — tokompleksowy projektktóry ujmuje:
Kto korzysta z systemu
Co robią
Jak są powiązane działania
Jak funkcje są wywoływane lub rozszerzane
Zapewnia:
Jasne określenie ról
Logiczny przebieg procesów akademickich
Integracja z systemami zewnętrznymi
Skalowalność i modułowość
Wyrównanie interesów stakeholderów
Poprzez jasne rozdzieleniegłówni aktorzyodpomocniczy aktorzy, a także poprzez wykorzystaniezawierairozszerzarelacje, diagram zapewnia solidne podstawy dla rozwoju oprogramowania, testowania i ciągłego ulepszania.
| Kolor | Znaczenie |
|---|---|
| Czarny | Interakcja głównego aktora |
| Czerwony | Działania związane z wydziałem |
| Złoty | Działania związane z doradcą |
| Ciemny turkus | Integracja z systemami zewnętrznymi |
Kodowanie kolorów poprawia czytelność i hierarchię wizualną.
| Symbol | Znaczenie |
|---|---|
aktor |
Użytkownik lub system zewnętrzny |
przypadek użycia |
Funkcjonalność dostępna dla aktorów |
powiązanie |
Bezpośrednie interakcje między aktorem a przypadkiem użycia |
<<zawiera>> |
Obowiązkowa funkcjonalność w innym przypadku użycia |
<<rozszerza>> |
Opcjonalna funkcjonalność wyzwalana przypadkiem użycia |
@startuml
aktor "Student" jako student
aktor "Faculty" jako faculty
przypadek użycia "Zapisz się na kursy" jako UC1
przypadek użycia "Zgłoś zadanie" jako UC3
przypadek użycia "Sprawdź oceny" jako UC4
student -> UC1 : Zapisuje się na kurs
UC1 --> UC6 : Przetwarzanie zapisu
student -> UC3 : Wysyła zadanie
faculty -> UC3 : Przegląda i ocenia
UC3 --> UC4 : Oceny są widoczne
@enduml
Pokazuje krok po kroku wykonanie — naturalny następny krok po diagramie przypadków użycia.
Ten przypadek studium ilustruje moc UML diagramy przypadków użyciaw odzwierciedlaniu skomplikowanych systemów rzeczywistych. W kontekście technologii edukacyjnej takie diagramy pełnią rolę most między polityką akademicką a wdrożeniem technicznym.
Pomagają upewnić się, że żaden użytkownik ani proces nie zostanie pominięty, że przepływy danych są logiczne, a integracja z systemami zewnętrznymi jest przejrzysta i zarządzalna.
W miarę jak uczelnie kontynuują cyfryzację, narzędzia takie jak ten model przypadków użycia będą nadal niezbędne do tworzenia reaktywnych, bezpiecznych i skupionych na użytkowniku systemów akademickich.
📌 Zalecenia dla zespołów wdrażających:
Użyj tego diagramu przypadków użycia jako dokumentu wymagań podstawowych i rozwijaj go poprzez iteracyjne opinie studentów, pracowników akademickich i administratorów.
✅ Ten studium przypadku jest odpowiedni do użytku akademickiego, dokumentacji projektów oprogramowania lub planowania IT na uczelniach.