pobierz plik referatu

Transkrypt

pobierz plik referatu - BDAS

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Rozdział 4
w
w
System monitorowania zgłoszeń, rozszerzeń
i defektów aplikacji WWW, bazujący na mechanizmie
przepływu zadań - Microsoft Workflow Foundation
1 Wstęp
da
.b
w
Streszczenie. Rozdział prezentuje system informatyczny wspomagający
ewidencjonowanie zgłoszeń rozszerzeń oraz defektów, dotyczących
monitorowanej aplikacji WWW. System pozwala na gromadzenie zgłoszeń
oraz śledzenie procesu realizacji zgłoszeń i przebiegu zadań naprawy
defektów aplikacji. W rozwiązaniu zastosowano specyficzny mechanizm
identyfikujący elementy monitorowanych stron WWW, dla których
generowane jest zgłoszenie, pozwalając przez to na łatwą lokalizację tych
elementów podczas późniejszej analizy zgłoszenia. Ze względu na złożoność
oraz w celu zapewnienia możliwości łatwej modyfikacji, proces obsługi
zgłoszeń został zaimplementowany z wykorzystaniem tzw. silnika przepływu
zadań – Microsoft Workflow Foundation. System monitorowania został m.in.
skutecznie użyty do obsługi zgłoszeń związanych z publikacją WWW,
wygenerowaną na podstawie repozytorium opisów procesów wytwórczych,
utworzonych z wykorzystaniem Eclipse Process Framework.
pl
s.
System FeedWeb to intranetowa aplikacja zaimplementowana w technologii .NET 3.0,
która została stworzona w celu usprawnienia obsługi zgłoszeń rozszerzeń oraz defektów do
oprogramowania aplikacyjnego, ze szczególnym uwzględnieniem rozwiązań webowych.
Dodatkowo wymóg definiowania odrębnych ścieżek obsługi zgłoszeń rozszerzeń oraz
defektów dla różnych produktów programowych, spowodował potrzebę stworzenia
rozwiązania umożliwiającego elastyczne definiowanie i obsługę tych ścieżek przez
projektanta lub administratora, co stanowiło przesłankę do wykorzystania w implementacji
mechanizmu przepływu zadań technologii .NET 3.0 (ang. Microsoft Workflow
Foundation).
Aplikacje wykonane w technologii cienkiego klienta, w tym również rozwiązania
portalowe oraz systemy CMS (ang. content management system), z założenia wymagają
dostępu do sieci Internet (intranet). Fakt ten wykorzystywany jest przez twórców
poszczególnych rozwiązań również do stworzenia mechanizmów umożliwiających
potencjalnym użytkownikom zgłaszanie defektów i potencjalnych rozszerzeń związanych
Dariusz Rafał Augustyn, Łukasz Wyciślik, Łukasz Warchał
Politechnika Śląska, Instytut Informatyki, ul. Akademicka 16, 44-100 Gliwice, Polska
email:{draugustyn, lwycislik}@polsl.pl
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
D.R. Augustyn, Ł. Wyciślik, Ł. Warchał
w
z właśnie obsługiwaną zawartością, prezentowaną przez przeglądarkę WWW.
Funkcjonalność ta najczęściej wspomagana jest przez systemy CMS poprzez umożliwienie
określenia przez projektanta witryny zwrotnego adresu mailowego lub strony
wspomagającego serwisu, odnośnik (ang. link), do którego zostanie umieszczony na
wybranych stronach wygenerowanych przez system CMS. Podobnie jest w sytuacji
wytwarzania aplikacji dedykowanych. Takie rozwiązania obsługi zgłoszeń defektów
i potencjalnych rozszerzeń są wysoce niedoskonałe i obarczone szeregiem uciążliwości:
− osoba zgłaszająca poza opisaniem li-tylko napotkanego problemu obarczana jest
opisem jego lokalizacji, kontekstu wystąpienia oraz wersji aplikacji WWW,
w której problem wystąpił,
− w przypadku braku autoryzacji, osoba zgłaszająca nie czuje się odpowiedzialna za
wprowadzaną zawartość, co negatywnie rzutuje na jakość opisu problemu,
− w przypadku konieczności autoryzacji w serwisie wspomagającym dodatkowa
pracochłonność może stanowić czynnik zniechęcający do zgłaszania defektów
i potencjalnych rozszerzeń,
− osoby kwalifikujące i analizujące zgłoszenia oprócz analizy natury problemu
obarczane są określaniem wersji aplikacji, do której zgłoszono defekt oraz jego
lokalizacją na podstawie być może nieprecyzyjnego opisu osoby zgłaszającej.
Niedogodności te zostały wyeliminowane przez proponowany system, co zostało
praktycznie wykazane na przykładzie witryny WWW, będącej publikacją z narzędzia EPF
(ang. Eclipse Process Framework) [10].
da
.b
w
w
2
Propozycja mechanizmu zgłaszania
dla intranetowych aplikacji WWW
defektów
i
rozszerzeń
pl
s.
Propozycja mechanizmu zgłaszania defektów lub rozszerzeń wypracowana została
w oparciu o założenie wyeliminowania niedogodności opisanych we wstępie,
a identyfikowanych w wielu istniejących systemach. Polega ona na tym, że użytkownik
przeglądając zawartość witryny WWW ma możliwość zgłoszenia swoich uwag do
aktualnie przeglądanej strony poprzez kliknięcie linka prezentowanego na każdej ze stron
danej witryny, co spowoduje automatycznie wyświetlenie okna przeglądarki z omawianą
aplikacją. Ponieważ przyjęto założenie, że zgłaszanie defektów lub rozszerzeń realizowane
jest w ramach sieci intranet, tak więc, potencjalny użytkownik nie musi interaktywnie
uczestniczyć w procesie autoryzacji, gdyż jego tożsamość przejmowana jest z systemu
operacyjnego i wykorzystana do weryfikacji uprawnień do wykonania operacji zgłaszania
uwag. Aplikacja prezentuje okno do zgłaszania uwag będąc „świadoma” tego kto zgłasza
(tożsamość systemu operacyjnego) oraz do której strony i której wersji witryny zgłasza
(jest to zapewnione przez odpowiedni kod java-script ukryty za odnośnikami
prezentowanymi na każdej ze stron). Użytkownikowi pozostaje więc tylko merytoryczne
opisanie problemu, na który się natknął podczas przeglądania zawartości witryny WWW.
Obsługa zgłoszonego problemu może być realizowana w oparciu o wcześniej
zdefiniowany przez projektanta schemat przepływu zadań obsługi zgłoszeń błędów i
rozszerzeń. Projektant, definiując schemat przepływu zadań dla zgłoszeń do danego
systemu, ma możliwość definiowania stanów zgłoszeń, z których wynikają bezpośrednio
czynności konieczne do wykonania przez poszczególnych uczestników, określając
jednocześnie role, które muszą oni pełnić w systemie, aby być dopuszczonymi do
wykonania tych zadań.
44
System monitorowania zgłoszeń rozszerzeń i defektów aplikacji WWW, bazujący na mechanizmie przepływu zadań
3
Mechanizm przepływu zadań Microsoft Workflow Foundation
w
Mechanizm Windows Workflow Foundation [1], [2], [3] został bardzo niedawno
wprowadzony na rynek narzędzi wytwórczych przez firmę Microsoft Corporation jako
element infrastruktury .NET w wersji 3.0.
Koncepcja WF zakłada wyodrębnienie elementów systemu odpowiedzialnych
za wyrażenie przepływu i reguł decyzyjnych oraz obsługę ich przetwarzania (wyodrębniona
definicja i obsługa logiki przetwarzania).
WF jest pewną ideą architektury systemów informatycznych oraz infrastrukturą
programową pozwalającą na wizualny, komponentowy sposób definiowania logiki
przetwarzania (sekwencje czynności, przepływy stanów, reguły biznesowe) oraz
zapewniający jej efektywną, systemową obsługę.
Definicja sposobu przetwarzania w ramach przepływu w znacznej mierze możliwa jest
do utworzenia i modyfikacji w trybie wizualnym przez projektanta systemu.
Logika przetwarzania może być wyrażana w postaci przepływu sekwencyjnego działań
lub przepływu stanów. Sposób wyrażania przepływu można uznać, w uproszczeniu, jako
wzorowany na diagramach czynności lub stanów języka UML.
Wśród wielu funkcjonalności dostarczanych w ramach mechanizmu WF, poniżej
wymieniono i krótko scharakteryzowano tylko niektóre, wykorzystane w omawianym
systemie FeedWeb:
− określanie przepływów z wykorzystaniem predefiniowanych aktywności lub
aktywności własnych (inaczej czynności użytkownika – ang. custom activities);
WF pozwala na tworzenie bibliotek elementarnych własnych czynności lub całych
reużywalnych przepływów. Przykładowo, w systemie FeedWeb, wykorzystano
mechanizm aktywności użytkownika do utworzenia bibliotecznych działań
powiadamiających, m.in. poprzez e-mail.
− uruchamianie (ang. debugging) na poziomie wizualnego projektanta przepływu;
Środowisko uruchomieniowe Visual Studio 2005, pozwala na obsługę punktów
kontrolnych (ang. break point) ustawianych nie tylko w kodzie programu, ale
również na poziomie graficznej reprezentacji przepływu, przez co ułatwiony jest
proces uruchamiania systemu.
− utrwalanie/odtwarzanie stanu przebiegu;
Integralną częścią infrastruktury WF jest moduł implementujący systemową
usługę dołączaną SQLWorkflowPresistanceService oraz skrypty tworzące
strukturę i procedury bazy danych dla DBMS MS SQL Server, pozwalające
utrwalać i odtwarzać stan przepływu. Utrwalanie polega na tzw. serializacji
instancji przepływu, identyfikowanej poprzez GUID, deponowanej w tablicy bazy
danych, albo na żądanie aplikacji sterującej, albo w chwilach bezczynności
przepływu.
− śledzenie/monitorowanie przebiegu przepływu;
Integralną częścią infrastruktury WF jest moduł implementujący systemową
usługę dołączaną SQLTrackingService oraz skrypty tworzące strukturę i procedury
bazy danych dla DBMS MS SQL Server, pozwalające utrwalać i przeglądać
wystąpienia zdarzeń związanych z uruchomionymi aktywnościami przepływów.
Możliwa jest obserwacja przebiegu przepływu w ramach przeglądu zawartości
tablic poprzez zapytania SQL ad hoc albo, dzięki funkcjonalności klasy
SqlTrackingQuery, można dokonać monitorowania przebiegu przepływu w trybie
programowym. Możliwe jest użycie narzędzi zewnętrznych (np. przykładowej
aplikacji WorkflowMonitor, dostarczanej w ramach .NET Framework 3.5
da
.b
w
w
pl
s.
45
w
−
−
pl
s.
−
da
.b
−
w
w
SDK [4]), pozwalających na przegląd stanu przepływu i stanu poszczególnych
aktywności w wizualnym trybie projektanta. WF dostarcza funkcjonalność
określenia zakresu monitorowania poprzez mechanizm profili śledzenia,
pozwalając na wskazanie w przepływie: miejsc podlegających śledzeniu – tzw.
lokalizacji w nomenklaturze WF oraz zagadnień agregujących lokalizacje – tzw.
punktów w nomenklaturze WF. Dzięki użyciu klasy TrackingProfile można
filtrować zdarzenia stanu aktywności, zdarzenia stanu przepływu, zdarzenia
użytkownika. Funkcjonalność śledzenia zdarzeń i zmian stanów przepływów
działań jest pomocna zarówno na etapie uruchamiania i wdrażania systemu, jak
i w trakcie eksploatacji.
obsługa transakcji zgodnie z modelem rozproszonych transakcji X/Open (model
XA [3]) oraz wykorzystanie mechanizmu transakcji otaczających;
W systemie FeedWeb wykorzystano wariant transakcji klasycznego modelu XA
oraz transakcji otaczających (ang. ambient transaction) i poprzez wykorzystanie
działania typu TransactionScope zapewniono objęcie jednym zakresem transakcji
operacji dotyczących utrwalania stanu przepływu oraz operacji dotyczących
zawartości dziedzinowej bazy danych (tzn. merytorycznej bazy danych systemu
FeedWeb).
wykorzystanie reguł – deklaratywnego mechanizmu sterującego wykonaniem
przepływów działań;
W systemie FeedWeb mechanizm reguł pozwolił na wyodrębnienie formuł
wykorzystywanych przy ocenie warunków dla działań sterujących typu
IfElseActivity, WhileActivity, itp., zwiększając przejrzystość definicji przepływu
i potencjalną łatwość jego modyfikacji. Reguły te wykorzystane są do sprawdzania
ról aktualnie zalogowanego użytkownika aplikacji FeedWeb, a tym samym
decydują o spełnieniu/niespełnieniu warunków dozoru, pokazanych na
krawędziach diagramu stanów zgłoszenia (rys.7).
użycie przepływów równoległych;
Model przetwarzania infrastruktury WF pozwala na równoległą realizację działań,
przepływów. W systemie FeedWeb zostało to wykorzystane w celu
zrównoleglenia wykonania administracyjnej czynności powiadamiania o wejściu
przepływu do określonego stanu (czynność monitująca właściwych
użytkowników) z wykonaniem czynności istotnych merytorycznie (operacji na
danych zgłoszenia).
tworzenie/modyfikacja definicji przepływu zadań spoza narzędzia Visual Studio;
WF umożliwia wizualne tworzenie i modyfikację definicji przepływu z poziomu
środowiska wytwórczego Visual Studio 2005 (dzięki programowemu dodatkowi
Windows Workflow Foundation Tools for Visual Studio), ostatecznie prowadząc
do utworzenia wykonywalnego podzespołu DLL.
WF umożliwia również deklaratywny model tworzenia i modyfikacji definicji
przepływu, wyrażonej w języku XML z wykorzystaniem słownictwa XAML [6].
Aby użyć (uruchomić) prosty przepływ wyrażony w języku XML, można
utworzyć instancję tego przepływu bezpośrednio na podstawie czytnika XML
(ang. XmlTextReader), inicjowanego definicją tego przepływu. Aby uruchomić
złożony przepływ wyrażony w języku XML, trzeba jednak skompilować jego
definicję do podzespołu DLL z wykorzystaniem narzędzia wfc (ang. workflow
compiler).
WF udostępnia mechanizm obsługi wizualnego tworzenia definicji przepływu
wyrażonego w XML (ang. Re-Hosting Workflow Designer) – API dla
programistów [5]. Mechanizm ten może pozwolić na zbudowanie aplikacji,
46
w
w
pozwalającej nie tylko tworzyć/modyfikować/pokazywać definicje przepływu, ale
również prezentować w trybie graficznym stan przetwarzania przepływu (poprzez
wykorzystanie informacji dostarczanych przez wspomnianą usługę śledzenia).
Funkcjonalność tę można wykorzystać do stworzenia własnego narzędzia do
wizualizacji przepływu, ale istnieją gotowe programy realizujące w pewnych
zakresach tę funkcjonalność (np. przykładowa aplikacja Workflow Designer [5]).
System FeedWeb uzupełniono o prostą, narzędziową aplikację w technologii
grubego klienta (technologia WinForm), pozwalającą na prezentację i modyfikację
grafu głównego przepływu działań, określającego zmiany stanów zgłoszenia.
Takie podejście pozwala na bezpośredni udział w czynności definiowania
przepływów na etapie wdrożenia i konfiguracji (kastomizacji) systemu przez
innych użytkowników (w tym użytkowników końcowych i przedstawicieli
zamawiającego), a nie tylko projektantów systemu.
określenie i realizacja sposobu przechodzenia pomiędzy ekranami aplikacji
z wykorzystaniem przepływu stanów, zdefiniowanego przez projektanta;
Nawigacja stron WWW w omawianej aplikacji, zrealizowanej w technologii
ASP.NET jest obsługiwana przez mechanizm WF.
−
w
4 Architektura rozwiązania
da
.b
Architektura omawianego systemu FeedWeb została zaprezentowana w ujęciu perspektywy
logicznej, tzn. modelu aplikacji w kontekście pakietów klas (rys. 1) oraz fizycznej,
tzn. komponentowej (rys. 2) i wdrożeniowej (rys. 3).
Na rys. 1 zobrazowano strukturę logiczną omawianego rozwiązania przy pomocy
diagramu pakietów (ang. UML package diagram [7]). Wykorzystane na diagramie regiony
(ang. boundaries) pokazują rozdzielenie w systemie warstwy prezentacji (aplikacja WWW)
od warstwy przetwarzania (moduły i przepływy). Poszczególne pakiety grupują w sobie
klasy i interfejsy pełniące podobną rolę. Taki podział wynika pośrednio z wykorzystania
do realizacji projektu WebClient Software Factory [8] – zbioru gotowych bibliotek oraz
wskazówek, pomagających tworzyć systemy elastyczne i implementujące uznane wzorce
projektowe.
pl
s.
47
Obsługa zgłoszeń
Aplikacja WWW FeedWeb
View s
+ AkceptowanieZgloszeniaPresenter
+ AnulowanieZgloszeniaPresenter
+ DefaultViewPresenter
ASP.NET Pages
+ PodgladZgloszeniaPresenter
+ PodsumowaniePresenter
+ AkceptowanieZgloszeniaPage
+ Presenter
+ AnulowanieZgloszeniaPage
+ Zgloszenie
+ DefaultPage
+ ZgloszeniePresenter
+ PodgladZgloszeniaPage
w
+ IAkceptowanieZgloszenia
Workflow s
«use»
+ PodsumowaniePage
+ ZgloszeniePage
+ IAnulowanieZgloszenia
+ ObslugaZgloszenPageFlow
+ IDefaultView
+ ObslugaZgloszenWorkflow
+ IPodgladZgloszenia
+ IPodsumowanie
+ IZgloszenie
w
«use»
Controllers
+ ObslugaZgloszenController
«use»
+ ObslugaZgloszenModuleInitializer
User Controls
w
+ ArtefaktUploadUserControl
+ FiltrZgloszenUserControl
+ ZestawArtefaktowUserControl
Serv ices
da
.b
+ ArtefaktyDbService
+ DbServiceBase
+ ZadaniaDbService
+ ZgloszeniaDbService
BusinessEntieties
+ Artefakt
+ FlitrWyszukiwania
+ IArtefaktyDbService
+ Zadanie
+ IDbServiceBase
+ Zgloszenie
+ IDisposable
+ IZadaniaDbService
+ IZgloszeniaDbService
Rys. 1. Diagram przedstawiający model logiczny systemu FeedWeb.
pl
s.
Jednym z takich wzorców projektowych jest MVP (ang. Model – View – Presenter) [9].
W omawianym rozwiązaniu każda strona ASP.NET (klasa z pakietu ASP.NET Pages)
traktowana jest jako widok (w nomenklaturze MVP) i posiada swój interfejs i prezenter
(klasy z pakietu Views). Działania użytkownika powodują wyzwalanie zdarzeń, których
obsługą zajmuje się prezenter. Ten z kolei wywołuje odpowiednie metody kontrolera
aplikacji/modułu (klasy z pakietu Controllers), które uruchamiają odpowiednie przepływy
(klasy z pakietu Workflows) i usługi (klasy z pakietu Services). Wszystkie wymienione
wyżej klasy wykorzystują do przekazywania danych obiekty, których definicje zawiera
pakiet BusinessEntities. Klasy pakietu BusinessEntities modelują pojęcia z dziedziny
przedmiotowej systemu i mają swoje bezpośrednie odwzorowanie w tabelach bazy danych.
Z powyższego opisu wynika, że mamy tu do czynienia z nieco bardziej rozbudowanym
wzorcem projektowym, niż klasyczny MVP. Jest to tak zwany Model – View – Presenter
with Application Controller [8].
48
Workflow s
«library»
Zgloszenia Workflow
«library»
Zgloszenia Pageflow
w
Aplication Modules
IZgloszeniaDbService
IZadaniaDbService
w
«module»
Obsługa zgłoszeń
w
View Interface
ISiteMapBuilderService
da
.b
UI
«module»
Shell
View Interface
Site Map Service
WebSite
pl
s.
Rys. 2. Diagram komponentów przedstawiający powiązania i interfejsy pomiędzy
poszczególnymi składnikami systemu.
Na rys. 2, przy pomocy diagramu komponentów (ang. UML component diagram [7]),
pokazano składniki, z których zbudowany jest system. Komponentem najwyższego
poziomu jest aplikacja WWW - WebSite. Korzysta ona z dwóch systemowych modułów
(w rozumieniu WebClient Software Factory [9]). Komponent Obsługa zgłoszeń zawiera
wszystkie klasy i interfejsy potrzebne do obsługi poszczególnych stron ASP.NET. W tym
celu korzysta z przepływów zdefiniowanych w bibliotekach Zgłoszenia Workflow
i Zgłoszenia Pageflow. Aplikacja WWW korzysta także z usług komponentu Shell, który
dostarcza infrastrukturę wspierającą tworzenie GUI (np. menu, mapa strony, historia
ekranów itp.).
Dzięki zdefiniowaniu interfejsów, poszczególne składniki systemu nie są ze sobą ściśle
związane (ang. loosely coupled). Zapewnia to dużą elastyczność całego rozwiązania –
podmiana jednego ze składników nie wymaga rekompilacji całego systemu, jeśli tylko
implementuje on odpowiedni interfejs.
49
w
da
.b
w
w
pl
s.
Rys. 3. Diagram wdrożenia systemu FeedWeb, uwzględniający wykorzystanie
podsystemów testowanej aplikacji i podsystemu autentykacji/autoryzacji oraz modułów
obsługujących mechanizm przepływów.
Proponowany model wdrożenia omawianego systemu został pokazany na rys. 3
na diagramie wdrożenia (ang. UML deployment diagram [7]). Oczywiście istnieją
możliwości innego rozkładu elementów systemu, np. zakładające intranetową infrastrukturę
FeedWeb i internetowy dostęp do testowanej aplikacji WWW. W szczególności nie
wyklucza się opcji wykorzystania innego systemu zarządzania bazą danych niż MS
SQLServer w roli serwera bazy danych, obsługującego bazą dziedzinową systemu
50
FeedWeb, a nawet w roli serwera baz danych dla systemowych usług WF utrwalania
i monitorowania.
5 Przykładowe wdrożenie i podsumowanie
w
Jednym z pierwszych, praktycznych zastosowań systemu FeedWeb było wykorzystanie
do obsługi witryny WWW, będącej publikacją pochodzącą z systemu EPF (ang. Eclipse
Process Framework). Publikacja ta, będąca bazą wiedzy o metodach i procesach
wytwórczych, stanowiła dostosowanie (ang. tailoring) zawartości istniejącej bazy procesów
(Basic Unified Process) do potrzeb konkretnego projektu realizacyjnego.
Domyślnie, w witrynach publikowanych przez system EPF, mechanizm zgłaszania uwag
dostępny jest z każdej ze stron witryny (rys. 4) i realizowany jest poprzez mechanizm
email, tzn. wskazanie odnośnika Feedback na stronie WWW powoduje otwarcie okna
(rys. 5), wywołującego program tzw. domyślnego klienta pocztowego z wpisanym
adresem email, określonym podczas publikacji.
da
.b
w
w
pl
s.
Rys. 4. Okno przeglądarki zawierające przykładową stronę publikacji EPF.
51
w
w
w
Rys. 5. Okno z programem „domyślnego klienta pocztowego”.
da
.b
Realizowane jest to przez funkcję javascript o nazwie sendFeedback, która zdefiniowana
jest w pliku topnav.js. W celu integracji testowanej publikacji WWW z systemem
FeedWeb, kod źródłowy tej funkcji zastąpiony został w taki sposób, że uaktywnienie
wspomnianego odnośnika Feedback z dowolnej strony, spowoduje otwarcie okna (rys. 6)
z aplikacją FeedWeb (z autoryzacją w tle – bez udziału użytkownika). Pola formularza
nowego zgłoszenia zostają wstępnie wypełnione: adresem strony WWW obsługiwanej
witryny, wersją publikacji, czasem zgłoszenia oraz danymi identyfikującymi użytkownika.
Zgłaszającemu pozostaje więc tylko opisanie problemu na poziomie merytorycznym.
Użytkownik ten ma również możliwość zapoznania się ze stanem swoich wcześniejszych
zgłoszeń.
pl
s.
52
w
da
.b
w
w
pl
s.
Rys. 6. Okno przeglądarki z systemem FeedWeb służące do rejestracji nowych zgłoszeń.
Obsługa zarejestrowanych zgłoszeń możliwa jest przy pomocy homogenicznego interfejsu
graficznego (rys. 8), a dopuszczalny, przykładowy przepływ stanów zgłoszeń został
zdefiniowany dla obsługiwanego systemu zgodnie z diagramem (rys. 7)
i zaimplementowany w oparciu o mechanizm WF.
53
Initial
[rola in
Zgłaszający]
Zgłoszone
[rola in { Zgłaszający,
Dopuszczający }]
[rola in Dopuszczający]
w
Do analizy
[rola in Planujący analizę]
Anulow ane
[rola in Planujący analizę]
w
Analiza
[rola in Weryfikujący analizę]
[rola in Analizujący]
Weryfikacj a analizy
w
[rola in Weryfikujący implementację]
Do implementacj i
da
.b
[rola in Planujący implementację]
Implementacj a
[rola in Implementujący]
Weryfikacj a
implementacj i
Zrealizow ane
pl
s.
Rys. 7. Przykładowy przepływ stanów zgłoszeń zdefiniowany do obsługi publikacji EPF.
54
w
da
.b
w
w
Rys. 8. Przykładowe okno systemu FeedWeb związane z obsługą zgłoszeń.
Literatura
1.
2.
3.
4.
5.
pl
s.
Podsumowując, należy stwierdzić, że przedstawione rozwiązanie umożliwia zbudowanie
elastycznego i ergonomicznego informacyjnego kanału zwrotnego (ang. feedback),
wspomagającego śledzenie funkcjonowania szerokiej klasy systemów opartych
o technologię cienkiego klienta. Końcowy użytkownik wprowadza tylko informację
dotyczącą merytorycznej strony problemu, ale dzięki automatycznej autentykacji, ma
świadomość odpowiedzialności za wprowadzane treści. Stan zgłoszonych uwag może być
również przez niego na bieżąco monitorowany. Obsługa zgłoszonych zastrzeżeń odbywa
się w homogenicznym, do końcowego użytkownika, środowisku a zastosowanie
mechanizmu Workflow Foundation umożliwia łatwą zmianę (kastomizację) przepływu
zadań, adekwatną do sposobu obsługi poszczególnych publikacji WWW.
Kitta T.: Professional Windows Workflow Foundation, Wrox Press, 2007.
Shukla D.Schmidt B.: Essential Windows Workflow Foundation, Addison-Wesley, 2006.
Scribner K.: Microsoft Windows Workflow Foundation Step by Step, Microsoft Press, 2007.
Windows Workflow Foundation Samples,
http://msdn2.microsoft.com/en-us/library/ms741723.aspx.
Windows Workflow Foundation, Everything About Re-Hosting the Workflow Designer,
http://msdn2.microsoft.com/en-us/library/aa480213.aspx.
55
6.
Petzold Ch.: Applications = Code + Markup. A Guide to the Microsoft Windows Presentation
Foundation, Microsoft Press, 2006.
7. Booch G., Rubmaugh, Jacobson I.: UML przewodnik użytkownika, WNT, 2002.
8. Patterns & Practices - Web Client Software Factory, http://www.codeplex.com/websf.
9. Metsker S.J.: C# Design Patterns, Addison-Wesley, 2005.
10. Eclipse Process Framework Project (EPF), http://www.eclipse.org/epf.
w
da
.b
w
w
pl
s.
56

pobierz plik referatu - BDAS

Transkrypt

Podobne dokumenty