W poszukiwaniu samotnych elementów w Enterprise Architect

Bardzo często zdarza się, że chcemy mieć informację o tych elementach, które nie zostały zmapowane na inne elementy. Przykładowo możemy szukać tych wymagań, które nie realizują żadnych przypadków użycia. Inny przykład to poszukujemy tych elementów procesu biznesowego, który nie wspierają usługi aplikacyjne. Innymi słowy szukamy samotnych elementów.

Enterprise Architect wspiera możliwość raportowania takich osieroconych elementów. Są dwa sposoby na szukanie. Pierwszy znany od dawna to skrypt w SQL i raportowanie w Excel, a drugi to wykorzystanie mechanizmów wbudowanych w Enterprise Architect (niestety elementy SQL także trzeba znać Uśmiech )

Postaram się dziś opisać ten drugi mechanizm. Przykładowy diagram prezentuje usługi aplikacyjne zmapowane na proces biznesowy. Używam notacji Archimate.

image

BusinessProcess2 nie jest wspierany przez usługi aplikacyjne. Może to być wynikiem błędu w analizie lub rzeczywiście tak jest. Oczywiście mając jeden diagram i 6 elementów sytuacja jest prosta. Mając kilkadziesiąt procesów i kilkaset usług aplikacyjnych jest trochę trudniej.

Dodatkowo poza diagramem w strukturze repozytorium mam jeden element, który nie żadnym diagramie.

image

Zadanie: szukamy elementów BusinessProcess, do których nie zostały podłączone usługi aplikacyjne.

Enterprise Architect oferuje diagram dashboard na którym można w toolbox znaleźć wiele różnych wykresów i raportów.

image

Do zrealizowania naszego zadania idealnym jest element ModelView. Po “wrzuceniu” go na diagram wystarczy, że napiszę parę linijek zapytania SQL.  W tym przypadku wspomniane zapytanie SQL wygląda następująco:

image

Wynikiem tego zapytania jest diagram, na którym mam wspomnianą listę.

image

Plusy takiego raportowania. Wszystko dzieje się w Enterprise Architect i raport jest aktualizowany w czasie rzeczywistym tj. wystarczy odświeżyć element ModelView. Minusy. Niestety trzeba wcześniej poczytać dokumentację Enterprise Architect i zorientować się jak w tabelach zapisywane są elementy oraz konektory. Znajomość SQL też jest przydatna.

W podany sposób można raportować wiele zależności pomiędzy elementami. Zawartość raportów ogranicza tylko nasza fantazja.

Podobne wpisy

  • Struktura dokumentów wymagań cz. 2 Standaryzowane struktury dokumentów powinny być dostosowywane do specyficznych wymagań projektów. Natomiast każda struktura dokumentu wymagań powinna uwzględniać następujące informacje: […]
  • Inżynieria wymagań – certyfikat Inżynieria wymagań jest pierwszym etapem projektów informatycznych i ma decydujące znaczenie dla ich powodzenia. Inżynieria wymagań określa wszystkich interesariuszy projektu i jego […]
  • Byt biznesowy Byt Biznesowy reprezentuje istotne i trwałe informacje, którymi posługują się aktorzy biznesowi oraz pracownicy biznesowi. Byty biznesowe są bierne czyli nie nawiązują interakcji […]
  • Modelowanie gier w języku UML O tym, że modelowanie jest przydatne w projektowani wszelakich aplikacji, nie trzeba przekonywać nikogo. Cieszy mnie bardzo, gdy widzę, że kolejne firmy mają ten sam pogląd i razem […]
  • Aplikacje WWW w terenie, czyli o tym, jak budować rozwiązania w technologii ASP.NET dla urządzeń przenośnych Artykuł opublikowany na Codeguru.pl Usługi WWW przebojem wkraczają w nasze życie. Coraz częściej istnieje potrzeba by korzystać z internetu nie tylko przy biurku w pracy czy domu, ale […]
Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry