diagram use case - galeria zdjęc - pomocy;)

0

Galerie zdjęc mam zamiar robic w PHP, a że na zaliczenie przedmiotu o UMLu mam tez zrobic jakis projekt wiec by to ładnie powiazac wybralam tez galerie. Obmyślałam to tak:

  • uzytkownik niezalogowany moze tylko przegladnąc zdjecia, no i wypelnic formularz rejestracyjny
    --- etap logowania: stajesz sie albo userem, albo administratorem.
  • użytkownik: przegląda zdjęcia, wyświetla info o zdjeciu, wysyla zdjęcia do admina, (ktory moze zaakceptować je i dodać, lub nie zaakceptować), dodać komentarz do zdjęcia.
  • admin - jak widac - zarządza userami, zarzadza kategoriami zdjęc, zarządza zdjęciami.

Czesc funkcji będzie wykonywanych typowo przez sam system (przez skrypty w php):

  1. wyciąganie "systemowych" informacji EXIF ze zdjęcia ktore będą mogly byc następnie wyświetlone tj.data zrobienia, typ aparatu fot. itd.,
  2. skalowanie zdjęcia (userzy przesylaja roznej wielkosci zdjecia, wiec system bedzie automatycznie skalowal ich rozmiar do np.640x480
  3. tworzenie miniatur zdjęcia (system będzie tworzyl miniaturki w celu pokazania ich w formie galerii).
    Nie wiem czy dodawac do tego cos w stylu - nadzorowanie poprawności logowania czy rejestracji bo to juz chyba za daleko.

No i troche nie moge załapać zasad dotyczących "strzałek" - te przerywania i kiedy to ma byc include a kiedy extend. Bo wg mnie to wszędzie powinnam mieć "extend".

Tu wstepny projekt, Sorrki że troche duzy:
// kapustka: wyrzuciłem ten duży diagram i umieściłem w jego miejsce linka.

user image

Prosze o przejrzenie moich wypocin i oczywiście krytyczne uwagi.

0

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

0

Bardzo dziękuje za wszelkie uwagi.
Zastosowałam się do nich i wyszło mi coś takiego: diagram-podejście drugie
Nie chodzi mi o zupelnie idealny projekt - chce by mniej wiecej bylo wporządku.
I grzecznie prosze o kolejne uwagi
Pozdr.

0

Naprawdę świetnie !
Tylko ja bym wrócił do tych strzałek w miejscach gdzie one były wcześniej ...

między przypadkami użycia mogą być relacje trzech typów:

  • extend
  • include
  • i relacja dziedziczenia (oznaczana strzałką z niewypełnionym grotem)

Na poprzednim diagramie między innymi "usuń zdjęcie" a "zarządzaj zdjęciami" było połączone dziedziczeniem i to było dobre ! To ma takie znaczenie, że usuwanie zdjęcia to szczególny rodzaj czynności jaką jest zarządzanie zdjęciami. Teraz jest extend, który może nie jest błędem ale mniej pasuje do tej sytuacji bo mówi: czasami zarządzając zdjeciami będziemy je usuwać.

Niby jest to prawda ale dziedziczenie jest precyzjniejsze w tym miejscu.
pozdrawiam i gratuluję: bardzo dobry diagram.

0

ok, DZIęKUJE za pomoc. No nie zwrocilam uwagi na znaczenie strzałek, ale juz rozumiem o co chodzi. Poprawie. Za niedlugo zajme się kolejnym diagramem. na razie THX i pozdrówka.

1 użytkowników online, w tym zalogowanych: 0, gości: 1