Projektowanie aplikacji biznesowych w oparciu o wzorzec projektowy MVC. System wspomagający pracę nauczycieli akademickich

Transkrypt

1 Projektowanie aplikacji biznesowych w oparciu o wzorzec projektowy MVC. System wspomagający pracę nauczycieli akademickich Miłosz Kubański 1, Agnieszka Kowalska 2 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ę tworzenia średnich oraz dużych systemów biznesowych z wykorzystaniem wzorca projektowego MVC. Przykładem zastosowania tej metodyki jest system wspomagający pracę nauczycieli akademickich, który powstał zgodnie z przedstawianym wzorcem. 1 Wstęp Komputery coraz częściej towarzyszą nam podczas codziennych czynności wykonywanych w naszym życiu. Pomagają nam podczas robienia zakupów przez internet, pozwalają kupić lub zarezerwować bilety, zamówić książki w bibliotece oraz w wielu innych przypadkach, gdzie nie jesteśmy nawet świadomi istnienia wsparcia systemów komputerowych. Systemy informatyczne doskonale sprawdzają się w sytuacjach, gdzie są zdefiniowane procedury postępowania w obrębie dziedziny którą obsługują. Wiele firm (a w szczególności instytucje finansowe takie jak banki) coraz częściej wykorzytuje systemy komputerowe do zapewnienia prawidłowości przebiegu procesów biznesowych. Instytucje te od lat posługują się ustalonymi i sprawdzonymi procedurami postępowania dla wszystkich zdarzeń, które mogą pojawić się podczas ich funkcjonowania. Dlatego też tak chętnie wybierają komputery w celu zapewnienia prawidłowej organizacji ich działania. Zapotrzebowanie na systemy wspomagające procesy biznesowe staje się coraz większe, ich złożoność rośnie, a nad procesem ich powstawania pracują coraz większe zespoły ludzi. Dlatego bardzo ważne jest odpowiednie wybranie procesu tworzenia oprogramowania jak i stworzenie przejrzystej architektury systemu pozwalającej na swobodne "poruszanie" się po niej wszystkim osobom biorącym udział w tworzeniu takiego systemu. W pracy zaproponowana zostanie metodyka tworzenia struktury aplikacji biznesowych na przykładzie systemu wspomagającego pracę nauczycieli akademickich. 1

2 2 Wymagania funkcjonalne i niefunkcjonalne systemu Głównym zadaniem systemu jest przechowywanie oraz zarządzanie informacjami na temat przebiegu studiów osób uczących się na wydziale Inżynierii Mechanicznej i Informatyki Politechniki Częstochowskiej. System przechowuje dane dotyczące ocen i obecności studentów na poszczególnych zajęciach, informacje dotyczące prowadzonych zajęć oraz list studentów. System umożliwia uprawnionym osobom wgląd w dane studentów, ich frekwencje na zajęciach oraz uzyskiwane oceny. Aplikacja oferuje pracownikom możliwość tworzenia list studentów uczestniczących na dane zajęcia, dostęp 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ęcia do różnych grup. Aplikacja oferuje możliwość przeglądania historii przebiegu studiów danego studenta oraz udostępniania 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ęciach. Statystyka ta umożliwi odnalezienie osób, które opuszczają zajęcia. Raport ocen umożliwi przedstawienie średniej ocen studentów: * Średnia dla całego roku przedstawia średnią ocen studentów z uwzględnieniem wszystkich przedmiotów dla całego roku. Umożliwi np. odnalezienie najlepszych studentów na danym roku. * Średnia dla danego przedmiotu przedstawia średnią ocen studentów z danego przedmiotu oraz oceny poszczególnych studentów. * Średnia dla danego prowadzącego przedstawia poszczególne oceny oraz ich średnią wystawioną przez danego prowadzącego w ramach jednego przedmiotu. Raport prowadzących umożliwi przedstawienie danych statystycznych dotyczących poszczególnych prowadzących i ilości prowadzonych przez nich zajęć w danym semestrze. Po zalogowaniu do systemu automatycznie tworzony jest profil dla danego użytkownika, prawa dostępu do poszczególnych grup oraz zestaw możliwych operacji. Prawa oraz operacje zostały podzielone na trzy kategorie "prowadzący", "zarządca" oraz "administrator". 2

3 Prowadzacy: * możliwość stworzenia oraz edycji listy studentów uczęstszających na zajęcia, mając jednocześnie wgląd w listę studentów w danej grupie dziekańskiej, * wyszukiwanie studenta w celu dostępu do jego danych w kontekście prowadzonego przedmiotu, * dodawanie oraz edycja ocen studenta, * sprawdzenie obecności na zajęciach, * dodawanie, przeglądanie oraz edycja notatek, * generowanie raportów ocen i obecności. Zarzadca: * mozliwość przeglądania wszystkich danych zawartych w systemie, * generowanie raportów (wszystkie raporty). Administrator: * tworzenie oraz edycja grup dziekańskich, * dodawanie i edycja zajęć z zaznaczeniem godzin, miejsca zajęć oraz przypisaniem osoby prowadzącej, * dodawanie i edycja przedmiotów, w ramach których będą prowadzone zajęcia, * 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ędą mieli dostęp tylko do danych im przysługującym. 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ę do ich wykonania duże zespoły ludzi. W takim zespole można wyróżnić pewne grupy ludzi zajmujących się poszczególnymi częściami systemu np. grupę analityków, projektantów systemu, programistów, projektantów stron, grafików etc. Każdy z ludzi biorących udział w projekcie posiada pewne predyspozycje, które umożliwiają przydzielenie ich do zadań, w których najlepiej mogą się 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łasną część systemu do 3

4 wykonania oraz by jego predyspozycje jak najlepiej pasowały do pracy, którą 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ęści ich czas wykonania zależał od pozostałych osób. Projekt takiego systemu musi być przejrzysty, tak aby każda z osób pracujących nad jego stworzeniem (nawet jeżeli zajmuje się tylko małym fragmentem systemu) mogła ogólnie zrozumieć jego architekturę i móc swobodnie "poruszać się" po nim. Biorąc pod uwagę wymagania jakie pojawiają się względem takiego projektu, najbardziej naturalnym rozwiązaniem wydaje się 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ę biznesowa. 4

5 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ę obsługą poszczególnych procesów biznesowych. Podział systemu na warstwy, które z kolei mogą 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ęścią programistów do warstwy modelu aplikacji. Każdy z członków poszczególnych zespołów jest zaznajomiony z ogólną funkcjonalnością jaką udostępniają warstwy, bez konieczności poznania szczegółów ich implementacji. Kolejną zaletą wykorzystania wzorca projektowego MVC jest możliwość zmiany funkcjonowania systemu modyfikując jedynie funkcjonalność pojedynczego modułu. 3.2 Struktura przedstawianego systemu System wspomagający pracę nauczycieli akademickich został zaprojektowany zgodnie z wzorcem MVC (Rys. 2). System udostępnia użytkownikowi dwie aplikacje klienckie. Pierwsza z nich została stworzona w J2SE z wykorzystaniem bibliotek SWING. Drugą aplikacją kliencką tego systemu jest aplikacja "web owa" korzystająca z technologi JSP (Struts wraz z JSF). Dzięki zastosowaniu wspomnianego wzorca projektowego stworzenie dodatkowego klienta udostępniającego identyczną funkcjonalność wymagało jedynie modyfikacji wartstwy prezentacji oraz niewielkiej ingerencji w warstwę kontrolera (moduły odpowiedzialne za wybór odpowiedniego widoku do prezentacji wyników) Model aplikacji Warstwa ta składa się z bazy danych ORACLE oraz szeregu funkcji pośredniczacych we wszystkich operacjach na danych (procedury składowane). Serwer bazy danych ORAC- LE przechowuje dane używane przez aplikacje klienckie oraz funkcje pośredniczące w operacjach na danych. Funkcje umieszczone na serwerze baz danych (SBD) są odpowiedzialne za integralność oraz bezpieczeństwo danych. Funkcje zaimplementowane w aplikacji (Rys. 3) zostały zgrupowane w poszczególne komponenty "encyjne", które są 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łącznie tej warstwy. Moduły należące do pozostałych warstw nie są wrażliwe na takie zmiany Warstwa prezentacji Warstwa prezentacji odpowiedzialna jest za komunikację z użytkownikiem. Warstwę tą stanowi aplikacja kliencka zaimplementowana z wykorzystaniem technologii JAVA 2SE. 5

6 Rys. 2: Ogólna architektura prezentowanego systemu Rys. 3: Warstwa modelu aplikacji prezentowanego systemu 6

7 Rys. 4: Warstwa modelu aplikacji klienta wykorzystującego biblioteki SWING W momencie wybrania opcji przez użytkownika, warstwa ta komunikuje sie bezpośrednio z kontrolerem, który decyduje jaką akcję (proces biznesowy) należy podjąć Kontroler Warstwa kontrolera (Rys. 5) odpowiedzialna jest za prawidłowy przebieg poszczególnych procesów biznesowych. Kontroler składa się z dwóch komponentów: ckontroler zawiera klasy udostępniające funkcje poszczególnych procesów biznesowych cuzytkownik zawiera klasy zarządzające profilami zalogowanych użytkowników Funckje zawarte w warstwie kontrolera operują na obiektach zawartych w warstwie modelu aplikacji. Rys. 5: Warstwa kontrolera prezentowanego systemu 4 Podsumowanie Dużą zaletą opisywanej metodyki tworzenia systemów komputerowych jest duża przejrzystość struktury systemu, możliwość szybkiego poprawienia błędów w systemie oraz 7

8 łatwa pielęgnacja napisanego kodu. Systemy zaprojektowane z wykorzystaniem wzorca MVC charakteryzują się dużą elastycznością oraz przenośnością. Zmiana architektury systemu, struktury logiki biznesowej, czy też sposobu prezentacji danych użytkownikowi wymaga niewielkiego nakładu pracy w porównaniu do innych rozwiązań. Kolejną zaletą stosowania podanego wzorca jest prostota testowania logiki oraz procesów biznesowych z pominięciem warstwy związanej z interfejsem użytkownika. Innym pozytywnym aspektem stosowania tej technologii jest możliwość korzystania z gotowych komponentów, które skracają czas implementacji systemu i podnoszą jego niezawodność. Do wad stosowania modelu MCV można zaliczyć zwiększenie liczby komponentów, które muszą zostać zaimplementowane w systemie, co w niewielkim stopniu zwiększa stopień złożoności projektu. Inną niedoskonałością związaną z podanym modelem jest ścisłe sprzężenie komponentów na poziomie interfejsów funkcyjnych. Wszelkie zmiany tych interfejsów niosą ze sobą konieczność zmian w kodzie warstw korzystających ze zmienionych modółów. Jednakże niedoskonałości modelu MVC są wręcz 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, [2] Gamma Erich, Helm Richard, Johnson Ralph, Vlissides John, Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku, WNT,