Temat: Wymagania na system.. jak opisać?
Osobiście wydaje mi się, że koncepcja przypadków użycia jest wartościowa i szczególnie użyteczna w procesie projektowania systemu. Oczywiście przy założeniu, że dobrze rozumiemy o co w tym wszystkim chodzi. Chciałbym zaznaczyć, że nie jestem adwokatem przypadków użycia ale często model ten jest analizowany w sposób wyrwany z kontekstu a same korzyści możemy dostrzec dopiero patrząc na tą technikę z perspektywy metodyki. Warto zastanowić się nad tym co Ivar Jacobson miał na myśli pisząc 'use case driven approach'. Chodziło mu przede wszystkim o to, że ta prosta technika analizy jaką są przypadki użycia może być wykorzystana w całym cyklu życia systemu informatycznego na różne sposoby:
1. Na początku przypadki użycia mogą służyć jako narzędzie sprawnej komunikacji z udziałowcami systemu (model przypadków użycia może być przecież wykonany jako wstępny szkic funkcjonalności określonej na podstawie modelu biznesowego ,który został przygotowany z wykorzystaniem notacji BPMN). To co jest w tym momencie istotne to to, że mamy proste narzędzie, które pozwala przedstawić zarys funkcjonalności udziałowcom i uzyskać (bądź nie) ich aprobatę. Gdy kontrakt jest wyraźnie zdefiniowany wówczas nie ma nieporozumień przy ustalaniu sukcesu/porażki przedsięwzięcia.
2. W kolejnym kroku przypadki użycia mogą być wykorzystane do analizy luk w wymaganiach. Oczywiście jeżeli każdy dobrze rozumie czym jest przypadek użycia - zbiór interakcji pomiędzy aktorem oraz systemem, które prowadzą do realizacjicelu aktora. Przyjęcie takiej perspektywy pozwala skupić się na wymaganiach wobec systemu na odpowiednim poziomie szczegółowości. Oczywiście analiza taka jest możliwa jeżeli mamy przygotowany model przypadków użycia (przez model rozumiem tutaj nie tylko diagram ale również scenariusze i prototypy interfejsów, które pozwalają lepiej zrozumieć istotę interakcji (na zasadzie pokaż mi jak to wygląda a odpowiem Ci, czy o to mi chodziło).
3. Każdy z przypadków użycia może stanowić dobrą podstawę do pisania testów akceptacyjnych od samego początku (tak jak zalecają podejścia takie jak XP oraz TDD).
4. Analizując przypadki użycia możemy zastanowić się nad tym jak określony cel aktora jest realizowany przez kolektywne zachowanie komponentów systemu. W tym miejscu mogą pojawić się klasy analityczne (stereotypy Jacobsona) oraz techniki analizy jak np. karty CRC.
5. Przypadki użycia mogą być również pomocne przy ustalaniu zrębów architektury systemu. Każdy z nas wie jak istotny jest to element działań w związku z ryzykiem jakie jest związane z architekturą. Idąc przez scenariusze możemy zastanawiać się nad tym w którym z podsystemów będzie realizowany określony krok. Możemy w ten sposób identyfikować nazwy dla podsystemów, oraz projektować w sposób prowadzący do architektury, której elementy są SPOISTE i LUŹNO POWIĄZANE (charakterystyki, które są bardzo istotne z punktu widzenia zarządzania zmianami, które są nieuchronne).
6. Przypadki użycia mogą być również wykorzystywane przy określaniu priorytetów strategicznych. Jeżeli jesteśmy w stanie zdefiniować ofertę w zakresie wartości dodanej w terminach funkcjonalności systemu, możemy ustalić kolejność realizacji, to które przypadki użycia będą napędzały proces definiowania architektury, oraz zaplanować iteracje. Jest wtedy szansa, że wszystko to, co najistotniejsze z perspektywy biznesowej zostało zawarte w architekturze systemu. Ponadto hierarchizując kolejność realizacji określonych obszarów funkcjonalnych możemy się również zastanowić nad tym jak chcemy stosować tzw. strategię różnicowania.
7. W końcu przypadki użycia mogą posłużyć jako wejście dla procesu przygotowywania podręczników użytkownika i pisania testów.
Tak więc na każdym z etapów, przypadki użycia Przypadki użycia skłaniają do ścisłej więzi z wymaganiami podczas projektowania, implementacji i testowania.
Wydaj mi się, że po głębszym zastanowieniu się nad przypadkami użycia w ten właśnie sposób można znaleźć szereg zdroworozsądkowych powodów, dla których warto z nich korzystać. Chciałbym zaznaczyć, że nie twierdzę, iż nie wolno kwestionować możliwości ich zastosowania. Wyszukiwanie powodów dla których ktoś uważa, że nie są najlepsze działa stymulująco i motywująco do poszukiwania innych , być może lepszych rozwiązań. Sam niejednokronie to robiłem przy uzasadnianiu dlaczego uważam, że moja metodologia (czy metodyka) modelowania nad którą pracuję jest lepsza i dzięki temu miałem szereg powodów aby dalej prowadzić nad nią prace. Takie działanie oczywiście nie deprecjonuje całkowicie metod, które opracowały naprawdę tęgie głowy (Jacobson, Booch etc.) oraz zostały zweryfikowane w tysiącach projektów.
Kolejną kwestią jest to, że modele, które budujemy w ramach działań analityczno projektowych powinny być tworzone w określonej kolejności. Często jest tak, że zmiana w ramach procesu abstrakcji może polepszyć proces analizy. Przykładowo, RUP zaleca rozpoczęcie działań od przypadków użycia. ICONIX z kolei (z tego co pamiętam) od modelu dziedziny etc. Tak więc wydaje mi się, że jakość kolejnego modelu (przygotowywanego w ramach procesu wytwórczego), stopień trudności analizy oraz jakość odwzorowania modelu organizacji na architekturę systemu (i co za tym idzie minimalizacja luki semantycznej) mogą zależeć od tego jaki artefakt pobieramy na wejściu. Przecież kolejne modele mogą być, zgodnie z zasadą abstrakcji, tworzone w ramach innej perspektywy analizy a analityk dla uzyskania pełniejszego obrazu wykorzystuje modele utworzone wcześniej.
Pozdrawiam :-)
Jacek Jakieła edytował(a) ten post dnia 17.01.08 o godzinie 18:51
пропозиції роботи
