Wstęp W niedawno napisanym artykule na temat przypadków użycia i ich definicji zgodnej z UML, wskazywałem między innymi, że: Przypadki użycia są sposobem na uchwycenie [wskazanie] wymagań stawianych systemom, tzn. tego, co systemy mają robić [powody, dla których one powstaną, co będą realizowały] na rzecz i na żądanie Aktora. źr.: Diagram Przypadków Użycia UML - Jarosław Żeliński IT-Consulting Sama specyfikacja UML o aktorze, jako elemencie wokół systemu, mówi bardzo niewiele, poza rozdziałem dotyczącym przypadków użycia: Przypadki użycia są sposobem na uchwycenie wymagań systemów, czyli tego, co systemy mają robić. Kluczowymi pojęciami…
Wprowadzenie Pojęcie kontekstu projektu i diagram przypadków użycia jako narzędzie, nadal rodzi wiele pytań. Spowodowane jest to tym, że diagram przypadków użycia to najczęściej wykorzystywany diagram, najczęściej też "nielegalnie przeciążany" informacjami o architekturze wewnętrznej (związki 'include' i 'extend'). Jest to także najbardziej abstrakcyjny diagram w notacji UML. Postanowiłem odpowiedź "publicznie" na pytanie, które w różnych formach, często pada w projektach, na szkoleniach i w mailach do mnie kierowanych. Przykład jednego z nich: Mam pytanie, które dręczy mnie od jakiegoś czasu i teraz zmobilizowałam się by je zadać. W artykule Jarosław…
Dzisiaj co nieco o filozofii i przypadkach użycia. Dzielenie przypadków użycia na "rodzaje" zawsze budziło mój sprzeciw, w UML (w oryginale) mamy jedno pojęcie: "przypadek użycia systemu", gdzie systemem jest coś (przedmiot opisu), czyli "analizowany/modelowany system" (patrząc na system w rozumieniu teorii systemów, tu zwracam uwagę na fakt, że UML to nie tylko IT). Wobec tego skoro system (wymiennie "przedmiot zainteresowania", "przedmiot analizy"), zanim będzie rozpatrywany, musi być określony (granice systemu, który jest częścią "nad" (super) systemu, a składa się z podsystemów, polecam Sienkiewicz, Teoria Systemów), otrzymamy prostą rzecz: przypadek…
