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

  • Sprint Planning Meeting – Planowanie Sprintu Na spotkaniu dot. Planowania Sprintu (ang. Sprint Planning Meeting) Zespół Scrum oraz Właściciel Produktu określają, które cechy i zadania będą poddane próbie wykonania w nadchodzącym […]
  • Metodyka Scrum – zapowiedź cyklu wpisów   W 2009 roku napisałem kilka postów dotyczących metodyki Scrum. Opisałem role, artefakty i wykonywane czynności. Dziś Scrum jest powszechnie wykorzystywaną metodyką pracy. Stanowi […]
  • Mój blog czytany przez eksperta Miłą niespodzianką dla mnie okazał się fakt iż mój blog czyta osoba, którą uważam za ekspert w dziedzinie modelowania. Tą osobą jest Jarosław Żeliński (http://it-consulting.pl/). Cieszy […]
  • Modelowanie biznesowe – znaczenie Celem modelowania biznesu jest: Zrozumienie bieżących problemów w docelowej organizacji i określenie potencjałów udoskonalenia. cena wpływu zmiany organizacyjnej. Zapewnienie, że […]
  • Czynność: Spotkanie Przeglądowe Sprintu (Sprint Review Meeting) Każdy sprint kończy się Spotkaniem Przeglądowym Sprintu (ang. Sprint Review Meeting), gdzie zespół pokazuje potencjalnie wykonalne przyrosty produktu. Na końcu każdego sprintu odbywa się […]
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