Wykorzystanie techniki IDEF0 i relacyjnej bazy danych we ...

More documents

Recommendations

Info

aplikacji, struktur´ jej interfejsu u˝ytkownika oraz niektóre z zastosowanych rozwiàzaƒ programistycznych. Model rozproszonego, wspó∏bie˝nego procesu projektowego Wspó∏bie˝ny proces projektowy, w trakcie którego ró˝ne zespo∏y projektantów, cz´sto pozbawione mo˝liwoÊci bezpoÊredniego kontaktu, pracujà równoczeÊnie nad poszczególnymi zadaniami, w tym równie˝ nad konkurencyjnymi rozwiàzaniami tych samych w´z∏ów konstrukcyjnych produktu, wymaga Êcis∏ej kontroli poprawnoÊci uzyskiwanych rezultatów i podejmowanych decyzji. Oprócz tworzenia dokumentacji projektowej, odwzorowujàcej stany projektu na kolejnych etapach jego rozwoju, istotne jest te˝ utrwalenie informacji o wybranych metodach post´powania i uzasadnieniach podj´tych decyzji, która tworzy niegraficznà warstw´ opisu projektu, okreÊlanà terminem design rationale. Jej szczególne znaczenie dla procesów rozproszonych wià˝e si´ ze wspomnianym ju˝ brakiem mo˝liwoÊci bezpoÊrednich kontaktów mi´dzy cz∏onkami zespo∏u projektowego. Proces projektowy mo˝e byç traktowany jako zbiór zadaƒ, rozumianych jako grupy czynnoÊci powodujàcych zmian´ jego aktualnego stanu, przy czym podzia∏u na zadania mo˝na dokonywaç na ró˝nych poziomach ogólnoÊci, poczàwszy od zadania najbardziej ogólnego, jakim jest wykonanie ca∏oÊci projektu wyrobu, a koƒczàc na zadaniach elementarnych. Dla procesu projektowego, podobnie jak dla ka˝dego przedsi´wzićia realizowanego w okreÊlonych ramach organizacyjnych, tworzony jest wprawdzie harmonogram czasowy, ale warunkiem koniecznym rozpoczćia wykonywania ka˝dego z zadaƒ jest dost´pnoÊç wymaganej informacji wejÊciowej oraz zasobów ludzkich i materialnych. Rzeczywisty przebieg procesu okreÊlajà zatem relacje wyjÊcie-wejÊcie (w szczególnoÊci relacje informacyjne), a nie relacje czasowe, co jest zgodne z szeregiem postulatów ju˝ od dawna formu∏owanych w literaturze przedmiotu (np. [1]). Takie podejÊcie jest te˝ realizowane w systemach zbudowanych zgodnie z zasadami architektury tablicowej (np. [2]). Model procesu projektowego powinien umo˝liwiaç przechowywanie w relacyjnej bazie danych wszystkich informacji odnoszàcych si´ do struktury produktu oraz przebiegu i rezultatów procesu projektowego, a tak˝e zwiàzywanie ich z poszczególnymi zadaniami projektowymi. Jego budowa polega na zdefiniowaniu encji niezb´dnych do opisu procesu projektowego, okreÊleniu dla ka˝dej z nich zbioru atrybutów oraz zidentyfikowaniu zale˝noÊci informacyjnych (zwiàzków) mi´dzy poszczególnymi encjami. W wyniku otrzymuje si´ diagram zwiàzków encji, który obrazuje zale˝noÊci informacyjne pomi´dzy poszczególnymi elementami modelu i który jest podstawà do budowy struktury logicznej bazy danych, z∏o˝onej z tabel i zwiàzków pozwalajàcych na prawid∏owe kojarzenie ze sobà danych zawartych w ró˝nych tabelach. Bli˝sze informacje na temat metod tworzenia relacyjnych modeli systemów rzeczywistych mo˝na znaleêç w licznych pracach dotyczàcych zastosowaƒ relacyjnych baz danych, np. w [3]. Modele procesów projektowych przeznaczone do stosowania w aplikacjach relacyjnych baz danych mogà mieç ró˝ny charakter. Przeglàd stosowanych rozwiàzaƒ mo˝na znaleêç w pracy [4]. W pracy tej opisano tak˝e model, którego podstawowymi elementami by∏y sieciowa struktura operacji procesu projektowego oraz hierarchiczne struktury komponentów produktu i dokumentów projektowych. Model proponowany w niniejszej pracy jest natomiast tworzony wokó∏ pojedynczego zadania projektowego w taki sposób, aby mo˝liwe by∏o sformu∏owanie warunków koniecznych jego rozpoczćia (dost´pnoÊç wymaganych zasobów informacyjnych, ludzkich i materialnych), zdefiniowanie ewentualnych ograniczeƒ oraz zapisanie uzyskanych efektów. KolejnoÊç poszczególnych zadaƒ jest okreÊlana jedynie poÊrednio – jako ˝àdany poziom dost´pnoÊci informacji wyjÊciowej z innych zadaƒ, niezb´dnej do przystàpienia do wykonywania danego zadania, czyli odpowiedni stopieƒ zaawansowania zadaƒ w logicznym sensie poprzedzajàcych dane zadanie projektowe. W omawianym modelu hierarchicznà struktur´ wersji komponentów produktu definiuje si´ przez okreÊlenie dla ka˝dej z nich (z wyjàtkiem wersji cz´Êci elementarnych) zbioru komponentów sk∏adowych. Odnoszàce si´ do sposobu i motywacji post´powania projektantów zapisy design rationale mogà byç przypisywane do zadaƒ projektowych traktowanych jako ca∏oÊç lub do dokonywanych w ich trakcie zmian definicji wersji komponentów produktu. Ka˝dy z takich zapisów mo˝e byç zwiàzany z pewnym zbiorem ograniczeƒ, a ponadto mo˝na do niego do∏àczyç zestaw s∏ów kluczowych, pochodzàcych z ich predefiniowanego zbioru. Zestawy s∏ów kluczowych mogà byç definiowane równie˝ dla wersji dokumentów projektowych. Mo˝na tak˝e okreÊlaç powiàzania mi´dzy wersjami dokumentów projektowych i wersjami komponentów produktu. Pe∏ny opis proponowanego modelu procesu projektowego mo˝na znaleêç w pracy [5]. W dalszym ciàgu niniejszej pracy zostanie dok∏adniej omówione pojćie zadania projektowego, majàce kluczowe znaczenie dla tego podejÊcia, które zamodelowano jako tzw. kostk´ IDEF0. Omówienie to zostanie poprzedzone przeglàdem podstawowych koncepcji tej techniki modelowania. Podstawowe koncepcje techniki IDEF0 Technika IDEF0 mo˝e byç stosowana do modelowania decyzji, dzia∏aƒ i aktywnoÊci pewnej organizacji, procesu lub systemu [6]. Stanowi ona pierwszy element ogólniejszego zbioru metod tworzenia zintegrowanych definicji systemów in˝ynierskich, co t∏umaczy jej nazw´ (IDEF – Integrated DEFinition) oraz oznaczenie cyfrowe. Narzuca ona Êcis∏à metodologi´ analizy oraz odwzorowywania graficznego funkcji procesów lub systemów, które sà przedmiotem rozwa˝aƒ, uj´tà w normie wydanej w roku 1993 przez amerykaƒski National Institute of Standards and Technology [7]. Kluczowy charakter dla techniki IDEF0 ma pojćie kostki IDEF0, zwanej tak˝e blokiem ICOM, która reprezentuje funkcj´ modelowanego procesu. Skrót ICOM pochodzi od okreÊlenia warunków uruchomienia i wyników dzia∏ania tej funkcji (Input – wejÊcie, Control – sterowanie, Output – wyjÊcie oraz Mechanism – zasoby lub/i narz´dzia). ROK WYD. LXIX ZESZYT 10/2010 19
Dekompozycja procesu na funkcje pozwala na okreÊlenie wspó∏zale˝noÊci poszczególnych funkcji takiego zbioru w kategoriach informacji wymaganej (wejÊciowej) i tworzonej (wyjÊciowej). Dla ka˝dej funkcji mo˝na ponadto okreÊliç konieczne zasoby ludzkie i materialne, a tak˝e ró˝nego rodzaju ograniczenia wp∏ywajàce na sposób jej realizacji. Technika IDEF0 nie pozwala natomiast na modelowanie nast´pstw czasowych. Ogólnà postaç kostki IDEF0 pokazano na rys. 1. Rys. 1. Reprezentacja funkcji procesu przy u˝yciu kostki IDEF0 Kostka IDEF0 jest opatrywana nazwà i do∏àczonym do niej numerem, których konkatenacja tworzy jej etykiet´. Kostki reprezentujàce poszczególne funkcje modelowanego procesu mogà byç ∏àczone za pomocà strza∏ek o postaciach okreÊlonych w normie [7], co pozwala na wykonywanie diagramów ujmujàcych w przejrzysty sposób zale˝noÊci mi´dzy tymi funkcjami. Mo˝liwe jest uzyskiwanie ró˝nej szczegó∏owoÊci opisu procesu, do czego wykorzystuje si´ hierarchicznà struktur´ kostek IDEF0. Ka˝da funkcja procesu mo˝e bowiem byç przedstawiona za pomocà hierarchii kostek, rozpoczynajàcej si´ od pojedynczej kostki, symbolizujàcej syntetyczne ujćie tej funkcji. Ni˝sze poziomy hierarchii odpowiadajà rosnàcej szczegó∏owoÊci opisu, przy czym zejÊcie na kolejny, bardziej szczegó∏owy poziom jest dokonywane dla konkretnej kostki poziomu bezpoÊrednio wy˝szego, co odpowiada dekompozycji reprezentowanej przez nià funkcji procesu na funkcje sk∏adowe. Poziom szczegó∏owoÊci opisu funkcji procesu mo˝na odczytaç z etykiety reprezentujàcej jà kostki IDEF0. Ciàgi znakowe tworzàce etykiety kostek najwy˝szego poziomu, odpowiadajàcych syntetycznemu ujćiu funkcji, koƒczà si´ zawsze cyfrà 0 (np. A0). Etykiety kostek poziomu bezpoÊrednio ni˝szego tworzone sà przez odrzucenie z etykiety poprzednio wzmiankowanej kostki koƒcowego zera i zastàpieniu go innà pojedynczà cyfrà, np. A1, A2 itd. Norma [7] dopuszcza na poziomie bezpoÊrednio ni˝szym jedynie szeÊç kostek podporzàdkowanych danej kostce wy˝szego poziomu, tj. u˝ycie cyfr od 1 do 6, jednak stosowana konwencja nazewnicza pozwala na tworzenie na ka˝dym poziomie dziewićiu kostek przypisanych danemu rodzicowi (cyfry od 1 do 9). Etykiety kostek z kolejnych ni˝szych poziomów tworzy si´ przez uzupe∏nienie etykiety rodzica nast´pnà pojedynczà cyfrà (np. kostki podporzàdkowane kostce A2 majà etykiety A21, A22 itd.). W ten sposób etykieta ka˝dej kostki jednoznacznie okreÊla jej miejsce w hie- 20 rarchii. ¸atwo te˝ stworzyç algorytmy pozwalajàce na generowanie etykiet kostek podporzàdkowanych danej kostce, innych kostek na tym samym poziomie szczegó∏owoÊci opisu lub kostek po∏o˝onych wzd∏u˝ Êcie˝ki ∏àczàcej danà kostk´ z kostkà najwy˝szego poziomu. Z przytoczonego opisu wynika, i˝ kostka IDEF0 mo˝e byç z powodzeniem zastosowana jako reprezentacja zadania projektowego. Mo˝na zatem u˝yç tej techniki przy tworzeniu zbudowanego wokó∏ zadania projektowego modelu rozproszonego procesu projektowego, w trakcie realizacji którego szczególne znaczenie ma kontrola kompletnoÊci i poprawnoÊci informacji wejÊciowych dla poszczególnych zadaƒ. Zale˝noÊci informacyjne, reprezentowane w klasycznym modelu IDEF0 przez strza∏ki, w modelu wykonanym zgodnie z wymogami formalizmu relacyjnego mogà byç odwzorowywane przy u˝yciu kluczy obcych odwo∏ujàcych si´ do swoich rodziców. Taki sposób zamodelowania zadania projektowego zostanie opisany w dalszym ciàgu pracy. Kostka IDEF0 jako model zadania projektowego Powiàzania zadaƒ procesu projektowego powinny byç definiowane za poÊrednictwem relacji wyjÊcie- -wejÊcie, która jest relacjà informacyjnà, a nie przez relacje czasowe. Warunkiem przystàpienia do wykonywania konkretnego zadania projektowego jest dost´pnoÊç koniecznej informacji wejÊciowej oraz zasobów ludzkich i materialnych. Prace wykonywane w ramach zadania muszà uwzgl´dniaç obowiàzujàce ograniczenia, które okreÊlajà zbiory rozwiàzaƒ dopuszczalnych przy podejmowaniu kolejnych decyzji. Zadanie, zmieniajàc stan procesu projektowego, tworzy pewnà informacj´ wyjÊciowà. Wszystkie wymienione elementy mo˝na zinterpretowaç jako wejÊcie, zasoby, sterowanie i wyjÊcie w schemacie kostki IDEF0 pokazanym na rys. 1. Zatem kostka IDEF0 mo˝e byç traktowana jako odpowiedni formalizm modelowania zadania projektowego. Ogólny schemat kostki IDEF0 reprezentujàcej zadanie projektowe pokazano na rys. 2. Jak widaç ze schematu z rys. 2, dost´pnoÊç wymaganej informacji wyjÊciowej jest okreÊlana przez stan zaawansowania innych zadaƒ projektowych. PodejÊcie takie jest charakterystyczne dla wspó∏bie˝nych procesów projektowych, kiedy to czasowa Rys. 2. Kostka IDEF0 reprezentujàca zadanie projektowe ROK WYD. LXIX ZESZYT 10/2010
Page 1: Wykorzystanie techniki IDEF0 i rela
Page 5 and 6: nych (tak˝e parametrycznych) oraz
Page 7 and 8: Rys. 8. Formularz prezentujàcy hie

Wykorzystanie techniki IDEF0 i relacyjnej bazy danych we ...

Create successful ePaper yourself

Delete template?

Save as template?