przegląd metodyk i narzędzi modelowania informatycznych ......i innych [15]. do innych, aktualnie...

JAROSŁAW BECKER

Zachodniopomorski Uniwersytet Technologiczny w Szczecinie

PRZEGL�D METODYK I NARZ�DZI MODELOWANIA INFORMATYCZNYCH SYSTEMÓW ZARZ�DZANIA W NOTACJI UML 2.0

Streszczenie

W artykule dokonano przegl�du metodyk oraz dost�pnych narz�dzi CASE

(ang. Computer-Aided Software Engineering) wykorzystuj�cych notacj� UML 2.0

w procesie obiektowego modelowania systemów informatycznych. Wynikiem bada�

jest ranking funkcjonalno�ci narz�dzi CASE. Pozwoli on wyłoni� lidera, który najle-

piej wspomo�e adaptacyjny proces budowy generatora DSS.

Słowa kluczowe: metodyki formalne, metodyki zwinne, narz�dzia CASE, UML 2.0, obiektowe

modelowanie systemów informatycznych

1. Wprowadzenie

Lata 80-te zaowocowały mnogoci� metodyk oraz notacji zwi�zanych ze strukturalnym, a tak-

�e obiektowym podejciem do analizy i projektowania systemów informatycznych. W praktyce

dominowało podejcie strukturalne, które pomimo ró�norodnoci opracowanych metodyk posiada-

ło wiele elementów wspólnych b�d�cych podstaw� dalszego rozwoju. Mo�na zaliczy� do nich:

poj�cie metodyki tworzenia systemów informatycznych i jej składniki, cykl �ycia sytemu, prototy-

powanie, diagramy zwi�zków encji, modele relacyjnych baz danych oraz narz�dzia CASE (ang.

Computer-Aided Software Engineering).

Od połowy lat 90-tych, wraz z rosn�c� popularnoci� programowania obiektowego, zaobser-

wowano znaczny rozwój metodyk i narz�dzi modelowania systemów informatycznych (CASE)

zgodnych z paradygmatem obiektowym. Od tego czasu modelowanie strukturalne coraz cz�ciej

jest wypierane przez ujednolicony j�zyk modelowania – UML (ang. Unified Modelling Language).

Rozwój technologiczny w kierunku podejcia obiektowego przyczynił si� do upowszechnienia

systemów czasu rzeczywistego oraz systemów internetowych. Post�p ten obj�ł takie kategorie jak

np. e-business, e-learning czy e-health. Spory wpływ na pobudzenie technologii obiektowych

miały realizowane w praktyce procesy integracji systemów informatycznych zarz�dzania dla np.

handlu, bankowoci, logistyki czy edukacji. [1]

Celem artykułu jest przegl�d metodyk i narz�dzi CASE wspomagaj�cych modelowanie syste-

mów informatycznych w notacji UML 2.0. Wynikiem bada� jest ranking narz�dzi CASE przepro-

wadzony z punktu widzenia potrzeb in�ynierii zautomatyzowanych generatorów SWD (systemów

wspomagania decyzji). Chodzi o wyłonienie rozwi�za�, które najlepiej b�d� wspomagały adapta-

cyjny proces budowy generatora oraz pozwol�, przy u�yciu in�ynierii wahadłowej, precyzyjnie

odwzorowa� i udokumentowa� jego architektur�. Rozwa�ania metodyczne przedstawione w artykule koncentruj� si� na: przegl�dzie metodyk

zgodnych z notacj� UML oraz wyborze odpowiedniego narz�dzia do modelowania informacyjnych

struktur zdarze� i rzeczy realizowanych w generatorze systemów wspomagania decyzji. Do

Jarosław Becker

Przegl�d metodyk i narz�dzi modelowania informatycznych systemów zarz�dzania

w notacji UML 2.0

18

wspomagania decyzji wykorzystano koncepcj� zadania WPL (Wielokryterialnego Programowania

Liniowego), w którym maksymalizuje si� odpowiedni� posta� funkcji u�ytecznoci dla ró�nie

zdefiniowanych, niestandardowych problemów (np. wspomaganie przetargów elektronicznych).

Opracowana dla wielu zastosowa� konstrukcja zadania WPL (szablon) stanowi podstaw� meto-

dyczn� organizacji systemu informatycznego (generatora). Problemy te omówiono w artykule

J. Becker (2008). [2]

Generatory DSS (ang. Decisions Support System) definiuje si� jako pakiety programów, po-

zwalaj�ce na łatwe i szybkie zbudowanie konkretnej aplikacji DSS. W zaproponowanym podejciu

zadaniem generatora jest zautomatyzowanie procesu budowy wyspecjalizowanych systemów

wspomagania decyzji (pewnej ich kategorii) dla problemów zwi�zanych z wyborem ofert, które

uznaje si� za najlepsze z punktu widzenia preferencji decydenta (dysponenta rodków finanso-

wych). Budowa systemu informatycznego, który na podstawie (zdefiniowanych przez projektan-

tów) szablonów zada� decyzyjnych musi samodzielnie konstruowa� nowe, wyspecjalizowane

systemy jest zadaniem trudnym i wymaga dobrych podstaw metodycznych. Na tym etapie zasadne

jest zastanowienie si� nad wyborem odpowiedniego narz�dzia wspomagaj�cego wizualizacj�, specyfikowanie, konstruowanie i dokumentowanie składników generatora. Szczególnie, je�eli

projektowanie zło�onego produktu (systemu) ma stanowi� powa�ne wyzwanie organizacyjne,

in�ynierskie i naukowe.

2. Przegl�d metodyk modelowania systemów informatycznych zgodnych z UML

Poj�cie metodyki projektowania systemów informatycznych pojawiło si� ju� na pocz�tku lat

80-tych. K. Subieta postrzega metodyk� (ang. methodology) jako „zestaw poj��, notacji, modeli,

j�zyków, technik i sposobów post�powania słu��cy do analizy dziedziny stanowi�cej przedmiot

projektowanego systemu oraz do projektowania poj�ciowego, logicznego i/lub fizycznego” [3].

Z kolei S. Wrycza twierdzi, �e metodyka tworzenia systemów informatycznych (TSI) stanowi

„spójny, logicznie uporz�dkowany zestaw metod i procedur o charakterze technicznym i organiza-

torskim, pozwalaj�cych zespołowi projektowemu realizowa� cykl �ycia systemu” [4]. Poza tym

metodyka zwi�zana jest tak�e z okrelon� notacj�, która słu�y przede wszystkim do zapisu i

wizualizacji wyników projektowania oraz wspomaga prac� zespołu zadaniowego w semantycznej,

syntaktycznej i pragmatycznej warstwie wymiany informacji pomi�dzy projektantami i u�ytkowni-

kami.

Metodyki projektowania systemów informatycznych mo�na podzieli� na trzy grupy (nur-

ty) [5]. Pierwsz� grup� reprezentuje podej�cie socjo-psychologiczne (zwane równie� społecznym),

które jest do� mocno zwi�zane z faz� analizy. W projektowaniu stosowane jest do celów ekono-

micznej i społecznej oceny systemów oraz do opracowania strategii realizacji i wdra�ania projektu.

Do drugiej grupy zalicza si� metodyki strukturalne. W podejciu strukturalnym system (lub

problem do rozwi�zania) rozkładany jest na cz�ci składowe, ulega hierarchicznej dekompozycji.

Zalet� takiego post�powania jest mo�liwo� podziału przedsi�wzi�cia projektowego na mniejsze

cz�ci, co w konsekwencji pozwala na równoległ�, grupow� prac�, czyli rozdział zada� mi�dzy

mniejsze zespoły. Prowadzi to w efekcie do skrócenia czasu opracowywania projektu. Trudnoci

mog� pojawi� si� w momencie scalania i zestrajania ze sob� opracowanych z osobna modułów [6,

s. 113]. Ostatni� i najnowsz� grup� stanowi� metodyki obiektowe, w których d��y si� do wyelimi-

nowania podziału na modelowanie procesów i danych. Integruje si� je w jedn� cało� zwan�obiektem (definiowanie obiektów projektowych). Podejcie obiektowe do projektowania w

POLSKIE STOWARZYSZENIE ZARZ�DZANIA WIEDZ�

Seria: Studia i Materiały, nr 22, 2009

19

stosunku do metodyk strukturalnych pozwala na (cz�sto ułatwia) budowanie du�ych, zło�onych

systemów informatycznych przez wieloosobowe zespoły. Według autorów prac [1, 3, 4, 5, 6] jest

ono powszechne i dominuj�ce w praktyce.

W latach 1989-1994 obiektowe podejcie do modelowania systemów informatycznych charak-

teryzowało si� spor� liczb� ró�norodnych metodyk oraz notacji. Jednak w przeciwie�stwie do

metodyk strukturalnych udało znale�� si� kompromis. Współpraca trzech autorów, dominuj�cych

w omawianym okresie rozwi�za�, mianowicie: J. Rumbaugh’a, G. Booch’a (1995) i I. Jacobson’a

(1996) zaowocowała powstaniem pierwowzoru UML, ujednoliconego j�zyka modelowania

systemów informatycznych, oznaczanego pocz�tkowo skrótem UM (ang. Unified Met-

hod). [1, s. 18]

W praktyce j�zyk UML przyj�ł posta� graficznej reprezentacji budowanego systemu. Składa

si� z logicznie powi�zanych ze sob� diagramów, które pozwalaj� na opisanie systemu od modeli

ogólnych do bardzo szczegółowych. W standardzie UML 2.0 wyst�puje trzynacie diagramów,

które charakteryzuj� statyk� i dynamik� opracowywanego systemu. J�zyka UML nie nale�y

uto�samia� z kompletn� metodyk� tworzenia systemów informatycznych, chocia� u jego podstaw

znajduj� si� rozwi�zania i dowiadczenia wniesione przez twórców, mianowicie:

• Rumbaugh – OMT (ang. Object Modeling Technique) to j�zyk modelowania obiektowego

systemów informatycznych opracowany w 1991 r.; stanowił wsparcie dla zorientowanego

obiektowo programowania; wyst�puj� w nim trzy główne diagramy: obiektów, dynamiki

oraz czynnoci; nie uwzgl�dniono w nim aspektów zwi�zanych z u�ytkownikami i imple-

mentacj� systemu; [7]

• Booch – OOAD (ang. Object Oriented Analysis and Design) dotyczy zorientowanych

obiektowo projektowania i analizy; jest to in�ynieria oprogramowania traktuj�ca modele

systemu jako grup� obiektów; wymagania systemowe reprezentowane s� przez poszcze-

gólne obiekty, które na siebie oddziałuj�; w podejciu tym nacisk poło�ony jest na projek-

towanie i implementacj�, nie przykłada si� zbyt du�ej uwagi do fazy identyfikacji i analizy

wymaga� u�ytkowników; [8, 9]

• Jacobson – OOSE (ang. Object Oriented Software Engineering) to pierwsza, zorientowana

obiektowo metodyka wraz z j�zykiem modelowania, do której wprowadzono analiz� przy-

padków u�ycia; do podstawowych etapów OOSE zalicza si�: modelowanie wymaga�, ana-

liz�, projektowanie, implementacj� i testowanie ka�dego przypadku u�ycia; uwzgl�dnia

ona cykl �ycia systemu oraz aspekty modelowania interakcji z u�ytkownikami; słab� stron�jest etap implementacji oraz sposób modelowania dziedziny. [10]

Dalsze prace zespołu trzech naukowców [11] nad j�zykiem UML, ukierunkowane na unifika-

cj� obiektowego procesu tworzenia systemów, zaowocowały w 1998 r. powstaniem metodyki

rodzajowej USDP (ang. Unified Software Development Process). Rodzajowo� (ang. generic)

oznacza w tym przypadku mo�liwo� opracowania ró�nych jej konfiguracji i implementa-

cji. [1, s. 319] Metodyka ta stanowi zbiór poj�� i wytycznych, ukierunkowany na modelowanie

przypadków u�ycia i koncentrowanie si� na architekturze systemu, jako głównym zagadnieniu

w procesie tworzenia oprogramowania. Głównym zało�eniem tego procesu jest jego iteracyjno-

przyrostowy charakter.

Implementacj� USDP stanowi opracowana przez firm� Rational Software metodyka RUP

(ang. Rational Unified Process). [12, 13] Pocz�tkowo była ona zbiorem praktyk Rational Appro-

ach z uwzgl�dnieniem podejcia Objectory I. Jacobson’a. Stopniowo rozwijana, w 2003 r. została

Jarosław Becker


w notacji UML 2.0

20

przej�ta przez firm� IBM i zacz�ła zdobywa� coraz wi�ksze uznanie. Obecnie dominuje w

obszarze formalnych, obiektowych metodyk tworzenia systemów zgodnych z notacj� j�zyka UML.

RUP stanowi konkurencyjne rozwi�zanie dla metodyki OPEN (ang. Object-oriented Process,

Environment, and Notation), która powstała na skutek poł�czenia ponad dwudziestu mi�dzynaro-

dowych metodyk i ich idei. Do najwa�niejszych zalicza si� MOSES, SOMA, Firesmith i Synthesis

oraz o mniejszym znaczeniu: BON, OOram, UML. [14]

Metodyka RUP posiada szerokie spektrum mo�liwoci i jest elastyczna, tzn. ukształtowana

w sposób umo�liwiaj�cy dopasowanie procesu budowy systemu do potrzeb konkretnego przedsi�-wzi�cia. Mo�e by� stosowana zarówno przy małych, jak i du�ych projektach informatycznych. Jest

kompletn� metodyk�, w której zało�ono przyrostowo-iteracyjny cykl �ycia systemu. Zawarto w

niej poj�cia, metody i techniki z zakresu j�zyka UML oraz inne np. heurystyczne. Wa�nymi

elementami RUP s�: role zdefiniowane w zespole projektowym, procedury zarz�dzania projektem,

kryteria oceny i monitorowanie post�pu prac. W jej ramach oferowany jest zintegrowany pakiet

narz�dzi CASE oraz zorganizowany system wsparcia w postaci hipertekstowej bazy wiedzy

i internetowego serwisu.[1] Istotnym elementem RUP s� zalecenia dobrej praktyki in�ynierskiej

(ang. best practices) [12]. Wi�kszo� tych zalece� mo�e by� z powodzeniem wykorzystana

w projektowaniu procesów technologicznych, systemów sterowania, wyrobów mechatronicznych

i innych [15].

Do innych, aktualnie rozwijanych metodyk obiektowych, równie� opartych na zało�eniach

rodzajowej metodyki USDP, zalicza si�: XP (ang. eXtreme Programming), AM (ang. Agile

Modeling), DSDM (ang. Dynamic Systems Development Method), FDD (ang. Feature Driven

Development), Scrum, Crystal. Kwalifikuje si� je do grupy metodyk lekkich, które z powodu

ograniczenia czasu przeznaczonego na modelowanie oraz udokumentowanie prac analityczno-

projektowych, w celu szybkiego przejcia do tworzenia kodu �ródłowego systemu, okrelane s�równie� jako metodyki „zwinne” (ang. agile). Z metodyki USDP zaczerpn�ły przede wszystkim

iteracyjno-przyrostowy cykl �ycia systemu oraz kategorie modelowania j�zyka UML. Umiej�tna

reakcja na zmiany to ich cecha wynikaj�ca z dobrej komunikacji w zespole i ci�głego przystoso-

wywania procesu do zmieniaj�cych si� warunków. Ich najwa�niejszym produktem jest działaj�cy

i przetestowany kod systemu.

eXtreme Programming (XP) jest to metodyka najlepiej przystosowana do tworzenia małych

i rednich projektów wysokiego ryzyka. Charakteryzuje si� ewolucyjnym podejciem do projekto-

wania i programowania oraz bardzo cisł� współprac� z odbiorc� systemu. Wymagane s� bardzo

krótkie iteracje w dostarczaniu kolejnych wersji oprogramowania, prowadz�ce do szybkich

odpowiedzi u�ytkownika. Przy tworzeniu oprogramowania stosuje si� m.in. programowanie w

parach, ci�gł� przebudow� kodu �ródłowego oraz integracj� i testowanie poł�czonych modułów.

Wi�cej praktyk stosowanych w metodyce XP opisano m. in. w pracach [16, 17].

Agile Modeling (AM) jest metodologi� opart� na praktyce stosowan� dla efektywnego mode-

lowania i dokumentacji oprogramowania. AM to zbiór wartoci, zasad oraz praktyk z zakresu

modelowania oprogramowania, które mog� by� pomocne przy tworzeniu projektu w skuteczny

i „zwinny” sposób. Metodyka AM charakteryzuje si� podejciem inkrementacyjnym. Tworzonych

jest wiele wersji systemu, jednak ka�da ma swoje przeznaczenie (posiada istotne zmiany). Zało�o-

no w niej, �e podstawowym celem jest działaj�ce oprogramowanie, dlatego jako� pracy jest na

bie��co sprawdzana. Przyszli u�ytkownicy programu mog� równie� bra� udział w jego powstawa-

niu poprzez prezentowanie własnych opinii, sugestii poprawy i nowych rozwi�za�. [18]



21

Metodyk� DSDM (ang. Dynamic Systems Development Method) charakteryzuje iteracyjne

oraz inkrementalne podejcie do tworzonego oprogramowania. Zespoły zadaniowe (dru�yny)

uprawnione s� do samodzielnego podejmowania decyzji. Nowe wersje oprogramowania s�dostarczane systematycznie i oceniane pod k�tem wymaga� (zastosowa�) biznesowych. Wersje te

s� tworzone w taki sposób, aby ka�da wprowadzona zmiana była odwracalna, a testy przeprowa-

dzane s� w ci�gu całego cyklu �ycia systemu. W metodyce tej bardzo istotn� kwesti� jest tak�e

zaanga�owanie do współpracy przyszłych u�ytkowników. [19]

Feature Driven Development (FDD) to projektowanie zorientowane na właciwoci. Metody-

k� t� cechuj� krótkie, iteracyjne cykle wytwarzania oprogramowania, a cały proces jest na bie��co

ledzony. Kolejne wersje oprogramowania tworzone s� do� cz�sto i na bie��co zawieraj� funkcje

wymagane przez klienta. W podejciu tym szczególny nacisk kładziony jest na jako� wytwarzane-

go systemu. Ka�dy programista indywidualnie odpowiada za swój kod (klas�, funkcj�), który

podlega cz�stym inspekcjom (np. sprawdzeniu kodu przez inn� osob� z zespołu) jeszcze przed

doł�czeniem go (kodu) do kontroli wersji i przekazaniem do testowania. FDD ma zatem odpo-

wiedni� struktur� dla pracy wi�kszych zespołów. [20]

Scrum to kolejna lekka metodyka, której ogólne zało�enia zostały zdefiniowane ju� w 1986 r.

przez H. Takeuchi i I. Nonaka, a jej pełn� definicj� i specyfikacj� sformułował K. Schweber

w 1995 r. Głównymi cechami tej metodyki s� iteracyjne oraz inkrementacyjne sposoby tworzenia

oprogramowania o du�ym stopniu zło�onoci i ryzyka. Ka�da iteracja trwa od 2 do 4 tygodni. Taki

cykl nazywany jest sprintem. Podczas jego trwania zespół zadaniowy (dru�yna) wybiera z listy

priorytetów wymaga� u�ytkownika te cechy, które posiadaj� najwi�ksz� warto� dla klienta. Na

ko�cu ka�dego sprintu dostarczany jest produkt potencjalnie mo�liwy do wysłania (ang. potentially

shippable product). W ten sposób Scrum dostarcza du�o, coraz bardziej dopracowanych wersji

projektu oraz wł�cza przyszłych u�ytkowników do współpracy. Podsumowuj�c, metodyka

SCRUM powstała, aby móc sprawnie zarz�dza� projektami o nieznanych lub wysoce zmiennych

wymaganiach. [21, 22]

Crystal jest to cała grupa metodyk lekkich, która charakteryzuje si� tym, �e posiada ró�ne od-

miany w zale�noci od stopnia ryzyka inwestycji oraz w zale�noci od rozmiaru projektu (mierzo-

nego liczb� zaanga�owanych projektantów). Ze wzgl�du na „krytyczno�” projektu, czyli rozmiar

strat jakie zostan� spowodowane defektami produktu („defekty powoduj� straty...”) dzieli si� je

na: komfortowe – C (Comfort), swobodnego dysponowania małymi finansami – D (Discretionary

Money), finansowo istotne – E (Essential Money) i krytyczne dla �ycia – L (Life Critical). Nato-

miast ze wzgl�du na liczb� osób bior�cych udział w projekcie dzieli si� je nast�puj�co, Crystal:

Clear (2-6 osób), Yellow (6-20 osób), Orange (20-40 osób), Red (40-100 osób), Magenta (100-

200 osób), Blue (200-500 osób) itd. Liczba osób mo�e zmienia� si� o ± 20%. Ide� tego podejcia

jest dobieranie odpowiedniego rodzaju metodyki do wymaga� implementowanego projek-

tu. Crystal, podobnie jak metodyka XP, skierowana jest na ludzi. Jednak – w przeciwie�stwie do

XP – zakłada si�, i� ludzie maj� trudnoci z podporz�dkowaniem si� trudnemu i wymagaj�cemu

dyscypliny procesowi. [23]

Metodyki lekkie (zwinne) to do� du�a grupa charakteryzuj�ca si� umiej�tnym dostosowaniem

do zmieniaj�cych si� warunków. Wszystkie metodologie cechuje wprowadzenie krótkich iteracji,

podczas których powstaj� kolejne wersje oprogramowania. Ka�da wersja musi wnosi� co nowego

i spełnia� wymagania klienta. Najwi�kszy nacisk kładziony jest na jako� produktu, kod musi by�przetestowany aby system działał poprawnie.

Jarosław Becker


w notacji UML 2.0

22

W praktyce zauwa�a si� „zniech�cenie” tradycyjnymi, formalnymi metodykami i entuzja-

styczny odwrót w stron� metodyk lekkich. Zjawisko to mo�e wynika� z pobie�nej oceny, w której

na pierwszym planie rysuj� si� same zalety podejcia „zwinnego”, tj. mniej dokumentacji

i wymaga� formalnych, generalnie mniej pracy oraz szybko uzyskane efekty. Jednak takie rozu-

mowanie mo�e jeszcze szybciej rozczarowa� wielu programistów, poniewa� zało�enia Agile s�równie wymagaj�ce, co programowanie w metodykach tradycyjnych. W obszarze behawioralnym

wymogi s� nawet du�o wi�ksze. Na przykład narzuca si� członkom zespołu do� du�� dyscyplin�, a post�py w pracy monitorowane s� z dokładnoci� do jednego osobodnia. Jak podaje M. Bartyzel

(2008) cyt. „dzi�ki krótkim iteracjom, które absolutnie musz� zako�czy� si� konkretnym (czytaj:

widocznym dla u�ytkownika) efektem nie ma miejsca na zajmowanie si� mało istotnymi, lecz

interesuj�cymi, miejscami w systemie”. Dalej twierdzi, �e nie bez znaczenia dla skutecznoci

metodyki jest ilo� osób bior�cych udział w pracach, cyt. „powy�ej 12 osób Agile przestaje by�

lekk� metodyk�, a staje si� metodyk� chaotyczn�”. [24]

Podsumowuj�c, metodyki „zwinne” musz� ugruntowa� si� w sferze praktyki. Przedsi�wzi�cia

informatyczne na wielk� skal�, dotycz�ce du�ych, zło�onych systemów (rozwijanych

i modyfikowanych przez wiele lat) wymagaj� takiej metodyki prowadzenia projektu, która

precyzyjnie odzwierciedli i okreli ka�dy element procesu wytwarzania oprogramowania (jak np.

metodyka RUP). Stosowanie formalnej (twardej) metodyki w takim przypadku jest konieczne

włanie ze wzgl�du na skal� i potencjalny czas trwania projektu. Ma ona za zadanie zapewni�bezpiecze�stwo przedsi�wzi�cia oraz osi�gni�cie zamierzonych celów. Mo�na s�dzi� z du�ym

prawdopodobie�stwem, �e w niedalekiej przyszłoci poziom profesjonalizmu wzronie wród

zwolenników metodyk lekkich. Podołaj� oni wielkim przedsi�wzi�ciom pod warunkiem zapewnie-

nia wysokiego poziomu kontroli prac nad projektem w ka�dym momencie jego trwania, nie trac�c

nic na „zwinnoci” działania.

3. Analiza porównawcza narz�dzi CASE wspomagaj�cych UML

J�zyk UML posiada spore wsparcie w postaci narz�dzi CASE [25], które zapewniaj� wspo-

maganie w modelowaniu i tworzeniu poprawnej dokumentacji projektowej. Wspieranie ka�dej

z faz tego procesu jest inne i wymaga zastosowania ró�nych funkcji. Sporód ich całej gamy warto

wyodr�bni� te najwa�niejsze, które wiadcz� o zaawansowaniu danego narz�dzia CASE i zapew-

nieniu odpowiedniego poziomu kontroli spełnianych w projekcie wymaga� u�ytkownika. Do

takich funkcji nale��: słownik danych (repozytorium metadanych wraz z systemem zarz�dzaj�-cym), edytor notacji graficznych (edytor diagramów), moduł kontroli poprawnoci (wyszukiwanie

bł�dów w diagramach oraz repozytoriach), moduł oceny jakoci projektu (np. ocena stopnia

zło�onoci oraz powi�za� elementów projektu), generatory raportów i dokumentacji technicznej,

generatory kodu �ródłowego, moduł projektowania interfejsu u�ytkownika, moduł in�ynierii

zwrotnej (mo�liwo� odtworzenia słownika danych lub diagramów na podstawie kodu �ródłowego

lub struktury bazy danych), moduł importu i eksportu danych oraz moduł zarz�dzania prac�grupow�. [26, 27]

Wprowadzenie wersji 2.0 j�zyka UML sprawiło konieczno� rozbudowy narz�dzi CASE.

Obecnie du�o programów wspiera t� wersj�, istnieje jednak spora cz�� rozwi�za� zwłaszcza

niekomercyjnych, która pozostała w standardzie UML 1.4. Starsza wersja UML zawiera 8 diagra-

mów oraz 2 nieoficjalne (diagram pakietów oraz obiektów) doł�czane do niektórych narz�dzi

CASE. UML 2.0 oferuje dodatkowo diagram struktur poł�czonych, przebiegów czasowych



23

(harmonogramowania) i przegl�du interakcji. Zmieniono w nim nazw� diagramu stanów na

diagram maszyny stanowej oraz diagramu współpracy na diagram komunikacji. Specyfikacj�diagramów UML wraz z odpowiednimi nazwami skróconymi zamieszczono w tabeli 1.

Tabela 1. Specyfikacja diagramów UML

Lp. Typy diagramówNazwa

skróconaUML 1.4 UML 2.0

1 use case diagram - diagram przypadków u�ycia ud + +

2 class diagram - diagram klas (diagram struktury statycznej) cld + +

3package diagram - diagram pakietów *)

czasami dost�pny i u�ywany nieoficjalnie w UML 1.4pd nieoficjalny

(* +

4object diagram - diagram obiektów *)

czasami dost�pny i u�ywany nieoficjalnie w UML 1.4ob nieoficjalny

(* +

5 composite structure diagram - diagram struktur poł�czonych csd − +

6 component diagram - diagram komponentów cod + +

7 deployment diagram - diagram wdro�enia (rozlokowania) dd + +

8 activity diagram - diagram aktywno�ci ad + +

9state machine diagram - diagram maszyny stanowej **)

nazwa w UML 1.4: statechart diagram - daigram stanówsm + (** +

10 sequence diagram - diagram sekwencji (przebiegu) sd + +

11communication diagram - diagram komunikacji ***)

nazwa w UML 1.4: collaboration diagram - diagram współdziałaniacd + (*** +

12timing diagram - diagram przebiegów czasowych (harmonogramowania)

td − +

13interaction overview diagram - diagram przegl�du interakcji (sterowania interakcj�)

iod − +

8 13SUMA ILO�CI DIAGRAMÓW

�ródło: Opracowanie własne na podstawie [1])

Do porównania zakwalifikowano dost�pne i rozpowszechnione w rodowisku lokalnym (aka-

demickim) rozwi�zania. Sporód komercyjnych narz�dzi CASE wybrano: Enterprise Architect,

Poseidon for UML, Rational Software Architect, Microsoft Visio, czy Visual Paradigm for UML.

Popularne niekomercyjne narz�dzia typu open source to miedzy innymi: AgroUML, StarUML oraz

UMLet. Poni�ej zaprezentowano ich krótkie charakterystyki. Analogiczn� list� narz�dzi oraz ich

analiz� porównawcz� opublikowano w pracy [1, s. 353-369].

System Enterprise Architect (wersja 7.1) firmy Sparx System [28] charakteryzuje si� pełnym

wsparciem dla j�zyka UML w wersji 2.0 (13 typów diagramu). Dost�pny jest w 5 wersjach:

Desktop, Professional, Corporate, Viewer oraz w wersji testowej. W dystrybucji dost�pna jest ju�równie� wersja 7.5 Enterprise Architect zapewniajaca pełn� zgodno� z UML 2.1.

Program Poseidon for UML (wersja 6.0.2) firmy Gentleware [29] jest równie� w pełni zgodny

ze standardem UML 2.0. Narz�dzie to jest napisane w j�zyku Java, co daje pełn� niezale�no� od

platformy systemowej. Dost�pny jest w 4 wersjach: Community Edition, Standard Edition,

Professional Edition oraz Embedded Edition (trzy ostatnie dost�pne s� równie� w 30-dniowych

wersjach testowych).

Jarosław Becker


w notacji UML 2.0

24

Narz�dzie Rational Software Architect (wersja 7.5.1) firmy IBM [30] jest zgodne z UML 2.0

(9 typów diagramu). System ten oferuje uproszczon� prac� z diagramami, np. poprzez mo�liwo�uj�cia schematów zwi�kszaj�cych przewidywalno� procesu modelowania aplikacji. Dla narz�dzia

Rational Software Architect Standard Edition dost�pne s� trzy licencje: dla autoryzowanego

u�ytkownika, licencja sieciowa oraz wersja testowa trial.

Microsoft Visio (wersja 2007) [31] jest programem ogólnego zastosowania słu��cym do two-

rzenia schematów ró�nego typu, mi�dzy innymi oferuje mo�liwo� opracowania 9 diagramów

w notacji UML 2.0.

Tabela 2. Porównanie narz�dzi CASE – cz. 1

Ent

erp

rise

Arc

hite

ct

we

rsja

7.1

Pos

eid

on f

or U

ML

we

rsja

6.0

.2

Ra

tiona

l Sof

twa

re

Arc

hite

ct w

ersj

a 7

.5.1

Mic

roso

ft V

isio

we

rsja

200

7

Vis

ual

Par

adig

m f

or U

ML

we

rsja

6.3

Arg

oUM

Lw

ers

ja 0

.26

Sta

rUM

Lw

ers

ja 5

.0.2

UM

Let

we

rsja

9.0

3

wersja UML 2.0 2.0 2.0 2.0 2.0 1.4 2.0 1.4 -ud + + + + + + + + 8

cld + + + + + + + + 8

pd + + − + + − − − 4

ob + + − − + − − − 3

csd + + + − + − + − 5

cod + + + + + − + − 6

dd + + + + + + + + 8

ad + + + + + + + + 8

sm + + + + + + + + 8

sd + + + + + + + + 8

cd + + + + + + + − 7

td + + − − + − − − 3

iod + + − − + − − − 3

SUMA 13 13 9 9 13 7 9 6

MS Windows + + + + + + + + 8

Linux − + + − + + − + 5

Mac OS − + − − + + − + 4

SUMA 1 3 2 1 3 3 1 3

Cobra IDL − + + − + − − − 3

C++ + + + + + + + − 7

C# + + − + + + + − 6

Delphi + + − − + + − − 4

Java + + + − + + + − 6

PHP + + − − + + − − 4

Visual Basic (VB) + − − + − − − − 2

VB.NET + + − + + − − − 4

SQL − + + − − + − − 3

liczba innych j�zyków 3 3 1 − 7 3 − − −

SUMA 10 11 5 4 14 9 3 0

Cobra IDL − − − − + − − − 1

C++ + − + + + + − − 5

C# + − + + − + − − 4

Delphi + − − − − − − − 1

Java + + + − + + − − 5

PHP + − − − + − − − 2

Visual Basic (VB) + − − + − − − − 2

VB.NET + − − + − − − − 2

liczba innych j�zyków − − 1 − 2 − − − −

SUMA 7 1 4 4 6 3 0 0

In�y

nie

ria z

wro

tna

SU

MA

Kryterium porównania

Dia

gra

my

Pla

tform

a

Narz�dzia CASE

Genero

wanie

kodu �

ródło

we

go

ródło: Opracowanie własne na podstawie [28-35].



25

Tabela 3. Porównanie narz�dzi CASE – cz. 2

En

terp

rise

Arc

hite

ct

wer

sja

7.1

Po

seid

on f

or U

ML

wer

sja

6.0

.2

Rat

iona

l Sof

twar

e A

rchi

tect

we

rsja

7.5

.1

Mic

roso

ft V

isio

wer

sja

200

7

Vis

ual P

arad

igm

for

UM

L w

ersj

a 6

.3

Arg

oUM

Lw

ersj

a 0

.26

Sta

rUM

Lw

ersj

a 5

.0.2

UM

Let

wer

sja

9.0

3

XMI / XML + − − + + + + − 5

Rational Rose - MDL − + − − + − + − 3

CSV + − − − − − − − 1

Java - pliki JAR + + − − − + − − 3

liczba innych formatów − 1 − 2 3 3 − − −

SUMA 3 3 0 3 5 5 2 0

XMI / XML + + + + + + + − 7

PDF − − + + − − − − 2

CSV + − − − − − − − 1

liczba innych formatów − − 1 − 2 − − − −

SUMA 2 1 3 2 3 1 1 0

EPS − + − − − + − + 3

GIF + + + − − + − − 4

JPG + + + − + − + + 6

PNG + + + − + + − − 5

SVG − + + − + + − + 5

WMF + + − − − − + − 3

BMP + + + − − − + − 4

EMF + − − − + − + − 3

PDF − + + + + − − + 5

liczba innych formatów − − − 1 − 1 − − −

SUMA 6 8 6 2 5 5 4 4

Sta

nd

ard

eksp

ort

ow

a-

nych d

anych

Sta

nda

rd e

kspo

rtu

dia

gra

mó

w

SU

MA


Narz�dzia CASE

Sta

nd

ard

impo

rto

wan

ych

dan

ych

ródło: Opracowanie własne na podstawie [28-35].

Visual Paradigm for UML (wersja 6.3) [32] jest jednym z najbardziej rozbudowanych pro-

gramów. Narz�dzie to nie tylko wspiera proces modelowania systemów, ale umo�liwia równie�przeprowadzanie in�ynierii odwrotnej, generowanie kodu, a tak�e synchronizacj� modelu i

dokumentacji. Visual Paradigm wyst�puje w wersjach: Enterprise, Standard, Professional,

Modeler, Personal, Community (do u�ytku niekomercyjnego) oraz Viewer (tylko do podgl�du).

Narz�dzia z grupy open source, tj. AgroUML [33] oraz UMLet [35] wspomagaj� standard

UML w wersji 1.4. Na wyró�nienie zasługuje StarUML [34] (wersja 5.0.2), który dostarcza

9 ro�nych diagramów. Funkcjonalno� tego programu mo�na rozszerza� instaluj�c dodatki (tzw.

wtyczki) dost�pne na odpowiedniej stronie internetowej. StarUML umo�liwia import projektów

wykonanych w komercyjnym programie Rational Rose. Warto doda�, �e AgroUML wykonany jest

w technologii Java i działa na platformie Windows, Linux oraz Mac OS (patrz: tab. 2).

Do analizy porównawczej zastosowano prost�, addytywn� metod� nadawania odpowiednich

wag z modelem SPMC (ang. Single Participant Multiple Criteria). Model tworz�, pojedynczy

decydent, zbiór mo�liwych wariantów (lub działa�) {A1, A2, ..., Am} oraz zbiór kryteriów

{C1, C2, ..., Cn}, z których ka�de dotyczy preferencji wyboru okrelonego wariantu. Zadaniem

analizy jest otrzymanie rankingu wariantów na podstawie podanych kryteriów.

Jarosław Becker


w notacji UML 2.0

26

Wyniki szczegółowego porównania narz�dzi CASE zestawiono w tabeli 2 i 3. Stanowi� one

opracowanie własne, którego dokonano na podstawie informacji zawartych na stronach interneto-

wych producentów oraz w elektronicznej dokumentacji doł�czonej do udost�pnionych wersji

(pełnych, testowych lub demonstracyjnych) oprogramowania. W celu kompletnego wyra�enia

kryteriów cz�stkowych w postaci wartoci liczbowych ich wybór zdeterminowano dost�pnoci�danych. Oceny systemów podsumowuj�ce ka�d� kategori� (kryterium główne) wyra�ono za

pomoc� pi�ciopunktowej (0-5) skali. Kryteriom nadano odpowiednie wartoci preferencji (wagi).

W podsumowaniu dla ka�dego systemu obliczono sum� i redni� wa�on� ocen punktowych,

których wartoci odwzorowuj� zaj�te miejsce w rankingu (tab. 4).

Pierwsz� kategori� analizy porównawczej wybranych narz�dzi CASE jest mo�liwo� odwzo-

rowania poszczególnych typów diagramów UML. Z zestawienia (tab. 2) wynika, �e pełne wsparcie

dla UML 2.0 zapewniaj� tylko trzy programy: Enterprise Architect, Poseidon for UML i Visual

Paradigm. Przy modelowaniu niedu�ych systemów informatycznych cz�sto wystarcza minimalna

liczba diagramów dost�pna w programie UMLet. S� to najcz�ciej u�ywane diagramy, stanowi�rdze� omawianych metodyk. Z punktu widzenia potrzeb naukowego podejcia do udokumentowa-

nia prac projektowo-badawczych nad generatorem SWD – którego wyjcie stanowi� wyspecjali-

zowane systemy informatyczne o ró�nych strukturach informacyjnych i modelach decyzyjnych –

zapewnienie standardu UML 2.0 jest uzasadnione (warto� współczynnika wagowego = 1; tab. 4).

Tabela 4. Ocena narz�dzi CASE

Ent

erpr

ise

Arc

hite

ct

wer

sja

7.1

Pos

eido

n fo

r U

ML

wer

sja

6.0

.2

Rat

iona

l Sof

twa

re

Arc

hite

ct w

ersj

a 7.

5.1

Mic

roso

ft V

isio

wer

sja

200

7

Vis

ual P

arad

igm

for

UM

L

wer

sja

6.3

Arg

oUM

Lw

ersj

a 0

.26

Sta

rUM

Lw

ersj

a 5

.0.2

UM

Let

wer

sja

9.0

3

liczba diagramów 13 13 9 9 13 7 9 6 −

ocena punktowa (0-5) 5 5 4 4 5 3 4 2,5 1

liczba platform 1 3 2 1 3 3 1 3 −

ocena punktowa (0-5) 3 5 4 3 5 5 3 5 0,5

liczba zgodnych j�zyków 10 11 5 4 14 9 3 0 −

ocena punktowa (0-5) 4,5 5 4 3,5 5 4 3,5 0 1

liczba zgodnych j�zyków 7 1 4 4 6 3 0 0 −

ocena punktowa (0-5) 5 3 4 4 4,5 3,5 0 0 1

liczba formatów 3 3 0 3 5 5 2 0 −

ocena punktowa (0-5) 3,5 3 0 3 5 5 3 0 0,6


ocena punktowa (0-5) 4 3 5 3,5 5 3 3 0 0,6


ocena punktowa (0-5) 4,5 5 4,5 1 4 4 2 2 0,3

21,85 20,6 18,35 17,2 24,2 19 13,2 5,6 −

4,37 4,12 3,67 3,44 4,84 3,8 2,64 1,12 5

2 3 5 6 1 4 7 8

In�ynieria zwrotna

POZYCJA W RANKINGU

�rednia wa�ona ocen punktowych (0-5)

Importowanie danych

Eksportowanie danych

Eksportowanie diagramów

Suma wa�ona ocen punktowych

WA

GA

(p

refe

ren

cja

do

kry

teri

um

)

Zakres wspomagania

diagramów

Kompatybilno�� platform

systemowych

Generowanie kodu

�ródłowego


Narz�dzia CASE

ródło: Opracowanie własne.



27

Na kolejne kryterium decyzyjne wybrano dost�pno� wersji oprogramowania zorientowanych

na ró�ne platformy systemowe (systemy operacyjne). W przypadku wszystkich analizowanych

rozwi�za� wspieranie systemów Windows mo�na uzna� za powszechn� praktyk� (tab. 2). Do�popularn� platform� jest tak�e Linux. Z powodu wieloletniej dominacji systemów Windows

upowszechnionych w rodowisku decydenta, wymóg ten oceniono wysoko przyznaj�c 3 pkt

(pozostałe po 1 pkt). Z kolei, aby dost�pno� innych wersji (Linux, Mac OS) nie odgrywała w

rankingu zbyt du�ej roli przyznano temu kryterium nisk� warto� współczynnika wagowego, równ�0,5 (tab. 4).

Innymi bardzo wa�nymi aspektami wspomagania in�ynierii systemów informatycznych jest,

po pierwsze, mo�liwo� generowania szkieletowego kodu �ródłowego oraz, po drugie, zdolno� do

utworzenia b�d� modyfikacji modelu systemu na podstawie kodu �ródłowego aplikacji (tzw.

in�ynieria zwrotna). Poł�czenie tych dwóch funkcji zyskało miano in�ynierii wahadłowej (ang.

round-trip engineering) i umo�liwia zachowanie spójnoci kodu systemu wzgl�dem jego modelu.

W rankingu właciwoci te s� silnie preferowane (warto� współczynnika wagowego = 1; tab. 4),

poniewa� usprawniaj�, stosowane przez decydenta rankingu, projektowanie adaptacyjne middle-

out. Głównym aspektem tego podejcia, w odró�nieniu od idei top-down i buttom-up, jest skupie-

nie uwagi na szybkim opracowaniu prototypu systemu, nast�pnie jego rozbudowie, doł�czaniu

nowych funkcji lub procedur do momentu wytworzenia kształtu systemu stabilnego, daj�cego si�przenosi�. Funkcja in�ynierii zwrotnej w takim podejciu zwalnia nas z nanoszenia poprawek

w dokumentacji projektowej po cz�stych zmianach w kodzie systemu. Na etapie zastosowania

generatora systemów informatycznych, szczególnie cenna wydaje si� mo�liwo� przekształcania

kodu �ródłowego wygenerowanych ró�nych od siebie systemów na posta� modelow�. Mo�liwoci

analizowanych rozwi�za� CASE w omawianym zakresie przedstawia tabela 2. Wida� wyra�nie, �e

liczba wspieranych standardów (j�zyków programowania i in.) dla danego narz�dzia w zakresie

generowania kodu �ródłowego jest nieco wi�ksza ni� w in�ynierii zwrotnej.

Nast�pn� bran� pod uwag� w rankingu funkcj� narz�dzi CASE s� mo�liwoci importowania

oraz eksportowania plików danych, którym przyznano mniej ni� przeci�tn� warto� preferencji

(współczynniki wagowe = 0,6; tab. 4), z uwagi na mniejsz� przydatno� w stosunku do powy�ej

omówionych kryteriów. Dominuj�cym formatem wymiany danych jest XMI/XML, za wyj�tkiem

programu UMLet oraz cz�ciowo Rational Software Architect, który pozbawiony jest funkcji

importu plików. Liderem pod wzgl�dem dwukierunkowej wymiany danych jest Visual Paradigm.

Równie rozwini�t� funkcj� importowania ma program ArgoUML. Interesuj�cy jest fakt posiadania

przez trzy programy interfejsu odczytu plików MDL z profesjonalnego pakietu firmy IBM (rodzina

programów Rational Rose), co wyszczególniono w tabeli 3.

Ostatnim kryterium decyzyjnym w analizie porównawczej jest funkcja generowania diagra-

mów w formacie graficznym (JPG, PNG, SVG itd.; tab. 3). Warto� wagi dla tej kategorii jest

bardzo niska (równa 0,3), poniewa� nie wpływa na jako� modelowania. Poza tym na rynku

istnieje du�o programów do konwersji formatu plików graficznych, a w systemach operacyjnych

mo�liwo� przenoszenia grafiki przez bufor (schowek) systemowy, aczkolwiek z pewn� utrat�jakoci do druku. Liderami w tej kategorii s� Poseidon for UML, Enterprise Architect i Rational

Software Architect, natomiast ostatni� pozycj�, co mo�e zdziwi�, uzyskał Microsoft Visio 2007

(tab. 4).

Jarosław Becker


w notacji UML 2.0

28

4. Podsumowanie i prezentacja wyników

Obliczone sumy wa�one ocen punktowych, zamieszczone w tabeli 4, odwzorowuj� zaj�te

miejsce w rankingu. Wyniki te uporz�dkowano w ci�gu malej�cym i zaprezentowano na wykre-

sie 1. Na podium (trzy pierwsze pozycje) znalazły si� rozwi�zania komercyjne. Zaskoczeniem jest

bardzo wysoka lokata (4 miejsce) narz�dzia ArgoUML nale��cego do kategorii open source, co

wi��e si� m. in. z całkowitym brakiem opłat licencyjnych. Najgorzej wypadł program UMLet

zdobywaj�c jedynie 5,6 pkt., czyli ponad czterokrotnie mniej ni� faworyt. Mo�na uzna� go za

prosty program graficzny do rysowania diagramów UML.

24,2

21,920,6

19,0 18,417,2

13,2

5,6

0,0

5,0

10,0

15,0

20,0

25,0

liczba punktów

VisualParadigmfor UML(w .6.3)

EnterpriseArchitect(w .7.1)

Poseidonfor UML

(w .6.0.2)

ArgoUML(w .0.26)

RationalSoftw areArchitect(w .7.5.1)

MicrosoftVisio 2007

StarUML(w .5.0.2)

UMLet(w .9.03)

Rys. 1. Wyniki rankingu narz�dzi CASE

ródło: Opracowanie własne na podstawie tab. 4.

Analizuj�c wyniki rankingu wyra�one w postaci rednich ocen wa�onych, mieszcz�cych si�w przyj�tej skali punktowej od 0 do 5 pkt., mo�na podj�� prób� podziału narz�dzi i wyodr�bnienia

ich kilku klas, które ró�ni� si� stopniem zaawansowania funkcjonalnego. Wokół oceny 4,5 pkt.

skupiaj� si� trzy programy zajmuj�ce czołowe miejsca rankingu. Jest to klasa rozwi�za� ponad-

przeci�tnych skierowana do profesjonalistów. Systemy zajmuj�ce kolejne trzy pozycje w rankingu

(ArgoUML, Rational Software Architect i Microsoft Visio 2007) oscyluj� blisko oceny 3,5 pkt.

i mo�na je okreli� mianem rozwi�za� przeci�tnych, spełniaj�cych ogólnie przyj�te standardy

modelowania. Poni�ej oceny przeci�tnej (około 2,5 pkt.) znajduje si� program StarUML, zliczany

do dobrych rozwi�za� klasy open source. Ostatni� i odr�bn� grup� stanowi bardzo prosty program

graficzny UMLet, którego rednia ocena wa�ona jest bliska jednoci.

Uzyskane wyniki rankingu maj� charakter subiektywny, mog� jednak stanowi� pewien punkt

odniesienia dla podobnych tego typu analiz. Ostatecznego wybór mo�na dokona� testuj�c wszyst-

kie lub wybrane narz�dzia CASE. Tym bardziej, �e wszyscy producenci programów znajduj�cych

si� w rankingu udost�pnili wersje do nieodpłatnej oceny.



29

Bibliografia

1. Wrycza S., Marcinkowski B., Wyrzykowski K., J�zyk UML 2.0 w modelowaniu

systemów informatycznych, Wyd. Helion, Gliwice 2005.

2. Becker J., Architektura informatycznego systemu generowania wielokryterialnych

rozwi�za� decyzyjnych: (cz. 1) Koncepcja budowy modelu WPL oparta na

niestandardowych zadaniach decyzyjnych, Seria: Badania Systemowe, tom 64 pt.:

„Badania operacyjne i systemowe: decyzje, gospodarka, kapitał ludzki i jako�”,

Wydawca: Instytut Bada� Systemowych PAN & Polskie Towarzystwo Bada�Operacyjnych i Systemowych, Warszawa 2008.

3. Subieta K., Wprowadzenie do obiektowych metodyk projektowania i notacji UML,

Instytut Podstaw Informatyki PAN, Warszawa 1999 (http://www.ipipan.waw.pl/~

subieta).

4. Wrycza S., Analiza i projektowanie systemów informatycznych zarz�dzania, PWN,

Warszawa 1999.

5. Doli�ska M., Projektowanie systemów informacyjnych na przykładzie zarz�dzania

marketingiem, Wyd. „Placet”, Warszawa 2003.

6. Kisielnicki J., Sroka H., Systemy informacyjne biznesu, Wyd. „Placet”, Warszawa 2005.

7. Totland Terje, Enterprise Modeling as a Means to Support Human Sense-making and

Communication in Organizations, PART II, Chapter 5, 5.2.7 Object Modeling Technique

(OMT), Informatics and Mathematics Norwegian University of Science and Technology,

Norway, Trondheim 1997 (http://www.idi.ntnu.no/grupper/su/publ/ html/totland/

thesis.htm).

8. Hoover H. James, OOAD Overview, [in:] Object-Oriented Analysis and Design, A

Practitioner's Approach, Copyright © 2000, Avra Software Lab Inc., Redaction 2.2.3,

May 23, 2001. (http://www.cs.ualberta.ca/~hoover/cmput660/readings/SoftwareArch/

section/document.htm)

9. Marino M., The Booch Method of Object-Oriented Analysis & Design, BaBar Offline

Workbook, 2008 (http://www.slac.stanford.edu/BFROOT/www/doc/workbook/

workbook.html)

10. SmartDraw.com, How to draw Jacobson's OOSE diagrams, [in:] tutorial, the World's

Most Popular Business Graphics Software, Software Design Center, 2009

(http://www.smartdraw.com/tutorials/software/oose/tutorial_01.htm).

11. Booch G., Jacobson I., Rumbaugh J., The Unified Software Development Process,

Addison-Wesley, Boston 1998.

12. IBM, Rational Unified Process, Best Practices for Software Development Teams,

Rational Software White Paper, TP026B, Rev 11/01,

(http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_b

estpractices_TP026B.pdf)

13. Kruchten Philippe, Rational Unified Process od strony teoretycznej, In�ynieria

oprogramowania, WNT, Warszawa 2006.

14. Henderson-Sellers Brian, What is OPEN? (http://www.open.org.au/, Last Updated:

12/5/05).

Jarosław Becker


w notacji UML 2.0

30

15. Mrozek Z., Metodyka RUP i j�zyk UMLw projektowaniu in�ynierskim, „Pomiary

Automatyka Robotyka”, 2/2005.

16. Jeffries R., What is Extreme Programming? XProgramming.com, 11/08/2001

(http://www.xprogramming.com/xpmag/whatisxp.htm).

17. Kaczmarski K., Extreme programming – zapewnienie skutecznej i wydajnej pracy

programistów, Serwis internetowy Wydziału Matematyki i Nauk Informacyjnych

Politechniki Warszawskiej, Warszawa 2003 (http://www.mini.pw.edu.pl-kaczmars/pion/

articles/xp-zespo1.pdf).

18. Ambler S., Agile Modeling: Effective Practices for eXtreme Programming and the

Unified Process, Published by John Wiley & Sons, Inc., New York 2002

(http://www.agilemodeling.com/practices.htm).

19. Davies R., DSDM explained, Agile Alliance Member, DSDM consortium, Sept 21, 2004

(http://www.agilexp.com/presentations/DSDMexplained.pdf).

20. Rybus R., Feature Driven Development – lekka metodyka tworzenia oprogramowania,

[w:] Problemy i metody in�ynierii oprogramowania (KKIO V), praca zbiorowa pod

redakcj� Zbigniewa Huzara i Zygmunta Mazura, WNT, 2003.

21. Kukli�ski R., Inicjowanie i prowadzenie projektów innowacyjnych w firmie cz.II, Project

Evolution Sp. z o.o., Serwis internetowy: „4pm Project Management”

(http://www.4pm.pl).

22. Scrum Alliance, What is Scrum? (http://www.scrumalliance.org/pages/what_is_scrum).

23. Cocburn Alistair A. R., Crystal light methods, Humans and Technology, from Cutter IT

Journal, 2001 (http:/alistair.cockburn.us/index.php/Crystal_light_methods).

24. Bartyzel M., Ewolucja Agile, Nowoczesne programowanie, Magazyn specjalistów

bran�y IT, online: „Dzie� dobry informatyku”, 04/2008 (http://ddinformatyku.pl/ pdf/04-

2008/12.pdf).

25. Malina W., Szwoch M., Metodologia i techniki programowania, PWN/MIKOM, 2008.

26. Chmielarz W., CASE, [w:] Wykład pt. „Analiza i projektowanie informatycznych

systemów zarz�dzania” zamieszczony w serwisie internetowym Wydziału Zarz�dzania

UW, (http://www2.wz.uw.edu.pl/ksiz/download/wch/Cale1.pdf).

27. Bednarczyk M., Fazy instalacji i konserwacji, Narz�dzia CASE, Wykład pt. „In�ynieria

oprogramowania”, Instytut Matematyki Uniwersytetu Gda�skiego, (http://math.univ.

gda.pl/~mab/softengine/wyk/w08.pdf).

28. Sparx System, Enterprise Architect – UML tool for analysis, design and implementation,

(http://www.sparxsystems.pl).

29. Gentleware, Poseidon for UML (http://www.gent1eware.com/products.html).

30. IBM, Rational Software Architect Standard Edition (http://www-01.ibm.com).

31. Microsoft, Microsoft Office Visio 2007 (http://office.microsoft.com/en-

us/visio/default.aspx).

32. Visual Paradigm, User's Guide (http://www.visual-paradigm.com/documentation/

#vpuml).

33. Odutola K., Oguntimehin A., Tolke L., Van der Wulp M., ArgoUML Quick Guide

(http://argoumlstats.tigris.org/documentation/quick-guide-0.26/).

34. Lee M., Kim H., Kim J., Lee J., Gum D., StarUML 5.0, Przewodnik u�ytkownika

(http://www.wolski.waw.pl).



31

35. UMLet, UMLet 9.03 Free UML Tool for Fast UML Diagrams (http://www.umlet.com/).

REVIEW OF METHODOLOGIES AND COMPUTER AIDED SOFTWARE ENGINEERING TOOLS APPLIED TO COMPUTER MANAGEMENT

SYSTEMS MODELING BASED ON UML 2.0 SPECIFICATION

Summary

In the article presented are review of methodologies and available CASE tools

based on UML 2.0 specification applied to computer management systems modeling.

Result of research is a ranking of the functionality case tools. It will let appoint the

leader which best will support adaptive design process of the DSS generator.

Keywords: formal methodologies, agile methodologies, CASE tools, UML 2.0, computer man-

agement systems modeling

Jarosław Becker

Katedra In�ynierii Systemów Informacyjnych

Wydział Informatyki

Zachodniopomorski Uniwersytet Technologiczny

71-210 Szczecin, ul. �ołnierska 49

e-mail: [email protected]

przegląd metodyk i narzędzi modelowania informatycznych ......i innych [15]. do innych, aktualnie...

Documents