Przetwarzanie informacji to tabele te zaś są prozą życia menedżerów :). Podczas wielu projektów związanych z kolekcjonowaniem wymagań na system IT wielokrotnie pojawiał się problem raportów i podobnych działań. Bardzo często wymagania tego typu są specyfikowane za pomocą wzorów raportów. Ma to jednak poważną wadę: zamyka lub utrudnia drogę rozwoju tej funkcjonalności (nie licząc usług płatnego definiowania kolejnych typów raportów świadczonych przez wykonawców systemów). Raporty jednak to tylko wierzchołek góry lodowej, “pod wodą” są dane i ich model czyli sposób zarządzania nimi i ich postać.
Ważną cechą interfejsu użytkownika jest możliwość decydowania o postaci tabel z danymi na ekranie. Nie zawsze uda się łatwo stworzyć nowy raport jednak można w wymaganiach zawrzeć oczekiwanie dowolnego kształtowania tabeli prezentującej wyniki. Niby małe a cieszy. Wybór kolumny do sortowania, filtry i wiele innych. Obiektowe narzędzia coraz częściej zasilane są bibliotekami gotowych rozwiązań, których celem jest między innymi podnoszenie użyteczności interfejsu użytkownika.
Tu okazuje się, że kluczem jest … model danych na etapie definiowania wymagań. Stara zasada: jakie dane taki wynik ich przetwarzania sprawdza się po raz kolejny. Oczywiście nie mam zamiaru udawać tu programisty. Jednak jako analityk współpracującymi z programistami nie raz słyszałem, że model danych to podstawa ich pracy. Przetwarzane informacje to dane biznesowe, nikt poza ich użytkownikiem i analitykiem nie zna ich kontekstu i tylko ta “para” jest w stanie wykonać “dobry” model danych. Elementy aplikacji pracujące na tabelach i same tabele warto więc szczegółowo przeanalizować gdyż ich późniejsza zmiana jest albo bardzo kosztowna albo wręcz niemożliwa w pewnych rygorach czasowych projektów.
Bardzo pomocna jest tu technologia EJB, za Wikipedią:
Enterprise Java Beans (EJB) – technologia będąca jednym z elementów specyfikacji J2EE. Innymi słowy EJB to pewien podzbiór interfejsów J2EE, uważany za jeden z najbardziej zaawansowanych elementów.
Idea EJB opiera się na tworzeniu komponentów, które mogą być osadzane na serwerze (tzw. bean containerze) i wołane zdalnie poprzez protokół RMI over IIOP. Ogólnie wyróżnia się 3 rodzaje komponentów EJB:
- sesyjne EJB (ang. session EJB),
- encyjne EJB (ang. entity EJB),
- sterowane komunikatami EJB (ang. message driven EJB).
Każdy z tych rodzajów komponentów ma różne zastosowanie. Sesyjne EJB są używane do umieszczania w nich logiki aplikacji – czyli kodu, który przetwarza dane. Encyjne EJB reprezentują w sposób obiektowy dane (np. przykrywają relacyjną bazę danych). EJB sterowane komunikatami znajdują zastosowanie w przetwarzaniu asynchronicznym i w zaawansowanych modelach współpracy oprogramowania. Np. model abonent-dostawca: bean rejestruje się jako dostawca pewnej usługi, klienci mogą zarejestrować się jako abonenci.
Główną zaletą EJB jest nakierowanie projektanta na pewne sprawdzone sposoby rozwiązania typowych problemów w systemie rozproszonym: zarządzanie połączeniami, transakcja rozproszona, mapowanie danych na model obiektowy itp. Mimo to użycie niektórych elementów tej technologii wydaje się dość kontrowersyjne. Np. stosowanie encyjnych EJB oznacza rezygnację z przetwarzania danych w modelu relacyjnym. Wszelki dostęp do danych (w tym i masowy) odbywa się poprzez obiekty napisane w języku Java, a zatem niesie ze sobą ograniczenia wydajnościowe i zajętości zasobów. Mimo iż technologia EJB jest popularyzowana przez teoretyków projektowania systemów trudno doszukać się pełnego wykorzystania tej technologii w dużych systemach, w których wydajność odgrywa istotną rolę (zwłaszcza encyjnych EJB).
Źródło: “http://pl.wikipedia.org/wiki/Enterprise_JavaBeans”
EJB to między innymi technologia bezpiecznego manipulowania danymi w systemie. Kłopoty “niedopasowania” pomiędzy obiektowym a relacyjnym modelem danych spędzają sen z powiek niejednemu projektantowi. W prostych systemach można sobie z tym stosunkowo łatwo poradzić stosując proste wzorce obiekt-tabela lub obiekt-wiersz. Jednak przy rozbudowanych systemach te wzorce już się nie sprawdzają. Należy stosować zaawansowane (i bardzo trudne) techniki mapowania obiektowo-relacyjnego (ang. ORM). EJB łączy zarządzanie danymi, reguły biznesowe i udostępnianie ich użytkownikom z możliwością korzystania z serwerów baz danych RDBMS. Jedną z technik jest stosowanie Java Persistence API (zapis danych do bazy oznacza w technologii obiektowej obiekty utrwalane o stereotypie Persistence).
Polecam bliższe zajęcie się tym szczególnie projektantom i analitykom gdyż modele danych to najczulsza cześć projektów systemów, szczególnie biznesowych. Zainteresowanych zapraszam do lektury artykułów Krzysztofa Barteczko Tabele w Java 6, Piotra Kochańskiego JBoss – aplikacje przyjazne użytkownikom, (Software Developer’s Journal, Wrzesień 2007) oraz na stronę JavaSoft.
W tym samym numerze warto przeczytać artykuł Rafała Kędzierskiego Dziesięć największych problemów w projektach informatycznych. Nie będę tu cytował jego obszernych fragmentów, odsyłam do numeru. Warto tu jednak przytoczyć dane opublikowane przez Standish Group w 2004 roku: Najczęstsze przyczyny niepowodzenia projektów informatycznych: 30% – zarzucone, 54% – przekroczony budżet, 66% – brak spełnienia wymagań nabywcy (!), 90% – przekroczony czas.
Co ciekawe poza Java i EJB oczywiście mamy środowisko .NET, Microsoft nie zasypia gruszek w popiele. Podobna tematykę dla tej platformy znajdziecie w artykule Sylwestra Lewandowskiego Enteprice Library 3.1 w następnym numerze. (Software Developer’s Journal, Październik 2007)
