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)

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.