| UML: od analizy biznesowej do analizy systemowej |
|---|
| Napisane przez Sun 15 Oct 2006 przez Artur (5131 cztane) |
|
UML: od analizy biznesowej do analizy systemowej Autor: Tomasz Para Analiza biznesowa jest fazą, która często jest pomijana podczas tworzenia nowych systemów informatycznych. Wynika to z faktu, że developer nie chce tracić czasu (czyt.: pieniędzy) na modelowanie czegoś co już istnieje i woli się skupić na analizie systemowej, która bezpośrednio jest potrzebna do wyprodukowania i dostarczenia zamawianego przez klienta systemu informatycznego. Należy natomiast pamiętać, że dostarczany system, nie tylko powinien spełniać wymagania postawione przez zamawiającego, ale także powinien usprawniać i korygować wadliwe procesy biznesowe zachodzące w organizacji klienta. Brak analizy biznesowej powoduje utrwalenie błędnych procesów. W niniejszym artykule zostanie przedstawiony krótki przewodnik, prezentujący w jaki sposób płynie przejść od analiz biznesowej do analizy systemowej oraz z jakich elementów UML należy skorzystać. 1. Modelowanie biznesowych przypadków użycia. a) Identyfikacja biznesowych przypadków użycia Na początek należy zidentyfikować tzw. end-to-end procesy biznesowe (czyli schematy działań organizacji podczas wykonywania określonych zadań zmierzających do osiągnięcia celów biznesowych). Po zidentyfikowaniu aktorów i przypadków użycia przedstawiamy wyniki na diagramie biznesowych przypadków użycia (o podstawowych elementach UML w modelowaniu biznesowym można poczytać tutaj: http://www.uml.com.pl/modules/articles/article.php?id=9 ) Na rys. 1 znajduje się przykładowy diagram biznesowego przypadku użycia. Oczywiście każdy przypadek użycia powinien ponadto zostać opisany za pomocą tekstowego scenariusza, którego forma jest uzależniona od metodyki i wewnętrznych preferencji developera. b) Określenie schematu działania biznesowych przypadków użycia W momencie gdy już zidentyfikowaliśmy przypadki użycia, musimy opisać czynności podejmowane kolejno przez aktorów w ramach każdego przypadku użycia (określane to jest nazwą „scope”, która nie ma równie celnego odpowiednika w języku polskim, a co można zdefiniować jako: wyszczególniony zestaw czynności i ludzi, którzy są w nie zaangażowani). Najlepszą graficzną formą zaprezentowania schematu działania jest diagram aktywności (rys. 2). Co prawda niektórzy analitycy preferują diagram sekwencji, ale w tym przypadku jest on mniej czytelny dla nie-technicznego klienta i lepiej używać go w fazie projektowania systemu, a nie rozmów z klientem. 2. Modelowanie systemowych przypadków użycia Gdy już zrozumieliśmy działanie i procesy zachodzące u klienta, nadchodzi czas aby zastanowić się jak nowy system IT może pomóc zautomatyzować te procesy patrząc z perspektywy użytkownika. a) Identyfikacja aktorów (mapa ról) Pierwszym krokiem jest zidentyfikowanie aktorów systemowych (ról odgrywanych w kontakcie z projektowanym systemem - w tym również innych systemów IT). Rezultaty tej analizy należy przedstawić na diagramie mapy ról (map diagram), najlepiej z uwzględnieniem generalizacji (przykład - rys. 3). Należy zauważyć, że zazwyczaj zbiór aktorów systemowych jest mniejszy niż zbiór aktorów biznesowych, nie można więc po prostu przepisać aktorów biznesowych jako systemowych. b) Identyfikacja pakietów przypadków użycia Ten krok jest opcjonalny i pomocny przy dużej liczbie systemowych przypadków użycia. Do pakietów „wrzucamy” przypadki użycia logicznie ze sobą powiązane (np. ze względu na wspólnego aktora; dotyczące jednego biznesowego przypadku użycia, itp. - rys.4 przykład). c) Identyfikacja systemowych przypadków użycia W tym kroku należy przeanalizować jakie przypadki użycia są potrzebne do wsparcia biznesowych przypadków użycia i przedstawić wyniki analizy za pomocą diagramu przypadków użycia (rys. 5). 3. Wstępny model statyczny W tym kroku rysujemy bardzo wstępny i pozbawiony wszelkich szczegółów diagram klas (rys. 6), który będzie służył głównie jako glosariusz pojęć potrzebnych do dalszej pracy, a jego uściślenie będzie następowało w dalszych etapach modelowania. 4a. Analiza dynamiczna a) Opis systemowych przypadków użycia W tym punkcie należy opisać według zadanego szablonu scenariusze przypadków użycia. Co prawda nie ma tutaj elementów UML, ale na podstawie stworzonych scenariuszy możemy przeorganizować model systemowych przypadków użycia dodając do niego relacje include, extend i generalize, co czyni ten model łatwiejszym do wprowadzania wszelkich zmian. b) Opis stanów zachowania Za pomocą diagramu stanów, należy wymodelować zmiany stanów kluczowych obiektów systemu (nie ma potrzeby modelowania wszystkich). Najprościej zrobić to poprzez wykonanie kolejnych kroków: - wyodrębnić poszczególne stany dla obiektu - znaleźć przyczyny przejść (transitions) obiektu z jednego stanu do drugiego - zidentyfikować działania zachodzące w czasie gdy obiekt jest w danym stanie oraz zaznaczyć kiedy zachodzą na działania (na wejściu, w trakcie, przy wyjściu ze stanu) - uprościć model poprzez zastosowanie stanów kompozytowych (stan zawierający kilka innych stanów) - wprowadzenie stanów współbieżnych (concurrent) - tzn. obiekt może być w różnych stanach w zależności jakie kryterium rozpatrujemy. Po zebraniu razem wszystkich powyższych danych, najlepiej jest przedstawić je na diagramie stanów (rys. 7). 4b. Analiza statyczna Model statyczny jest abstrakcyjną reprezentacją tego czym system jest. Pokazuje aspekty systemu, które nie są powiązane z czasem; ich strukturę oraz związki pomiędzy nimi. Głównym diagramem tutaj używanym jest diagram klas wraz z wszelkimi jego aspektami: dziedziczeniem, agregacją, kompozycją, asocjacją, liczebnością. Przykładowy model klas znajduje się na rys. 8. Na koniec części analizy statycznej pozostaje znalezienie atrybutów i operacji poszczególnych klas. Punkty 4a i 4b powinny być wykonywane współbieżnie. Kolejne etapy działań stają się już działaniami bardziej projektowymi i wykraczają poza ramy tego artykułu. Od tego momentu projekt przechodzi do fazy wykonania i developerzy (m.in. analityk systemowy, architekt systemowy, architekt baz danych) zaczynają działania zmierzające do przekształcenia wypracowanego modelu biznesowego na model do użytku technicznego. |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.