Projektowanie aplikacji biznesowych w oparciu o wzorzec

Projektowanie aplikacji biznesowych w oparciu o
wzorzec projektowy MVC. System wspomagajacy
˛
prac˛e nauczycieli akademickich
Miłosz Kubański1 , Agnieszka Kowalska2
1 Wydział
Inżynierii Mechanicznej i Informatyki
Kierunek Informatyka, Rok V
2 Wydział Inżynierii Mechanicznej i Informatyki
Kierunek Informatyka, Rok V
{miloszes,a_g_n_e_s}@tlen.pl
Streszczenie
W poniższej pracy zaproponowano metodyk˛e tworzenia średnich oraz dużych
systemów biznesowych z wykorzystaniem wzorca projektowego MVC. Przykładem
zastosowania tej metodyki jest system wspomagajacy
˛ prac˛e nauczycieli akademickich, który powstał zgodnie z przedstawianym wzorcem.
1 Wst˛ep
Komputery coraz cz˛eściej towarzysza˛ nam podczas codziennych czynności wykonywanych w naszym życiu. Pomagaja˛ nam podczas robienia zakupów przez internet, pozwalaja˛ kupić lub zarezerwować bilety, zamówić ksia˛żki w bibliotece oraz w wielu innych
przypadkach, gdzie nie jesteśmy nawet świadomi istnienia wsparcia systemów komputerowych.
Systemy informatyczne doskonale sprawdzaja˛ si˛e w sytuacjach, gdzie sa˛ zdefiniowane
procedury post˛epowania w obr˛ebie dziedziny która˛ obsługuja.˛ Wiele firm (a w szczególności instytucje finansowe takie jak banki) coraz cz˛eściej wykorzytuje systemy komputerowe do zapewnienia prawidłowości przebiegu procesów biznesowych. Instytucje te od
lat posługuja˛ si˛e ustalonymi i sprawdzonymi procedurami post˛epowania dla wszystkich
zdarzeń, które moga˛ pojawić si˛e podczas ich funkcjonowania. Dlatego też tak ch˛etnie
wybieraja˛ komputery w celu zapewnienia prawidłowej organizacji ich działania.
Zapotrzebowanie na systemy wspomagajace
˛ procesy biznesowe staje si˛e coraz wi˛eksze, ich złożoność rośnie, a nad procesem ich powstawania pracuja˛ coraz wi˛eksze zespoły
ludzi. Dlatego bardzo ważne jest odpowiednie wybranie procesu tworzenia oprogramowania jak i stworzenie przejrzystej architektury systemu pozwalajacej
˛ na swobodne "poruszanie" si˛e po niej wszystkim osobom bioracym
˛
udział w tworzeniu takiego systemu.
W pracy zaproponowana zostanie metodyka tworzenia struktury aplikacji biznesowych na przykładzie systemu wspomagajacego
˛
prac˛e nauczycieli akademickich.
1
2 Wymagania funkcjonalne i niefunkcjonalne systemu
Głównym zadaniem systemu jest przechowywanie oraz zarzadzanie
˛
informacjami na temat przebiegu studiów osób uczacych
˛
si˛e na wydziale Inżynierii Mechanicznej i Informatyki Politechniki Cz˛estochowskiej. System przechowuje dane dotyczace
˛ ocen i obecności
studentów na poszczególnych zaj˛eciach, informacje dotyczace
˛ prowadzonych zaj˛eć oraz
list studentów. System umożliwia uprawnionym osobom wglad
˛ w dane studentów, ich frekwencje na zaj˛eciach oraz uzyskiwane oceny. Aplikacja oferuje pracownikom możliwość
tworzenia list studentów uczestniczacych
˛
na dane zaj˛ecia, dost˛ep do list grup dziekańskich, sprawdzania obecności, wystawiania ocen, tworzenia własnych uwag oraz generowania raportów. Jednym z podstawowych wymagań tego systemu jest uniemożliwienie
zapisania jednego studenta na takie same zaj˛ecia do różnych grup. Aplikacja oferuje możliwość przegladania
˛
historii przebiegu studiów danego studenta oraz udost˛epniania informacje z poprzednich lat. Program umożliwi użytkownikom generowanie szczegółowych
raportów:
• Raport obecności – umożliwi przedstawienie frekwencji studentów na zaj˛eciach.
Statystyka ta umożliwi odnalezienie osób, które opuszczaja˛ zaj˛ecia.
• Raport ocen – umożliwi przedstawienie średniej ocen studentów:
* Średnia dla całego roku – przedstawia średnia˛ ocen studentów z uwzgl˛ednieniem wszystkich przedmiotów dla całego roku. Umożliwi np. odnalezienie
najlepszych studentów na danym roku.
* Średnia dla danego przedmiotu – przedstawia średnia˛ ocen studentów z danego przedmiotu oraz oceny poszczególnych studentów.
* Średnia dla danego prowadzacego
˛
– przedstawia poszczególne oceny oraz ich
średnia˛ wystawiona˛ przez danego prowadzacego
˛
w ramach jednego przedmiotu.
• Raport prowadzacych
˛
– umożliwi przedstawienie danych statystycznych dotycza˛
cych poszczególnych prowadzacych
˛
i ilości prowadzonych przez nich zaj˛eć w danym semestrze.
Po zalogowaniu do systemu automatycznie tworzony jest profil dla danego użytkownika,
prawa dost˛epu do poszczególnych grup oraz zestaw możliwych operacji. Prawa oraz operacje zostały podzielone na trzy kategorie "prowadzacy",
˛
"zarzadca"
˛
oraz "administrator".
2
• Prowadzacy:
˛
* możliwość stworzenia oraz edycji listy studentów ucz˛estszajacych
˛
na zaj˛ecia,
majac
˛ jednocześnie wglad
˛ w list˛e studentów w danej grupie dziekańskiej,
* wyszukiwanie studenta w celu dost˛epu do jego danych w kontekście prowadzonego przedmiotu,
* dodawanie oraz edycja ocen studenta,
* sprawdzenie obecności na zaj˛eciach,
* dodawanie, przegladanie
˛
oraz edycja notatek,
* generowanie raportów ocen i obecności.
• Zarzadca:
˛
* mozliwość przegladania
˛
wszystkich danych zawartych w systemie,
* generowanie raportów (wszystkie raporty).
• Administrator:
* tworzenie oraz edycja grup dziekańskich,
* dodawanie i edycja zaj˛eć z zaznaczeniem godzin, miejsca zaj˛eć oraz przypisaniem osoby prowadzacej,
˛
* dodawanie i edycja przedmiotów, w ramach których b˛eda˛ prowadzone zaj˛ecia,
* tworzenie grupy dziekańskiej na danym semestrze,
* generowanie raportów (wszystkie raporty).
Kolejnym istotnym wymaganiem dla tego systemu jest wieloplatformowość. Aplikacja musi być niezależna od systemu operacyjnego. Równie ważnym aspektem jest bezpieczeństwo. Program musi być zabezpieczony przed nieupoważnionymi osobami. Poszczególni użytkownicy rozpoznani przez system, po zalogowaniu b˛eda˛ mieli dost˛ep tylko do
danych im przysługujacym.
˛
3 Ogólna architektura systemu
3.1 Modułowa budowa systemu
Tworzenie złożonych systemów biznesowych wymaga ogromnych nakładów pracy. Aby
przyspieszyć proces tworzenia takich projektów, przydziela si˛e do ich wykonania duże
zespoły ludzi. W takim zespole można wyróżnić pewne grupy ludzi zajmujacych
˛
si˛e poszczególnymi cz˛eściami systemu np. grup˛e analityków, projektantów systemu, programistów, projektantów stron, grafików etc. Każdy z ludzi bioracych
˛
udział w projekcie
posiada pewne predyspozycje, które umożliwiaja˛ przydzielenie ich do zadań, w których
najlepiej moga˛ si˛e sprawdzić.
W celu zoptymalizowania pracy wielu osób nad tworzonym systemem, należy tak zaprojektować system, aby każdy z przydzielonych twórców miał własna˛ cz˛eść systemu do
3
wykonania oraz by jego predyspozycje jak najlepiej pasowały do pracy, która˛ ma wykonać. Podczas projektowania takiego systemu należy również zadbać o to by prace wykonywane przez poszczególnych członków zespołu mogły być wykonywane w tym samym
czasie i aby w jak najmniejszej cz˛eści ich czas wykonania zależał od pozostałych osób.
Projekt takiego systemu musi być przejrzysty, tak aby każda z osób pracujacych
˛
nad
jego stworzeniem (nawet jeżeli zajmuje si˛e tylko małym fragmentem systemu) mogła
ogólnie zrozumieć jego architektur˛e i móc swobodnie "poruszać si˛e" po nim. Biorac
˛ pod
uwag˛e wymagania jakie pojawiaja˛ si˛e wzgl˛edem takiego projektu, najbardziej naturalnym
rozwiazaniem
˛
wydaje si˛e być podzielenie systemu na warstwy zgodnie z modelem MVC
(ang. Model–View–Controller)[1] [2].
Rys. 1: Trójwarstwowy wzorzec projektowy MVC (ang. Model–View–Controller)
Wzorzec MVC (Rys. 1) zakłada podzielenie systemu na trzy warstwy:
• Model aplikacji (ang. Model) – odpowiedzialna za przechowywanie danych oraz
operacje na tych danych. Odzwierciedla logik˛e biznesowa.˛
4
• Warstwa prezentacji (ang. View) – odpowiedzialna za prezentacje wyników użytkownikowi.
• Kontroler (ang. Controller) – odpowiedzialna za tlumaczenie akcji użytkownika na
operacje na Modelu oraz wybor odpowiedniego widoku (ang. View) na odpowiedź.
Zajmuje si˛e obsługa˛ poszczególnych procesów biznesowych.
Podział systemu na warstwy, które z kolei moga˛ zostać podzielone na moduły umożliwia łatwe przydzielenie grup deweloperskich do warstw systemu np. grafików oraz projektantów GUI można przydzielić do prac nad modułami warstwy widoku, programistów
do warstwy kontrolera, a projektantów z cz˛eścia˛ programistów do warstwy modelu aplikacji.
Każdy z członków poszczególnych zespołów jest zaznajomiony z ogólna˛ funkcjonalnościa˛ jaka˛ udost˛epniaja˛ warstwy, bez konieczności poznania szczegółów ich implementacji. Kolejna˛ zaleta˛ wykorzystania wzorca projektowego MVC jest możliwość zmiany
funkcjonowania systemu modyfikujac
˛ jedynie funkcjonalność pojedynczego modułu.
3.2 Struktura przedstawianego systemu
System wspomagajacy
˛ prac˛e nauczycieli akademickich został zaprojektowany zgodnie
z wzorcem MVC (Rys. 2). System udost˛epnia użytkownikowi dwie aplikacje klienckie.
Pierwsza z nich została stworzona w J2SE z wykorzystaniem bibliotek SWING. Druga˛
aplikacja˛ kliencka˛ tego systemu jest aplikacja "web’owa" korzystajaca
˛ z technologi JSP
(Struts wraz z JSF).
Dzi˛eki zastosowaniu wspomnianego wzorca projektowego stworzenie dodatkowego
klienta udost˛epniajacego
˛
identyczna˛ funkcjonalność wymagało jedynie modyfikacji wartstwy prezentacji oraz niewielkiej ingerencji w warstw˛e kontrolera (moduły odpowiedzialne za wybór odpowiedniego widoku do prezentacji wyników).
3.2.1 Model aplikacji
Warstwa ta składa si˛e z bazy danych ORACLE oraz szeregu funkcji pośredniczacych we
wszystkich operacjach na danych (procedury składowane). Serwer bazy danych ORACLE przechowuje dane używane przez aplikacje klienckie oraz funkcje pośredniczace
˛ w
operacjach na danych.
Funkcje umieszczone na serwerze baz danych (SBD) sa˛ odpowiedzialne za integralność oraz bezpieczeństwo danych.
Funkcje zaimplementowane w aplikacji (Rys. 3) zostały zgrupowane w poszczególne
komponenty "encyjne", które sa˛ odpowiedzialne za wywoływanie odpowiednich metod
zawartych w SBD oraz buforowanie informacji zwróconych przez ten serwer.
Umieszczenie funkcji na SBD minimalizuje generowanie ruchu sieciowego oraz optymalizuje czas wykonania danej akcji zleconej przez użytkownika.
Zmiana struktury bazy danych lub SBD wymaga modyfikacji wyłacznie
˛
tej warstwy.
Moduły należace
˛ do pozostałych warstw nie sa˛ wrażliwe na takie zmiany.
3.2.2 Warstwa prezentacji
Warstwa prezentacji odpowiedzialna jest za komunikacj˛e z użytkownikiem. Warstw˛e ta˛
stanowi aplikacja kliencka zaimplementowana z wykorzystaniem technologii JAVA 2SE.
5
Rys. 2: Ogólna architektura prezentowanego systemu
Rys. 3: Warstwa modelu aplikacji prezentowanego systemu
6
Rys. 4: Warstwa modelu aplikacji klienta wykorzystujacego
˛
biblioteki SWING
W momencie wybrania opcji przez użytkownika, warstwa ta komunikuje sie bezpośrednio
z kontrolerem, który decyduje jaka˛ akcj˛e (proces biznesowy) należy podjać.
˛
3.2.3 Kontroler
Warstwa kontrolera (Rys. 5) odpowiedzialna jest za prawidłowy przebieg poszczególnych
procesów biznesowych. Kontroler składa si˛e z dwóch komponentów:
• cKontroler – zawiera klasy udost˛epniajace
˛ funkcje poszczególnych procesów biznesowych
• cUzytkownik – zawiera klasy zarzadzaj
˛
ace
˛ profilami zalogowanych użytkowników
Funckje zawarte w warstwie kontrolera operuja˛ na obiektach zawartych w warstwie
modelu aplikacji.
Rys. 5: Warstwa kontrolera prezentowanego systemu
4 Podsumowanie
Duża˛ zaleta˛ opisywanej metodyki tworzenia systemów komputerowych jest duża przejrzystość struktury systemu, możliwość szybkiego poprawienia bł˛edów w systemie oraz
7
łatwa piel˛egnacja napisanego kodu. Systemy zaprojektowane z wykorzystaniem wzorca
MVC charakteryzuja˛ si˛e duża˛ elastycznościa˛ oraz przenośnościa.˛ Zmiana architektury
systemu, struktury logiki biznesowej, czy też sposobu prezentacji danych użytkownikowi
wymaga niewielkiego nakładu pracy w porównaniu do innych rozwiazań.
˛
Kolejna˛ zaleta˛ stosowania podanego wzorca jest prostota testowania logiki oraz procesów biznesowych z pomini˛eciem warstwy zwiazanej
˛
z interfejsem użytkownika. Innym pozytywnym
aspektem stosowania tej technologii jest możliwość korzystania z gotowych komponentów, które skracaja˛ czas implementacji systemu i podnosza˛ jego niezawodność.
Do wad stosowania modelu MCV można zaliczyć zwi˛ekszenie liczby komponentów,
które musza˛ zostać zaimplementowane w systemie, co w niewielkim stopniu zwi˛eksza
stopień złożoności projektu. Inna˛ niedoskonałościa˛ zwiazan
˛ a˛ z podanym modelem jest
ścisłe sprz˛eżenie komponentów na poziomie interfejsów funkcyjnych. Wszelkie zmiany
tych interfejsów niosa˛ ze soba˛ konieczność zmian w kodzie warstw korzystajacych
˛
ze
zmienionych modółów. Jednakże niedoskonałości modelu MVC sa˛ wr˛ecz niezauważalne
w porównaniu z zaletami jakie daje nam stosowanie tej technologii.
Literatura
[1] Martin Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley
Professional, 2005.
[2] Gamma Erich, Helm Richard, Johnson Ralph, Vlissides John, Wzorce projektowe.
Elementy oprogramowania obiektowego wielokrotnego użytku, WNT, 2005.
8