Mam sporo uwag.
Zakładam, że ta lista funkcji jest poza zakresem rozważań i nie będę jej próbował rozszerzać czy też modyfikować. Przepraszam jeśli pewne rzeczy, które zaraz powiem są zbyt oczywiste ... nie wiem na jakim poziomie mogę rozmawiać dlatego na wszelki wypadek będę tłumaczył prawie wszystko.
Dobrą i powszechną praktyką jest na pewnym początkowym etapie skupienie się na tym co system ma robić aby usatysfakcjonował użytkowników. Na tym etapie warto zapomnieć o tym w jakiej technologii przyjdzie nam ten sysmtem realizować. To jest właśnie etap analizy. Wynikiem tego etapu jest model wymagań systemu, który może być zapisany w postaci naturalnego tekstu (bardzo często właśnie tak jest), lub innej metodyki na przykład przypadków użycia (inaczej zwany metodą Use-Case).
Zamieszczony diagram jest właśnie częścią metodyki Use-Case a jednocześnie narzędziem analitycznym. W rezultacie na tym diagramie pokazujemy wyłącznie CO system będzie robił a pomijamy całkowicie JAK będzie to robił.
Zanim zaczniemy usuwać z tego diagramu informacje które nie są opisem funkcjonalności musimy dodać jeden ważny i wymagany element tego diagramu: system. Umieszcz się go w postaci prostokąta opatrzonego tytułem. Elementy, które będą na zewnątrz tego prostokąta są poza systemem. Są tam jego użytkownicy i inne, samodzielne systemy. Zawartość tego prostokąta to przypadki użycia, które system obiecuje realizować oraz aktorzy wewnętrzni, których przedstawia się w systemach tak złożonych, że właściwie składają się one z kilku wyraźnych i niezależnych podsystemów.
Przejdźmy do wyszukiwania informacji niezwiązanych z funkcjonalnością. Przede wszystkim widzę aktora skrypt. O ile on sam powinien zniknąć to powiązane z nim przypadki użycia wnoszą pewną informację odnośnie funkcjonalności systemu a nie sposobu jego implementacji. Niestety przypadki użycia nie mogą wisieć w powietrzu, dlatego po śmierci aktora "skrypt" musimy je gdzieś przenieść.
Tworzenie miniatury zdjęcia możemy połączyć z jednym z dwóch przypadków: wysłanie zdjęcia lub przeglądanie zdjęcia. Musimy tutaj jednak podjąć decyzję projektową. Czy na pewno musimy ją podejmować ? Lepiej się tym nie zajmować na etapie analizy. Na szczęście jest to możliwe.
Zmieńmy nazwę przypadku na "wyświetl miniaturę". Nie utraciliśmy informacji o tym, że system będzie miniatury obsługiwał ale teraz już nie musimy decydować na jakim etapie będą one tworzone. Połączmy ten przypadek relacją include z "przeglądanie zdjęć". Relacja ta mówi, że za każdym razem kiedy przeglądamy zdjęcia będziemy przeglądać miniatury ... może więc lepiej użyjmy relacji extends, która zmienia "zawsze" na "czasami".
Nie jestem pewien jak ma działać skalowanie ... prawdopodobnie jest to rzecz jaką możemy wykonać przy okazji gdy wysyłamy zdjęcia a więc mamy relację extends między wysyłaniem zdjęcia a skalowaniem. To, że jestem foto-ignorantem wychodzi podczas przypadku użycia "wyciąganie EXIF". Nie wiem co to jest. Może i dobrze, że nie zrobię wszystkiego za Ciebie.
Jest już znacznie lepiej, mamy zaznaczone granice systemu i nazwany system (mam nadzieję). Pozbyliśmy się też pewnych informacji projektowych z tego diagramu. Jesteśmy na dobrej drodze ale diagram wciąż ma błędy. Są one bardziej podchwytliwe i aby je zrozumieć, musimy zrobić gruntowne powtórzenie materiału odnośnie przypadków użycia.
Przypadek użycia to czynność jaką system zobowiązuje sie wykonywać na rzecz użytkownika. Przypadki te dzielą sie na trzy rodzaje, w zależności od tego, ile czasu one trwają: streszczenia, przypadki na poziomie celu użytkownika i podfukcje.
Najważniejsze są cele użytkownika. Są to takie czynności, dla których użytkownik może podejść do komputera, wykonać je w jednym posiedzeniu a po wykonaniu tej czynności może już odejść usatysfakcjonowany. System właśnie wykonał coś pożytecznego dla użytkownika.
Konwencja notacji jest taka, że przypadki użycia na poziomie celu użytkownika to te, które są połączone z użytkownikiem bezpośrednio. Już widzicie, które baloniki trzymane sprzedawców nie pasują do tego opisu ? (przepraszam za ten kiepski dowcip ale diagram Use-Case od zawsze kojarzył mi się ze sprzedawcami baloników).
Logowanie ! To najbardziej powszechny błąd. Jest tak powszechny, że nawet niektórzy wykładowcy uważają, że zamieszczenie logowania jest wskazane. Niestety zapominają, że użytkownik, który podszedł do systemu tylko po to aby się zalogować, nie może odejść usatysfakcjonowany. Chyba że to jakiś kiepski haker, który próbuje się włamać zgadując hasło. Wykluczając brutalnych hakerów, nikt normalny nie odejdzie usatysfakcjonowany. Celem systemu nie jest logowanie samo w sobie. To tylko wypełnienie wymagania niefunkcjonalnego odnośnie bezpieczeństwa systemu.
Słowo o wymaganiach nie-funkcjonalnych. Nie umieszcza się ich na tym diagramie. Aby specyfikacja była kompletna trzeba je dostarczyć w osobnym opisie, na przykład tekstowym typu: system ma być bezpieczny co będzie zrealizowane koniecznością logowania się.
Nie wyjasniłem jeszcze wspomniancy wyżej przypadków użycia na poziomie streszczenia i podfukcji. Streszczenia to wieloposiedzeniowe historie z udziałem kilku aktorów. Nie można ich przedstawić na diagramie sprzedawców baloników ale można, i często się to robi, przedstawić te przypadki użycia w tekstowych przypadkach użycia, które są inną formą zapisu tego samego modelu.
Podfunkcje to natomiast rzeczy mniejsze od przypadków użycia. Są to czynności zbyt małe aby same w sobie satysfakcjonowały aktora. Przykładem tego jest skalowanie obrazków przy okazji wklejania nowego zdjęcia.
Relacja dziedziczenia pomiędzy "zarządzanie x" na przykład "zarządzanie zdjęciami" a szczegółowymi przypadkami jest ok. Po tych uwagach chyba będziesz już w stanie poprawić ten diagram. powodzenia.
pozdrawiam
kapustka