Modelowanie, prototypowanie i specyfikowanie oprogramowania
Wstęp
Analiza wymagań
Przypadki użycia
Identyfikacja aktorów
Specyfikowanie przypadków użycia
Tworzenie diagramu przypadków użycia oraz diagramu klas
Diagram klas
Generalizacja
Zawieranie
Powiązania
Tworzenie_scenariuszy
Tworzenie_wytycznych
Tworzenie_diagramu_interakcji
Budowa_pakietów
Analiza_aplikacji
Analiza systemów
Modele w dziedzinie inżynierii oprogramowania tworzy się po to, aby lepiej zrozumieć działanie projektowanego systemu, lub jego pojedynczej składowej w postaci obiektu. Jeżeli obiekt ten reprezentuje konstrukcję fizyczną (np. budynek, pojazd), to w takim przypadku model może być jego dokładną kopią. Jednak, aby właściwie spojrzeć na cały projektowany system informatyczny musimy przede wszystkim w naszym modelu przedstawić wszystkie przetwarzane informacje, funkcje odpowiedzialne za ich przetwarzanie, a także zachowanie systemu podczas działania jego procesów. W tym celu należy przede wszystkim stworzyć modele:
funkcji
zachowania
Najprostszy model funkcji to tak zwany model kontekstowy, który sprowadza się w zasadzie do podania nazwy analizowanego produktu. Model ten jednak jest zalążkiem bardziej szczegółowych modeli, prowadzących do dokładnego opisania wszystkich funkcji systemu.
Oprogramowanie zazwyczaj reaguje również na zdarzenia zachodzące w jego otoczeniu. Program komputerowy zawsze bowiem znajduje się w pewnym stanie (np. czekania, przetwarzania danych, drukowania, pobierania danych), który może się zmienić tylko w odpowiedzi na pewne zdarzenie. System może na przykład pozostawać w stanie oczekiwania, aż zegar systemowy wskaże, że minął pewien określony czas. Również zdarzenie zewnętrzne, którym jest poruszenie myszką spowoduje wystąpienie przerwania. Dlatego w celu uwzględnia takich stanów stosuje się modele zachowania. Modele te opisują więc możliwe stany i zdarzenia, które mogą spowodować zmianę stanu dowolnego obiektu projektowanego systemu.
Modele powyższe powstają podczas fazy analizy wymagań i spełniają takie zadania jak:
pomagają analitykom zrozumieć przetwarzane informacje, funkcje i zachowania systemu, a tym samym ułatwiają i pozwalają uporządkować analizę wymagań
stanowią główny klucz do sprawdzenia kompletności, spójności i dokładności specyfikacji
są podstawą działań projektowych, ponieważ powstałe w ten sposób opisy oprogramowania można dosyć łatwo przełożyć na projekt w postaci implementacji
Opisane podejście jest więc niezbędnym wstępem do przeprowadzenia skutecznego procesu analizowania wymagań. Proces ten oprócz modelowania dzieli się na cztery podstawowe obszary:
rozpoznanie problemu
analizowanie i synteza rozwiązania
specyfikowanie
przegląd
Rozpoczynając pracę analityk musi się zapoznać ze specyfikacją systemu informatycznego oraz z planem przedsięwzięcia. Jest to warunek niezbędny, aby zrozumieć zakres działania produktu w zakresie sporządzania prognoz. Następnie musi on nawiązać komunikację z klientami i użytkownikami, aby poznać szczegóły zagadnień i oczekiwań. Celem tej czynności jest zrozumienie podstawowych aspektów problemu z punktu widzenia klienta (użytkownika). Następny etap analizowania to synteza rozwiązań. Analityk powinien bowiem zdefiniować wszystkie obiekty danych widoczne z zewnątrz, określić przepływ danych i zawartość informacji, ustalić listę funkcji oprogramowania, zrozumieć zachowanie oprogramowania w kontekście zdarzeń mających wpływ na pracę systemu, opisać wszystkie potrzebne interfejsy i wykryć dodatkowe ograniczenia projektowe. Wszystkie te powyższe zadania należy wykonać tak, aby uzyskany opis problemu umożliwił stworzenie jego rozwiązania.
Faza inżynierii oprogramowania, w której precyzowany jest pomysł, jest bardzo krótka. Może trwać krócej niż pomysł połączony z czasem wymaganym do zapisania pomysłu na kartce. Aby przejść do analizy, należy przede wszystkim zrozumieć, w jaki sposób produkt będzie używany i jak musi działać. Głównym celem fazy analizy jest sprecyzowanie tych wymagań. Efektem końcowym natomiast tej fazy jest stworzenie dokumentu zawierającego opracowane wymagania. Pierwszą częścią tego dokumentu jest analiza przypadków użycia produktu.
Istotną częścią analizy, projektowania i implementacji są przypadki użycia. Przypadek użycia jest ogólnym opisem sposobu, w jaki produkt będzie używany. Przypadki użycia nie tylko ukierunkowują analizę, ale także pomagają w określeniu klas oraz są szczególnie ważne podczas testowania produktu.
Tworzenie stabilnego i wyczerpującego zestawu przypadków użycia może być więc najważniejszym zadaniem całej analizy. Właśnie wtedy jesteśmy najbardziej uzależnieni od ekspertów w danej dziedzinie, ponieważ to oni wiedzą najwięcej o dziedzinie pracy, której wymagania próbujemy określić. Przypadki użycia są w niewielkim stopniu związane z interfejsem użytkownika, nie są natomiast związane z wnętrzem budowanego systemu. Każda osoba (lub system) współpracująca z projektowanym systemem jest nazywana aktorem.
Dlatego też możemy tutaj wyróżnić główne pojęcia, takie jak:
przypadek użycia - opis sposobu, w jaki używane będzie oprogramowanie,
eksperci - osoby znające się na dziedzinie, dla której jest tworzony produkt,
aktor - każda osoba (lub system) współpracująca z projektowanym systemem.
Przypadek użycia jest opisem interakcji zachodzących pomiędzy aktorem a samym systemem. W trakcie analizy przypadku użycia system jest traktowany jako „czarna skrzynka.” Aktor „wysyła komunikat” do systemu, po czym zwracana jest informacja, zmienia się stan systemu, itd.
Rozważając przedstawione powyżej informacje należy pamiętać, że nie wszyscy aktorzy są ludźmi. Systemy współpracujące z budowanym systemem także są aktorami. Gdy budujemy na przykład bankomat, aktorami mogą być urzędnik bankowy i klient - a także inny system współpracujący z aktualnie tworzonym systemem, na przykład system śledzenia pożyczek czy udzielania kredytów studenckich. Możemy jednak powiedzieć jednoznacznie, że aktorzy:
istnieją zawsze na zewnątrz dla systemu,
współpracują z systemem.
Często najtrudniejszą częścią analizy przypadków użycia jest jej początek. Zwykle najlepszą metodą rozwiązania tego problemu jest sesja burzy mózgów. Spisujemy wtedy po prostu listę osób i systemów, które będą pracować z nowym systemem. Należy pamiętać jednak, że mówiąc o ludziach, w rzeczywistości mamy na myśli role - urzędnika bankowego, kasjera, klienta, itd. Jedna osoba może natomiast pełnić więcej niż jedną rolę.
We wspomnianym przykładzie, na naszej liście mogą wystąpić następujące role:
klient
personel banku
system bankowy
osoba wypełniająca bankomat pieniędzmi i materiałami
Wygenerowanie trzech lub czterech aktorów przeważnie wystarcza do rozpoczęcia generowania przypadków użycia. Każdy z tych aktorów pracuje bowiem przeważnie z systemem w inny sposób.
Zaczynając od roli klienta podczas burzy mózgów możemy określić dla niego następujące przypadki użycia:
klient sprawdza stan swojego rachunku,
klient wpłaca pieniądze na swój rachunek,
klient wypłaca pieniądze ze swojego rachunku,
klient przelewa pieniądze z rachunku na rachunek,
klient otwiera rachunek,
klient zamyka rachunek.
Powinniśmy tutaj dokonać odpowiedzi na pytanie na przykład pomiędzy przypadkiem, kiedy klient wpłaca pieniądze na swój rachunek bieżący oraz wtedy, kiedy klient wpłaca pieniądze na lokatę, czy powinniśmy te działania połączyć, czy też pozostawić je jako oddzielnie występujące przypadki. Odpowiedź na to pytanie zależy głównie od tego, czy takie rozróżnienie ma znaczenie dla danej dziedziny (dziedzina jest rzeczywistym środowiskiem, które modelujemy - w tym przypadku jest nią bankowość). Aby sprawdzić, czy te działania są jednym przypadkiem użycia, czy też dwoma, musimy przede wszystkim uzyskać odpowiedź na pytanie, czy ich mechanizmy są różne (czy klient w każdym z określonych przypadków robi coś innego) oraz czy różne są ich wyniki (czy system odpowiada na różne sposoby). W naszym przykładzie, w obu przypadkach odpowiedź brzmi negatywnie. Klient składa bowiem pieniądze na każdy z rachunków w ten sam sposób, przy czym wynik także jest podobny, gdyż bankomat odpowiada, zwiększając stan odpowiedniego rachunku.
Zakładając, że aktor i system działają i odpowiadają mniej więcej identycznie, bez względu na to, na jaki rachunek dokonuje wpłaty, te dwa przypadki użycia są w rzeczywistości jednym sposobem. Później, gdy opracujemy już scenariusze przypadków użycia, możemy wypróbować obie wariacje i sprawdzić, czy ich rezultatem są jakiekolwiek różnice.
Odpowiadając na poniższe pytania, możemy utworzyć również w bardzo prosty sposób dodatkowe przypadki użycia:
Dlaczego aktor używa tego systemu?
Klient używa tego systemu, aby zdobyć gotówkę, złożyć depozyt lub sprawdzić bieżący stan rachunku.
Jakiego wyniku oczekuje aktor po każdym żądaniu?
Zwiększenia stanu rachunku lub uzyskania gotówki na zakupy.
Co spowodowało, że aktor używa w tym momencie systemu?
Być może ostatnio otrzymał wypłatę lub jest na zakupach.
Co aktor musi zrobić, aby użyć systemu?
Włożyć kartę do szczeliny w bankomacie.
Potrzebujemy więc następnego przypadku użycia dla logowania się klienta do systemu.
Jakie informacje aktor musi dostarczyć systemowi?
Musi wprowadzić kod PIN.
Potrzebujemy więc przypadków użycia dla uzyskania i edycji kodu PIN.
Jakich informacji aktor oczekuje od systemu?
Stanu rachunku itd.
Często dodatkowe przypadki użycia możemy znaleźć też skupiając się na atrybutach obiektów w danej dziedzinie. Po szczegółowym przeanalizowaniu przypadków użycia dla klienta, następnym krokiem w opracowywaniu listy przypadków użycia jest opracowanie przypadków użycia dla wszystkich pozostałych aktorów. Poniższa lista przedstawia pierwszy zestaw przypadków użycia dla naszego przykładu z bankomatem:
klient sprawdza stan swojego rachunku,
klient wpłaca pieniądze na swój rachunek,
klient wypłaca pieniądze ze swojego rachunku,
klient przekazuje pieniądze z rachunku na rachunek,
klient otwiera rachunek,
klient zamyka rachunek,
klient loguje się do swojego rachunku,
klient sprawdza ostatnie transakcje,
urzędnik bankowy loguje się do specjalnego konta przeznaczonego do zarządzania,
urzędnik bankowy dokonuje zmian w rachunku klienta,
system bankowy aktualizuje stan rachunku klienta na podstawie działań zewnętrznych,
zmiany rachunku użytkownika są odzwierciedlane w systemie bankowym,
bankomat sygnalizuje niedobór pieniędzy,
technik uzupełnia w bankomacie gotówkę i materiały.
Mając już pierwszą wersję przypadków użycia, możemy zacząć wypełniać dokument wymagań szczegółowym modelem dziedziny. Model dziedziny jest dokumentem zawierającym wszystko to, co wiemy o danej dziedzinie (zagadnieniu). Jako część modelu dziedziny tworzymy więc obiekty dziedziny, opisujące wszystkie obiekty wymienione w przypadkach użycia.
Przykład z bankomatem zawiera następujące obiekty: klient, personel banku, system bankowy, rachunek bieżący, lokata, itd. Dla każdego z tych obiektów dziedziny możemy uzyskać tak ważne dane, jak nazwa obiektu (na przykład klient, rachunek, itd.), odpowiedź na pytanie czy obiekt jest aktorem, podstawowe atrybuty i zachowanie obiektu.
To, co opisujemy, nie jest jednak obiektem projektu, ale obiektem dziedziny. Odzwierciedla więc sposób funkcjonowania świata, a nie sposób działania naszego systemu. Możemy określić jednak relacje (asocjacje) pomiędzy obiektami dziedziny korzystając z modelu struktury języka modelowania UML, w postaci diagramu klas.
Na utworzonym diagramie prostokąty reprezentują różne obiekty dziedziny; zaś strzałki wskazują generalizację. UML zakłada, że linie są rysowane w kierunku od klasy wyspecjalizowanej do bardziej ogólnej klasy „bazowej.” Dlatego, zarówno Rachunek bieżący, jak i Rachunek lokaty, wskazują na Rachunek bankowy, informując że każdy z nich jest wyspecjalizowaną formą Rachunku bankowego.
Podstawowe relacje diagramu klas to:
generalizacja (lub specjalizacja),
zawieranie
powiązanie.
Generalizacja jest często porównywana z „dziedziczeniem,” lecz istnieje pomiędzy nimi wyraźna, istotna różnica. Generalizacja opisuje relację; dziedziczenie jest programową implementacją generalizacji - jest sposobem przedstawienia generalizacji w kodzie. Odwrotnością generalizacji jest specjalizacja. Pojazd wodny jest wyspecjalizowaną formą pojazdu, zaś pojazd jest generalną formą pojazdu wodnego lub pojazdu lądowego.
Specjalizacja określa, że obiekt wyprowadzony jest podtypem obiektu bazowego. Zatem na przykład rachunek bieżący jest rachunkiem bankowym. Taka relacja jest symetryczna, bowiem rachunek bankowy generalizuje ogólne zachowanie i atrybuty rachunku bieżącego jak i rachunku lokaty.
Często obiekt składa się z wielu podobiektów. Na przykład samochód składa się z kierownicy, kół, drzwi, radia, itd. Rachunek bieżący składa się ze stanu, historii transakcji, identyfikatora klienta, itd. Mówimy wtedy, że rachunek bieżący posiada te elementy. W języku UML możemy taki typ relacji przedstawić za pomocą strzałki z rombem, wskazującej obiekt zawierany.
Diagram z powyższego rysunku mówi nam, że rachunek osobisty posiada stan. Można również połączyć oba diagramy, przedstawiając w ten sposób dość złożony zestaw relacji.
Diagram z powyższego rysunku informuje, że rachunek bieżący i rachunek lokaty są rachunkami bankowymi oraz, że rachunki bankowe posiadają zarówno stan, jak i historię transakcji.
Trzecią relacją, wykrywaną zwykle podczas analizowania dziedziny, jest proste powiązanie. Powiązanie sugeruje, że dwa obiekty w jakiś sposób ze sobą współpracują. Ta definicja staje się dużo bardziej precyzyjna w fazie projektowania, ale w fazie analizy sugerujemy jedynie, że obiekt A współpracuje z obiektem B, oraz że jeden obiekt nie zawiera drugiego, a także, że żaden z nich nie jest specjalizacją drugiego. W języku UML powiązania między obiektami są przedstawiane przy pomocy zwykłej prostej linii pomiędzy obiektami.
Diagram ten oznacza, że ObiektA jest powiązany z ObiektemB.
Na etapie posiadanego już gotowego wstępnego zestawu przypadków użycia oraz narzędzi, dzięki którym możemy przedstawić relacje pomiędzy obiektami w dziedzinie, powinniśmy następnie dążyć do uporządkowania przypadków użycia i zdefiniowania ich przeznaczenia.
Każdy przypadek użycia można „rozbić” na serie scenariuszy. Scenariusz jest opisem określonego zestawu okoliczności towarzyszących danemu przypadkowi użycia. Na przykład, przypadek użycia „klient wypłaca pieniądze ze swojego rachunku” może posiadać następujące scenariusze:
klient żąda dwieście złotych z rachunku bieżącego, otrzymuje gotówkę, po czym system drukuje kwit,
klient żąda dwieście złotych z rachunku bieżącego, lecz na rachunku znajduje się na przykład tylko sto złotych. Klient jest informowany wtedy, że na koncie znajduje się zbyt mało środków, aby spełnić jego żądanie,
klient żąda tysiąca złotych z rachunku bieżącego, ale tego dnia pobrał już czterysta złotych, a limit dzienny wynosi pięćset złotych. Klient jest informowany wtedy o problemie i może się zdecydować na pobranie jedynie stu złotych,
klient żąda dwustu złotych z rachunku bieżącego, ale skończył się papier w drukarce. Klient jest informowany o problemie i może się zdecydować na pobranie pieniędzy bez potwierdzenia w postaci kwitu.
Każdy scenariusz przedstawia wariant tego samego przypadku użycia. Często te sytuacje są sytuacjami wyjątkowymi (zbyt mało środków na rachunku, zbyt mało gotówki w bankomacie, itd.). Czasem warianty dotyczą drobnych różnic w podejmowaniu decyzji w samym sposobie użycia (na przykład, czy przed podjęciem gotówki klient chce dokonać transferu środków).
Nie musimy jednak analizować każdego ewentualnego scenariusza. Szukamy tylko tych scenariuszy, które prezentują wymagania systemu lub szczegóły interakcji z aktorem.
W celu udokumentowania każdego ze scenariuszy możemy utworzyć tak zwane wytyczne. Wytyczne te znajdą się w dokumentacji wymagań. Dlatego też każdy scenariusz powinien zawierać:
warunki wstępne - warunki jaki muszą być spełnione, aby scenariusz się rozpoczął,
włączniki - co powoduje, że scenariusz się rozpoczyna,
akcje, jakie podejmuje aktor,
wyniki lub zmiany powodowane przez system,
informację zwrotną otrzymywaną przez aktora,
informacje o występowaniu cyklicznych operacji i o przyczynach ich wykonywania,
schematyczny opis przebiegu scenariusza,
okoliczności powodujące zakończenie scenariusza,
warunki końcowe - jakie warunki muszą być spełnione w momencie zakończenia scenariusza.
Diagram, który nie dostarcza zbyt wielu informacji, poza wysokopoziomową abstrakcją interakcji pomiędzy aktorem (klientem) a systemem jest bezużyteczny. Diagram ten stanie się nieco bardziej użyteczny, gdy przedstawimy interakcję pomiędzy sposobami użycia. Możliwe są tutaj tylko dwie interakcje: <<zawiera>> (<<include>>) i <<rozszerza>> (<<extends>>). Stereotyp <<zawiera>> wskazuje, że jeden przypadek zawiera w sobie inny. Na przykład, nie jest możliwa wypłata gotówki bez wcześniejszego zalogowania się.
Powyższy przykład pokazuje, że przypadek użycia Wypłata Gotówki „zawiera w sobie” („korzysta z”) przypadku użycia Logowanie i w pełni implementuje Logowanie jako część Wypłaty Gotówki.
Przypadek użycia <<rozszerza>> został opracowany w celu wskazania relacji warunkowych i częściowo odnosi się do dziedziczenia. Stereotypu <<zawiera>> używa się, aby uniknąć kopiowania i wklejania całego przypadku użycia, a <<rozszerza>> wtedy, gdy korzysta się z przypadku użycia tylko w określonych warunkach.
Diagram przypadku użycia może mieć ograniczoną wartość, dlatego też często wiąże się go z przypadkiem użycia, który może znacznie wzbogacić dokumentację i ułatwić zrozumienie interakcji. Na przykład kiedy wiemy, że scenariusz Wypłata Gotówki reprezentuje interakcję pomiędzy następującymi obiektami dziedziny: klientem, rachunkiem bieżącym oraz interfejsem użytkownika możemy przedstawić tę interakcję na następującym diagramie interakcji.
Diagram interakcji z powyższego przykładu przedstawia te szczegóły scenariusza, które mogą nie zostać zauważane podczas czytania tekstu. Współdziałające ze sobą obiekty są obiektami dziedziny, a cały bankomat wraz z interfejsem użytkownika traktowany jest jako pojedynczy obiekt, wywoływany szczegółowo jest tylko określony rachunek bankowy.
Ten prosty przykład bankomatu pokazuje jednak jedynie ograniczony zestaw interakcji, ale szczegółowe ich przeanalizowanie może okazać się bardzo pomocne w zrozumieniu zarówno dziedziny problemu, jak i wymagań nowego systemu.
Ponieważ dla każdego problemu o znacznej złożoności generuje się wiele przypadków użycia, język UML umożliwia grupowanie ich w pakiety.
Pakiet przypomina kartotekę lub folder - jest zbiorem obiektów modelowania (klas, aktorów, itd.). Aby opanować złożoność przypadków użycia, możemy tworzyć pakiety pogrupowane według charakterystyk, mających znaczenie dla danego projektu. Możemy więc pogrupować własne przypadki użycia według rodzaju rachunku (wszystko, co odnosi się do rachunku bieżącego albo do lokaty), według wpływów albo obciążeń, według rodzaju klienta czy według jakiejkolwiek innej charakterystyki, która ma sens w danym przypadku. Pojedynczy przypadek użycia może występować w kilku różnych pakietach, ułatwiając w ten sposób projektowanie.
Oprócz tworzenia przypadków użycia, dokument wymagań powinien zawierać założenia i ograniczenia klienta, a także wymagania wobec sprzętu i systemu operacyjnego. Wymagania aplikacji są założeniami pochodzącymi od konkretnego klienta.
Wymagania aplikacji są często narzucane przez konieczność współpracy z istniejącymi systemami. W takim przypadku kluczowym elementem analizy jest zrozumienie sposobów działania istniejących systemów
W idealnych warunkach analizuje się problem, projektuje rozwiązanie, po czym decyduje, jaka platforma i system operacyjny najlepiej odpowiadają potrzebom danego projektu. Taka sytuacja jest jednak nie tylko idealna, ale i bardzo rzadka. Dużo częściej zdarza się, że klient zainwestował już w określony sprzęt lub system operacyjny. Plany jego firmy opierają się na działaniu oprogramowania w istniejącym już systemie, więc należy poznać te wymagania jak najwcześniej i odpowiednio się do nich dostosować.
Często oprogramowanie jest zaprojektowane jako samodzielne. Współpracuje ono jedynie z końcowym użytkownikiem. Analiza systemów to proces zbierania wszystkich informacji na temat systemów, z którymi będziemy mieli do czynienia. Są to głównie odpowiedzi na pytania: czy nowy system będzie serwerem, dostarczającym usługi istniejącym systemom, czy też będzie ich klientem, czy będziemy mogli negocjować interfejs pomiędzy systemami, czy też musimy się dostosować do istniejącego standardu, czy inne systemy pozostaną niezmienne, czy też przez cały czas będziemy śledzili zachodzące w nich zmiany. Na te pytania należy odpowiedzieć podczas fazy analizowania, jeszcze przed przystąpieniem do projektowania nowego systemu. Oprócz tego, powinniśmy poznać ograniczenia wynikające ze współpracy z innymi systemami.
11
Wyszukiwarka