Przypadki użycia Electrolux Eft 620 są szczególnie przydatne dla operatorów magazynów, którzy szukają skutecznego i wygodnego sposobu przenoszenia towarów pomiędzy różnymi poziomami magazynu. Electrolux Eft 620 jest wyposażony w szeroki zakres funkcji, w tym wyświetlacz LCD, który pozwala na łatwe sterowanie i ułatwia pracę. Jest on również wyposażony w czujniki bezpieczeństwa, które chronią operatorów przed przypadkowymi uszkodzeniami. Ponadto urządzenie posiada szeroki zakres funkcji nawigacji, które pomagają operatorom w łatwym i szybkim przemieszczaniu się po magazynie.
Ostatnia aktualizacja: Przypadki użycia Electrolux Eft 620
Dzisiejszy odcinek będzie o przypadkach użycia. Większość z Was pewnie bardziej kojarzy Przypadki Robinsona Crusoe;), czyli mega fajną historię. Przypadki użycia są nie mniej fajnym narzędziem, które możecie wykorzystać w projektach. Narzędzie, które pozwala rozwiązać dużo problemów: – definiowanie zakresu Jeżeli to Was interesuje, to serdecznie zapraszam. Jeżeli nie interesuje, to warto, żeby zainteresowało, bo to jedno z najlepszych narzędzi, mocno niedocenionych, które warto znać. Use Case-y to naprawdę świetna sprawa, nie tylko dla IT. Możecie wykorzystać przypadki użycia i ten sposób opisywania rzeczywistości do praktycznie każdej dziedziny. Przejdziemy krok po kroku przez przykład, który dla Was przygotowałem, po to, żebyśmy później mogli pracować na bardziej zaawansowanych tematach. Wzięło się z IT, dlatego, że bardzo często sytuacja wygląda tak, że to jak sobie myślisz o pewnych rzeczach definiując wymagania i o tym, żeby było zrobione i wykonane myślisz tzw. głównym scenariuszem sukcesu. Wyobraź sobie przykład bankomatu. Ktoś Ciebie pyta jak ten bankomat ma działać. Najprawdopodobniej odpowiedziałbyś „podchodzę do bankomatu, wkładam kartę, wpisuję pin, podaję kwotę do wypłaty, bankomat wypłaca pieniądze, zabieram kartę, zabieram pieniądze i odchodzę. ” To jest główny scenariusz sukcesu, w którym zakładasz, że nic złego się nie wydarzy. A co się stanie jeśli PIN będzie nieprawidłowy, jak się wtedy ma zachować oprogramowanie bankomatu? Co jeżeli nie ma wystarczającej kwoty w bankomacie, co jeżeli kwota wpisana nie jest podzielna przez nominały, które znajdują się w bankomacie, co jeżeli nie możesz się połączyć z bankiem, żeby sprawdzić z saldo? Cała masa wyjątków, o których musi pomyśleć programista. To powoduje trudność, bo będzie do Ciebie wracał i pytał jak w każdym z przypadków ma zachować się oprogramowanie. Jeśli przewidzisz pewne wypadki wcześniej to będzie mniej frustracji i szybciej to zostanie zrobione. Przy definiowaniu zakresu projektu, czyli to co mamy do zrobienia – pułapka widzenia tylko głównego scenariusza sukcesu sprawia, że nie widzisz tego co się kryje pod spodem. Nie oszacowujesz jak złożony jest projekt, ile na to potrzeba czasu i pieniędzy. Pewnie znacie sytuację, że wydawało się proste, a później okazało się, że tak nie jest. Use Case-y (Przypadki Użycia) są właśnie takim narzędziem, które umożliwia przewidzenie takich sytuacji, ocenić złożoność problemu odpowiednio wcześniej. Pomyślcie chwilę, gdybyście mieli kogoś nauczyć otwierania drzwi, to w jaki sposób miałaby wyglądać instrukcja. To co widzicie na poniższym obrazku to jest notacja. Jest pewien standard opisywania przypadków użycia, po to, że jak ktoś inny patrzy na wasze przypadki użycia, żeby był w stanie je zrozumieć. Przypadek użycia ujęty jest w kształcie prostokąta z zaokrąglonymi bokami (może ktoś wie i napisze w komentarzu jak się ten kształt nazywa). Przypadek użycia opisujemy przez Scenariusz Akcji np. : 1. Podchodzę do drzwi 2. Naciskam klamkę 3. Pcham drzwi 4. Przechodzę 5. Wykonaj „Zamykam drzwi” Pod spodem opisujemy wyjątki: 3a. Drzwi nie otwierają się (drzwi pomimo pchania, nie otwierają się) W skrócie tak właśnie wygląda przypadek użycia – macie listę kroków po kolei do wykonania i listę wyjątków, które mogą się zadziać. pl/wp-content/uploads/2020/04/przypadek-uzycia-1024x312. pl/wp-content/uploads/2020/04/przypadek-uzycia-300x91. pl/wp-content/uploads/2020/04/przypadek-uzycia-768x234. pl/wp-content/uploads/2020/04/przypadek-uzycia-260x79. pl/wp-content/uploads/2020/04/przypadek-uzycia-50x15. pl/wp-content/uploads/2020/04/przypadek-uzycia-150x46. pl/wp-content/uploads/2020/04/przypadek-uzycia-400x122. pl/wp-content/uploads/2020/04/przypadek-uzycia-350x107. pl/wp-content/uploads/2020/04/przypadek-uzycia-600x183. pl/wp-content/uploads/2020/04/przypadek-uzycia. png 1107w" alt=""/> Kolejna rzecz bardzo ważna – mamy Aktorów. Aktor to najczęściej osoba, która w danym przypadku ma do odegrania jakąś rolę. W tym przypadku to osoba otwierająca drzwi. W jednym przypadku może brać udział więcej aktorów niż jeden. Kolejna sprawa – mamy dwa rodzaje rozszerzenia głównego przypadku użycia: Extend – rozszerzenie nasz główny przypadek użycia o „exceptions” czyli wyjątkowe sytuacje Np. Wyjątek – warunkowy przypadek użycia Drzwi się nie otwierają Główny scenariusz sukcesu: Exceptions – wyjątki 2. 1. b Nie mam klucza (do tego też może być jakiś wyjątek) Widzicie to? Proste przechodzenie przez drzwi wcale nie jest takim prostym algorytmem do oprogramowania. Include – to drugie rozszerzenie głównego przypadku użycia Zawsze przypadek zawiera konkretne działania, jest to na tyle złożone, że nie chcemy tego przypadku użycia rozpisywać na 629 stron bo byłby ciężki tylko niektóre elementy opisujemy jako osobny przypadek użycia Np. : Funkcja – złożony przypadek użycia wykorzystywany jako część innego Przechodzenie przez drzwi Jak rozpisujecie waszą, rzeczywistość to definiujecie jakie są główne przypadki użycia. Kto bierze w tym udział (rozpisujemy aktorów i łączymy z przypadkami użycia), a później przy rozpisywaniu przypadków użycia wychodzą nam wyjątki. Do wyjątków przypisujemy kolejne elementy. Jeśli chcesz wykorzystać to do rozpisania procesów w swojej firmie to też możesz korzystać z takiego podejścia Tak może wygladać przykład rozpisanej firmy: Mała firma IT, kilku aktorów i rozpisane główne przypadki użycia. Klient korzysta z gotowego produktu, poniżej jak może wyglądać rozpisanie korzystania z produktu: Może się okazać, że korzysta z produktu i proponuje zmiany do wdrożenia. W tym przypadku aktorem będzie klient, wsparcie i szef handlowiec, którzy przekazuje uwagi do szefa technicznego, tam dochodzi do doprecyzowania wymagań. Jeżeli wszystko jest ok, funkcjonalność przechodzi do wdrożenia – aktorem tu jest programista, szef techniczny i kierownik projektu. Później wdrażamy funkcjonalność do tego włączony jest aktor wsparcie, a jednym z elementów w ramach zdarzenia jest testowanie. Testowanie – aktor wsparcie. Use case-y mają pokazać wam obszar, mapę w ramach, której się poruszacie. Osobiście korzystam z MindManagera przy tworzeniu przypadków użycia, jest całkiem ok. „Writting Effective Use Cases” Alistair Cockburn – świetna książka, dla władających angielskim numer 1. Po jej przeczytaniu jesteś w stanie pisać use case-y od razu. Mam nadzieję, że było to dla was przydatne. Moim zdaniem Use Case-y są niedoceniane, a są naprawdę świetnym narzędziem, korzystajcie? Przypadek użycia opisuje, w jaki sposób użytkownik używa systemu do osiągnięcia określonego celu. Diagram przypadków użycia składa się z systemu, powiązanych przypadków użycia i aktorów i łączy je ze sobą w celu wizualizacji: co jest opisywane? ( system), kto korzysta z systemu? ( aktorzy) i co aktorzy chcą osiągnąć? ( przypadki użycia), a zatem przypadki użycia pomagają zapewnić opracowanie właściwego systemu poprzez uchwycenie wymagań z punktu widzenia użytkownika. Relacje przypadków użycia modelują zależności między przypadkami użycia w modelu interakcji systemu. Chociaż niezależne przypadki użycia mogą odpowiednio reprezentować prostsze systemy. Jednak w celu przedstawienia złożonych lub dużych systemów może być konieczne skonstruowanie złożonych przypadków użycia za pomocą zależności między przypadkami użycia. Ustanawianie relacji między przypadkami użycia umożliwia ponowne wykorzystanie przypadków użycia, które muszą być definiowane w kółko, co zmniejsza wysiłek programistów. UML definiuje trzy stereotypy strukturyzowania powiązań przypadków użycia. Rozszerzający się przypadek użycia jest w rzeczywistości alternatywnym przebiegiem podstawowego przypadku użycia. Przypadek użycia <<rozszerz>> osiąga to poprzez koncepcyjne wstawienie dodatkowych sekwencji działań do podstawowej sekwencji przypadków użycia. Czas na użycie relacji <<include>> następuje po ukończeniu pierwszego opisu wszystkich głównych przypadków użycia. Możesz teraz przyjrzeć się Przypadkom Użycia i zidentyfikować typowe sekwencje interakcji użytkownika z systemem. Relacja dołączania dodaje dodatkowe funkcje, które nie zostały określone w podstawowym przypadku użycia. Relacja <<Include>> jest używana do włączania typowego zachowania z uwzględnionego przypadku użycia do podstawowego przypadku użycia w celu wspierania ponownego wykorzystania typowego zachowania. Relacje rozszerzające są ważne, ponieważ przedstawiają opcjonalne funkcje lub zachowanie systemu. Relacja <<extend>> służy do uwzględnienia opcjonalnego zachowania z rozszerzającego się przypadku użycia w rozszerzonym przypadku użycia. W powyższym przykładzie występuje złącze rozszerzające z punktem rozszerzenia „Nieprawidłowe hasło”. Ogólny przypadek użycia jest abstrakcyjny. Nie można utworzyć instancji, ponieważ zawiera niepełne informacje. Tytuł abstrakcyjnego przypadku użycia jest zaznaczony kursywą. Ten przykład diagramu przypadków użycia przedstawia model kilku biznesowych przypadków użycia (celów), które reprezentują interakcję między restauracją (systemem biznesowym) a jej kluczowymi interesariuszami (uczestnikami biznesowymi i pracownikami biznesowymi). Po zidentyfikowaniu podstawowych przypadków użycia w pierwszej rundzie cięć, być może uda nam się dalej budować te przypadki użycia z „rozszerzeniem” i „włączeniem” przypadków użycia w drugiej rundzie rewizji.
– zamodelowanie sobie całego systemu, w którym pracujecie
– określenie skąd mogą przyjść problemy i nieoczekiwane wymaganiaCzym są przypadki użycia?
Po co są przypadki użycia i skąd to się wzięło?
Use Case (Przypadki Użycia) na przykładzie otwierania drzwi
Use Case (Przpadki użycia) –literatura
Strukturyzacja przypadków użycia
Co to jest przypadek użycia <<Uwzględnij>>?
Przykład przypadku użycia — uwzględnij związek
Co to jest przypadek użycia <<Rozszerz>>?
Rozszerz związek
Abstrakcyjny i uogólniony przypadek użycia
Przykład diagramu przypadków użycia
„Pewnego dnia do firmy został zatrudniony Stanisław. Jest on analitykiem z niewielkim doświadczeniem i wciąż z brakami wiedzy, w pewnych ważnych obszarach. W poprzedniej pracy niestety nabył praktykę „Klient ma zawsze rację”.
Pewnego dnia podczas pracy z klientem dostał zadanie identyfikacji oraz stworzenia przypadków użycia. Zrobił to zgodnie ze znanymi zasadami i przesłał do klienta.
Klient odpowiedział, że w ramach tych przypadków chciałbym mieć opisane, z którego ekranu zaczyna się scenariusz, oraz aby w opisie kroków scenariusza było opisane, na którym ekranie jest aktualnie użytkownik i jakie pola ten ekran zawiera. Chciałbym również, aby w ramach tych opisów zawierały się wszelkie reguły biznesowe, walidacje na polach i ogólnie, aby taki przypadek zawierał wszystko.
Ku zasadzie „klient zawsze ma rację”, Stanisław poprawił przypadki. Efekt był niesamowity, duże obszernie opisane przypadki użycia z nawet 20 krokami. Największy z przypadków ma ponad 6 stron A4. Pojawiły się oczywiście diagramy i nawet przypadki, które nie posiadają scenariuszy, lecz są „ważną” częścią całości.
Stasiek przesłał wynik swoich prac do klienta, więc klient ucieszony zaakceptował i rozpoczęli realizację. Od początku zespół nie wiedział jak czytać te przypadki i przeszukiwanie dokumentu zajmowało ogromną część czasu podczas pracy. Developerzy denerwowali się, ponieważ te same rzeczy, występowały w wielu miejscach dokumentu i ciężko było mówić o spójności. Stanisław stale musiał konsultować ze zespół i z klientem.
Klient z racji tego, że Stanisław spełnił jego życzenie, uznał to za swój wkład w świat analizy i teraz wymaga tego we wszystkich kolejnych projektach…”
Historia Stanisława
Czy takie dokumentowanie jest dobre i czy ma sens, przy pełnym wachlarzu dostępnych technik i narzędzi analizy? Moim zdaniem nie.
Złe praktyki
Czas na to, po co tu przyszedłeś. W rozdziale tym przedstawiłem złe praktyki, których należy unikać podczas tworzenia przypadków użycia.
Diagram przypadków bez opisu przypadków
Pierwszy błąd to diagram przypadków użycia, bez jakiegokolwiek opisu zaprezentowanych przypadków. Zespół nie mając informacji o zawartości „chmurek” musi sam opracować zasady działania systemu (więc nie wykonałeś swojej pracy, tworząc przypadek użycia! ). Diagram sam w sobie niesie małą wartość, ponieważ po jednym zdaniu w nazwie, nie dowiesz się, jak ma dokładnie działać system, a taką wartość muszą dawać przypadki użycia.
Błędne stosowanie relacji
W wypadku błędnego stosowania relacji zauważam dwa warianty.
- Nie znajomość zasad korzystania z relacji
- Braki wynikające z innych błędów w tworzeniu (zawieranie interfejsu itd. )
Pierwszy dość szybko można wykryć, jeżeli znasz zasady tworzenia relacji, w drugim przypadku trzeba nieco doświadczenia, aby go zauważyć i odpowiednio poprawić. Kiedyś spotkałem się z sytuacją, gdy ktoś stworzył diagram, aby był diagram, bo tego wymagała umowa i nikt nie sprawdzał tej części dokumentacji. Szkoda, ponieważ z dobrze stworzonego diagramu z poprawnymi relacjami, można szybko i efektywnie określić co jest do zrobienia i w jakiej kolejności. Nawet jeżeli chcemy tylko i wyłącznie poznać system jako nowa osoba w zespole.
Powyżej, jest przykład źle zrobionego diagramu i podziału przypadków użycia. Unikaj takiego podejścia! Jest tu błędne zastosowanie relacji, zła identyfikacja i uwidacznia efekt opisu elementów interfejsu w ramach przypadku użycia.
Przejdźmy teraz do błędów z powyższego diagramu. Pierwszy błąd to identyfikacja przypadku użycia na podstawie interfejsu, czyli „Wyświetliłem ekran główny”. Drugi błąd, to „Zalogowałem się”, co nie może być przypadkiem użycia. Trzeci błąd jest powiązany z „Use Case 3”, przypadkiem niemający żadnej relacji do aktora, ani innego przypadku użycia. Czwarty błąd, który można podejrzewać to relacje extend, przy czym tutaj trzeba wejść w opis samych przypadków i ich zależności, ponieważ czasami z tzw. Big Picture coś wygląda błędnie, lecz jest bardzo dobrze zrobione.
Stosowanie relacje jest bardzo pomocne w zrozumieniu, dlatego ważne, aby zrobić to poprawnie i z głową.
Za duże lub za małe
Czasami spotykane przypadki użycia mają 15-30 kroków w scenariuszu głównym i do tego scenariusz alternatywne. Bez wizualizacji w postaci diagramu aktywności, odbiorca nie ma szans, zrozumieć jak coś działa i czasami, taki przypadek opisuje zbyt duży obszar systemu, więc powinien zostać podzielony. Dobrą praktyką jest zawieranie do 8-10 kroków w scenariuszu, ponieważ pozwala to na zrozumienie jego przebiegu i zależności w przeważnie pierwszym czytaniu.
Oczywiście pojawia się też sytuacja odwrotna, gdy pojawiają się przypadki ze scenariuszami, posiadającymi 1-2 kroki. Tworzenie takich elementów również nie ma sensu, ponieważ opisuje to przeważnie coś, co powinno zostać opisane poprzez np. wymaganie.
Przypadki użycia zawierają elementy intefejsu
Miejscem do opisu interfejsu musi być dedykowana część dokumentacji, gdzie opiszemy ekrany, listę pól, logikę pól i odwołania do funkcjonalności. Niestety, zbyt często miejscem tym stają się przypadki użycia. Przez to pojawiają się późniejsze problemy z utrzymywaniem aktualności przypadków użycia z nadmiarem w postaci opisu interfejsu (np. Użytkownik musi kliknąć przycisk „Kliknij tutaj”, zostanie wyświetlony ekran „klikacz tutejszy” …). W moim odczuciu powodem, dlaczego tak przypadki są tworzone, jest obrazowość opisu, ponieważ łatwiej jest wyobrazić sobie przycisk niż wybór opcji. Specyficzne słowa, których należy unikać to nazwy elementów np. przycisk, lista rozwijana, checkbox itd. Popełnienie tego błędu, bardzo szybko prowadzi do niespójności w dokumentacji i kosztownego utrzymywania aktualności dokumentów.
Łączenie wszystkich przypadków z jednym
„Czy wiesz o tym, że możesz zrobić to w alternatywnym scenariuszu i nie dodawać kolejnego przypadku? ” – mniej więcej podobne słowa kiedyś usłyszałem. Następnie za namową tej osoby powstał wielki scenariusz z kilkoma scenariuszami alternatywnymi. Niestety to był duży błąd, ponieważ jak potem okazało się, była to inna funkcjonalność. Jest to pułapka, w którą można wpaść. Jeżeli pojawia się wiele scenariuszy alternatywnych, należy zrobić krok wstecz i sprawdzić, czy przypadek użycia nie zawiera w sobie wielu funkcjonalności i jeżeli to się potwierdzi, podzielić go zgodnie z wynikającymi funkcjonalności. Tworząc przypadek użycia ogranicz opis do tego co jest niezbędne, do przekazania. Nie trzeba opisać całego świata. Czasami wystarczy jedynie odnośnik do „ważnego” elementu. Pamiętaj! Przypadek użycia to nie scenariusz filmu!
Przypadek użycia zastępuję całą dokumentację
Przypadek użycia ma pewną formę, która świetnie odwzorowuje to co dzieje się w systemie. Jednak czasami, w ramach opisu jest to nadużywane. Wynikiem tego jest zawieranie w scenariuszu wcześniej wspomnianych elementów, które nie powinny się tam znaleźć jak np. reguły biznesowe czy opis interfejsu. Są to zawsze rzeczy nadmiarowe, które powinny mieć swoje oddzielne miejsce w dokumentacji i być odpowiednio opisane.
Brak zastosowania struktury przypadku
Ostatni błąd, który często jest przyczyną wszystkich powyższych to BRAK ZASTOSOWANIA SZABLONU lub brak jego zrozumienia!
Jeżeli zaczynasz tworzyć przypadek użycia, zastosuj szablon. Następnie przeczytaj instrukcję oraz zobacz przykład, jak powinien zostać prawidłowo wypełniony dokument. Wiele jest standardów, świetnych artykułów, szkoleń, a temat „jak tworzyć przypadki użycia” przewija się co chwilę na blogach, więc nie będziesz miał problemu w stworzeniu czegoś własnego, jeżeli nie masz firmowego szablonu.
Aby Cię naprowadzić, określę w skrócie, tylko że przypadek użycia, powinien być opisany następującymi cechami:
- Nazwą
- Opisem wprowadzającym
- Warunkami wstępnymi
- Sposobem użycia (Scenariusze) – jak coś się dzieje i jak ma zachować się funkcjonalność podczas wyjątków.
- Wymaganiami specjalnymi
- Warunkami końcowymi
- Zależnościami i relacjami
Zawsze zaczynaj od szablonu i jego zrozumienia! Dopiero wtedy twórz piękne opisy.
