pobierz plik referatu - BDAS
Transkrypt
pobierz plik referatu - BDAS
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 email: [email protected] Artur Wilczek: Politechnika Wrocławska, Instytut Informatyki Stosowanej, ul. Wybrzeże Wyspiańskiego 27, 50-370 Wrocław, Polska email: [email protected] (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006 Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 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 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006 Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006 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 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006 Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006 P. Adamowicz, W. Macyna, A. Wilczek 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 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006 Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006 Tworzenie systemów klasy ERP przy użyciu struktur szkieletowych CAB 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 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006 Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006 P. Adamowicz, W. Macyna, A. Wilczek 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 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006 Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006 Tworzenie systemów klasy ERP przy użyciu struktur szkieletowych CAB 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 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006 Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006 P. Adamowicz, W. Macyna, A. Wilczek 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 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006 Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006 Tworzenie systemów klasy ERP przy użyciu struktur szkieletowych CAB 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 (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006 Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006 w da .b w w pl s. (c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006