Przetwarzanie infor­ma­cji to tabe­le te zaś są pro­zą życia mene­dże­rów :). Podczas wie­lu pro­jek­tów zwią­za­nych z kolek­cjo­no­wa­niem wyma­gań na sys­tem IT wie­lo­krot­nie poja­wiał się pro­blem rapor­tów i podob­nych dzia­łań. Bardzo czę­sto wyma­ga­nia tego typu są spe­cy­fi­ko­wa­ne za pomo­cą wzo­rów rapor­tów. Ma to jed­nak poważ­ną wadę: zamy­ka lub utrud­nia dro­gę roz­wo­ju tej funk­cjo­nal­no­ści (nie licząc usług płat­ne­go defi­nio­wa­nia kolej­nych typów rapor­tów świad­czo­nych przez wyko­naw­ców sys­te­mów). Raporty jed­nak to tyl­ko wierz­cho­łek góry lodo­wej, ​„pod wodą” są dane i ich model czy­li spo­sób zarzą­dza­nia nimi i ich postać.

Ważną cechą inter­fej­su użyt­kow­ni­ka jest moż­li­wość decy­do­wa­nia o posta­ci tabel z dany­mi na ekra­nie. Nie zawsze uda się łatwo stwo­rzyć nowy raport jed­nak moż­na w wyma­ga­niach zawrzeć ocze­ki­wa­nie dowol­ne­go kształ­to­wa­nia tabe­li pre­zen­tu­ją­cej wyni­ki. Niby małe a cie­szy. Wybór kolum­ny do sor­to­wa­nia, fil­try i wie­le innych. Obiektowe narzę­dzia coraz czę­ściej zasi­la­ne są biblio­te­ka­mi goto­wych roz­wią­zań, któ­rych celem jest mię­dzy inny­mi pod­no­sze­nie uży­tecz­no­ści inter­fej­su użytkownika.

Tu oka­zu­je się, że klu­czem jest … model danych na eta­pie defi­nio­wa­nia wyma­gań. Stara zasa­da: jakie dane taki wynik ich prze­twa­rza­nia spraw­dza się po raz kolej­ny. Oczywiście nie mam zamia­ru uda­wać tu pro­gra­mi­sty. Jednak jako ana­li­tyk współ­pra­cu­ją­cy­mi z pro­gra­mi­sta­mi nie raz sły­sza­łem, że model danych to pod­sta­wa ich pra­cy. Przetwarzane infor­ma­cje to dane biz­ne­so­we, nikt poza ich użyt­kow­ni­kiem i ana­li­ty­kiem nie zna ich kon­tek­stu i tyl­ko ta ​„para” jest w sta­nie wyko­nać ​„dobry” model danych. Elementy apli­ka­cji pra­cu­ją­ce na tabe­lach i same tabe­le war­to więc szcze­gó­ło­wo prze­ana­li­zo­wać gdyż ich póź­niej­sza zmia­na jest albo bar­dzo kosz­tow­na albo wręcz nie­moż­li­wa w pew­nych rygo­rach cza­so­wych projektów.

Bardzo pomoc­na jest tu tech­no­lo­gia EJB, za Wikipedią:

Enterprise Java Beans (EJB) – tech­no­lo­gia będą­ca jed­nym z ele­men­tów spe­cy­fi­ka­cji J2EE. Innymi sło­wy EJB to pewien pod­zbiór inter­fej­sów J2EE, uwa­ża­ny za jeden z naj­bar­dziej zaawan­so­wa­nych elementów.

Idea EJB opie­ra się na two­rze­niu kom­po­nen­tów, któ­re mogą być osa­dza­ne na ser­we­rze (tzw. bean con­ta­ine­rze) i woła­ne zdal­nie poprzez pro­to­kół RMI over IIOP. Ogólnie wyróż­nia się 3 rodza­je kom­po­nen­tów EJB:

• sesyj­ne EJB (ang. ses­sion EJB),
• encyj­ne EJB (ang. enti­ty EJB),
• ste­ro­wa­ne komu­ni­ka­ta­mi EJB (ang. mes­sa­ge dri­ven EJB).

Każdy z tych rodza­jów kom­po­nen­tów ma róż­ne zasto­so­wa­nie. Sesyjne EJB są uży­wa­ne do umiesz­cza­nia w nich logi­ki apli­ka­cji – czy­li kodu, któ­ry prze­twa­rza dane. Encyjne EJB repre­zen­tu­ją w spo­sób obiek­to­wy dane (np. przy­kry­wa­ją rela­cyj­ną bazę danych). EJB ste­ro­wa­ne komu­ni­ka­ta­mi znaj­du­ją zasto­so­wa­nie w prze­twa­rza­niu asyn­chro­nicz­nym i w zaawan­so­wa­nych mode­lach współ­pra­cy opro­gra­mo­wa­nia. Np. model abo­nent-dostaw­ca: bean reje­stru­je się jako dostaw­ca pew­nej usłu­gi, klien­ci mogą zare­je­stro­wać się jako abonenci.

Główną zale­tą EJB jest nakie­ro­wa­nie pro­jek­tan­ta na pew­ne spraw­dzo­ne spo­so­by roz­wią­za­nia typo­wych pro­ble­mów w sys­te­mie roz­pro­szo­nym: zarzą­dza­nie połą­cze­nia­mi, trans­ak­cja roz­pro­szo­na, mapo­wa­nie danych na model obiek­to­wy itp. Mimo to uży­cie nie­któ­rych ele­men­tów tej tech­no­lo­gii wyda­je się dość kon­tro­wer­syj­ne. Np. sto­so­wa­nie encyj­nych EJB ozna­cza rezy­gna­cję z prze­twa­rza­nia danych w mode­lu rela­cyj­nym. Wszelki dostęp do danych (w tym i maso­wy) odby­wa się poprzez obiek­ty napi­sa­ne w języ­ku Java, a zatem nie­sie ze sobą ogra­ni­cze­nia wydaj­no­ścio­we i zaję­to­ści zaso­bów. Mimo iż tech­no­lo­gia EJB jest popu­la­ry­zo­wa­na przez teo­re­ty­ków pro­jek­to­wa­nia sys­te­mów trud­no doszu­kać się peł­ne­go wyko­rzy­sta­nia tej tech­no­lo­gii w dużych sys­te­mach, w któ­rych wydaj­ność odgry­wa istot­ną rolę (zwłasz­cza encyj­nych EJB).

Źródło: ​„http://​pl​.wiki​pe​dia​.org/​w​i​k​i​/​E​n​t​e​r​p​r​i​s​e​_​J​a​v​a​B​e​ans”

EJB to mię­dzy inny­mi tech­no­lo­gia bez­piecz­ne­go mani­pu­lo­wa­nia dany­mi w sys­te­mie. Kłopoty ​„nie­do­pa­so­wa­nia” pomię­dzy obiek­to­wym a rela­cyj­nym mode­lem danych spę­dza­ją sen z powiek nie­jed­ne­mu pro­jek­tan­to­wi. W pro­stych sys­te­mach moż­na sobie z tym sto­sun­ko­wo łatwo pora­dzić sto­su­jąc pro­ste wzor­ce obiekt-tabe­la lub obiekt-wiersz. Jednak przy roz­bu­do­wa­nych sys­te­mach te wzor­ce już się nie spraw­dza­ją. Należy sto­so­wać zaawan­so­wa­ne (i bar­dzo trud­ne) tech­ni­ki mapo­wa­nia obiek­to­wo-rela­cyj­ne­go (ang. ORM). EJB łączy zarzą­dza­nie dany­mi, regu­ły biz­ne­so­we i udo­stęp­nia­nie ich użyt­kow­ni­kom z moż­li­wo­ścią korzy­sta­nia z ser­we­rów baz danych RDBMS. Jedną z tech­nik jest sto­so­wa­nie Java Persistence API (zapis danych do bazy ozna­cza w tech­no­lo­gii obiek­to­wej obiek­ty utrwa­la­ne o ste­reo­ty­pie Persistence).

Polecam bliż­sze zaję­cie się tym szcze­gól­nie pro­jek­tan­tom i ana­li­ty­kom gdyż mode­le danych to naj­czul­sza cześć pro­jek­tów sys­te­mów, szcze­gól­nie biz­ne­so­wych. Zainteresowanych zapra­szam do lek­tu­ry arty­ku­łów Krzysztofa Barteczko Tabele w Java 6, Piotra Kochańskiego JBoss – apli­ka­cje przy­ja­zne użyt­kow­ni­kom, (Software Developer’s Journal, Wrzesień 2007) oraz na stro­nę JavaSoft.

W tym samym nume­rze war­to prze­czy­tać arty­kuł Rafała Kędzierskiego Dziesięć naj­więk­szych pro­ble­mów w pro­jek­tach infor­ma­tycz­nych. Nie będę tu cyto­wał jego obszer­nych frag­men­tów, odsy­łam do nume­ru. Warto tu jed­nak przy­to­czyć dane opu­bli­ko­wa­ne przez Standish Group w 2004 roku: Najczęstsze przy­czy­ny nie­po­wo­dze­nia pro­jek­tów infor­ma­tycz­nych: 30% – zarzu­co­ne, 54% – prze­kro­czo­ny budżet, 66% – brak speł­nie­nia wyma­gań nabyw­cy (!), 90% – prze­kro­czo­ny czas.

Co cie­ka­we poza Java i EJB oczy­wi­ście mamy śro­do­wi­sko .NET, Microsoft nie zasy­pia gru­szek w popie­le. Podobna tema­ty­kę dla tej plat­for­my znaj­dzie­cie w arty­ku­le Sylwestra Lewandowskiego Enteprice Library 3.1 w następ­nym nume­rze. (Software Developer’s Journal, Październik 2007)