niedziela, 30 sierpnia 2015

Strategiczne partnerstwo Sparx Systems oraz IIBA

Organizacja IIBA, czyli International Institute of Business Analysis, a zatem organizacja wyznaczająca standard w dziedzinie analizy biznesowej ogłosiła niedawno, że podpisała memorandum stanowiące globalne strategiczne partnerstwo z trzema organizacjami. Jedną z nich jest Sparx Systems Pty Ltd., a zatem producent narzędzia Enterprise Architect.



Co może oznaczać ten sojusz dla użytkowników EA?

W komunikacie prasowym wskazano, że Sparx Systems oraz IIBA podzielają zainteresowanie i zaangażowanie w zwiększanie wartości świadczonych dla swoich interesariuszy. Poprzez wzajemne wspieranie wysiłków w określonych obszarach dzięki nowej współpracy skorzystają zarówno członkowie IIBA, jak również klienci Sparx Systems.

Wskazano następujące konkretne inicjatywy:

  • Potencjalna integracja BABOK® 3.0 z Enterprise Architect.
  • Oferta dostępu do różnych zewnętrznych zasobów, narzędzi oraz rozszerzeń w celu zwiększenia produktywności i wydajności.
  • Pozostałe korzyści dotyczą wzajemnego docierania do szerszych grup odbiorców, dzięki czemu IIBA będzie mogła zyskać na popularności w świecie użytkowników Sparx EA, jak również członkowie IIBA będą kojarzyć modelowanie z oprogramowaniem firmy Sparx Systems.
Osobiście uważam, że jeśli pojawią się namacalne efekty tego sojuszu, to przyczyni się do to większego ustandaryzowania w dziedzinie analizy biznesowej i systemowej. Co prawda, nie wyobrażam sobie, na czym może polegać integracja BABOK® w oprogramowaniu, które jest tak elastyczne w dziedzinie modelowania. Na pewno dużą wartość dodaną wniesie już ujednolicenie stosowanych terminów oraz stworzenie materiałów szkoleniowych, które pokazują jak prowadzić analizę zgodną z  BABOK® w Sparx EA.

IIBA zawiązała podobny sojusz jeszcze z firmami:

  • BCS The Chartered Institute for IT
  • IREB®
  • BRMI  

Link do komunikatu na stronie IIBA: www.iiba.org/mou.aspx


sobota, 29 sierpnia 2015

Bo ten projekt jest specyficzny...

Gdy rozmawiam z ludźmi zaangażowanymi w realizację projektów informatycznych i dochodzimy do kwestii stosowania standardów, czy to ogólnie przyjętych, czy też standardów ustanowionych w organizacji, często słyszę, że w odniesieniu do tego, konkretnego projektu niemożliwe jest zastosowanie żadnego standardu, bo ten projekt jest specyficzny...
Później przychodzi refleksja, że tak naprawdę można to powiedzieć o każdym projekcie. Czy to oznacza, że każdy projekt jest specyficzny?

Otóż według metodyk zarządzania projektami projekt to przedsięwzięcie:
  • jednorazowe,
  • niepowtarzalne,
  • złożone.
Cechy traktujące o tym, że projekt jest jednorazowy i niepowtarzalny - oznaczają de facto, że projekt w swojej naturze jest specyficzny. Z drugiej strony złożoność przedsięwzięcia skłania do posiłkowania się jakimś usystematyzowanym podejściem, aby lepiej radzić sobie z planowaniem, kontrolowaniem i sterowaniem.

Jak to zatem jest w praktyce? Przecież osoby zaangażowane w projekty z reguły znają doskonale metodyki zarządzania projektami: PMI, Prince2..., znają standardy wytwarzania oprogramowania, takie jak: SWEBOK, standardy analityczne, takie jak: BABOK. A jak przychodzi do ich stosowania w świecie rzeczywistym, to kierują się bardziej intuicją niż wypracowanym podejściem?

Zauważam często problemy w przełożeniu teorii na praktykę. Trudno powiedzieć z czego one wynikają.
Czy źródło problemu leży po stronie metodyk, ludzi czy samych przedsięwzięć? A może po części wynika z każdego z tych elementów?

Z punktu widzenia metodyk, czy też innych standardów, które warto stosować w projektach być może za słabo jest akcentowany temat dostosowania przy jednoczesnym narzucaniu szczegółowych rozwiązań...
Choć często metodyka, czy standard wyróżnia elementy obligatoryjne oraz elementy fakultatywne. Jednakże być może brakuje dostatecznego uzasadnienia dla stosowania elementów obligatoryjnych. W przypadku metodyki Prince2 powstało nawet pojęcie PINO, czyli Prince In Name Only.

A może metodyki są zbyt szczegółowe i powinny narzucać tylko ogólne pryncypia, natomiast każdy specyficzny projekt określałby rozszerzenia wykonawcze opisujące, jak takie pryncypia są realizowane?
Ale, czy w takim ujęciu metodyki byłyby w ogóle przydatne?

A może problem nie leży jednak w po stronie metodyk i standardów, tylko ludzi, którzy powinni się nimi kierować? W trakcie szkoleń ludzie zapoznają się z materiałami w stopniu umożliwiającym im zdanie egzaminu. Nawet, jeśli pytania egzaminacyjne są nakierowane na wykorzystanie zdobytej wiedzy w praktyce, to jednak taka wiedza może jest niewystarczająca...  Rzeczywistość bywa z reguły bardziej złożona od modelu, który ją opisuje. Modele opisują rzeczywistość projektową, z którymi ludzie mają do czynienia w trakcie szkoleń i egzaminów. Modele te nie są w stanie opisać w pełni rzeczywistości. W rozpatrywanych przypadkach może brakować czynników takich, jak relacje międzyludzkie, konflikty interesów, brak zrozumienia po stronie klienta, czy menedżera. A są to czynniki, które pośrednio wpływają na podejmowane decyzje. W przypadku, gdy człowiek odczuwa zagrożenie (np. ze strony szefa, kolegów, klientów) zaczyna się kierować intuicją, która ma pomóc mu zmniejszyć zagrożenie. Można to porównać do ucieczki zwierzęcia przed drapieżnikiem: takie zwierzę skupia się bardziej nad tym, żeby biec, niż nad tym - dokąd biegnie.

Podobnie bywa w "lesie projektowym". Członkowie zespołu projektowego starają się "dowieźć" projekt. Zaczynają bieg, za nimi zawsze biegnie ktoś inny. W takiej sytuacji nie ma pewności, czy biegacz będzie biegł po ścieżkach wyznaczonych standardami, czy może jednak będzie wybierać drogi, które w danym momencie wydają się lepsze. A w takim przypadku nie ma pewności, czy dobiegnie do mety, czy po drodze nie wpadnie w jakieś pułapki, których nie dostrzegł w porę.


poniedziałek, 1 grudnia 2014

EA WorkPlace - wszystko w jednym miejscu

Podczas niedawnej konferencji EA User Group w Monachium Jackie Mitchell, twórca eaDocX i jedna z najbardziej aktywnych osób w społeczności użytkowników Sparx Enterprise Architect - zaprezentował nową stronę: EA Workplace.



W zamyśle twórcy ma to być miejsce, gdzie można przejrzeć katalog wszystkich dodatków i narzędzi do EA, Oprócz narzędzi serwis kataloguje również szkolenia, książki, linki i inne zasoby dotyczące EA oraz kontakty do specjalistów od EA. Dodatkowo, aby ułatwić korzystanie z narzędzi i usług pochodzących od różnych dostawców serwis ma umożliwiać dokonywanie zakupów z jednego miejsca.


wtorek, 8 lipca 2014

Entity Relationship Model w Enterprise Architect

Rdzeniem programu Enterprise Architect był od początku UML. Jednakże program ten nadaje się świetnie do modelowania przy użyciu wielu innych notacji, wśród nich jest również Entity Relationship Model. Zamiast tego pojęcia stosuje się również nierzadko Entity Relationship Diagram (ERD) zwany po polsku diagramem związków encji. Notacja ERD straciła wiele na znaczeniu w ciągu ostatnich lat, a nawet dziesięcioleci i ustąpiła pola na rzecz diagramów klas UML. ERD służy do modelowania strukturalnego, zaś UML do obiektowego. Zatem strukturalny język modelowania w wielu zastosowaniach został zastąpiony przez język obiektowy.
Nic w tym dziwnego, skoro niegdyś w inżynierii oprogramowania królowały języki strukturalne, a obecnie języki obiektowe. Modelowanie, które jest w swojej istocie powiązane z programowaniem zatem idzie w parze z tymi przemianami.

piątek, 4 lipca 2014

Data Dictionary w EA

Data Dictionary to jedna z technik dokumentowania danych przetwarzanych przez system. Załóżmy, że mamy do czynienia z istniejącą aplikacją, która przechowuje dane w dużej relacyjnej bazie danych. Aby lepiej poznać struktury, w których dane są przechowywane warto zapoznać się ze schematem bazy danych. Taki schemat można zaimportować do programu Enterprise Architect.

Zaimplementowana w EA funkcjonalność importu schematu bazy danych (Import DB schema from ODBC) powoduje utworzenie klas ze stereotypem <<table>> wraz z ich atrybutami. Dodatkowo możliwe jest automatyczne umieszczenie takich tabel na diagramie klas. Dzięki temu możemy się posiłkować wizualizacją samych tabel i powiązań między nimi.

Poniższy diagram prezentuje przykład prostego schematu bazy danych opracowany dla aplikacji służącej do rejestrowania i raportowania wydatków pracowniczych.
Taki diagram wygląda dość czytelnie, ale pod warunkiem, że tabel jest niewiele. W przypadku większych struktur diagram może stać się nieczytelny, a samo rozmieszczenie zawartości diagramu może okazać się czasochłonne.

Jako alternatywę można stosować technikę Data Dictionary. Technika ta służy do opisu standardowych definicji elementów danych, ich znaczeń i możliwych wartości w formie tabelarycznej. Taka forma ze swej natury nie jest jednak stworzona do wizualizacji powiązań między tabelami. Data Dictionary zawiera definicje wszystkich atrybutów i wskazuje, w jaki sposób one składają się na większe struktury, czyli tabele.

Jak zatem wyglądałby Data Dictionary dla zmieszczonego powyżej przykładu?

Jest to tabela uzyskana jako wynika odpowiedniego zapytania. Taki widok pozostawia jeszcze trochę do czynienia. Na szczęście można przeciągnąć nagłówek kolumny o nazwie Table_Name na pole oznaczone tekstem Drag a column header here to group by that column.
Po tej operacji uzyskamy następujący efekt.



Data Dictionary może być przydatny dla projektantów, analityków, testerów aby upewnić się, czy wszystkie zainteresowane strony zgadzają się co do formatu i zawartości informacji przetwarzanych przez system. Dla zespołów wsparcia i administratorów może być przydatne w rozwiązywaniu problemów z działaniem systemu. Zebranie takich definicji w repozytorium EA może sprawić, że taka informacja będzie dostępna dla wszystkich zainteresowanych w jednym miejscu.

Metoda uzyskania widoku typu Data Dictionary nie została zaimplementowana w łatwy sposób w narzędziu. Sparx Systems zawarł jedynie krótką wzmiankę na ten temat w dokumencie "Data Modeling. From Conceptual Model to DBMS". Zamieszczono tam treść zapytania SQL, które po zapisaniu w programie pozwala wygenerować odpowiedni widok.
Data Dictionary (EAP):
SELECT t_attribute.ea_guid AS CLASSGUID, 'Attribute' AS CLASSTYPE,
t_object.Name as Table_Name,
t_attribute.Name,
iif(t_attribute.IsOrdered, "PK", "") as PrimaryKey,
iif(t_attribute.IsCollection, "FK", "") as ForeignKey ,
t_attribute.Type, t_attribute.Length, t_attribute.Precision, t_attribute.Scale,
iif(t_attribute.IsStatic, "Unique", "") as isUnique,
iif(t_attribute.AllowDuplicates, "NotNull","") as NotNull
FROM t_attribute, t_object
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table"


Niestety składnia SQL jest wrażliwa na silnik bazodanowy wykorzystywany jako repozytorium dla projektów Enterprise Architect. Powyższe zapytanie działać będzie tylko w przypadku plików EAP. Jeśli zamiast pliku lokalnego korzystamy z repozytorium w postaci bazy danych, wówczas konieczne jest przebudowanie tego zapytania.
Poniżej to samo zapytanie (z jednym wyjątkiem - dodatkowo zwracane są opisy atrybutów, czyli zawartość pola Notes) przygotowane dla repozytoriów EA pod kontrolą MySQL.
Data Dictionary (MySQL):
SELECT t_attribute.ea_guid AS CLASSGUID, 'Attribute' AS CLASSTYPE,
t_object.Name as Table_Name,
t_attribute.Name,
t_attribute.Notes,
CASE WHEN t_attribute.IsOrdered THEN "PK" ELSE "" END as PrimaryKey,
CASE WHEN t_attribute.IsCollection THEN "FK" ELSE "" END as ForeignKey,
t_attribute.Type, t_attribute.Length, t_attribute.Precision, t_attribute.Scale,
CASE WHEN t_attribute.IsStatic THEN "Unique" ELSE "" END as isUnique,
CASE WHEN t_attribute.AllowDuplicates THEN "NotNull" ELSE "" END as NotNull
FROM t_attribute, t_object
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table"


Na koniec warto dodać, że gdybyśmy w jednym repozytorium EA przechowywali schematy kilku baz danych, wówczas wszystkie tabele mogłyby się ze sobą wymieszać. Aby temu zapobiec można w ostatniej linii dopisać dodatkowy warunek ograniczający zakres zwracanych tabel tylko do gałęzi pakietów wybranej w oknie Project Browser.
Ostatnia linia wyglądałaby wówczas następująco:
WHERE t_attribute.object_Id = t_object.Object_ID and t_object.Stereotype = "Table" and t_object.Package_ID In(#Branch#)

czwartek, 3 lipca 2014

Model Search - predefiniowane definicje

W artykule wprowadzającym w temat wyszukiwania w programie Enterprise Architect opisałem podstawowe możliwości w zakresie przeszukiwania zawartości projektów EA. Takie wyszukiwanie działa de facto w oparciu o jedną z predefiniowanych definicji, które są wbudowane w aplikację. Takich definicji jest jednak więcej i chciałbym je w tym miejscu przybliżyć.

Lista tych definicji jest dostępna w oknie Model Search w postaci listy rozwijalnej opatrzonej dość intuicyjną nazwą: Search.
Predefiniowane definicje są zgrupowane w sekcji Built-In. Są to:

  • Simple
  • Extended
  • Element Name
  • Attribute Details
  • Find Orphans
  • Failed Internal Tests
  • Method Details
  • Responsibility
  • Resources
  • Requirements
  • Find Bookmarked Elements
  • Recently Modified Elements
  • Recently Modified Diagrams
  • My Checked Out Packages
Lista ta może się różnić w zależności od wersji programu Enterprise Architect.

środa, 2 lipca 2014

Model Search - Podstawy wyszukiwania w EA

Wyszukiwanie w zwykłych dokumentach, takich jak dokumenty pakietu MS Office, czy PDF jest proste i intuicyjne. Wystarczy wywołać okno wyszukiwania (z reguły działa skrót Ctrl+F), a następnie wpisać wyszukiwaną frazę. W przypadku projektów w programie Enterprise Architect jest nieco trudniej. Ale czy jest bardzo trudno?

Zauważyłem, że gdy ktoś pragnie wyszukać określone elementy w EA najczęściej korzysta z przycisku Find in Project Browser umieszczonego na belce okna.
Rzeczywiście jest to skuteczny sposób. Po wpisaniu szukanej frazy w oknie Project Browser zaznaczany jest pierwszy element, którego nazwa, alias lub opis odpowiada kryterium wyszukiwania.
Jego wadą jest jednak to, że nie widzimy od razu wszystkich elementów. Jeśli takich elementów jest wiele, wówczas konieczne jest wielokrotne naciskanie przycisku Find.

Ja polecam wszystkim koleżankom i kolegom korzystanie z mechanizmu Model Search. Zauważyłem, że ludzie szybko przestawiają się właśnie na ten tryb.

Okno wyszukiwania Model Search możemy otworzyć na kilka sposobów:

  • przy użyciu zaznaczonej poniżej ikonki z paska narzędzi,
  • menu Edit --> Find in Project
  • skrót klawiaturowy Ctrl+F lub Ctrl+Alt+A


Okno Model Search wygląda na skomplikowane. Widać w nim kilka przycisków, pole tekstowe, listę rozwijalną...
Jednak wykorzystanie do najprostszego zadania, jakim jest wyszukanie elementów zawierających poszukiwaną frazę jest bardzo proste. Wystarczy w polu Search Term wpisać frazę i nacisnąć Enter lub przycisk Run.
Przykładowo wpisanie słowa biblioteka zwróciło listę pakietów i elementów, w których nazwie, aliasie lub opisie znalazło się to słowo. Można zauważyć, że na liście znalazły się również pozycje ze słowem bibliotekarz. Aby wykluczyć elementy wystarczy dodać spację na końcu poszukiwanego słowa.

Listę znalezionych elementów możemy oczywiście sortować klikając na nagłówkach kolumn lub grupować po określonej kolumnie. Na przykład przeciągnięcie nagłówka kolumny Type pozwala zmienić układ widoku.
Jeśli znajdziemy na liście poszukiwaną pozycję, wówczas dwukrotne kliknięcie na takim elemencie powoduje wyświetlenie okna jego właściwości (Properties). Jeśli chcemy sprawdzić, w jakim pakiecie taki element jest umieszczony lub na jakich diagramach występuje, wówczas możemy kliknąć na nim prawym przyciskiem myszy i wybrać akcję z menu kontekstowego.

Najczęściej wybieranymi akcjami są zapewne Find in Project Browser oraz Find in Diagrams...
Dzięki temu łatwiej jest nawigować w większych projektach i łatwo wyszukiwać właściwe treści. Ponadto Model Search pomaga w znalezieniu ewentualnych duplikatów oraz ich usunięciu.