Wykorzystanie techniki IDEF0 i relacyjnej bazy danych we ...
Wykorzystanie techniki IDEF0 i relacyjnej bazy danych we ...
Wykorzystanie techniki IDEF0 i relacyjnej bazy danych we ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Wykorzystanie</strong> <strong>techniki</strong> <strong>IDEF0</strong> i <strong>relacyjnej</strong> <strong>bazy</strong> <strong>danych</strong><br />
<strong>we</strong> wspomaganiu procesów projektowych<br />
WITOLD MAROWSKI<br />
Wymagania wspó∏czesnego rynku wymuszajà<br />
sta∏à intensyfikacj´ procesów projektowych. No<strong>we</strong><br />
wyroby muszà byç projektowane szybciej i taniej,<br />
a rezultaty prac projektowych nale˝y dostosowywaç<br />
do wymagaƒ konkretnych grup u˝ytkowników. RównoczeÊnie<br />
rozwój technik komputerowych oraz infrastruktury<br />
siecio<strong>we</strong>j o globalnym zasi´gu umo˝liwia<br />
wspó∏prac´ projektantów znajdujàcych si´ w bardzo<br />
odleg∏ych geograficznie miejscach. Procesy projekto<strong>we</strong><br />
majà zatem coraz cz´Êciej charakter rozproszonych<br />
procesów wspó∏bie˝nych, w które zaanga-<br />
˝owane sà zarówno zespo∏y projektantów z firmy<br />
macierzystej, jak i wyspecjalizowani partnerzy zewn´trzni.<br />
Procesy takie muszà byç szczególnie dok∏adnie<br />
planowane, kierowane, dokumentowane i nadzorowane,<br />
aby uniknàç niebezpieczeƒstwa utraty spójnoÊci<br />
projektu. W tym celu stosuje si´ odpowiednie<br />
narz´dzia komputero<strong>we</strong>. Przewa˝nie korzystajà<br />
one z relacyjnych baz <strong>danych</strong>, w których przechowywane<br />
sà informacje o stanie zaawansowania realizowanych<br />
procesów projektowych. Budowa takich<br />
narz´dzi wymaga stworzenia modelu procesu projekto<strong>we</strong>go,<br />
który uwzgl´dnia ograniczenia forma-<br />
Dr hab. in˝. Witold Marowski jest pracownikiem Instytutu<br />
Maszyn Roboczych Ci´˝kich Poli<strong>techniki</strong> Warszawskiej.<br />
18<br />
lizmu relacyjnego, a wi´c jest mo˝liwy do odwzorowania<br />
w strukturze logicznej <strong>relacyjnej</strong> <strong>bazy</strong><br />
<strong>danych</strong>.<br />
W niniejszej pracy zaproponowano zastosowanie<br />
do modelowania procesu projekto<strong>we</strong>go <strong>techniki</strong><br />
<strong>IDEF0</strong>. Proces projektowy traktowany jest w tej koncepcji<br />
jako zbiór zadaƒ czàstkowych (kroków) o ró˝nym<br />
zakresie ogólnoÊci. O mo˝liwoÊci wykonania<br />
konkretnego kroku decyduje spe∏nienie warunków<br />
poczàtkowych (dost´pnoÊç wymaganej informacji<br />
<strong>we</strong>jÊcio<strong>we</strong>j oraz zasobów ludzkich i materialnych),<br />
a nie z góry okreÊlone nast´pstwo czaso<strong>we</strong>. Do modelowania<br />
poszczególnych zadaƒ projektowych<br />
wykorzystano kostki <strong>IDEF0</strong>. Przy odwzorowywaniu<br />
elementów procesu projekto<strong>we</strong>go w <strong>relacyjnej</strong> bazie<br />
<strong>danych</strong> po∏o˝ono nacisk na standaryzacj´, tak aby<br />
opisy ró˝nych procesów projektowych by∏y wykonywane<br />
<strong>we</strong>d∏ug tego samego schematu i przy<br />
u˝yciu tej samej terminologii, zachowujàc w ten<br />
sposób porównywalnoÊç. Takie podejÊcie u∏atwia<br />
wykorzystywanie przy pracy nad aktualnym projektem<br />
doÊwiadczeƒ z prac zrealizowanych w przesz∏oÊci.<br />
Przedstawiona koncepcja zosta∏a przetestowana<br />
za pomocà prototypo<strong>we</strong>j aplikacji <strong>relacyjnej</strong> <strong>bazy</strong><br />
<strong>danych</strong> zbudowanej w Êrodowisku programu Microsoft<br />
Access. W pracy omówiono zakres funkcji tej<br />
ROK WYD. LXIX ZESZYT 10/2010
aplikacji, struktur´ jej interfejsu u˝ytkownika oraz<br />
niektóre z zastosowanych rozwiàzaƒ programistycznych.<br />
Model rozproszonego, wspó∏bie˝nego<br />
procesu projekto<strong>we</strong>go<br />
Wspó∏bie˝ny proces projektowy, w trakcie którego<br />
ró˝ne zespo∏y projektantów, cz´sto pozbawione mo˝liwoÊci<br />
bezpoÊredniego kontaktu, pracujà równoczeÊnie<br />
nad poszczególnymi zadaniami, w tym<br />
równie˝ nad konkurencyjnymi rozwiàzaniami tych<br />
samych w´z∏ów konstrukcyjnych produktu, wymaga<br />
Êcis∏ej kontroli poprawnoÊci uzyskiwanych rezultatów<br />
i podejmowanych decyzji. Oprócz tworzenia dokumentacji<br />
projekto<strong>we</strong>j, odwzorowujàcej stany projektu<br />
na kolejnych etapach jego rozwoju, istotne jest<br />
te˝ utrwalenie informacji o wybranych metodach<br />
post´powania i uzasadnieniach podj´tych decyzji,<br />
która tworzy niegraficznà warstw´ opisu projektu,<br />
okreÊlanà terminem design rationale. Jej szczególne<br />
znaczenie dla procesów rozproszonych wià˝e si´ ze<br />
wspomnianym ju˝ brakiem mo˝liwoÊci bezpoÊrednich<br />
kontaktów mi´dzy cz∏onkami zespo∏u projekto<strong>we</strong>go.<br />
Proces projektowy mo˝e byç traktowany jako zbiór<br />
zadaƒ, rozumianych jako grupy czynnoÊci powodujàcych<br />
zmian´ jego aktualnego stanu, przy czym<br />
podzia∏u na zadania mo˝na dokonywaç na ró˝nych<br />
poziomach ogólnoÊci, poczàwszy od zadania najbardziej<br />
ogólnego, jakim jest wykonanie ca∏oÊci projektu<br />
wyrobu, a koƒczàc na zadaniach elementarnych.<br />
Dla procesu projekto<strong>we</strong>go, podobnie jak dla<br />
ka˝dego przedsi´wzi´cia realizowanego w okreÊlonych<br />
ramach organizacyjnych, tworzony jest<br />
wprawdzie harmonogram czasowy, ale warunkiem<br />
koniecznym rozpocz´cia wykonywania ka˝dego z zadaƒ<br />
jest dost´pnoÊç wymaganej informacji <strong>we</strong>jÊcio<strong>we</strong>j<br />
oraz zasobów ludzkich i materialnych. Rzeczywisty<br />
przebieg procesu okreÊlajà zatem relacje<br />
wyjÊcie-<strong>we</strong>jÊcie (w szczególnoÊci relacje informacyjne),<br />
a nie relacje czaso<strong>we</strong>, co jest zgodne z szeregiem<br />
postulatów ju˝ od dawna formu∏owanych<br />
w literaturze przedmiotu (np. [1]). Takie podejÊcie jest<br />
te˝ realizowane w systemach zbudowanych zgodnie<br />
z zasadami architektury tablico<strong>we</strong>j (np. [2]).<br />
Model procesu projekto<strong>we</strong>go powinien umo˝liwiaç<br />
przechowywanie w <strong>relacyjnej</strong> bazie <strong>danych</strong> wszystkich<br />
informacji odnoszàcych si´ do struktury produktu<br />
oraz przebiegu i rezultatów procesu projekto<strong>we</strong>go,<br />
a tak˝e zwiàzywanie ich z poszczególnymi<br />
zadaniami projektowymi. Jego budowa polega na<br />
zdefiniowaniu encji niezb´dnych do opisu procesu<br />
projekto<strong>we</strong>go, okreÊleniu dla ka˝dej z nich zbioru<br />
atrybutów oraz zidentyfikowaniu zale˝noÊci informacyjnych<br />
(zwiàzków) mi´dzy poszczególnymi<br />
encjami. W wyniku otrzymuje si´ diagram zwiàzków<br />
encji, który obrazuje zale˝noÊci informacyjne<br />
pomi´dzy poszczególnymi elementami modelu<br />
i który jest podstawà do budowy struktury logicznej<br />
<strong>bazy</strong> <strong>danych</strong>, z∏o˝onej z tabel i zwiàzków pozwalajàcych<br />
na prawid∏o<strong>we</strong> kojarzenie ze sobà <strong>danych</strong><br />
zawartych w ró˝nych tabelach. Bli˝sze informacje<br />
na temat metod tworzenia relacyjnych modeli systemów<br />
rzeczywistych mo˝na znaleêç w licznych<br />
pracach dotyczàcych zastosowaƒ relacyjnych baz<br />
<strong>danych</strong>, np. w [3].<br />
Modele procesów projektowych przeznaczone do<br />
stosowania w aplikacjach relacyjnych baz <strong>danych</strong><br />
mogà mieç ró˝ny charakter. Przeglàd stosowanych<br />
rozwiàzaƒ mo˝na znaleêç w pracy [4]. W pracy tej<br />
opisano tak˝e model, którego podstawowymi elementami<br />
by∏y sieciowa struktura operacji procesu<br />
projekto<strong>we</strong>go oraz hierarchiczne struktury komponentów<br />
produktu i dokumentów projektowych. Model<br />
proponowany w niniejszej pracy jest natomiast tworzony<br />
wokó∏ pojedynczego zadania projekto<strong>we</strong>go<br />
w taki sposób, aby mo˝li<strong>we</strong> by∏o sformu∏owanie warunków<br />
koniecznych jego rozpocz´cia (dost´pnoÊç<br />
wymaganych zasobów informacyjnych, ludzkich i materialnych),<br />
zdefiniowanie e<strong>we</strong>ntualnych ograniczeƒ<br />
oraz zapisanie uzyskanych efektów. KolejnoÊç poszczególnych<br />
zadaƒ jest okreÊlana jedynie poÊrednio<br />
– jako ˝àdany poziom dost´pnoÊci informacji wyjÊcio<strong>we</strong>j<br />
z innych zadaƒ, niezb´dnej do przystàpienia do<br />
wykonywania danego zadania, czyli odpowiedni<br />
stopieƒ zaawansowania zadaƒ w logicznym sensie<br />
poprzedzajàcych dane zadanie projekto<strong>we</strong>.<br />
W omawianym modelu hierarchicznà struktur´<br />
<strong>we</strong>rsji komponentów produktu definiuje si´ przez<br />
okreÊlenie dla ka˝dej z nich (z wyjàtkiem <strong>we</strong>rsji cz´Êci<br />
elementarnych) zbioru komponentów sk∏adowych.<br />
Odnoszàce si´ do sposobu i motywacji post´powania<br />
projektantów zapisy design rationale mogà byç<br />
przypisywane do zadaƒ projektowych traktowanych<br />
jako ca∏oÊç lub do dokonywanych w ich trakcie<br />
zmian definicji <strong>we</strong>rsji komponentów produktu. Ka˝dy<br />
z takich zapisów mo˝e byç zwiàzany z pewnym zbiorem<br />
ograniczeƒ, a ponadto mo˝na do niego do∏àczyç<br />
zestaw s∏ów kluczowych, pochodzàcych z ich predefiniowanego<br />
zbioru. Zestawy s∏ów kluczowych<br />
mogà byç definiowane równie˝ dla <strong>we</strong>rsji dokumentów<br />
projektowych. Mo˝na tak˝e okreÊlaç powiàzania<br />
mi´dzy <strong>we</strong>rsjami dokumentów projektowych<br />
i <strong>we</strong>rsjami komponentów produktu. Pe∏ny opis proponowanego<br />
modelu procesu projekto<strong>we</strong>go mo˝na<br />
znaleêç w pracy [5].<br />
W dalszym ciàgu niniejszej pracy zostanie dok∏adniej<br />
omówione poj´cie zadania projekto<strong>we</strong>go, majàce<br />
kluczo<strong>we</strong> znaczenie dla tego podejÊcia, które zamodelowano<br />
jako tzw. kostk´ <strong>IDEF0</strong>. Omówienie to zostanie<br />
poprzedzone przeglàdem podstawowych koncepcji<br />
tej <strong>techniki</strong> modelowania.<br />
Podstawo<strong>we</strong> koncepcje <strong>techniki</strong> <strong>IDEF0</strong><br />
Technika <strong>IDEF0</strong> mo˝e byç stosowana do modelowania<br />
decyzji, dzia∏aƒ i aktywnoÊci pewnej organizacji,<br />
procesu lub systemu [6]. Stanowi ona pierwszy<br />
element ogólniejszego zbioru metod tworzenia<br />
zintegrowanych definicji systemów in˝ynierskich,<br />
co t∏umaczy jej nazw´ (IDEF – Integrated DEFinition)<br />
oraz oznaczenie cyfro<strong>we</strong>. Narzuca ona Êcis∏à metodologi´<br />
analizy oraz odwzorowywania graficznego<br />
funkcji procesów lub systemów, które sà przedmiotem<br />
rozwa˝aƒ, uj´tà w normie wydanej w roku 1993<br />
przez amerykaƒski National Institute of Standards<br />
and Technology [7]. Kluczowy charakter dla <strong>techniki</strong><br />
<strong>IDEF0</strong> ma poj´cie kostki <strong>IDEF0</strong>, zwanej tak˝e blokiem<br />
ICOM, która reprezentuje funkcj´ modelowanego<br />
procesu. Skrót ICOM pochodzi od okreÊlenia warunków<br />
uruchomienia i wyników dzia∏ania tej funkcji<br />
(Input – <strong>we</strong>jÊcie, Control – sterowanie, Output –<br />
wyjÊcie oraz Mechanism – zasoby lub/i narz´dzia).<br />
ROK WYD. LXIX ZESZYT 10/2010 19
Dekompozycja procesu na funkcje pozwala na okreÊlenie<br />
wspó∏zale˝noÊci poszczególnych funkcji takiego<br />
zbioru w kategoriach informacji wymaganej (<strong>we</strong>jÊcio<strong>we</strong>j)<br />
i tworzonej (wyjÊcio<strong>we</strong>j). Dla ka˝dej funkcji<br />
mo˝na ponadto okreÊliç konieczne zasoby ludzkie<br />
i materialne, a tak˝e ró˝nego rodzaju ograniczenia<br />
wp∏ywajàce na sposób jej realizacji. Technika <strong>IDEF0</strong><br />
nie pozwala natomiast na modelowanie nast´pstw<br />
czasowych. Ogólnà postaç kostki <strong>IDEF0</strong> pokazano na<br />
rys. 1.<br />
Rys. 1. Reprezentacja funkcji procesu przy u˝yciu kostki <strong>IDEF0</strong><br />
Kostka <strong>IDEF0</strong> jest opatrywana nazwà i do∏àczonym<br />
do niej numerem, których konkatenacja tworzy jej<br />
etykiet´. Kostki reprezentujàce poszczególne funkcje<br />
modelowanego procesu mogà byç ∏àczone za pomocà<br />
strza∏ek o postaciach okreÊlonych w normie [7],<br />
co pozwala na wykonywanie diagramów ujmujàcych<br />
w przejrzysty sposób zale˝noÊci mi´dzy tymi<br />
funkcjami. Mo˝li<strong>we</strong> jest uzyskiwanie ró˝nej szczegó∏owoÊci<br />
opisu procesu, do czego wykorzystuje si´<br />
hierarchicznà struktur´ kostek <strong>IDEF0</strong>. Ka˝da funkcja<br />
procesu mo˝e bowiem byç przedstawiona za pomocà<br />
hierarchii kostek, rozpoczynajàcej si´ od pojedynczej<br />
kostki, symbolizujàcej syntetyczne uj´cie tej funkcji.<br />
Ni˝sze poziomy hierarchii odpowiadajà rosnàcej<br />
szczegó∏owoÊci opisu, przy czym zejÊcie na kolejny,<br />
bardziej szczegó∏owy poziom jest dokonywane dla<br />
konkretnej kostki poziomu bezpoÊrednio wy˝szego,<br />
co odpowiada dekompozycji reprezentowanej przez<br />
nià funkcji procesu na funkcje sk∏ado<strong>we</strong>. Poziom<br />
szczegó∏owoÊci opisu funkcji procesu mo˝na odczytaç<br />
z etykiety reprezentujàcej jà kostki <strong>IDEF0</strong>. Ciàgi<br />
znako<strong>we</strong> tworzàce etykiety kostek najwy˝szego poziomu,<br />
odpowiadajàcych syntetycznemu uj´ciu<br />
funkcji, koƒczà si´ zawsze cyfrà 0 (np. A0). Etykiety<br />
kostek poziomu bezpoÊrednio ni˝szego tworzone sà<br />
przez odrzucenie z etykiety poprzednio wzmiankowanej<br />
kostki koƒco<strong>we</strong>go zera i zastàpieniu go innà<br />
pojedynczà cyfrà, np. A1, A2 itd. Norma [7] dopuszcza<br />
na poziomie bezpoÊrednio ni˝szym jedynie szeÊç<br />
kostek podporzàdkowanych danej kostce wy˝szego<br />
poziomu, tj. u˝ycie cyfr od 1 do 6, jednak stosowana<br />
kon<strong>we</strong>ncja nazewnicza pozwala na tworzenie na<br />
ka˝dym poziomie dziewi´ciu kostek przypisanych<br />
danemu rodzicowi (cyfry od 1 do 9). Etykiety kostek<br />
z kolejnych ni˝szych poziomów tworzy si´ przez<br />
uzupe∏nienie etykiety rodzica nast´pnà pojedynczà<br />
cyfrà (np. kostki podporzàdkowane kostce A2 majà<br />
etykiety A21, A22 itd.). W ten sposób etykieta ka˝dej<br />
kostki jednoznacznie okreÊla jej miejsce w hie-<br />
20<br />
rarchii. ¸atwo te˝ stworzyç algorytmy pozwalajàce<br />
na generowanie etykiet kostek podporzàdkowanych<br />
danej kostce, innych kostek na tym samym poziomie<br />
szczegó∏owoÊci opisu lub kostek po∏o˝onych wzd∏u˝<br />
Êcie˝ki ∏àczàcej danà kostk´ z kostkà najwy˝szego<br />
poziomu.<br />
Z przytoczonego opisu wynika, i˝ kostka <strong>IDEF0</strong><br />
mo˝e byç z powodzeniem zastosowana jako reprezentacja<br />
zadania projekto<strong>we</strong>go. Mo˝na zatem u˝yç tej<br />
<strong>techniki</strong> przy tworzeniu zbudowanego wokó∏ zadania<br />
projekto<strong>we</strong>go modelu rozproszonego procesu projekto<strong>we</strong>go,<br />
w trakcie realizacji którego szczególne<br />
znaczenie ma kontrola kompletnoÊci i poprawnoÊci<br />
informacji <strong>we</strong>jÊciowych dla poszczególnych zadaƒ.<br />
Zale˝noÊci informacyjne, reprezentowane w klasycznym<br />
modelu <strong>IDEF0</strong> przez strza∏ki, w modelu wykonanym<br />
zgodnie z wymogami formalizmu relacyjnego<br />
mogà byç odwzorowywane przy u˝yciu kluczy<br />
obcych odwo∏ujàcych si´ do swoich rodziców. Taki<br />
sposób zamodelowania zadania projekto<strong>we</strong>go zostanie<br />
opisany w dalszym ciàgu pracy.<br />
Kostka <strong>IDEF0</strong> jako model<br />
zadania projekto<strong>we</strong>go<br />
Powiàzania zadaƒ procesu projekto<strong>we</strong>go powinny<br />
byç definiowane za poÊrednict<strong>we</strong>m relacji wyjÊcie-<br />
-<strong>we</strong>jÊcie, która jest relacjà informacyjnà, a nie przez<br />
relacje czaso<strong>we</strong>. Warunkiem przystàpienia do wykonywania<br />
konkretnego zadania projekto<strong>we</strong>go jest<br />
dost´pnoÊç koniecznej informacji <strong>we</strong>jÊcio<strong>we</strong>j oraz<br />
zasobów ludzkich i materialnych. Prace wykonywane<br />
w ramach zadania muszà uwzgl´dniaç obowiàzujàce<br />
ograniczenia, które okreÊlajà zbiory rozwiàzaƒ<br />
dopuszczalnych przy podejmowaniu kolejnych decyzji.<br />
Zadanie, zmieniajàc stan procesu projekto<strong>we</strong>go,<br />
tworzy pewnà informacj´ wyjÊciowà. Wszystkie<br />
wymienione elementy mo˝na zinterpretowaç jako<br />
<strong>we</strong>jÊcie, zasoby, sterowanie i wyjÊcie w schemacie<br />
kostki <strong>IDEF0</strong> pokazanym na rys. 1. Zatem kostka <strong>IDEF0</strong><br />
mo˝e byç traktowana jako odpowiedni formalizm<br />
modelowania zadania projekto<strong>we</strong>go. Ogólny schemat<br />
kostki <strong>IDEF0</strong> reprezentujàcej zadanie projekto<strong>we</strong><br />
pokazano na rys. 2.<br />
Jak widaç ze schematu z rys. 2, dost´pnoÊç wymaganej<br />
informacji wyjÊcio<strong>we</strong>j jest okreÊlana przez<br />
stan zaawansowania innych zadaƒ projektowych.<br />
PodejÊcie takie jest charakterystyczne dla wspó∏bie˝nych<br />
procesów projektowych, kiedy to czasowa<br />
Rys. 2. Kostka <strong>IDEF0</strong> reprezentujàca zadanie projekto<strong>we</strong><br />
ROK WYD. LXIX ZESZYT 10/2010
ównoleg∏oÊç realizacji ró˝nych etapów rozwoju projektu<br />
mo˝e prowadziç do sytuacji, w której informacj´<br />
<strong>we</strong>jÊciowà dla pewnego zadania mogà stanowiç<br />
cele, które planuje si´ osiàgnàç w innym aktualnie<br />
realizowanym zadaniu. W takim wypadku nale˝y<br />
oczywiÊcie dokonaç <strong>we</strong>ryfikacji poprawnoÊci uczynionych<br />
za∏o˝eƒ po zakoƒczeniu tego zadania.<br />
Bardzo istotnà cechà <strong>techniki</strong> <strong>IDEF0</strong> jest omówiona<br />
wczeÊniej mo˝liwoÊç zbudowania hierarchicznej struktury<br />
kostek reprezentujàcych pewnà funkcj´ procesu.<br />
Umo˝liwia to tworzenie definicji zadaƒ projektowych<br />
o ró˝nym poziomie ogólnoÊci i dokonywanie<br />
dekompozycji zadaƒ uj´tych w sposób ogólniejszy na<br />
bardziej szczegó∏o<strong>we</strong> zadania czàstko<strong>we</strong>, nale˝àce<br />
do hierarchicznie ni˝szych poziomów opisu procesu<br />
projekto<strong>we</strong>go. Warto zauwa˝yç, i˝ najogólniejsze uj´cie<br />
mo˝e polegaç na potraktowaniu ca∏ego projektu<br />
jako pojedynczego zadania, dekomponowanego<br />
nast´pnie na zadania odpowiadajàce dzia∏aniom<br />
wykonywanym w procesie rozwoju projektu. Dzia∏ania<br />
takie mogà mieç zarówno charakter ÊciÊle techniczny,<br />
jak i wià˝àcy si´ np. z zarzàdzaniem projektem<br />
lub jego finansowaniem. Schemat dekompozycji<br />
zadania projekto<strong>we</strong>go na zadania o wy˝szych<br />
stopniach szczegó∏owoÊci pokazano na rys. 3.<br />
Rys. 3. Dekompozycja zadania projekto<strong>we</strong>go na zadania<br />
czàstko<strong>we</strong><br />
Wykonanie zadania projekto<strong>we</strong>go powoduje na<br />
ogó∏ powstanie nowych zasobów informacji projekto<strong>we</strong>j,<br />
które sà traktowane jako wielkoÊci wyjÊcio<strong>we</strong><br />
(efekty) tego zadania. Wynikajàca stàd zmiana<br />
dotychczaso<strong>we</strong>j definicji produktu mo˝e polegaç na<br />
zdefiniowaniu no<strong>we</strong>go komponentu i równoczesnym<br />
utworzeniu jego pierwszej <strong>we</strong>rsji, utworzeniu na podstawie<br />
jednej z ju˝ istniejàcych (niekoniecznie ostatniej)<br />
<strong>we</strong>rsji pewnego komponentu produktu jego<br />
no<strong>we</strong>j <strong>we</strong>rsji lub wprowadzeniu zmian do definicji<br />
istniejàcej <strong>we</strong>rsji komponentu. Wyniki zadania sà<br />
przechowywane w nowo utworzonych lub zmodyfikowanych<br />
w tym zadaniu <strong>we</strong>rsjach dokumentów<br />
projektowych oraz zapisach wyjaÊniajàcych sposób<br />
post´powania lub/i zawierajàcych motywacje podejmowanych<br />
decyzji. Schemat struktury informacji<br />
wyjÊcio<strong>we</strong>j, która mo˝e byç efektem wykonania zadania<br />
projekto<strong>we</strong>go, pokazano na rys. 4.<br />
Warto zauwa˝yç, i˝ miejsce danego zadania w hierarchii<br />
wszystkich zadaƒ procesu projekto<strong>we</strong>go jest<br />
jednoznacznie okreÊlone przez wartoÊç etykiety tego<br />
zadania, utworzonej zgodnie z regu∏ami sk∏adni etykiet<br />
kostek <strong>IDEF0</strong> i przechowywanej w jednym z jego<br />
atrybutów. Z uwagi na tak du˝e znaczenie tego atrybutu,<br />
jego wartoÊci powinny byç generowane przez<br />
kod aplikacji <strong>bazy</strong> <strong>danych</strong> u˝ywanej do wspomagania<br />
realizacji procesu projekto<strong>we</strong>go, a zdefiniowanie<br />
jednoznacznego indeksu na kolumnach iden-<br />
Rys. 4. Struktura informacji wyjÊcio<strong>we</strong>j zadania projekto<strong>we</strong>go<br />
tyfikatora projektu i etykiety zadania powinno dodatkowo<br />
gwarantowaç zachowanie unikatowoÊci etykiet<br />
zadaƒ w obr´bie danego projektu. Stosowanie etykiet<br />
zadaƒ projektowych budowanych zgodnie z zasadami<br />
<strong>techniki</strong> <strong>IDEF0</strong> bardzo u∏atwia wyszukiwanie<br />
w bazie <strong>danych</strong>, przy u˝yciu tworzonych w kodzie<br />
aplikacji k<strong>we</strong>rend SQL, informacji o podzbiorach zadaƒ<br />
danego projektu. Warunki wyszukiwania takich<br />
k<strong>we</strong>rend formu∏uje si´ dla etykiet zadaƒ projektowych<br />
i zawierajà one jako wartoÊci odniesienia wzorce<br />
ciàgów znakowych, które ∏atwo okreÊliç dla etykiet<br />
niektórych podzbiorów zadaƒ. Na przyk∏ad, etykiety<br />
wszystkich zadaƒ bezpoÊrednio hierarchicznie podporzàdkowanych<br />
zadaniu o etykiecie A14 sà zbudowane<br />
zgodnie z szablonem A14?, gdzie znak zapytania<br />
zast´puje dowolny pojedynczy znak na koƒcu<br />
etykiety. Z kolei wzorcem etykiet zadaƒ nale˝àcych<br />
do ga∏´zi drzewa hierarchii rozpoczynajàcej si´ od<br />
kostki o etykiecie A14 jest ciàg A14*, w którym<br />
gwiazdka oznacza dowolny ciàg znakowy o niezero<strong>we</strong>j<br />
d∏ugoÊci.<br />
Trzeba podkreÊliç, i˝ traktowanie procesu projekto<strong>we</strong>go<br />
jako zbioru zadaƒ nie pociàga za sobà<br />
koniecznoÊci okreÊlenia ich ustalonej sek<strong>we</strong>ncji, czyli<br />
nie jest równoznaczne z ograniczeniem si´ do rozpatrywania<br />
procesów o charakterze sek<strong>we</strong>ncyjnym,<br />
gdy˝ o przystàpieniu do wykonywania ka˝dego<br />
z zadaƒ decyduje wy∏àcznie dost´pnoÊç informacji<br />
<strong>we</strong>jÊcio<strong>we</strong>j oraz niezb´dnych zasobów, co czyni<br />
mo˝liwym równoleg∏e wykonywanie zadaƒ niekolidujàcych<br />
pod tym wzgl´dem ze sobà. Stosowanie<br />
kostek <strong>IDEF0</strong> jako graficznej reprezentacji zadaƒ<br />
sprzyja prawid∏o<strong>we</strong>mu rozumieniu tego aspektu<br />
proponowanego modelu procesu projekto<strong>we</strong>go.<br />
Aplikacja <strong>bazy</strong> <strong>danych</strong><br />
do wspomagania procesów projektowych<br />
Przedstawiony model procesu projekto<strong>we</strong>go zosta∏<br />
wykorzystany przy budowie aplikacji <strong>relacyjnej</strong><br />
<strong>bazy</strong> <strong>danych</strong> przeznaczonej do wspomagania procesów<br />
projektowych. Zasadniczym celem by∏o przetestowanie<br />
poprawnoÊci i przydatnoÊci modelu,<br />
zatem aplikacja mog∏a zostaç wykonana przy u˝yciu<br />
stosunkowo prostego narz´dzia, jakim jest Microsoft<br />
Access. Wykorzystano przy tym mo˝liwoÊci dostarczane<br />
bezpoÊrednio przez to Êrodowisko, takie jak<br />
tworzenie k<strong>we</strong>rend przechowywanych w bazie da-<br />
ROK WYD. LXIX ZESZYT 10/2010 21
nych (tak˝e parametrycznych) oraz formularzy i raportów<br />
zwiàzanych ze êród∏ami <strong>danych</strong>, rozszerzajàc<br />
je w miar´ potrzeby przy u˝yciu kodu napisanego<br />
w j´zyku Visual Basic z zastosowaniem obiektów<br />
dost´pu do <strong>danych</strong>.<br />
Wspomaganie procesu projekto<strong>we</strong>go przy u˝yciu<br />
omawianej aplikacji polega w pierwszym rz´dzie na<br />
stworzeniu mo˝liwoÊci rejestrowania i monitorowania<br />
jego aktualnego stanu, ze szczególnym uwzgl´dnieniem<br />
wszelkiego rodzaju elementów informacji<br />
tworzonych lub modyfikowanych w trakcie wykonywania<br />
zadaƒ projektowych. Aplikacja umo˝liwia<br />
tak˝e traktowanie przechowywanych w jej bazie<br />
<strong>danych</strong> zasobów informacji o procesach projektowych<br />
realizowanych w przesz∏oÊci jako pewnego<br />
rodzaju <strong>bazy</strong> wiedzy, która mo˝e byç wykorzystywana<br />
np. przy rozwiàzywaniu aktualnych zadaƒ projektowych<br />
lub w pracach polegajàcych na uogólnianiu<br />
zebranych doÊwiadczeƒ. Dost´pne sà w tym celu<br />
elastyczne mechanizmy przeszukiwania <strong>bazy</strong> <strong>danych</strong>,<br />
od strony programistycznej oparte na k<strong>we</strong>rendach<br />
SQL budowanych w kodzie programu zale˝nie od<br />
aktualnego kontekstu pracy aplikacji.<br />
Interfejs u˝ytkownika aplikacji jest systemem<br />
wzajemnie powiàzanych formularzy, które zosta∏y<br />
zaprojektowane w taki sposób, aby mo˝li<strong>we</strong> by∏o<br />
definiowanie wszystkich elementów wchodzàcych<br />
w sk∏ad modelu procesu projekto<strong>we</strong>go oraz Êledzenie<br />
przebiegu realizacji tego procesu. Schemat<br />
struktury interfejsu, z którego mo˝na tak˝e odczytaç<br />
struktur´ modelu procesu projekto<strong>we</strong>go oraz powiàzania<br />
pomi´dzy jej poszczególnymi elementami,<br />
zosta∏ pokazany na rys. 5. Umieszczone na nim<br />
prostokàty symbolizujà formularze, przy czym prostokàty<br />
narysowane linià przerywanà i znajdujàce si´<br />
<strong>we</strong>wnàtrz innych prostokàtów, z bokami w postaci<br />
Rys. 5. Struktura interfejsu u˝ytkownika aplikacji<br />
22<br />
linii ciàg∏ych, odpowiadajà podformularzom, tzn.<br />
formularzom osadzonym w innych formularzach,<br />
zwanych formularzami g∏ównymi. Je˝eli formularz<br />
g∏ówny i podformularz sà zwiàzane ze êród∏ami<br />
<strong>danych</strong> po∏àczonymi ze sobà zwiàzkiem typu jeden do<br />
wielu (przy czym êród∏o ze strony jeden musi byç<br />
powiàzane z formularzem g∏ównym, zaÊ êród∏o ze<br />
strony wiele – z podformularzem), to wówczas na<br />
podformularzu prezentowane sà jedynie te rekordy<br />
<strong>danych</strong>, które odpowiadajà aktualnemu rekordowi<br />
<strong>danych</strong> formularza g∏ównego. Powiàzanie takie jest<br />
realizowane przez zwiàzek klucza obcego z jego<br />
rodzicem definiowany przy tworzeniu struktury logicznej<br />
<strong>bazy</strong> <strong>danych</strong>.<br />
Na formularzach s∏u˝àcych do Êledzenia hierarchii<br />
komponentów produktu i historii rozwoju konkretnego<br />
komponentu znajdujà si´ formanty TreeView,<br />
pokazane na schemacie z rys. 5. Prezentujà one<br />
zale˝noÊci hierarchiczne w postaci rozwijalnych<br />
drzew, podobnych do drzewa folderów w eksploratorze<br />
Êrodowiska Windows, z∏o˝onych z w´z∏ów<br />
reprezentujàcych elementy hierarchii. W´z∏y struktury<br />
hierarchicznej prezentowanej w formancie<br />
TreeView definiuje si´ w kodzie aplikacji jako obiekty<br />
typu Node b´dàce elementami kolekcji w´z∏ów<br />
(kolekcji Nodes) takiego formantu. Formant TreeView<br />
znajduje si´ w zbiorze formantów ActiveX zawartych<br />
w bibliotece COMCTL32.OCX, instalowanej w folderze<br />
System lub System32 Êrodowiska Windows.<br />
Sposoby jego wykorzystywania, w∏aÊciwoÊci, metody<br />
oraz wchodzàca w sk∏ad jego definicji kolekcja Nodes,<br />
sà omówione w plikach pomocy comctl1.hlp lub<br />
comctl2.hlp, natomiast wyczerpujàce informacje na<br />
temat algorytmów pozwalajàcych na przedstawienie<br />
w takim formancie zale˝noÊci hierarchicznych<br />
w zbiorach elementów modelu procesu projekto<strong>we</strong>go<br />
mo˝na znaleêç np. w pracach [4 i 5].<br />
Linie ze strza∏kami umieszczone na schemacie<br />
z rys. 5 pokazujà zasadnicze Êcie˝ki poruszania si´<br />
w zbiorze formularzy interfejsu u˝ytkownika. Nie<br />
wyczerpujà one oczywiÊcie wszystkich dost´pnych<br />
mo˝liwoÊci. Jak widaç, korzystanie z aplikacji nale˝y<br />
rozpoczàç od zdefiniowania no<strong>we</strong>go projektu lub<br />
odszukania w∏aÊci<strong>we</strong>j pozycji w zbiorze projektów<br />
przechowywanych w bazie <strong>danych</strong>. Nast´pnie mo˝na<br />
przejÊç do definiowania lub udost´pniania <strong>danych</strong><br />
dotyczàcych wybranego projektu. Formularze interfejsu<br />
u˝ytkownika aplikacji mo˝na najogólniej podzieliç<br />
na formularze przeznaczone do definiowania<br />
elementów opisu procesu projekto<strong>we</strong>go, formularze,<br />
których zasadniczym przeznaczeniem jest<br />
analiza aktualnego stanu takiego procesu oraz formularze<br />
przeznaczone do operowania s∏ownikami<br />
standaryzowanych terminów u˝ywanych przy definiowaniu<br />
elementów opisu procesu projekto<strong>we</strong>go.<br />
Ta ostatnia grupa jest reprezentowana na rys. 5<br />
przez pojedynczy prostokàt opatrzony etykietà S∏owniki.<br />
W sk∏ad grupy drugiej wchodzà formularze<br />
Historia rozwoju komponentu i Hierarchia komponentów<br />
produktu, a tak˝e majàcy du˝e znaczenie przy<br />
korzystaniu z mo˝liwoÊci stwarzanych przez aplikacj´<br />
formularz prezentujàcy zadanie projekto<strong>we</strong> w postaci<br />
zbli˝onej do schematu kostki <strong>IDEF0</strong>. Pozosta∏e formularze<br />
mo˝na zaliczyç do grupy pierwszej.<br />
Formularze grupy pierwszej zosta∏y zaprojektowane<br />
jako klasyczne formularze Êrodowiska Microsoft<br />
ROK WYD. LXIX ZESZYT 10/2010
Access, zwiàzane ze êród∏ami <strong>danych</strong> w postaci tabel.<br />
Dla pól kluczy obcych zastosowano w nich formanty<br />
pola kombi (listy rozwijalne), dla których êród∏ami<br />
wierszy sà k<strong>we</strong>rendy zapisane w bazie <strong>danych</strong> i pobierajàce<br />
dane z tabel rodziców odpowiednich kluczy<br />
obcych. Pozwala to na ukrycie numerycznych wartoÊci<br />
kluczy obcych, które nie sà zwiàzane z ich znaczeniem<br />
i wynikajà wy∏àcznie z okreÊlanych automatycznie<br />
przez system zarzàdzajàcy bazà <strong>danych</strong> wartoÊci kluczy<br />
g∏ównych b´dàcych ich rodzicami. Zamiast nich<br />
w polach kombi pokazywane sà alfanumeryczne<br />
etykiety wskazujàce na rzeczywisty sens wybieranej<br />
wartoÊci. Na formularzach tej grupy cz´sto stosowany<br />
jest tak˝e formant typu karta, zw∏aszcza gdy danemu<br />
elementowi opisu procesu projekto<strong>we</strong>go mo˝e byç<br />
przyporzàdkowane wiele ró˝nych elementów innych<br />
rodzajów, i w zwiàzku z tym konieczne jest u˝ycie<br />
wielu podformularzy. Zastosowanie formantu karta<br />
pozwala rozmieÊciç je na kilku ró˝nych stronach, co<br />
zwi´ksza powierzchni´ przeznaczonà na wpisywanie<br />
lub wyÊwietlanie <strong>danych</strong>, a tak˝e umo˝liwia u˝ytkownikowi<br />
skoncentrowanie si´ w danej chwili na<br />
pewnym wycinku definicji elementu opisu procesu<br />
projekto<strong>we</strong>go. Formularzami, na których zastosowano<br />
w tym celu formant karty, sà m.in. formularze definicji<br />
<strong>we</strong>rsji komponentu, definicji zadania projekto<strong>we</strong>go<br />
oraz <strong>we</strong>rsji dokumentu projekto<strong>we</strong>go. W charakterze<br />
przyk∏adu na rys. 6 pokazano formularz definiowania<br />
zadania projekto<strong>we</strong>go, na którym widoczna<br />
jest karta z podformularzem pozwalajàcym na wprowadzenie<br />
do <strong>bazy</strong> <strong>danych</strong> informacji o nowych dokumentach<br />
projektowych utworzonych w tym zadaniu.<br />
Warto zwróciç uwag´ na przycisk Wygeneruj<br />
umieszczony w górnej cz´Êci formularza z rys. 6. Powoduje<br />
on wyÊwietlenie formularza pozwalajàcego<br />
na automatyczne wygenerowanie etykiety zadania<br />
projekto<strong>we</strong>go zgodnej ze sk∏adnià ustalonà przez<br />
standard <strong>IDEF0</strong>. Niezb´dne jest w tym celu okreÊlenie<br />
zadania nadrz´dnego w stosunku do zadania, dla<br />
którego zamierza si´ wygenerowaç etykiet´. Hierarchia<br />
zadaƒ du˝ego projektu mo˝e byç doÊç z∏o˝ona,<br />
dlatego te˝ istotne jest zastosowanie jasnej, intuicyjnej<br />
<strong>techniki</strong> wyboru takiego zadania. W omawianej<br />
aplikacji wykorzystano w tym celu hierarchiczny cha-<br />
Rys. 6. Formularz definiowania zadania projekto<strong>we</strong>go – na<br />
podformularzu jest widoczna karta nowych dokumentów<br />
projektowych<br />
rakter zbioru zadaƒ procesu projekto<strong>we</strong>go, w którym<br />
zadaniem rozpoczynajàcym drzewo hierarchii jest<br />
projekt, traktowany jako ca∏oÊç, i mo˝liwoÊç przejrzystego<br />
zaprezentowania tej hierarchii w formancie<br />
TreeView. Takie drzewo hierarchii, pozwalajàce na rozwijanie<br />
jedynie tych ga∏´zi, które odpowiadajà aktualnie<br />
analizowanemu przypadkowi, pozwala na ∏atwy<br />
wybór w∏aÊci<strong>we</strong>go zadania nadrz´dnego. Zaprojektowany<br />
zgodnie z tà koncepcjà formularz generatora<br />
etykiet zadaƒ projektowych pokazano na rys. 7.<br />
Rys. 7. Formularz generatora etykiet zadaƒ projektowych<br />
Nadawanie zadaniom projektowym etykiet zgodnych<br />
ze standardem <strong>IDEF0</strong> pozwala na zastosowanie<br />
w kodzie aplikacji bardzo prostej procedury wype∏niania<br />
kolekcji w´z∏ów formantu TreeView. W pierwszym<br />
kroku wype∏nia si´ t´ kolekcj´ w´z∏ami<br />
wszystkich ju˝ zdefiniowanych zadaƒ w taki sposób,<br />
jakby ka˝dy z nich mia∏ rozpoczynaç no<strong>we</strong> drzewo<br />
hierarchii, przy czym etykiety zadaƒ pe∏nià rol´<br />
kluczy elementów tej kolekcji. W drugim kroku okreÊlana<br />
jest wartoÊç w∏aÊciwoÊci Parent ka˝dego z elementów<br />
kolekcji, której nale˝y przypisaç odwo∏anie<br />
obiekto<strong>we</strong> do w´z∏a bezpoÊrednio hierarchicznie<br />
nadrz´dnego (tzw. rodzica). W´ze∏ taki mo˝na odnaleêç<br />
przez odwo∏anie si´ do elementu kolekcji Nodes<br />
opatrzonego kluczem o odpowiedniej wartoÊci, którà<br />
uzyskuje si´ przez odrzucenie ostatniej cyfry z etykiety<br />
(a zarazem klucza) aktualnego w´z∏a lub przez zastàpienie<br />
tej cyfry cyfrà 0 (dla w´z∏ów bezpoÊrednio<br />
podporzàdkowanych w´z∏owi reprezentujàcemu projekt<br />
jako ca∏oÊç). Dla rozpoczynajàcego hierarchi´<br />
w´z∏a projektu wartoÊç w∏aÊciwoÊci Parent pozostaje<br />
oczywiÊcie pusta.<br />
Do drugiej grupy formularzy interfejsu aplikacji,<br />
przeznaczonych przede wszystkim do analizowania<br />
i nadzorowania aktualnego stanu rozwoju projektu,<br />
nale˝y m.in. formularz pokazany na rys. 8, prezentujàcy<br />
w formancie TreeView hierarchicznà struktur´<br />
komponentów produktu, a w formancie listy<br />
– histori´ rozwoju komponentu odpowiadajàcego<br />
zaznaczonemu w´z∏owi drzewa hierarchii.<br />
Formant TreeView, umieszczony po le<strong>we</strong>j stronie<br />
formularza, zawiera w´z∏y, których etykiety z∏o˝one<br />
sà ze skróto<strong>we</strong>j nazwy komponentu produktu, numeru<br />
jego <strong>we</strong>rsji oraz podanej w nawiasie liczby sztuk<br />
danego komponentu wchodzàcych w sk∏ad odpowiedniego<br />
komponentu nadrz´dnego. Z uwagi na<br />
zupe∏nie inny ni˝ w wypadku zadaƒ projektowych<br />
ROK WYD. LXIX ZESZYT 10/2010 23
Rys. 8. Formularz prezentujàcy hierarchi´ komponentów produktu<br />
i histori´ rozwoju wybranego komponentu<br />
sposób definiowania zale˝noÊci hierarchicznych<br />
w zbiorze <strong>we</strong>rsji komponentów produktu (dla ka˝dego<br />
elementu takiego zbioru definiuje si´ zbiór jego<br />
komponentów sk∏adowych), do wype∏niania kolekcji<br />
w´z∏ów formantu TreeView nale˝a∏o zastosowaç inny,<br />
znacznie bardziej z∏o˝ony algorytm, uwzgl´dniajàcy<br />
mo˝liwoÊç <strong>we</strong>jÊcia danej <strong>we</strong>rsji komponentu w sk∏ad<br />
kilku ró˝nych komponentów nadrz´dnych. Wykorzystuje<br />
on k<strong>we</strong>rend´ parametrycznà oraz zwracany<br />
przez nià zestaw rekordów zawierajàcy dane <strong>we</strong>rsji<br />
komponentów produktu utworzonych w trakcie danego<br />
projektu. Dok∏adny opis tego algorytmu, ze<br />
wzgl´du na jego rozmiary, wykracza poza ramy niniejszej<br />
pracy. Mo˝na go znaleêç w [5], w tym miejscu<br />
warto jedynie nadmieniç, i˝ ma on charakter iteracyjny<br />
i wykorzystuje dwa formanty TreeView – widoczny<br />
i niewidoczny – oraz ich kolekcje w´z∏ów.<br />
Pierwszym krokiem algorytmu jest, identycznie jak<br />
dla zadaƒ projektowych, utworzenie elementów<br />
kolekcji Nodes bez okreÊlania ich rodziców. Tak zdefiniowana<br />
kolekcja jest przeszukiwana za pomocà<br />
zagnie˝d˝onych instrukcji cyklu. P´tla zewn´trzna<br />
przebiega kolejno przez wszystkie jej w´z∏y, zaÊ p´tla<br />
<strong>we</strong>wn´trzna przeszukuje dla ka˝dego z nich t´ samà<br />
kolekcj´ Nodes, odnajdujàc w´z∏y, których rodzicem<br />
móg∏by byç aktualny w´ze∏ p´tli zewn´trznej. Je˝eli<br />
odnalezione w´z∏y nie majà jeszcze zdefiniowanych<br />
rodziców – zostajà przypisane do tego w´z∏a jako<br />
bezpoÊrednio nadrz´dnego elementu hierarchii. O ile<br />
nie istnieje taka <strong>we</strong>rsja komponentu produktu, która<br />
wchodzi w sk∏ad wi´cej ni˝ jednego komponentu<br />
nadrz´dnego, to wówczas pojedyncze wykonanie<br />
p´tli zewn´trznej wystarcza do kompletnego zdefiniowania<br />
hierarchicznej struktury <strong>we</strong>rsji komponentów<br />
produktu. Je˝eli ten warunek nie jest spe∏niony,<br />
to w p´tlach <strong>we</strong>wn´trznych sà odnajdywane<br />
w´z∏y, które powinny byç przypisane do aktualnego<br />
w´z∏a p´tli zewn´trznej, ale majà ju˝ innych rodziców,<br />
okreÊlonych <strong>we</strong> wczeÊniejszych krokach algorytmu.<br />
W ka˝dym z takich wypadków, zamiast definiowania<br />
rodzica w´z∏a z p´tli <strong>we</strong>wn´trznej,<br />
tworzony jest dodatkowy w´ze∏ reprezentujàcy t´<br />
samà <strong>we</strong>rsj´ komponentu produktu. W´ze∏ ten,<br />
któremu na razie nie przypisuje si´ ˝adnego w´z∏a<br />
nadrz´dnego, jest umieszczany w kolekcji Nodes<br />
niewidocznego formantu TreeView, gdy˝ zawartoÊç<br />
kolekcji formantu widocznego nie mo˝e byç modyfikowana<br />
w trakcie jej przeglàdania. Formant<br />
niewidoczny pe∏ni wi´c rol´ bufora przechowujàcego<br />
obiekty typu Node. Po zakoƒczeniu ka˝dej iteracji<br />
(czyli po kompletnym wykonaniu zewn´trznej in-<br />
24<br />
strukcji cyklu) wszystkie dodatko<strong>we</strong> w´z∏y, które<br />
zosta∏y utworzone w jej trakcie w niewidocznym<br />
formancie TreeView, sà kopiowane do formantu<br />
widocznego, aby w kolejnej iteracji mog∏y im zostaç<br />
przypisane ich w´z∏y nadrz´dne (rodzice). Procedura<br />
ta jest powtarzana do momentu, w którym kolejna<br />
iteracja nie tworzy ju˝ dodatkowych w´z∏ów w niewidocznym<br />
formancie TreeView.<br />
Histori´ rozwoju tej <strong>we</strong>rsji komponentu produktu,<br />
którà reprezentuje zaznaczony w´ze∏ drzewa hierarchii<br />
wyÊwietlanego w formancie TreeView, zawiera lista<br />
umieszczona po pra<strong>we</strong>j stronie formularza z rys. 8.<br />
Do jej wype∏nienia wykorzystuje si´ w kodzie aplikacji<br />
k<strong>we</strong>rend´, której parametrem jest identyfikator<br />
<strong>we</strong>rsji komponentu. Mo˝na go odczytaç z w∏aÊciwoÊci<br />
Tag zaznaczonego w´z∏a, w której umieszcza go procedura<br />
wype∏niajàca kolekcj´ Nodes. K<strong>we</strong>renda<br />
parametryczna mo˝e wówczas zwróciç identyfikator<br />
oraz inne dane <strong>we</strong>rsji komponentu, która by∏a podstawà<br />
do utworzenia <strong>we</strong>rsji zaznaczonej w formancie<br />
TreeView (nie musi byç to <strong>we</strong>rsja o bezpoÊrednio<br />
ni˝szym numerze). Dane te zostanà wprowadzone do<br />
w∏aÊciwoÊci êród∏o wiersza formantu listy (typem<br />
êród∏a wiersza dla takiej listy musi byç lista wartoÊci),<br />
zaÊ identyfikator <strong>we</strong>rsji jest dodatkowo wykorzystywany<br />
jako parametr przy kolejnym uruchomieniu<br />
k<strong>we</strong>rendy, które stanowi prób´ odnalezienia <strong>we</strong>rsji<br />
b´dàcej punktem wyjÊcia dla <strong>we</strong>rsji odszukanej<br />
w poprzednim kroku. W ten sposób budowany jest<br />
ciàg znakowy w∏aÊciwoÊci êród∏o wiersza pola listy,<br />
a post´powanie koƒczy si´ w momencie, gdy k<strong>we</strong>renda<br />
zwróci pusty zestaw rekordów.<br />
Formularzem omawianej grupy, który jest najÊciÊlej<br />
zwiàzany z przyj´tà koncepcjà budowy modelu procesu<br />
projekto<strong>we</strong>go, koncentrujàcego si´ na zadaniach<br />
projektowych reprezentowanych przez kostki <strong>IDEF0</strong>,<br />
jest formularz warunków poczàtkowych i efektów<br />
zadania projekto<strong>we</strong>go pokazany na rys. 9 i 10. Tak˝e<br />
w jego projekcie zastosowano formant karta, którego<br />
pierwsza strona (rys. 9) mieÊci pola z listami warunków<br />
poczàtkowych, zasobów i ograniczeƒ dla<br />
zadania, a druga (rys. 10) – listy efektów wykonania<br />
Rys. 9. Karta warunków wykonania zadania na formularzu prezentacji<br />
zadania projekto<strong>we</strong>go<br />
zadania. Oprócz tego formularz zawiera narz´dzia<br />
umo˝liwiajàce nawigacj´ po zbiorze zadaƒ procesu<br />
projekto<strong>we</strong>go. Na karcie efektów zadania umieszczono<br />
te˝ przyciski pozwalajàce na przechodzenie<br />
do formularzy umo˝liwiajàcych oglàdanie, edycj´<br />
lub tworzenie definicji <strong>we</strong>rsji komponentów produktu<br />
lub dokumentów projektowych, a tak˝e odczy-<br />
ROK WYD. LXIX ZESZYT 10/2010
tywanie lub redagowanie zapisów motywacji post´powania.<br />
Formularz z rys. 9 i 10 mo˝e prezentowaç informacje<br />
dotyczàce jedynie wybranego zadania, tego<br />
zadania i zadaƒ mu hierarchicznie bezpoÊrednio<br />
lub poÊrednio podporzàdkowanych, tego zadania<br />
i zadaƒ po∏o˝onych wzd∏u˝ Êcie˝ki ∏àczàcej je z zadaniem<br />
najwy˝szego poziomu, reprezentujàcym<br />
ca∏oÊç projektu, a tak˝e wszystkich zadaƒ spe∏niajàcych<br />
jeden z dwóch poprzednich warunków.<br />
Do wype∏niania list umieszczonych na formularzu,<br />
Rys. 10. Karta efektów wykonania zadania na formularzu prezentacji<br />
zadania projekto<strong>we</strong>go<br />
w wypadku informacji ograniczajàcej si´ jedynie do<br />
wybranego zadania, wykorzystywane sà k<strong>we</strong>rendy<br />
parametryczne przechowywane w bazie <strong>danych</strong>,<br />
natomiast w pozosta∏ych wypadkach k<strong>we</strong>rendy êród-<br />
∏o<strong>we</strong> dla list sà tworzone w kodzie aplikacji przy u˝yciu<br />
warunków wyszukiwania budowanych na podstawie<br />
regu∏ sk∏adni etykiet zadaƒ projektowych<br />
wynikajàcych ze standardu <strong>IDEF0</strong>.<br />
Jak widaç, omawiany formularz mo˝e stanowiç<br />
zasadnicze narz´dzie analizowania i nadzorowania<br />
przebiegu procesu projekto<strong>we</strong>go. Jego uk∏ad graficzny<br />
celowo nawiàzuje do schematu kostki <strong>IDEF0</strong>. Pozwala<br />
on na Êledzenie powiàzaƒ informacyjnych mi´dzy<br />
poszczególnymi zadaniami, a tak˝e umo˝liwia<br />
przechodzenie do formularzy zawierajàcych pe∏ne definicje<br />
pozycji zaznaczonych na listach, równie˝ w celu<br />
ich modyfikacji lub dodawania nowych elementów.<br />
Trzecia grupa formularzy, umo˝liwiajàcych dost´p<br />
do zasobów s∏ownikowych, czyli list standaryzowanych<br />
terminów przechowywanych w bazie <strong>danych</strong>,<br />
sk∏ada si´ z prostych formularzy, zwiàzanych ze êród-<br />
∏ami <strong>danych</strong> i zaprojektowanych na ogó∏ jako formularze<br />
ciàg∏e, tj. wyÊwietlajàcych w oknie wiele<br />
rekordów <strong>danych</strong>, do których mo˝na uzyskiwaç<br />
szybki dost´p przy u˝yciu piono<strong>we</strong>go paska przewijania.<br />
U˝ytkownik aplikacji mo˝e wyÊwietliç wybrany<br />
formularz s∏ownikowy za poÊrednict<strong>we</strong>m formularza<br />
sterujàcego pokazanego na rys. 11.<br />
Jak widaç z rys. 11, zasoby s∏owniko<strong>we</strong> mo˝na podzieliç<br />
na kilka grup dotyczàcych pokrewnych zagadnieƒ.<br />
Po zakoƒczeniu pracy ze s∏ownikami nast´puje<br />
powrót do formularza projektów. Warto jednak<br />
nadmieniç, i˝ niektóre s∏owniki sà dost´pne tak˝e<br />
z poziomu innych formularzy odwo∏ujàcych si´ do<br />
ich zawartoÊci, co jest widoczne np. na formularzu<br />
pokazanym na rys. 6. Umieszczony w jego górnej<br />
cz´Êci (tj. na formularzu g∏ównym) przycisk Nowy<br />
udost´pnia s∏ownik statusów zadaƒ projektowych.<br />
Rys. 11. Formularz sterujàcy dost´pem do formularzy s∏ownikowych<br />
Uwagi koƒco<strong>we</strong><br />
W niniejszej pracy przedstawiono koncepcj´ budowy<br />
modelu procesu projekto<strong>we</strong>go, w którym do<br />
opisu zadania projekto<strong>we</strong>go wykorzystano formalizm<br />
kostki <strong>IDEF0</strong>. Model taki pozwala na odwzorowanie<br />
procesu projekto<strong>we</strong>go na ró˝nych poziomach<br />
szczegó∏owoÊci opisu bez przyjmowania istotnych<br />
za∏o˝eƒ dotyczàcych wzajemnego usytuowania jego<br />
zadaƒ sk∏adowych, umo˝liwia przejrzyste Êledzenie<br />
wymaganej informacji <strong>we</strong>jÊcio<strong>we</strong>j, zasobów i ograniczeƒ<br />
zwiàzanych z poszczególnymi zadaniami,<br />
a tak˝e ich efektów. Przyj´te przy jego tworzeniu<br />
za∏o˝enia dotyczàce struktury informacji o procesie<br />
projektowym i wzajemnych powiàzaƒ mi´dzy jej<br />
elementami dajà si´ bez trudnoÊci odwzorowaç przy<br />
u˝yciu formalizmu relacyjnego, co pozwoli∏o na<br />
budow´ wykorzystujàcej ten model aplikacji <strong>bazy</strong><br />
<strong>danych</strong> przeznaczonej do komputero<strong>we</strong>go wspomagania<br />
procesów projektowych. Tak˝e w interfejsie<br />
tej aplikacji mo˝na odwo∏ywaç si´ do odwzorowania<br />
zadania projekto<strong>we</strong>go jako kostki <strong>IDEF0</strong>.<br />
Intuicyjny charakter tej reprezentacji pozwala na<br />
nadanie jednemu z podstawowych formularzy interfejsu<br />
u˝ytkownika postaci bardzo czytelnej i ∏at<strong>we</strong>j<br />
w obs∏udze.<br />
LITERATURA<br />
1. Härtlein N., Negele H., Fricke E.: Process modelling for<br />
integrated product development. Proceedings of the 12th<br />
Intern. Conf. on Engineering Design ICED 99, München,<br />
1999, Vol. 1, pp. 397 – 400.<br />
2. Pokojski J. [red.]: Inteligentne wspomaganie procesu integracji<br />
Êrodowiska do komputerowo wspomaganego projektowania<br />
maszyn. WNT, Warszawa 2000.<br />
3. Riordan R. M.: Projektowanie systemów relacyjnych baz<br />
<strong>danych</strong>. READ ME, Warszawa 2000.<br />
4. Marowski W.: Identyfikacja i aplikacja modeli integracji<br />
<strong>danych</strong> produktu i procesu projekto<strong>we</strong>go w Êrodowisku<br />
<strong>relacyjnej</strong> <strong>bazy</strong> <strong>danych</strong>. WNT, Warszawa 2002.<br />
5. Linkiewicz G., Marowski W., Pokojski J.: Komputero<strong>we</strong><br />
wspomaganie projektowania w Êrodowisku rozproszonym.<br />
WNT, Warszawa 2007.<br />
6. Mayer R. J., Painter M. K., deWitte P. S.: IDEF Family of<br />
Methods for Concurrent Engineering and Business Re-<br />
-engineering Applications. www.idef.com, Knowledge Based<br />
Systems, Inc., 1992.<br />
7. Integration Definition for Function Modelling (<strong>IDEF0</strong>). National<br />
Institute of Standards and Technology, USA,<br />
www.idef.com, 1993.<br />
ROK WYD. LXIX ZESZYT 10/2010 25
Change language