Więk­szość pro­gra­mi­stów pra­cuje wyko­rzy­su­jąc te narzę­dzia, inni ich nie uży­wają z róż­nych przy­czyn, ale wie­dzą o co cho­dzi. Tym, któ­rzy nie wie­dzą podaję krótką i strawną defi­ni­cję, żeby wie­dzieli o czym jest ten arty­kuł i ewen­tu­al­nie prze­stali go czy­tać

Narzę­dzia CASE (czyli Com­pu­ter Aided Software Engi­ne­ering lub Com­pu­ter Aided Sys­tem Engi­ne­ering) to sys­temy kom­pu­te­rowe, prze­zna­czone do wspo­ma­ga­nia ruty­no­wych czyn­no­ści pro­cesu two­rze­nia opro­gra­mo­wa­nia. Dzięki nim pro­jekty two­rzy się dokład­niej, a praca nad dia­gra­mami, spraw­dza­nie ich popraw­no­ści oraz śledze­nie wyko­na­nych testów jest prost­sze i szybsze.

Pro­log
Wiele CASE’ów, szcze­gól­nie tych dar­mo­wych, ma słabą funk­cjo­nal­ność. Inne – zazwy­czaj te komer­cyjne – zbyt dużą jak na prze­cięt­nego pro­gra­mi­stę. Nie­które sys­temy ogra­ni­czają się do two­rze­nia dia­gra­mów UML, mode­lo­wa­nia baz danych, czy też pro­stego gene­ro­wa­nia sza­blonu kodu i sche­ma­tycz­nych doku­men­ta­cji. Reverse engi­ne­ering jest rzad­ko­ścią, cho­ciaż np. Sta­rUML sobie z tym radzi. W innych „sys­te­mach” widzimy prze­rost formy nad tre­ścią, cho­ciażby taki Visio, który z zało­że­nia miał być dla nas czymś w rodzaju CASE (cho­ciaż de facto nim nie jest). Czy można stwo­rzyć ide­alne roz­wią­za­nie dla wszyst­kich? Teo­re­tycz­nie nie, ale czemu nie spróbować?

Praw­dziwa modu­ło­wość
Sporą popu­lar­no­ścią wśród mło­dych infor­ma­ty­ków cie­szą się pro­gramy, które można dosto­so­wy­wać do swo­ich potrzeb. Dla infor­ma­tycz­nych laików jest to spory minus, gdyż czę­sto liczba opcji takiego pro­gramu prze­kra­cza moż­li­wo­ści opa­no­wa­nia przez takiego śmier­tel­nika. Jed­nak dla zapa­leńca, który chce dopie­ścić pro­gram do gra­nic, jest to roz­wią­za­nie ide­alne. Bar­dzo dobrym przy­kła­dem takiego podej­ścia jest komu­ni­ka­tor inter­ne­towy Miranda. Samo jądro Mirandy w głów­nej mie­rze służy do obsługi plug-inów oraz zapew­nia pod­sta­wowe metody do obsługi komu­ni­ka­tora, z któ­rych korzy­stają deve­lo­pe­rzy piszący wtyczki. Dzięki temu użyt­kow­nik ma do wyboru kil­ka­set wty­czek, które wzbo­ga­cają komu­ni­ka­tor o kon­kretne funk­cje. Z takiego roz­wią­za­nia korzy­sta się coraz czę­ściej, lecz zazwy­czaj w ogra­ni­czo­nym stop­niu. Wtyczki do zwy­kłych pro­gra­mów popra­wiają jego funk­cjo­nal­ność w nie­wiel­kim stop­niu. W tym przy­padku każda funk­cja jest oddziel­nym plug-inem. Oddziel­nie mamy okienko roz­mowy, oddziel­nie listę kon­tak­tów, oddziel­nie histo­rię. Każda z tych wty­czek ma zazwy­czaj sporo opcji do samo­dziel­nego usta­wie­nia i dosto­so­wa­nia. Na podob­nej zasa­dzie działa odtwa­rzacz muzyczny Foobar. I cho­ciaż wtyczki do niego są nieco bar­dziej ogra­ni­czone, to moż­li­wość wła­snej kon­fi­gu­ra­cji jest ogromna.

Dla­czego by nie zasto­so­wać podob­nego roz­wią­za­nia w przy­padku sys­te­mów CASE? Prze­cież nie każdy pro­gra­mi­sta musi korzy­stać ze wszel­kich modu­łów stan­dar­do­wego CASE’a. Poza tym pod­czas two­rze­nia pew­nego pro­jektu, różne osoby mają różne zada­nia do wyko­na­nia. Po co im więc ten sam zestaw funk­cji w CASE’ie? Można taki sys­tem roz­bić na duże, nie­za­leżne moduły, które obsłu­gują jedną poważną funk­cjo­nal­ność, a do każ­dego z tych modu­łów mogli­by­śmy doda­wać pomniej­sze udo­god­nie­nia. Przy­kła­dowo – jeden z naj­waż­niej­szych (w tym wypadku) modu­łów to Moduł Importu/Eksportu. Jest szcze­gól­nie ważny, gdyż dzięki niemu moż­liwa jest wymiana danych mię­dzy róż­nymi pro­gra­mami, a nawet mię­dzy oso­bami pra­cu­ją­cymi na naszym ide­al­nym CASE’ie, tylko róż­nie skon­fi­gu­ro­wa­nym. Do tego modułu możemy doda­wać obsługę kolej­nych for­ma­tów prze­sy­ła­nia danych, a także różną obsługę wymiany danych (np. za pomocą usta­lo­nego pro­to­kołu sie­cio­wego). Inny przy­kład – two­rze­nie dia­gra­mów w róż­nych stan­dar­dach. Jeśli osoba A potrze­buje do pracy tylko pew­nego nie­wiel­kiego zestawu dia­gra­mów – po co mu cała reszta? Skoro jest od wielu lat ten­den­cja do jak naj­węż­szej spe­cja­li­za­cji, to wiel­kie kom­bajny „do wszyst­kiego” są zbędne. W dodatku zaj­mują nie­ba­ga­telną ilość zaso­bów systemu.

Cechy i funk­cje ide­alne
Dla mnie, jako stu­denta infor­ma­tyki, ważną cechą doty­czącą jakie­go­kol­wiek pro­gramu jest jego dar­mo­wość i otwar­tość. Otwar­tość jest szcze­gól­nie ważna przy zało­że­niu, że każdy bar­dziej zaawan­so­wany pro­gra­mi­sta mógłby do takiego CASE’a napi­sać swój wła­sny moduł czy plug-in.

Z otwar­to­ścią wiąże się także wie­lo­plat­for­mo­wość takiego pro­gramu. Chciał­bym mieć moż­li­wość pracy na nim zarówno pod Win­dow­sem, jak i Linuk­sem (a może nawet MacOS’em?).

Intu­icyj­ność obsługi jest rów­nież ważna. Popra­wia z pew­no­ścią ergo­no­mię, a zatem także szyb­kość pracy. Wszel­kie menu, kla­wi­szo­lo­gia i inne paski narzę­dziowe powinny być w 100% kon­fi­gu­ro­walne przez użytkownika.

Wie­lo­stan­dar­do­wość. Jest to ważne, gdyż różni ludzie mają różne przy­zwy­cza­je­nia i wła­sne ozna­cze­nia w dia­gra­mach. Każdy użyt­kow­nik naszego CASE’a powi­nien mieć moż­li­wość dosto­so­wa­nia stan­dar­dów do sie­bie, a jed­no­cze­śnie powi­nien mieć moż­li­wość kon­wer­sji tych dia­gra­mów do postaci wygod­nej dla współ­pra­cow­ni­ków. Taka kon­wer­sja powinna prze­bie­gać auto­ma­tycz­nie pod­czas wymiany danych z innymi pra­cow­ni­kami przy danym projekcie.

Dla nowych użyt­kow­ni­ków CASE’a przy­dałby się roz­bu­do­wany i „inte­li­gentny” help. Z jed­nej strony coś na kształt pod­ręcz­nika użyt­kow­nika (jeśli ktoś lubi tego typu publi­ka­cje), a z dru­giej strony – pod­po­wie­dzi w cza­sie rze­czy­wi­stym. Oczy­wi­ście w pełni kon­fi­gu­ro­walne i zaim­ple­men­to­wane jako osobny plug-in do danego modułu. Zaawan­so­wany użyt­kow­nik może go więc wyłą­czyć i nie obcią­żać nie­po­trzeb­nie zaso­bów systemu.

Gene­ra­tor kodu i środo­wi­sko pro­gra­mi­styczne. Wiele środo­wisk pro­gra­mi­stycz­nych (np. Eclipse) ma moż­li­wość roz­bu­dowy o ele­menty obsługi UMLa czy też innych skład­ni­ków stan­dar­do­wego CASE’a. Można więc zro­bić odwrot­nie. Jed­nym z modu­łów naszego CASE’a byłoby wła­śnie środo­wi­sko pro­gra­mi­styczne (IDE) dla kon­kret­nego języka pro­gra­mo­wa­nia. Wtedy gene­ra­tor kodu byłby dopa­so­wany ide­al­nie do tego środo­wi­ska, a co za tym idzie – unik­nę­li­by­śmy dziw­nej nad­mia­ro­wo­ści kodu i pro­ble­mów zwią­za­nych z bra­kiem kon­kret­nych nagłów­ków czy innych wyma­ga­nych dekla­ra­cji w programie.

Epi­log
Są różni pro­gra­mi­ści, z róż­nymi pomy­słami i przy­zwy­cza­je­niami. Obecne narzę­dzia CASE w pew­nym stop­niu narzu­cają nam wła­sny spo­sób obsługi. Bar­dzo czę­sto wpływa to nega­tyw­nie na nasta­wie­nie pra­cow­nika, a co za tym idzie – na jakość i szyb­kość jego pracy. Two­rząc CASE’a zgod­nego z powyż­szymi pomy­słami, mamy moż­li­wość przy­naj­mniej czę­ścio­wego wyeli­mi­no­wa­nia tego problemu.