Na etapie projektowania po przeanalizowaniu wielu wariantów podjęto decyzję, aby wykorzystać następujące technologie:
framework ASP .NET MVC,
języka C#,
framework Razor (warstwa wizualna).
Wynikło to z faktu, iż Microsoft posiada świetną rozwiązanie zarządzania workflow (Windows Workflow Foundation) i dla maksymalnej kompatybilności zastosowany został szereg innych technologii tej firmy, czyli:
C#
ASP .NET
Razor
Entity Framework
Model View Controller (MVC) został wybrany jako naturalny wzorzec projektowy z racji webowej charakterystyki systemu, oraz faktu, że był on najszerzej znany wśród członków zespołu. Dodatkowo wyraźny podział MVC na trzy elementy:
trwałość danych
mechanika aplikacji
warstwa wizualna
pozwolił na wytworzenie podzespołów, które pracowały równolegle, co zapewniło maksymalną efektywność pracy.
Tworzenie projektu systemu oparto o zasady zgodnych z DDD (Domain Driven Design), czyli metodologii, która skupia się wokół maksymalnego odwzorowania rzeczywistości. Jest to szczególnie ważne w zespole, w którym nie każdy miał styczność z budową rozbudowanych systemów, ale posiada wiedzę merytoryczną dotyczącą problematyki zagadnień związanych z funkcjonowaniem systemu. Wynika to z faktu, iż zarówno osoba projektująca, analityk czy programista rozmawiają o procesie / modelu, który faktycznie ma miejsce w rzeczywistości.
Celem fazy projektowania było zapewnienie możliwości zakodowania wszystkich funkcjonalności opracowanych na etapie analizy lub takie przygotowanie systemu, aby ewentualny rozwój istniejących możliwości systemu był jak najłatwiejszy.
5.1. Zastosowane rozwiązania
Rozwiązanie zaproponowanie w toku fazy projektowania udało się przygotować bez potrzeby znacznych zmian w stosunku do diagramu analitycznego. Dzięki czemu przejście między fazami analizy, projektowania i implementacji odbyło się płynnie. Rozwój systemu był cały czas kontrolowany z perspektywy analitycznej i projektowej - bez straty czasu na rozpoznawanie i rozumienie różnić pomiędzy tymi etapami. Projekt był kontrolowany iteracyjnie. Po implementacji danego fragmentu funkcjonalności regularnie odbywała się kontrola zgodności z modelem analitycznym, a następnie zgodności z projektem. Również sam projekt podlegał kilkukrotnemu sprawdzeniu poprawności względem ustaleń z etapu analizy (etapu pierwotnego jak i późniejszych iteracji).
Rysunek 60. Klasa asocjacyjna PrivilegeType. Źródło: Opracowanie własne.
Pewne niezbędne zmiany miały jednak miejsce. Dla zwiększenia wydajności i wygody obsługi zarządzania uprawnieniami klasa asocjacyjna, umiejscowiona pomiędzy klasą Pracownik a klasą Uprawnienia Systemowe stała się modelem danych w bezpośredniej asocjacji z modelem Employee. Wynika to z faktu, że uprawnienia systemowe mogą występować w różnych konstelacjach.
Dodatkowo bezpośredni dostęp do konfiguracji jest ważniejszy niż wgląd do opisu uprawnień, utworzonych na potrzeby zarządzania nimi.
Kwestię agregacji rozwiązano poprzez zastosowanie kolekcji w modelu Employee, będącym częścią grupy (model Group). Jak widać na rysunku nr 61, model Employee, który jest składową wielu grup użytkowników, posiada pole GroupList. Pole to przetrzymuje kolekcję grup do których należy. Tym samym zachowana została zasada, że całość nie zarządza czasem istnienia części.
Jedną z ważnych funkcjonalności systemu Service Desk jest generyczność. Ma ona szczególne znaczenie w elementach takich jak budowanie formularzy (przy typie zgłoszenia) i produktów.
Produkty dzielą się na urządzenia i usługi. Są to dwie, bardzo odmienne grupy. Produkty mają parametry fizyczne takie jak: wymiary, masa, żywotność baterii itp. Usługi zaś definiowane są przez bardziej umowne elementy jak: skuteczność czy niezawodność. Aby zapewnić możliwość obsługi tego mechanizmu, utworzona została opcja definiowania parametrów, które mogą opisywać produkty i przydzielenie ich do odpowiedniej grupy (urządzenia lub usługi). Przy każdym modelu wybierane są tylko te parametry, które faktycznie go opisują. W ten sposób każdy klient korzystający z systemu będzie widział jedynie te parametry, które faktycznie definiują jego produkty. W tym celu utworzony został zestaw własności produktów.
Rysunek 61. Klasa Employee. Źródło: Opracowanie własne.
Projekt analityczny musiał zostać zmodyfikowany, gdyż zakładał zwykłe dziedziczenie specjalistycznych własności z abstrakcyjnej, ogólnej własności. W celu maksymalizacji elastyczności zastosowano asocjację z modelem opisującym własności produktu, który to zawiera kolekcję własności (poprzez kolejną asocjację)
Rysunek 62. Projekt implementacyjny Produktów i ich cech. Źródło: Opracowanie własne.
Uproszczony schemat własności został zastosowany w przypadku generyczności formularzy dla danego typu zgłoszenia. W tym przypadku, konkretny typ zgłoszenia posiada kolekcję właściwości określonego typu. Ich kolejność definiuje porządek wyświetlania pól formularza. Można byłozastosować tu uproszczony (zgodny z założeniami analizy) schemat, ponieważ typy pól formularza html są z góry zdefiniowane i znane. Jedyne zmiana, która została tu dokonana polega na możliwości definiowania podtypów pól. Dla przykładu model PropertyDate jest niczym innym jak zwykłym polem tekstowym, jednak można wykorzystać podtyp i wygenerować odpowiednie skrypty do budowania kalendarza tzw. datepickera.
Rysunek 63. Projekt generyczności parametrów Produktów. Źródło: Opracowanie własne.
5.2. Opis encji
Rysunek 64. Projekt implementacji firmy. Źródło: Opracowanie własne.
Firma jest to główna jednostka opisująca klienta. Zawiera wszystkie informacje na jego temat. Najważniejszymi elementami w kontekście workflow są tu: Umowa (Contract - potwierdza nawiązanie współpracy), Lokalizacja (Location - lokalizacje w których może być dokonana usługa serwisowa), osoby zgłaszające (RequestingPerson - osoby upoważnione do zgłaszania i prowadzenia spraw usług).
Rysunek 65. Projekt implementacji produktu. Źródło: Opracowanie własne.
Produkt to rzecz/usługa, która może podlegać serwisowaniu lub naprawie. Opisany jest przez zbiór elementów, takich jak: skuteczność, wymiary, waga, funkcjonalności.
Rysunek 66. Projekt implementacji pracownika. Źródło: Opracowanie własne.
Uprawnienia dotyczą Pracowników systemu. Ich celem jest udostępnianie odpowiednim osobom tylko tych elementów, do których faktycznie potrzebują dostępu. Służy to ograniczeniu błędnych procedur wewnątrz firmy.