pobierz plik referatu - BDAS

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 22
w
Tworzenie systemów klasy ERP przy użyciu struktur
szkieletowych CAB
w
1 Wstęp
da
.b
w
Streszczenie. Kluczem do osiągnięcia sukcesu przy tworzeniu dużego
systemu informatycznego jest z reguły dobre zarządzanie takim
przedsięwzięciem. Prace projektowe muszą być odpowiednio podzielone
pomiędzy ludzi zaangażowanych w projekt i to najlepiej w taki sposób, aby
poszczególne zespoły projektowe mogły tworzyć jak najbardziej niezależne
od siebie komponenty systemu. Praca prezentuje podejście do tworzenia
systemów klasy ERP przy użyciu szkieletu CAB zintegrowanego z Visual
Studio 2005. Cechą charakterystyczna przedstawionego szkieletu jest
możliwość projektowania i implementacji niezależnych od siebie
komponentów na poziomie każdej warstwy systemu ERP.
pl
s.
Trudno sobie obecnie wyobrazić nowoczesne przedsiębiorstwo bez dobrze funkcjonującego
systemu ERP. Zintegrowany system ERP składa się najczęściej z kilku modułów
obsługujących wszystkie funkcje w przedsiębiorstwie np. produkcja, dystrybucja, finanse.
Integracja poszczególnych modułów powoduje, że system wspomaga realizację pełnego
procesu biznesowego od zaplanowanie sprzedaży do uzyskania zapłaty. Duża konkurencja
na rynku producentów systemów ERP sprawia, że firmy tworzące takie systemy muszą je
tworzyć szybciej, bardziej efektywnie i taniej, aby się na tym rynku utrzymać. Oprócz tego
takie systemy muszą sprostać ciągle zmieniającym się wymaganiom klientów oraz
specyficznym rodzajom działalności biznesowej jaką klienci ci prowadzą. Wydaje się więc,
że proces tworzenia nowoczesnego systemu ERP należy oprzeć na nowoczesnej,
komponentowej technologii, która jest w stanie zapewnić skalowalność systemu oraz
Przemysław Adamowicz: Politechnika Wrocławska, Instytut Matematyki i Informatyki,
ul. Janiszewskiego 14a, 50-372 Wrocław, Polska
email: [email protected]
Wojciech Macyna: Politechnika Wrocławska, Instytut Matematyki i Informatyki,
ul. Janiszewskiego 14a, 50-372 Wrocław, Polska
Artur Wilczek: Politechnika Wrocławska, Instytut Informatyki Stosowanej,
ul. Wybrzeże Wyspiańskiego 27, 50-370 Wrocław, Polska
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
P. Adamowicz, W. Macyna, A. Wilczek
umożliwia efektywne przydzielenie procesu wytwarzania systemu niezależnym zespołom
produkcyjnym.
Praca przedstawia szkielet Composite Application Block (CAB) oraz sposób tworzenia
dużych systemów w oparciu o ten szkielet. Więcej na temat CAB można znaleźć w pracach
[1] i [2]. Z kolei sam opis sposobu tworzenia systemów jest wynikiem doświadczeń
autorów niniejszej pracy.
w
2 Framework Composite UI Application Block
da
.b
w
w
Systemy ERP z uwagi na swoja złożoność są trudne w implementacji i wymagają dużego
nakładu prac projektowych. Możliwość implementacji poszczególnych modułów przez
niezależne zespoły programistów jest bardzo pożądanym rozwiązaniem tego problemu.
Wprowadzenie przez firmę Microsoft szkieletu CAB wzbudziło duże zainteresowanie już
w wersji Beta. Odseparowanie poszczególnych części ułatwia projektowanie systemu i
pozwala na traktowanie poszczególnych funkcjonalności jak oddzielnych zagadnień.
Podział prac podczas fazy implementacyjnej, przy realizacji poszczególnych
komponentów, pozwala programistom na skoncentrowanie się na powierzonych im
zadaniach.
2.1 Wymagania technologiczne dla zespołów programistycznych
CAB jest napisanym przez firmę Microsoft szkieletem zaproponowanym jako pomoc przy
realizacji dużych projektów. Możliwość podziału prac i odseparowania zadań jest
podstawowym atutem tego szkieletu. CAB bazuje na .Net Framework 2.0 i Windows
Forms. Od Programistów wymagana jest znajomość Microsoft Visual C#.
2.2 Zastosowane wzorce w CAB
pl
s.
W CAB zastosowano szereg wzorców projektowych. Pełny opis tych wzorców można
znaleźć z [3] i [4]. Szkielet korzysta zatem z dobrze sprawdzonych i przetestowanych
rozwiązań.
2.2.1 Model View Controller
Wzorzec ten jest sposobem na odseparowanie od siebie poszczególnych części aplikacji.
Definiuje trzy podstawowe niezależne od siebie elementy aplikacji. Oddzielone od siebie
części to: sterowanie aplikacją, logika prezentacyjna, logika biznesowa. Użycie tego
wzorca zapewnia dużą elastyczność podczas budowania, użytkowania i rozszerzania
aplikacji. Widok pobiera dane z modelu i wyświetla je w odpowiednio zdefiniowany
sposób. Widok w żaden sposób nie ingeruje w samą zawartość danych. Zadaniem
kontrolera jest przetwarzanie żądań i wywoływanie odpowiednich akcji. Model jest
odpowiedzialny za przechowywanie danych oraz udostępnia interfejs, dzięki czemu ukrywa
właściwą implementację. Tak więc obiekty korzystające z modelu nie muszą na przykład
wiedzieć, czy przechowywanie danych oparte jest o bazę danych czy też o pliki.
210
Tworzenie systemów klasy ERP przy użyciu struktur szkieletowych CAB
Widok
Kontroler
w
Model
Rys. 1. Model View Controller
da
.b
w
w
2.2.2 Dependency Injection
Wzorzec ten pozwala na wiązanie elementów poprzez “wstrzykiwanie” zależności między
komponentami podczas działania programu. Nie musimy więc tworzyć obiektu. Wystarczy,
że zaczniemy z niego korzystać, a system sam wykona potrzebne operacje. W przypadku
CAB’a chcemy stworzyć w obiekcie odpowiadającym za logikę aplikacji element widoku
oraz element, który będzie nam służył do komunikacji miedzy widokiem a logiką
biznesową. Kłopot w tym, że chcielibyśmy by element widoku mógł bez problemu
odwoływać się do elementu służącego do komunikacji i odwrotnie. Jednak w tym celu
musielibyśmy podać obu elementom referencje wzajemnie na siebie. Dzięki wzorcowi
dependency injection nie musimy tego robić. Gdy element widoku próbuje się odwołać do
elementu służącego do komunikacji z logiką, wówczas element komunikacji zostaje
stworzony.
2.2.3 Event Broker Service
W przypadku systemów posiadających wiele komponentów odseparowanych od siebie
pojawia się problem komunikacji między nimi. Rozwiązaniem jest Event Broker Service,
który pozwala na komunikację pomiędzy takimi komponentami.
Publishers
Subscribers
*
1
Event Catalog
Rys. 2. EventBroker
pl
s.
Event Topic
Method
Event
event://UpdatesAvailable
2.3 Komponenty zawarte w CAB
Podstawową cechą CAB jest wsparcie dla rozwoju aplikacji poprzez użycie niezależnych,
ale porozumiewających się ze sobą komponentów. CAB zawiera następujące typy
komponentów:
211
w
− SmartParts – widoki stanowiące interfejs graficzny użytkownika, oparte o kontrolki
typu Windows forms zawierające wizualną część aplikacji.
− WorkItems – klasy zawierające logikę aplikacji, może być rozumiany również jako
komponent realizujący dany przypadek użycia. Można go określić jako kontener na
elementy, które pracują razem by wypełnić funkcjonalność danego przypadku
użycia.
− Services – obiekty, które raz zarejestrowane, widoczne są z dowolnego komponentu
w aplikacji.
− Controllers – klasy odpowiadają za komunikację warstwy widoku z logiką
biznesową.
− Service Agents – klasy pomagające w łączeniu się z zewnętrznymi systemami i
usługami internetowymi.
w
WorkItem
SmartPart
Controller
Controller
da
.b
w
Services
SmartPart
Data Access Logic
Components
Service Agent
Rys. 3. Interakcja między elementami w CAB
2.4 Komunikacja między komponentami
pl
s.
Kluczowym zagadnieniem jest komunikacja pomiędzy poszczególnymi komponentami. W
przypadku, gdy mamy do czynienia z różnymi modułami mogą one komunikować się
między sobą za pomocą zdarzeń, w przypadku komponentów z tego samego WorkItem
zwykle będzie to dzielenie informacji o stanie w jakim znajduje się dany obiekt (dzięki
własności ShareState).
2.4.1 Komunikacja za pomocą zdarzeń
Zdarzenia mogą być używane przez elementy, które chcą wysyłać lub odbierać
powiadomienia. Szkielet CAB posiada specjalnie do tego przeznaczony komponent Event
Broker, który pozwala na wprowadzenie dowolnie wielu elementów publikujących
komunikaty oraz dowolnie wielu elementów odbierających powiadomienia.
Komunikaty mogą być publikowane przy użyciu atrybutu EventPublication. Nazwa
komunikatu jest po prostu łańcuchem znaków identyfikującym go w systemie.
Atrybuty umieszczane są w obszarze ujętym w nawiasy kwadratowe, przed deklaracja
zdarzenia. Atrybuty służą do przekazania dodatkowych informacji o zdarzeniu.
[EventPublication("event://UpdatesAvailable", EventScope.Global)]
public event EventHandler<ApplicationEventArgs> UpdatesAvailable;
212
Zdarzenia mogą być przechwytywane przez metody przy pomocy atrybutu
EventSubscription w deklaracji metody. Jedno zdarzenia mogą być odbierane przez wiele
metod.
[EventSubscriber("event://UpdatesAvailable")]
public void SomethingHappened(object sender,
ApplicationEventArgs e)
{ … }
w
w
2.4.2 Komunikacja za pomocą współdzielenia stanu
Klasa WorkItem może przechowywać stan (atrybut State). WorkItemy, które pojawią się w
systemie dziedziczą po klasie WorkItem zdefiniowanej w CAB. SmartParty zawarte w
WorkItem mogą używać stanu do komunikacji z innymi komponentami w obrębie tego
samego WorkItem.
globalWorkItem.State["CustName"] = textbox1.text;
w
2.5 Komendy
da
.b
Bardzo często zdarza się, że aplikacja posiada więcej niż jedną możliwość uruchomienia
jakiejś funkcji. Przykładowo: zarówno przycisk na pasku jak i menu mogą zawierać opcję
otwierania plików. CAB daje wsparcie dla pisania klas, które mogą odbierać komunikaty
od wielu elementów. Poprzez implementację interfejsu ICommandService klasy mogą
korzystać z komend. Komendy i operacje z nimi związane są kontrolowane przez Event
Broker Service.
2.6 Podział ról w zespole programistów
pl
s.
Z uwagi na dobrze wyspecyfikowane komponenty w CAB możemy na etapie
implementacji wyszczególnić następujące role dla programistów:
− Shell developer – programista jest odpowiedzialny za stworzenie powłoki aplikacji.
− Business logic developer – programista odpowiedzialny za stworzenie komponentów
logiki biznesowej, które będą dołączane do aplikacji.
− Infrastructure developer – programista odpowiedzialny za stworzenie infrastruktury
serwisów, które będą wpisane do aplikacji.
Można zdefiniować dodatkowo programistów, którzy zajmą się bezpośrednio
zaprojektowaniem widoków oraz tych, którzy będą odpowiedzialni za implementację
WorkItemów.
3 Projektowanie systemów z użyciem CABa
Projekt każdego systemu powinien składać się z części konceptualnej, logicznej i fizycznej.
Z uwagi na brak miejsca w pracy tej skupiono się jedynie na prostym diagramie
przypadków użycia oraz na projekcie fizycznym systemu, gdyż tylko na taki projekt ma
wpływ CAB. W podrozdziale 3.1 opisany jest sposób realizacji przypadków użycia
tworzących moduł: Obsługa zamówień. Z kolei rozdział 3.2 opisuje sposób łączenia
poszczególnych modułów tworzących system ERP.
213
3.1 Projektowanie pojedynczego modułu
w
Rozważmy przykładowy moduł, którego zadaniem jest zarejestrowanie zamówienia. W
najprostszym przypadku zarejestrowanie zamówienia polega na wybraniu kontrahenta, a
następnie na wybraniu karty towaru oraz elementu towaru z magazynu i wpisaniu jego ceny
oraz ilości. W takim przypadku możemy więc wyróżnić następujące przypadki użycia:
− Obsługa zamówienia – dodaje, usuwa oraz modyfikuje zamówienie,
− Obsługa kontrahenta – dodaje, usuwa oraz modyfikuje kontrahenta,
− Obsługa towarów – dodaje, usuwa oraz modyfikuje towar.
Z uwagi na ograniczoną ilość miejsca nie będziemy wyszczególniać wszystkich
scenariuszy poszczególnych przypadków użycia. Z rysunku 4 wynika, że przypadek użycia:
Obsługa zamówienia może być rozszerzony o pozostałe dwa przypadki użycia. Wynika to
z faktu, że podczas rejestracji zamówienia należy wybrać kontrahenta, a jeśli danego
kontrahenta nie ma, wówczas należy przejść do przypadku użycia Obsługa kontrahenta,
aby dopisać nowego kontrahenta. Z drugiej strony przypadek użycia Obsługa kontrahenta
może być realizowany niezależnie. Użytkownik może bowiem dodać kontrahenta
niezależnie od rejestrowania zamówienia.
da
.b
w
w
pl
s.
Rys. 4. Przypadki użycia podsystemu Obsługa zamówień
Główną zasadą podczas projektowania aplikacji w oparciu o CAB jest projektowanie
poszczególnych przypadków użycia jako WorkItem.
Klasa WorkItem zawiera metodę Run, która aktywuje WorkItem. Każdy WorkItem
obsługuje klasy związane z interfejsem użytkownika (smartparty i kontrolery) oraz zawiera
logikę biznesową, która obsługuje serwisy i służy do pobierania danych z bazy danych
poprzez pośrednią warstwę DAL (Data Access Layer).
W górnej części rysunku 5 są trzy workitemy reprezentujące poszczególne przypadki
użycia:
− CustomerWorkItem – obsługuje przypadek użycia: Obsługa kontrahenta,
− OrderWorkItem – obsługuje przypadek użycia: Obsługa zamówienia,
214
w
− ArticleWorkItem – obsługuje przypadek użycia: Obsługa towaru.
Każdy z tych workitemów obsługuje po dwa smartparty: widok listy oraz widok danych
poszczególnego obiektu. Dla przykładu: CustLSP jest kontrolką wyświetlającą listę
kontrahentów, CustISP jest kontrolką, na której wyświetlane są dane poszczególnego
kontrahenta, a CustLCtr oraz CustICtr są kontrolerami obsługującymi tę kontrolki.
Kontrolery są połączone z klasą biznesową CustBusiness, która z kolei implementuje
serwis CustService oraz podaje dane do encji biznesowej CustEntity.
Działanie takiej aplikacji polega na tym, że zawsze jest aktywny jeden WorkItem. Może
być on aktywowany i dezaktywowany. I tak, jeśli podczas rejestracji zamówienia
użytkownik zechce zmodyfikować dane kontrahenta, wówczas przechodzimy do przypadku
użycia Obsługa Kontrahenta poprzez zaktywowanie CustomerWorkItem, co z kolei pociąga
za sobą aktywację smartparta CustISP .
w
CustWorkItem
CustWorkItem
CustWorkItem
w
CustIS
ArtLSP
ArtISP
OrdLS
OrdISP
CustLC
CustICt
ArtLCt
ArtICtr
OrdLCt
OrdICt
CustBusiness
da
.b
CustLS
ArtBusiness
CustEntity
CustService
OrdBusiness
CustEntity
CustService
DB
CustServi
pl
s.
DAL
CustEntity
Rys. 5. Projekt fizyczny podsystemu Obsługa zamówień
3.2 Projektowanie całego systemu ERP
Najwygodniej jest projektować system ERP jako zestaw składających się z wielu
współdziałających ze sobą modułów. Moduły te powinny być od siebie jak najbardziej
niezależne, aby klient systemu miał możliwość zakupienia tylko tych, z których będzie
korzystał.
Szkielet CAB umożliwia podpinanie modułów zapisanych w pliku ProfileCatalog.xml
do aplikacji szkieletowej. Poniższy przykład kodu ładuje trzy niezależne moduły systemu.
W efekcie powstaje system widoczny na rysunku 6. Wewnątrz takiego pliku
215
konfiguracyjnego można również nadawać prawa dostępu poszczególnym użytkownikom
do danych modułów.
Purchase
OrderManagement
da
.b
w
w
Business Intelligence
w
<?xml version="1.0" encoding="utf-8" ?>
<SolutionProfile xmlns="http://schemas.microsoft.com/pag/cab-profile">
<Modules>
<ModuleInfo AssemblyFile="OrderManagement.dll"/>
<ModuleInfo AssemblyFile="Purchase.dll"/>
<ModuleInfo AssemblyFile="BusinessIntelligence.dll"/>
</Modules>
</SolutionProfile>
Shell Application
Rys. 6. Widok systemu złożonego z trzech podsystemów
3.3 Zarządzanie projektem programistycznym
pl
s.
Wydaje się, że wykorzystanie CABa nie ma większego wpływu na aspekty związane
z prowadzeniem projektu programistycznego (np. na metodologie projektowe, sposoby
zarządzania wersjami, itd). Autorzy tego rozdziału zdecydowali się na tworzenie prototypu
z wykorzystaniem metodologii MSF (ang. Microsoft Solution Framework) [5].
Niezależność poszczególnych komponentów sprawia, że praca nad poszczególnymi
modułami może być podzielona pomiędzy wiele zespołów pracujących nawet
w oddzielnych lokalizacjach. Ważną sprawą w takiej sytuacji jest trzymanie się pewnych
standardów zarówno narzuconych przez CAB (np. ścisły sposób tworzenia encji
biznesowych, serwisów, workitemów, itd.), jak również poprzez opracowane standardy
korporacyjne (np. odpowiednie standardy nazewnictwa, wspólne metody tworzenia kodu).
Wszystko to sprawia, że składowe systemu są tworzone dokładnie w ten sam sposób w
różnych i niezależnych zespołach projektowo-programistycznych.
Praca nad systemem ERP o architekturze CABa powinna się opierać na dwóch grupach.
Pierwsza powinna śledzić rozwój CABa, dostosowywać go do własnych potrzeb oraz
tworzyć standardy sposoby projektowe i programistyczne. Natomiast druga grupa powinna
216
zajmować się właściwym tworzeniem systemu ERP z wykorzystaniem wiedzy i
standardów, które wypracuje grupa pierwsza.
4 Zakończenie
w
W pracy przedstawiono nowe podejście do tworzenia systemów ERP oparte na szkielecie
CAB. Należy nadmienić, że CAB jest nowym i ciągle rozwijających się podejściem.
Autorzy CABa zapewniają, że produkt będzie stopniowo rozszerzany o nowe cechy takie
jak na przykład serwisy autoryzacji.
Także autorzy tej pracy starają się tak zmodyfikować CABa, aby jego przydatność do
tworzenia dużych systemów była jeszcze większa. Obecnie trwają badania nad możliwością
wkomponowania w architekturę systemu opartą na CAB obsługi rozszerzeń (ang. plug-in)
modyfikujących system o dodatkową funkcjonalność. W niedługim czasie spodziewane jest
także napisanie prototypu systemu ERP, dzięki któremu można byłoby przetestować
wydajność systemu opartego na tej platformie.
w
w
Literatura
2.
3.
4.
5.
da
.b
1.
Microsoft, Introduction to the Composite Application Block, 2005, http://www.gotdotnet.com/,
21.01.2006.
Microsoft, Design of the Composite UI Application Block, 2005, http://www.gotdotnet.com/,
21.01.2006.
Martin Fowler, Model View Controller, 2003, http://www.martinfowler.com/, 23.01.2006
Martin Fowler, Inversion of Control Containers and the Dependency Injection pattern, 2004,
http://www.martinfowler.com/, 19.01.2006.
Microsoft, Microsoft Solution Framework, 2005, http://msdn.microsoft.com/vstudio/teamsystem
22.01.2006.
pl
s.
217
w
da
.b
w
w
pl
s.

pobierz plik referatu - BDAS

Transkrypt

Podobne dokumenty

dAF XF 460 FT(10 SZTUK)

Wersja PDF - Etykiety samoprzylepne Blue System Bydgoszcz

MITSUBISHI L200 Single Cab / Club Cab / Double - Auto

MITSUBISHI L200 Single Cab / Club Cab / Double - Auto

L200 4WORK pobierz katalog PDF - Auto

Hanse 470e (4 cab) - Broszura {ModelName}