Archiwalne tagi diagram aktywności

Wymagania na system specyfikują system z różnych perspektyw. Z moich doświadczeń wynika, że warto jest dokumentować wymagania z trzech perspektyw.

  • Perspektywa danych: W tej pespektywie dokumentowana jest struktura danych wejściowych/wyjściowych do/z systemu, a także statyczna struktura danych wykorzystywanych w systemie oraz relacje pomiędzy tymi danymi.
  • Perspektywa funkcjonalna: W tej perspektywie dokumentowane są informacje z otoczenia systemu, które są modyfikowane przez system oraz informacje jakie będą transmitowane z systemu do jego otoczenia.
  • Perspektywa zachowania: W tej perspektywie dokumentowane jest osadzenie systemu w jego otoczeniu oraz podstawowe stany systemu z perspektywy otoczenia. Dokumentowanie z perspektywy zachowania wykonywane jest m.in. poprzez opis reakcji systemu na zdarzenia z otoczenia, warunków, które powodują zmianę stanu systemu, czy też efektów oddziaływania systemu na jego otoczenie.

Kilka dni temu po raz kolejny uczestniczyłem w dyskusji na temat przewagi BPMN nad diagramami aktywności i odwrotnie w kontekście modelowania procesów biznesowych i systemowych (patrz tekst:  Diagramy procesów systemowych). Oba diagramy bardzo podobne do siebie choć BPMN 2.0 to już mega możliwości. Myślę, że kluczem do decyzji jest zastosowanie (czyt. Twoje potrzeby)

Lubię używać diagramów aktywności gdy:

Modele mają pomóc nam poradzić sobie ze złożonością systemów, które budujemy. Co więcej sam język UML tego nie ułatwia, gdyż jest to zestaw abstrakcyjnych piktogramów, które znaczą tylko coś wtedy, gdy umiemy je przeczytać. Prowadzę tego bloga prawię 5 lat i nigdy jeszcze nie opisywałem notacji UML. Dziś postanowiłem to naprawić. Na stronie diagramy UML opublikowałem linki do technik UML,…

W trakcie prac projektowych lub analitycznych wielokrotnie powstaje potrzeba policzenia parametrów procesu biznesowego lub szacowania złożoności budowanego oprogramowania.  Większość metod formalnych wymaga bardzo często dość trudnych obliczeń. Z drugiej strony w trakcie prac analitycznych lub projektowych powstaje zazwyczaj diagram aktywności, który w sposób naturalny prezentuje składowe procesu biznesowego lub elementy scenariusza przypadku użycia. W artykule tym postaram się zaprezentować jak za pomocą diagramów aktywności zamodelowanych w Enterprise Architect i dodatkowego narzędzia (Tormigo) można policzyć wybrane parametry procesu biznesowego.

Gdy zachodzi potrzeba zrobienia raportu zawierającego listę elementów znajdujących się wewnątrz partycji, tak jak to ma miejsce na poniższym rysunku, nie można bazować na gotowych rozwiązaniach gdyż takich w EA nie ma.

image 

Budowa raportu to kilka kroków. Przedstawiam je poniżej.

1. Należy zbudować raport (zakładka template w raportach EA) o zawartości:

clip_image002

Co zrobić w sytuacji gdy do wykonania danej funkcji, opisanej przez przypadek użycia, potrzeba w tym samym momencie więcej niż jednego aktora? Czy można pokazać to na diagramie przypadków użycia? Otóż nie. Diagram przypadków użycia nie definiuje nam tego kto w jakiej sytuacji, w jakim momencie korzysta z danej funkcji. Relacja aktor - przypadek użycia mówi jedynie o tym kto…

Scenariusze Procesów Biznesowych opisują, jak pracownicy i byty biznesowe wchodzą w interakcje, aby zrealizować funkcje reprezentowane przez biznesowe przypadki użycia. Scenariusz Procesu Biznesowego zazwyczaj jest realizowany za pomocą opisu słownego i/lub diagramu aktywności. Scenariusze Procesów Biznesowych są wykorzystywane, aby sprawdzić, czy zespół projektowy (lub inne osoby) rozumieją, w jaki sposób jest zbudowana i działa organizacja. Scenariusze Procesów Biznesowych mogą być…

12
Chcę otrzymywać powiadomienia o nowych wpisach na tym blogu

Wyrażam zgodę na przetwarzanie powyższych danych. Potwierdzam zapisanie się na newsletter w celu otrzymywania powiadomień o nowych wpisach. (Mogę wypisać się w dowolnym momencie)

FreshMail.pl
 
Close