Przegląd metodyk i narzędzi modelowania informatycznych

Transkrypt

PRZEGLĄD METODYK I NARZĉDZI MODELOWANIA INFORMATYCZNYCH
SYSTEMÓW ZARZĄDZANIA W NOTACJI UML 2.0
JAROSŁAW BECKER
Zachodniopomorski Uniwersytet Technologiczny w Szczecinie
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 najlepiej wspomoĪe adaptacyjny proces budowy generatora DSS.
Słowa kluczowe: metodyki formalne, metodyki zwinne, narzdzia CASE, UML 2.0, obiektowe
modelowanie systemów informatycznych
1. Wprowadzenie
Lata 80-te zaowocowały mnogoci metodyk oraz notacji zwizanych ze strukturalnym, a take 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 bdcych podstaw dalszego rozwoju. Mona zaliczy do nich:
pojcie metodyki tworzenia systemów informatycznych i jej składniki, cykl ycia sytemu, prototypowanie, diagramy zwizków encji, modele relacyjnych baz danych oraz narzdzia CASE (ang.
Computer-Aided Software Engineering).
Od połowy lat 90-tych, wraz z rosnc popularnoci programowania obiektowego, zaobserwowano znaczny rozwój metodyk i narzdzi modelowania systemów informatycznych (CASE)
zgodnych z paradygmatem obiektowym. Od tego czasu modelowanie strukturalne coraz czciej
jest wypierane przez ujednolicony jzyk 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. Postp 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 zarzdzania dla np.
handlu, bankowoci, logistyki czy edukacji. [1]
Celem artykułu jest przegld metodyk i narzdzi CASE wspomagajcych modelowanie systemów informatycznych w notacji UML 2.0. Wynikiem bada jest ranking narzdzi CASE przeprowadzony z punktu widzenia potrzeb inynierii zautomatyzowanych generatorów SWD (systemów
wspomagania decyzji). Chodzi o wyłonienie rozwiza, które najlepiej bd wspomagały adaptacyjny proces budowy generatora oraz pozwol, przy uyciu inynierii wahadłowej, precyzyjnie
odwzorowa i udokumentowa jego architektur.
Rozwaania metodyczne przedstawione w artykule koncentruj si na: przegldzie metodyk
zgodnych z notacj UML oraz wyborze odpowiedniego narzdzia do modelowania informacyjnych
struktur zdarze i rzeczy realizowanych w generatorze systemów wspomagania decyzji. Do
18
Jarosław Becker
Przegląd metodyk i narzĊdzi modelowania informatycznych systemów zarządzania
w notacji UML 2.0
wspomagania decyzji wykorzystano koncepcj zadania WPL (Wielokryterialnego Programowania
Liniowego), w którym maksymalizuje si odpowiedni posta funkcji uytecznoci dla rónie
zdefiniowanych, niestandardowych problemów (np. wspomaganie przetargów elektronicznych).
Opracowana dla wielu zastosowa konstrukcja zadania WPL (szablon) stanowi podstaw metodyczn 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, pozwalajce 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 zwizanych z wyborem ofert, które
uznaje si za najlepsze z punktu widzenia preferencji decydenta (dysponenta rodków finansowych). Budowa systemu informatycznego, który na podstawie (zdefiniowanych przez projektantó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 narzdzia wspomagajcego wizualizacj,
specyfikowanie, konstruowanie i dokumentowanie składników generatora. Szczególnie, jeeli
projektowanie złoonego produktu (systemu) ma stanowi powane wyzwanie organizacyjne,
inynierskie i naukowe.
2. Przegląd metodyk modelowania systemów informatycznych zgodnych z UML
Pojcie metodyki projektowania systemów informatycznych pojawiło si ju na pocztku 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 organizatorskim, pozwalających zespołowi projektowemu realizowaü cykl Īycia systemu” [4]. Poza tym
metodyka zwizana jest take z okrelon notacj, która słuy przede wszystkim do zapisu i
wizualizacji wyników projektowania oraz wspomaga prac zespołu zadaniowego w semantycznej,
syntaktycznej i pragmatycznej warstwie wymiany informacji pomidzy projektantami i uytkownikami.
Metodyki projektowania systemów informatycznych mona podzieli na trzy grupy (nurty) [5]. Pierwsz grup reprezentuje podejĞcie socjo-psychologiczne (zwane równie społecznym),
które jest do mocno zwizane z faz analizy. W projektowaniu stosowane jest do celów ekonomicznej i społecznej oceny systemów oraz do opracowania strategii realizacji i wdraania projektu.
Do drugiej grupy zalicza si metodyki strukturalne. W podejciu strukturalnym system (lub
problem do rozwizania) rozkładany jest na czci składowe, ulega hierarchicznej dekompozycji.
Zalet takiego postpowania jest moliwo podziału przedsiwzicia projektowego na mniejsze
czci, co w konsekwencji pozwala na równoległ, grupow prac, czyli rozdział zada midzy
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 dy si do wyeliminowania 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 (czsto ułatwia) budowanie duych, złoonych
systemów informatycznych przez wieloosobowe zespoły. Według autorów prac [1, 3, 4, 5, 6] jest
ono powszechne i dominujce w praktyce.
W latach 1989-1994 obiektowe podejcie do modelowania systemów informatycznych charakteryzowało si spor liczb rónorodnych metodyk oraz notacji. Jednak w przeciwiestwie do
metodyk strukturalnych udało znale si kompromis. Współpraca trzech autorów, dominujcych
w omawianym okresie rozwiza, mianowicie: J. Rumbaugh’a, G. Booch’a (1995) i I. Jacobson’a
(1996) zaowocowała powstaniem pierwowzoru UML, ujednoliconego jzyka modelowania
systemów informatycznych, oznaczanego pocztkowo skrótem UM (ang. Unified Method). [1, s. 18]
W praktyce jzyk UML przyjł posta graficznej reprezentacji budowanego systemu. Składa
si z logicznie powizanych ze sob diagramów, które pozwalaj na opisanie systemu od modeli
ogólnych do bardzo szczegółowych. W standardzie UML 2.0 wystpuje trzynacie diagramów,
które charakteryzuj statyk i dynamik opracowywanego systemu. Jzyka UML nie naley
utosamia z kompletn metodyk tworzenia systemów informatycznych, chocia u jego podstaw
znajduj si rozwizania i dowiadczenia wniesione przez twórców, mianowicie:
• Rumbaugh – OMT (ang. Object Modeling Technique) to jzyk modelowania obiektowego
systemów informatycznych opracowany w 1991 r.; stanowił wsparcie dla zorientowanego
obiektowo programowania; wystpuj w nim trzy główne diagramy: obiektów, dynamiki
oraz czynnoci; nie uwzgldniono w nim aspektów zwizanych z uytkownikami i implementacj systemu; [7]
• Booch – OOAD (ang. Object Oriented Analysis and Design) dotyczy zorientowanych
obiektowo projektowania i analizy; jest to inynieria oprogramowania traktujca modele
systemu jako grup obiektów; wymagania systemowe reprezentowane s przez poszczególne obiekty, które na siebie oddziałuj; w podejciu tym nacisk połoony jest na projektowanie i implementacj, nie przykłada si zbyt duej uwagi do fazy identyfikacji i analizy
wymaga uytkowników; [8, 9]
• Jacobson – OOSE (ang. Object Oriented Software Engineering) to pierwsza, zorientowana
obiektowo metodyka wraz z jzykiem modelowania, do której wprowadzono analiz przypadków uycia; do podstawowych etapów OOSE zalicza si: modelowanie wymaga, analiz, projektowanie, implementacj i testowanie kadego przypadku uycia; uwzgldnia
ona cykl ycia systemu oraz aspekty modelowania interakcji z uytkownikami; słab stron
jest etap implementacji oraz sposób modelowania dziedziny. [10]
Dalsze prace zespołu trzech naukowców [11] nad jzykiem UML, ukierunkowane na unifikacj 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 moliwo opracowania rónych jej konfiguracji i implementacji. [1, s. 319] Metodyka ta stanowi zbiór poj i wytycznych, ukierunkowany na modelowanie
przypadków uycia i koncentrowanie si na architekturze systemu, jako głównym zagadnieniu
w procesie tworzenia oprogramowania. Głównym załoeniem tego procesu jest jego iteracyjnoprzyrostowy charakter.
Implementacj USDP stanowi opracowana przez firm Rational Software metodyka RUP
(ang. Rational Unified Process). [12, 13] Pocztkowo była ona zbiorem praktyk Rational Approach z uwzgldnieniem podejcia Objectory I. Jacobson’a. Stopniowo rozwijana, w 2003 r. została
20
Jarosław Becker
w notacji UML 2.0
przejta przez firm IBM i zaczła zdobywa coraz wiksze uznanie. Obecnie dominuje w
obszarze formalnych, obiektowych metodyk tworzenia systemów zgodnych z notacj jzyka UML.
RUP stanowi konkurencyjne rozwizanie dla metodyki OPEN (ang. Object-oriented Process,
Environment, and Notation), która powstała na skutek połczenia ponad dwudziestu midzynarodowych metodyk i ich idei. Do najwaniejszych zalicza si MOSES, SOMA, Firesmith i Synthesis
oraz o mniejszym znaczeniu: BON, OOram, UML. [14]
Metodyka RUP posiada szerokie spektrum moliwoci i jest elastyczna, tzn. ukształtowana
w sposób umoliwiajcy dopasowanie procesu budowy systemu do potrzeb konkretnego przedsiwzicia. Moe by stosowana zarówno przy małych, jak i duych projektach informatycznych. Jest
kompletn metodyk, w której załoono przyrostowo-iteracyjny cykl ycia systemu. Zawarto w
niej pojcia, metody i techniki z zakresu jzyka UML oraz inne np. heurystyczne. Wanymi
elementami RUP s: role zdefiniowane w zespole projektowym, procedury zarzdzania projektem,
kryteria oceny i monitorowanie postpu prac. W jej ramach oferowany jest zintegrowany pakiet
narzdzi CASE oraz zorganizowany system wsparcia w postaci hipertekstowej bazy wiedzy
i internetowego serwisu.[1] Istotnym elementem RUP s zalecenia dobrej praktyki inynierskiej
(ang. best practices) [12]. Wikszo tych zalece moe 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łoeniach
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 analitycznoprojektowych, 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 jzyka UML. Umiejtna
reakcja na zmiany to ich cecha wynikajca z dobrej komunikacji w zespole i cigłego przystosowywania procesu do zmieniajcych si warunków. Ich najwaniejszym produktem jest działajcy
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 projektowania i programowania oraz bardzo cisł współprac z odbiorc systemu. Wymagane s bardzo
krótkie iteracje w dostarczaniu kolejnych wersji oprogramowania, prowadzce do szybkich
odpowiedzi uytkownika. Przy tworzeniu oprogramowania stosuje si m.in. programowanie w
parach, cigł przebudow kodu ródłowego oraz integracj i testowanie połczonych modułów.
Wicej praktyk stosowanych w metodyce XP opisano m. in. w pracach [16, 17].
Agile Modeling (AM) jest metodologi opart na praktyce stosowan dla efektywnego modelowania 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 kada ma swoje przeznaczenie (posiada istotne zmiany). Załoono w niej, e podstawowym celem jest działajce oprogramowanie, dlatego jako pracy jest na
bieco sprawdzana. Przyszli uytkownicy programu mog równie bra udział w jego powstawaniu poprzez prezentowanie własnych opinii, sugestii poprawy i nowych rozwiza. [18]
21
Metodyk DSDM (ang. Dynamic Systems Development Method) charakteryzuje iteracyjne
oraz inkrementalne podejcie do tworzonego oprogramowania. Zespoły zadaniowe (druyny)
uprawnione s do samodzielnego podejmowania decyzji. Nowe wersje oprogramowania s
dostarczane systematycznie i oceniane pod ktem wymaga (zastosowa) biznesowych. Wersje te
s tworzone w taki sposób, aby kada wprowadzona zmiana była odwracalna, a testy przeprowadzane s w cigu całego cyklu ycia systemu. W metodyce tej bardzo istotn kwesti jest take
zaangaowanie do współpracy przyszłych uytkowników. [19]
Feature Driven Development (FDD) to projektowanie zorientowane na właciwoci. Metodyk t cechuj krótkie, iteracyjne cykle wytwarzania oprogramowania, a cały proces jest na bieco
ledzony. Kolejne wersje oprogramowania tworzone s do czsto i na bieco zawieraj funkcje
wymagane przez klienta. W podejciu tym szczególny nacisk kładziony jest na jako wytwarzanego systemu. Kady programista indywidualnie odpowiada za swój kod (klas, funkcj), który
podlega czstym 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 odpowiedni struktur dla pracy wikszych zespołów. [20]
Scrum to kolejna lekka metodyka, której ogólne załoenia 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 duym stopniu złoonoci i ryzyka. Kada iteracja trwa od 2 do 4 tygodni. Taki
cykl nazywany jest sprintem. Podczas jego trwania zespół zadaniowy (druyna) wybiera z listy
priorytetów wymaga uytkownika te cechy, które posiadaj najwiksz warto dla klienta. Na
kocu kadego sprintu dostarczany jest produkt potencjalnie moliwy do wysłania (ang. potentially
shippable product). W ten sposób Scrum dostarcza duo, coraz bardziej dopracowanych wersji
projektu oraz włcza przyszłych uytkowników do współpracy. Podsumowujc, metodyka
SCRUM powstała, aby móc sprawnie zarzdza 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 odmiany w zalenoci od stopnia ryzyka inwestycji oraz w zalenoci od rozmiaru projektu (mierzonego liczb zaangaowanych projektantów). Ze wzgldu 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). Natomiast ze wzgldu na liczb osób biorcych udział w projekcie dzieli si je nastpujco, Crystal:
Clear (2-6 osób), Yellow (6-20 osób), Orange (20-40 osób), Red (40-100 osób), Magenta (100200 osób), Blue (200-500 osób) itd. Liczba osób moe zmienia si o ± 20%. Ide tego podejcia
jest dobieranie odpowiedniego rodzaju metodyki do wymaga implementowanego projektu. Crystal, podobnie jak metodyka XP, skierowana jest na ludzi. Jednak – w przeciwiestwie do
XP – zakłada si, i ludzie maj trudnoci z podporzdkowaniem si trudnemu i wymagajcemu
dyscypliny procesowi. [23]
Metodyki lekkie (zwinne) to do dua grupa charakteryzujca si umiejtnym dostosowaniem
do zmieniajcych si warunków. Wszystkie metodologie cechuje wprowadzenie krótkich iteracji,
podczas których powstaj kolejne wersje oprogramowania. Kada wersja musi wnosi co nowego
i spełnia wymagania klienta. Najwikszy nacisk kładziony jest na jako produktu, kod musi by
przetestowany aby system działał poprawnie.
22
Jarosław Becker
w notacji UML 2.0
W praktyce zauwaa si „zniechcenie” tradycyjnymi, formalnymi metodykami i entuzjastyczny odwrót w stron metodyk lekkich. Zjawisko to moe wynika z pobienej 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 rozumowanie moe jeszcze szybciej rozczarowa wielu programistów, poniewa załoenia Agile s
równie wymagajce, co programowanie w metodykach tradycyjnych. W obszarze behawioralnym
wymogi s nawet duo wiksze. Na przykład narzuca si członkom zespołu do du dyscyplin,
a postpy 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 biorcych udział w pracach, cyt. „powyĪej 12 osób Agile przestaje byü
lekką metodyką, a staje siĊ metodyką chaotyczną”. [24]
Podsumowujc, metodyki „zwinne” musz ugruntowa si w sferze praktyki. Przedsiwzicia
informatyczne na wielk skal, dotyczce duych, złoonych systemów (rozwijanych
i modyfikowanych przez wiele lat) wymagaj takiej metodyki prowadzenia projektu, która
precyzyjnie odzwierciedli i okreli kady element procesu wytwarzania oprogramowania (jak np.
metodyka RUP). Stosowanie formalnej (twardej) metodyki w takim przypadku jest konieczne
włanie ze wzgldu na skal i potencjalny czas trwania projektu. Ma ona za zadanie zapewni
bezpieczestwo przedsiwzicia oraz osignicie zamierzonych celów. Mona sdzi z duym
prawdopodobiestwem, e w niedalekiej przyszłoci poziom profesjonalizmu wzronie wród
zwolenników metodyk lekkich. Podołaj oni wielkim przedsiwziciom pod warunkiem zapewnienia wysokiego poziomu kontroli prac nad projektem w kadym momencie jego trwania, nie tracc
nic na „zwinnoci” działania.
3. Analiza porównawcza narzĊdzi CASE wspomagających UML
Jzyk UML posiada spore wsparcie w postaci narzdzi CASE [25], które zapewniaj wspomaganie w modelowaniu i tworzeniu poprawnej dokumentacji projektowej. Wspieranie kadej
z faz tego procesu jest inne i wymaga zastosowania rónych funkcji. Sporód ich całej gamy warto
wyodrbni te najwaniejsze, które wiadcz o zaawansowaniu danego narzdzia CASE i zapewnieniu odpowiedniego poziomu kontroli spełnianych w projekcie wymaga uytkownika. Do
takich funkcji nale: słownik danych (repozytorium metadanych wraz z systemem zarzdzajcym), 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łoonoci oraz powiza elementów projektu), generatory raportów i dokumentacji technicznej,
generatory kodu ródłowego, moduł projektowania interfejsu uytkownika, moduł inynierii
zwrotnej (moliwo odtworzenia słownika danych lub diagramów na podstawie kodu ródłowego
lub struktury bazy danych), moduł importu i eksportu danych oraz moduł zarzdzania prac
grupow. [26, 27]
Wprowadzenie wersji 2.0 jzyka UML sprawiło konieczno rozbudowy narzdzi CASE.
Obecnie duo programów wspiera t wersj, istnieje jednak spora cz rozwiza zwłaszcza
niekomercyjnych, która pozostała w standardzie UML 1.4. Starsza wersja UML zawiera 8 diagramów oraz 2 nieoficjalne (diagram pakietów oraz obiektów) dołczane do niektórych narzdzi
CASE. UML 2.0 oferuje dodatkowo diagram struktur połczonych, przebiegów czasowych
23
(harmonogramowania) i przegldu 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
Nazwa
skrócona
UML 1.4
UML 2.0
1 use case diagram - diagram przypadków uĪycia
ud
+
+
2 class diagram - diagram klas (diagram struktury statycznej)
cld
+
Lp.
3
4
Typy diagramów
package diagram - diagram pakietów
)
* czasami dostĊpny i uĪywany nieoficjalnie w UML 1.4
object diagram - diagram obiektów
)
* czasami dostĊpny i uĪywany nieoficjalnie w UML 1.4
pd
ob
+
nieoficjalny
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
+
9
state machine diagram - diagram maszyny stanowej
)
** nazwa w UML 1.4: statechart diagram - daigram stanów
10 sequence diagram - diagram sekwencji (przebiegu)
11
communication diagram - diagram komunikacji
)
*** nazwa w UML 1.4: collaboration diagram - diagram współdziałania
timing diagram - diagram przebiegów czasowych
12
(harmonogramowania)
interaction overview diagram - diagram przeglądu interakcji
13
(sterowania interakcją)
SUMA ILOĝCI DIAGRAMÓW
+
(
sm
+ **
+
sd
+
+
(
cd
+ ***
+
td
−
+
iod
−
+
8
13
ródło: Opracowanie własne na podstawie [1])
Do porównania zakwalifikowano dostpne i rozpowszechnione w rodowisku lokalnym (akademickim) rozwizania. Sporód komercyjnych narzdzi CASE wybrano: Enterprise Architect,
Poseidon for UML, Rational Software Architect, Microsoft Visio, czy Visual Paradigm for UML.
Popularne niekomercyjne narzdzia typu open source to miedzy innymi: AgroUML, StarUML oraz
UMLet. Poniej zaprezentowano ich krótkie charakterystyki. Analogiczn list narzdzi 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 jzyka UML w wersji 2.0 (13 typów diagramu). Dostpny jest w 5 wersjach:
Desktop, Professional, Corporate, Viewer oraz w wersji testowej. W dystrybucji dostpna 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. Narzdzie to jest napisane w jzyku Java, co daje pełn niezaleno od
platformy systemowej. Dostpny jest w 4 wersjach: Community Edition, Standard Edition,
Professional Edition oraz Embedded Edition (trzy ostatnie dostpne s równie w 30-dniowych
wersjach testowych).
24
Jarosław Becker
w notacji UML 2.0
Narzdzie 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 moliwo
ujcia schematów zwikszajcych przewidywalno procesu modelowania aplikacji. Dla narzdzia
Rational Software Architect Standard Edition dostpne s trzy licencje: dla autoryzowanego
uytkownika, licencja sieciowa oraz wersja testowa trial.
Microsoft Visio (wersja 2007) [31] jest programem ogólnego zastosowania słucym do tworzenia schematów rónego typu, midzy innymi oferuje moliwo opracowania 9 diagramów
w notacji UML 2.0.
Tabela 2. Porównanie narzĊdzi CASE – cz. 1
Poseidon for UML
wersja 6.0.2
Rational Software
Architect wersja 7.5.1
Microsoft Visio
wersja 2007
Visual Paradigm for UML
wersja 6.3
ArgoUML
wersja 0.26
StarUML
wersja 5.0.2
UMLet
wersja 9.03
2.0
2.0
2.0
2.0
2.0
1.4
2.0
1.4
-
ud
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
−
−
+
+
+
+
+
+
+
−
−
+
+
+
−
−
+
+
+
+
+
+
−
−
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
−
−
−
−
+
+
+
+
+
−
−
+
+
−
−
+
+
+
+
+
+
+
−
−
+
+
−
−
−
−
+
+
+
+
−
−
−
8
iod
+
+
+
+
+
+
+
+
+
+
+
+
+
SUMA
13
13
9
9
13
7
9
6
Platforma
MS Windows
Mac OS
+
−
−
+
+
+
+
+
−
+
−
−
+
+
+
+
+
+
+
−
−
+
+
+
SUMA
1
3
2
1
3
3
1
3
Cobra IDL
SQL
−
+
+
+
+
+
+
+
−
+
+
+
+
+
+
−
+
+
+
+
−
−
+
−
−
−
+
+
+
+
+
+
+
−
+
−
−
+
+
+
+
+
−
−
+
liczba innych jĊzyków
3
3
1
−
+
+
−
−
−
+
+
−
−
7
3
−
+
+
−
+
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
SUMA
10
11
5
4
14
9
3
0
Cobra IDL
−
−
−
−
+
−
−
−
−
−
+
+
−
+
−
−
−
1
−
+
+
−
−
−
+
+
−
+
+
−
−
+
+
−
−
liczba innych jĊzyków
−
+
+
+
+
+
+
+
−
2
−
+
+
−
+
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
SUMA
7
1
4
4
6
3
0
0
Kryterium porównania
cld
pd
ob
Diagramy
csd
cod
dd
ad
sm
sd
cd
td
Linux
C++
C#
Delphi
Java
PHP
Visual Basic (VB)
VB.NET
InĪynieria zwrotna
C++
C#
Delphi
Java
PHP
Visual Basic (VB)
VB.NET
ródło: Opracowanie własne na podstawie [28-35].
SUMA
Enterprise Architect
wersja 7.1
wersja UML
Generowanie kodu Ĩródłowego
NarzĊdzia CASE
8
4
3
5
6
8
8
8
8
7
3
3
8
5
4
3
7
6
4
6
4
2
4
3
−
1
5
4
1
5
2
2
2
−
25
Tabela 3. Porównanie narzĊdzi CASE – cz. 2
Standard eksportu diagramów
Standard
eksportowanych danych
+
−
−
−
+
+
−
−
+
−
−
+
2
3
3
+
+
−
−
−
−
−
−
−
−
SUMA
3
3
0
3
5
5
2
0
XMI / XML
+
−
+
−
+
−
−
−
+
+
−
+
+
−
−
+
−
−
+
−
−
−
+
−
−
−
−
−
−
−
PDF
CSV
liczba innych formatów
1
2
SUMA
2
1
3
2
3
1
1
0
EPS
+
+
+
+
+
+
+
−
+
−
−
+
+
+
+
−
+
−
+
−
−
−
−
−
−
−
−
−
+
1
−
−
+
+
+
−
−
+
+
−
+
+
−
+
+
−
−
−
−
−
+
+
+
−
+
+
+
−
−
1
−
−
+
−
−
+
+
+
−
−
+
−
+
−
+
−
−
−
+
−
SUMA
6
8
6
2
5
5
4
4
GIF
JPG
PNG
SVG
WMF
BMP
EMF
PDF
SUMA
Rational Software
Poseidon for UML
wersja 6.0.2
1
UMLet
wersja 9.03
−
−
−
−
−
StarUML
wersja 5.0.2
Java - pliki JAR
−
+
−
+
ArgoUML
wersja 0.26
CSV
+
−
+
+
−
wersja 6.3
XMI / XML
Rational Rose - MDL
Microsoft Visio
wersja 2007
Standard
importowanych
danych
wersja 7.1
NarzĊdzia CASE
5
3
1
3
−
7
2
1
−
3
4
6
5
5
3
4
3
5
−
ródło: Opracowanie własne na podstawie [28-35].
Visual Paradigm for UML (wersja 6.3) [32] jest jednym z najbardziej rozbudowanych programów. Narzdzie to nie tylko wspiera proces modelowania systemów, ale umoliwia równie
przeprowadzanie inynierii odwrotnej, generowanie kodu, a take synchronizacj modelu i
dokumentacji. Visual Paradigm wystpuje w wersjach: Enterprise, Standard, Professional,
Modeler, Personal, Community (do uytku niekomercyjnego) oraz Viewer (tylko do podgldu).
Narzdzia 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 ronych diagramów. Funkcjonalno tego programu mona rozszerza instalujc dodatki (tzw.
wtyczki) dostpne na odpowiedniej stronie internetowej. StarUML umoliwia 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 moliwych wariantów (lub działa) {A1, A2, ..., Am} oraz zbiór kryteriów
{C1, C2, ..., Cn}, z których kade dotyczy preferencji wyboru okrelonego wariantu. Zadaniem
analizy jest otrzymanie rankingu wariantów na podstawie podanych kryteriów.
26
Jarosław Becker
w notacji UML 2.0
Wyniki szczegółowego porównania narzdzi CASE zestawiono w tabeli 2 i 3. Stanowi one
opracowanie własne, którego dokonano na podstawie informacji zawartych na stronach internetowych producentów oraz w elektronicznej dokumentacji dołczonej do udostpnionych wersji
(pełnych, testowych lub demonstracyjnych) oprogramowania. W celu kompletnego wyraenia
kryteriów czstkowych w postaci wartoci liczbowych ich wybór zdeterminowano dostpnoci
danych. Oceny systemów podsumowujce kad kategori (kryterium główne) wyraono za
pomoc piciopunktowej (0-5) skali. Kryteriom nadano odpowiednie wartoci preferencji (wagi).
W podsumowaniu dla kadego systemu obliczono sum i redni waon ocen punktowych,
których wartoci odwzorowuj zajte miejsce w rankingu (tab. 4).
Pierwsz kategori analizy porównawczej wybranych narzdzi CASE jest moliwo odwzorowania 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 nieduych systemów informatycznych czsto wystarcza minimalna
liczba diagramów dostpna w programie UMLet. S to najczciej uywane diagramy, stanowi
rdze omawianych metodyk. Z punktu widzenia potrzeb naukowego podejcia do udokumentowania prac projektowo-badawczych nad generatorem SWD – którego wyjcie stanowi wyspecjalizowane 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
wersja 7.1
Poseidon for UML
wersja 6.0.2
Rational Software
Microsoft Visio
wersja 2007
wersja 6.3
ArgoUML
wersja 0.26
StarUML
wersja 5.0.2
UMLet
wersja 9.03
WAGA (preferencja
do kryterium)
NarzĊdzia CASE
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
−
3
5
0,5
3
0
−
Zakres wspomagania
diagramów
KompatybilnoĞü platform
systemowych
liczba diagramów
3
5
4
3
5
5
Generowanie kodu
Ĩródłowego
liczba zgodnych jĊzyków
10
11
5
4
14
9
4,5
5
4
3,5
5
4
3,5
0
1
7
1
4
4
6
3
0
0
−
InĪynieria zwrotna
Importowanie danych
Eksportowanie danych
Eksportowanie diagramów
liczba zgodnych jĊzyków
5
3
4
4
4,5
3,5
0
0
1
liczba formatów
3
3
0
3
5
5
2
0
−
0,6
3,5
3
0
3
5
5
3
0
liczba formatów
2
1
3
2
3
1
1
0
−
4
3
5
3,5
5
3
3
0
0,6
liczba formatów
6
8
6
2
5
5
4
4
−
4,5
5
4,5
1
4
4
2
2
0,3
Suma waĪona ocen punktowych
21,85
20,6
18,35
17,2
24,2
19
13,2
5,6
−
ĝrednia waĪona ocen punktowych (0-5)
4,37
4,12
3,67
3,44
4,84
3,8
2,64
1,12
5
POZYCJA W RANKINGU
2
3
5
6
1
4
7
8
ródło: Opracowanie własne.
27
Na kolejne kryterium decyzyjne wybrano dostpno wersji oprogramowania zorientowanych
na róne platformy systemowe (systemy operacyjne). W przypadku wszystkich analizowanych
rozwiza wspieranie systemów Windows mona uzna za powszechn praktyk (tab. 2). Do
popularn platform jest take Linux. Z powodu wieloletniej dominacji systemów Windows
upowszechnionych w rodowisku decydenta, wymóg ten oceniono wysoko przyznajc 3 pkt
(pozostałe po 1 pkt). Z kolei, aby dostpno innych wersji (Linux, Mac OS) nie odgrywała w
rankingu zbyt duej roli przyznano temu kryterium nisk warto współczynnika wagowego, równ
0,5 (tab. 4).
Innymi bardzo wanymi aspektami wspomagania inynierii systemów informatycznych jest,
po pierwsze, moliwo generowania szkieletowego kodu ródłowego oraz, po drugie, zdolno do
utworzenia bd modyfikacji modelu systemu na podstawie kodu ródłowego aplikacji (tzw.
inynieria zwrotna). Połczenie tych dwóch funkcji zyskało miano inynierii wahadłowej (ang.
round-trip engineering) i umoliwia zachowanie spójnoci kodu systemu wzgldem 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 middleout. Głównym aspektem tego podejcia, w odrónieniu od idei top-down i buttom-up, jest skupienie uwagi na szybkim opracowaniu prototypu systemu, nastpnie jego rozbudowie, dołczaniu
nowych funkcji lub procedur do momentu wytworzenia kształtu systemu stabilnego, dajcego si
przenosi. Funkcja inynierii zwrotnej w takim podejciu zwalnia nas z nanoszenia poprawek
w dokumentacji projektowej po czstych zmianach w kodzie systemu. Na etapie zastosowania
generatora systemów informatycznych, szczególnie cenna wydaje si moliwo przekształcania
kodu ródłowego wygenerowanych rónych od siebie systemów na posta modelow. Moliwoci
analizowanych rozwiza CASE w omawianym zakresie przedstawia tabela 2. Wida wyranie, e
liczba wspieranych standardów (jzyków programowania i in.) dla danego narzdzia w zakresie
generowania kodu ródłowego jest nieco wiksza ni w inynierii zwrotnej.
Nastpn bran pod uwag w rankingu funkcj narzdzi CASE s moliwoci importowania
oraz eksportowania plików danych, którym przyznano mniej ni przecitn warto preferencji
(współczynniki wagowe = 0,6; tab. 4), z uwagi na mniejsz przydatno w stosunku do powyej
omówionych kryteriów. Dominujcym formatem wymiany danych jest XMI/XML, za wyjtkiem
programu UMLet oraz czciowo Rational Software Architect, który pozbawiony jest funkcji
importu plików. Liderem pod wzgldem dwukierunkowej wymiany danych jest Visual Paradigm.
Równie rozwinit funkcj importowania ma program ArgoUML. Interesujcy 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 diagramó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 duo programów do konwersji formatu plików graficznych, a w systemach operacyjnych
moliwo 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 moe zdziwi, uzyskał Microsoft Visio 2007
(tab. 4).
28
Jarosław Becker
w notacji UML 2.0
4. Podsumowanie i prezentacja wyników
Obliczone sumy waone ocen punktowych, zamieszczone w tabeli 4, odwzorowuj zajte
miejsce w rankingu. Wyniki te uporzdkowano w cigu malejcym i zaprezentowano na wykresie 1. Na podium (trzy pierwsze pozycje) znalazły si rozwizania komercyjne. Zaskoczeniem jest
bardzo wysoka lokata (4 miejsce) narzdzia ArgoUML nalecego do kategorii open source, co
wie si m. in. z całkowitym brakiem opłat licencyjnych. Najgorzej wypadł program UMLet
zdobywajc jedynie 5,6 pkt., czyli ponad czterokrotnie mniej ni faworyt. Mona uzna go za
prosty program graficzny do rysowania diagramów UML.
25,0
24,2
21,9
20,6
19,0
20,0
18,4
17,2
15,0
13,2
liczba
punktów
10,0
5,6
5,0
0,0
Visual
Paradigm
for UML
(w .6.3)
Enterprise
Architect
(w .7.1)
Poseidon
for UML
(w .6.0.2)
ArgoUML
(w .0.26)
Rational
Softw are
Architect
(w .7.5.1)
Microsoft
Visio 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.
Analizujc wyniki rankingu wyraone w postaci rednich ocen waonych, mieszczcych si
w przyjtej skali punktowej od 0 do 5 pkt., mona podj prób podziału narzdzi i wyodrbnienia
ich kilku klas, które róni si stopniem zaawansowania funkcjonalnego. Wokół oceny 4,5 pkt.
skupiaj si trzy programy zajmujce czołowe miejsca rankingu. Jest to klasa rozwiza ponadprzecitnych skierowana do profesjonalistów. Systemy zajmujce kolejne trzy pozycje w rankingu
(ArgoUML, Rational Software Architect i Microsoft Visio 2007) oscyluj blisko oceny 3,5 pkt.
i mona je okreli mianem rozwiza przecitnych, spełniajcych ogólnie przyjte standardy
modelowania. Poniej oceny przecitnej (około 2,5 pkt.) znajduje si program StarUML, zliczany
do dobrych rozwiza klasy open source. Ostatni i odrbn grup stanowi bardzo prosty program
graficzny UMLet, którego rednia ocena waona jest bliska jednoci.
Uzyskane wyniki rankingu maj charakter subiektywny, mog jednak stanowi pewien punkt
odniesienia dla podobnych tego typu analiz. Ostatecznego wybór mona dokona testujc wszystkie lub wybrane narzdzia CASE. Tym bardziej, e wszyscy producenci programów znajdujcych
si w rankingu udostpnili wersje do nieodpłatnej oceny.
29
Bibliografia
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Wrycza S., Marcinkowski B., Wyrzykowski K., Jzyk UML 2.0 w modelowaniu
systemów informatycznych, Wyd. Helion, Gliwice 2005.
Becker J., Architektura informatycznego systemu generowania wielokryterialnych
rozwiza 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.
Subieta K., Wprowadzenie do obiektowych metodyk projektowania i notacji UML,
Instytut Podstaw Informatyki PAN, Warszawa 1999 (http://www.ipipan.waw.pl/~
subieta).
Wrycza S., Analiza i projektowanie systemów informatycznych zarzdzania, PWN,
Warszawa 1999.
Doliska M., Projektowanie systemów informacyjnych na przykładzie zarzdzania
marketingiem, Wyd. „Placet”, Warszawa 2003.
Kisielnicki J., Sroka H., Systemy informacyjne biznesu, Wyd. „Placet”, Warszawa 2005.
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).
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)
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)
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).
Booch G., Jacobson I., Rumbaugh J., The Unified Software Development Process,
Addison-Wesley, Boston 1998.
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)
Kruchten Philippe, Rational Unified Process od strony teoretycznej, Inynieria
oprogramowania, WNT, Warszawa 2006.
Henderson-Sellers Brian, What is OPEN? (http://www.open.org.au/, Last Updated:
12/5/05).
30
Jarosław Becker
w notacji UML 2.0
15. Mrozek Z., Metodyka RUP i jzyk UMLw projektowaniu inynierskim, „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 inynierii oprogramowania (KKIO V), praca zbiorowa pod
redakcj Zbigniewa Huzara i Zygmunta Mazura, WNT, 2003.
21. Kukliski 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
brany IT, online: „Dzie dobry informatyku”, 04/2008 (http://ddinformatyku.pl/ pdf/042008/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 zarzdzania” zamieszczony w serwisie internetowym Wydziału Zarzdzania
UW, (http://www2.wz.uw.edu.pl/ksiz/download/wch/Cale1.pdf).
27. Bednarczyk M., Fazy instalacji i konserwacji, Narzdzia CASE, Wykład pt. „Inynieria
oprogramowania”, Instytut Matematyki Uniwersytetu Gdaskiego, (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/enus/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 uytkownika
(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 management systems modeling
Jarosław Becker
Katedra Inynierii 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

Transkrypt

Podobne dokumenty

Metodyki, model FURPS, Use Case, Diagram Klas

Koncepcja architektury sterowanej regułami spójności modeli (CMDA)