Zespół io07-7e: Agata Chrobak Kornel Jakubczyk Tomek Klukowski Przemek Kosiak Projekt SZOP SAD
Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................ 3 1.3 Definicje....................................... 3 1.4 Omówienie reszty dokumentu........................... 3 2 Cele i ograniczenia nałożone na architekturę systemu 4 2.1 Platforma techniczna................................ 4 2.2 Bezpieczeństwo................................... 4 2.3 Trwałość....................................... 4 2.4 Niezawodność/Dostępność............................. 4 2.5 Wydajność...................................... 5 2.6 Regionalizacja.................................... 5 3 Przeglad przypadków użycia 6 3.1 Wyszukiwanie dokumentu............................. 6 3.2 Odczytaj dokument................................. 6 3.3 Utworzenie schematu obiegu............................ 7 3.4 Wprowadzenie nowego dokumentu......................... 7 3.5 Zarządzanie grupami................................ 7 3.6 Kontroluj efektywność obiegu........................... 7 3.7 Kontrola stanu dokumentu............................. 7 3.8 Zarządzanie użytkownikami............................ 7 4 Realizacje przypadków użycia 7 4.1 Edycja dokumentu................................. 7 4.2 Odczytaj dokument................................. 8 4.3 Utworzenie schematu obiegu............................ 8 4.4 Wprowadzenie nowego dokumentu......................... 9 4.5 Zarządzanie grupami................................ 10 4.6 Kontroluj efektywność obiegu........................... 10 4.7 Kontrola stanu dokumentu............................. 11 4.8 Zarządzanie użytkownikami............................ 11 5 Dekompozycja logiczna systemu 11 5.1 Omówienie architektury logicznej......................... 12 5.2 Najważniejsze komponenty............................. 13 6 Dekompozycja na procesy 15 7 Instalacja systemu 15 2
8 Implementacja systemu 16 8.1 Warstwy....................................... 16 9 Przechowywane dane 16 10 Wydajność systemu 17 11 Jakość 17 1 Wprowadzenie 1.1 Cel Dokumentacja Architektury Systemowej (SAD) zawiera kompletny opis budowy systemu SZOP. Jego zadaniem jest uchwycic i przekazywac informacje o ważnych decyzjach związanych z architekturą systemu podjętych podczas realizacji projektu. 1.2 Zakres Dokument ten swoim zakresem obejmuje opis architektury systemu zarządzającego obiegiem dokumentów tworzonego przez zespół io07-7e. 1.3 Definicje SAD - Software Architecture Document, Dokumentacja Architektury Systemowej SZOP - System Zarządzania Obiegiem Papierów DMS - Document Menagement System - System zarządzania obiegiem, przechowywaniem i udostępnianiem dokumentów w firmie metadata - dodatkowe informacje dołączone do dokumentu, ale nie wchodzące w jego skład OCR - narzędzie służace do konwersji do postaci elektronicznej dokumentu w formie papierowej pdf - format dokumentów umożliwiający ich przenoszenie między użytkownikami zachowując jednolity wygląd plug-in - dodatek do innego programu, instalowany niezależnie, rozszerzający jego funkcjonalność 1.4 Omówienie reszty dokumentu W celu pełnego udokumentowania wszystkich aspektów budowy systemu, Dokumentacja Architektury Systemowej zawiera nastepujace sekcje: Sekcja 2: Ta część opisuje wymagania software owe i cele mające wpływ na architekturę Sekcja 3: Krótki opis przypadków użycia 3
Sekcja 4: Opis sposobu realizacji przypadków użycia Sekcja 5: Przedstawienie podziału na warstwy Sekcja 6: Aspekt sprzętowy systemu Sekcja 7: Omówienie pakietów wymagających implementacji Sekcja 8: Ograniczenia ilościowe przechowywanych danych Sekcja 9: Wydajność Sekcja 10: Jakość 2 Cele i ograniczenia nałożone na architekturę systemu 2.1 Platforma techniczna Wykorzystana zostanie platforma J2EE, zarówmo do budowy aplikacji klienckiej i obsługi serwera. Wykorzystamy wbudowaną w nią obsługę transakcji. Jako serwer bazy danych planujemy użyć PostgreSQL. 2.2 Bezpieczeństwo System musi zapewniać bezpieczeństwo przy korzystaniu zarówno z sieci lokalnej jaki i przez Internet. Aplikacja musi zapewniać podstawowe aspekty bezpieczeństwa: 1. Autentyfikacja użytkowników: logowanie z użyciem nazwy użytkownika i hasła 2. Autoryzacja: przynależność do grupy definiuje dostęp do dokumentów i edycji schematów obiegu Wymagania niezbędne przy dostępie przez sieć Internet: 1. Poufność: tajne dane muszą być kodowane (ważne dokumenty) 2. Integralnośc danych: przesyłane dane nie mogą zostać zmodyfikowane podczas transportu 3. Rewizja: każda ważna akcja musi zostać zalogowana Zostanie użyty model bezpieczeństwa J2EE 2.3 Trwałość Trwałość danych zostanie zapewniona przez relacyjną bazę danych. 2.4 Niezawodność/Dostępność Minimalną dostępnością jest 10/5: 10 godzin dziennie, 5 dni w tygodniu Docelową dostępnością jest 16/7: 16 godzin dziennie, 7 dni w tygodniu Pozostały czas jest zarezerwowany na czynności administracyjne 4
2.5 Wydajność 1. Czas wyszukiwania dokumentu musi być mniejszy niż 4s 2. Czas znajdowania następcy w schemacie obiegu nie przekroczy 4s 3. Czas weryfikacji schematu obiegu nie może przekraczać 10s 2.6 Regionalizacja Polska jako docelowy rynek pociąga za sobą konieczność obsługi języka polskiego. Warstwa prezentacji i modelu musi obsługiwać kodowanie ISO8859-2 i UTF8. 5
3 Przeglad przypadków użycia 3.1 Wyszukiwanie dokumentu Pozwala na sprawne wyszukiwanie dokumentu. 3.2 Odczytaj dokument Pozwala odczytać wybrany dokument w odpowiednim formacie. 6
3.3 Utworzenie schematu obiegu Daje możliwość definiowania schematu obiegu dla poszczególnych dokumentów, według którego potem będzie przemieszczał się dokument. 3.4 Wprowadzenie nowego dokumentu Pozwala na wprowadzenie do systemu nowego dokumentu. Dokument ten może być stworzony w systemie lub wprowadzony do systemu, jeżeli już istnieje. 3.5 Zarzadzanie grupami Umożliwia tworzenie nowych grup, modyfikowanie ich składu oraz praw. 3.6 Kontroluj efektywność obiegu Ten przypadek użycia pozala na kontrolowanie efektywności obiegu i ewentualne poprawianie jej. 3.7 Kontrola stanu dokumentu Pozwala uprawnionemu Użytkownikowi na sprawdzenie, w jakim stanie znajduje się dokument. Ewentualnie sprawdza czy przypisany mu schemat obiegu jest optymalny. 3.8 Zarzadzanie użytkownikami Umożliwia zarządzanie i kontrolowanie schematu komunikacji między modułami wewnątrz systemu oraz zewnętrznymi elementami pracy podwładnych. 4 Realizacje przypadków użycia 4.1 Edycja dokumentu Pracownik wskazuje dokument. Zgłasza chęć edycji wybranego dokumentu. System sprawdza, czy Pracownik ma dostęp do edycji dokumentu. System włącza odpowiedni Edytor. Pracownik wprowadza zmiany. Pracownik zatwierdza zmiany w Systemie. System zapisuje nową wersję dokumentu. System pyta się o chęć modyfikacji informacji o dokumencie. Jeżeli Pracownik potwierdzi chęć, modyfikuje informacje o dokumencie. System zachowuje zmiany dotyczce nowej wersji dokumentu. System pyta o zakończenie danego etapu edycji. Pracownik kończy dany etap edycji bądź odrzuca tę możliwość. Jeżęli pracownik kończy dany etap edycji, System przekazuje dokument dalej wg okrelonej dla niego ścieżki, a System wysyła powiadomienia do Zainteresowanych. 7
4.2 Odczytaj dokument Pracownik zalogowany w systemie wybiera potrzebny mu dokument ze wskaznego katalogu albo wyszukuje go wg wybranych kryteriow (zawartości, słów kluczowych, typu, nazwy). Nastęnie prosi o otwarcie tego dokumentu. Jeżeli System wspiera jego format, uruchamia odpowiedni Edytor, gdzie Pracownik ogląda dokument. Jeśli system nie rozpoznaje formatu dokumentu, prosi Pracownika o wybów odpowiedniego edytora z listy dostępnych. Pracownik wskazuje odpowiedni edytor. Rysunek 1: Wybór dokumentu 4.3 Utworzenie schematu obiegu Zalogowany Przełożony z odpowiednimi uprawnieniami tworzy w systemie nowy typ dokumentu lub wskazuje już istniejący, dla którego nie określono jeszcze schematu obiegu. Określa stany (odpowiadające fazom prac), w jakich może znajdować się dany typ dokumentu oraz określa ich kolejność. Następnie dla każdego stanu określa, w jakie miejsca System może skierować dokument. Alternatywne scenariusze:jeżeli dla wybranego typu dokumentu jest ju utworzony schemat obiegu, System sprawdza w jakich stanach znajdują się aktualnie dokumenty tego typu. Następnie dla każdego stanu w którym są akutalnie dokumenty Przeołony wskazuje odpowiadajcy im stan w nowym schemacie obiegu. 8
Rysunek 2: Tworzenie schematu obiegu 4.4 Wprowadzenie nowego dokumentu Użytkownik wyraża chęć dodania dokumentu, wybiera sposób wprowadzenia dokumentu do systemu (np. pobranie z dysku komputera, dodanie za pomoc skanera), po czym dokonuje wprowadzenia. System prezentuje zdefiniowane schematy obiegu. Użytkownik wybiera odpowiedni schemat. System prosi o podanie informacji o dokumencie (takich jak opis, słowa kluczowe czy autor). Użytkownik wypełnia formularz i zatwierdza zmiany. System zapisuje dokument i wykonuje pierwszy krok schematu obiegu. Rysunek 3: Wprowadzenie nowego dokumentu 9
4.5 Zarzadzanie grupami Administrator wybiera czy chce stworzyć nową grupę czy edytować istniejącą. Jeśli Administrator zgasza chęć utworzenia nowej grupy, to jest ona dodawana do Systemu. Administrator z listy pracowników wybiera kolejne nazwiska i dodaje do nowoutworzonej grupy. Następnie spośród czonków grupy wybiera jej kierownika. Jeśli Administrator wybrał opcję edycji istniejącej grupy, to wskazuje grupę którą chce edytować. Następnie może dodawać i usuwać jej czonków, a take zmieniać kierownika tej grupy. Administrator może także usunąć wskazaną grupę z Systemu. Rysunek 4: Zarządzanie grupami użytkowników 4.6 Kontroluj efektywność obiegu Zalogowany Przełożony wskazuje w Systemie interesujcy go typ dokumentu. System prezentuje diagram informujący o ilości dokumentów przechodzących przez każdy stan systemu, na którym oznacza dodatkowo stany które stanowi wąskie garda. Przełożony ogląda statystyki dla wskazanych przez niego stanów dotyczące ilości i czasu przechowywania dokumentu w różnych zdefiniowanych dla niego miejscach. System proponuje rozszerzenia miejsc, gdzie może zostać skierowany dokument, a które nie są w pełni wykorzystywane. Przełożony wybiera któreś z zaproponowanych rozwiązań. 10
4.7 Kontrola stanu dokumentu Zalogowany Przeołony wskazuje dokument, którego stan chce skontrolować. Wybiera interesującą go wersję. System otwiera ją za pomocą Edytora. Przełożony moze wprowadzać swoje uwagi do dokumentu poprzez nadanie mu odpowiedniego komentarza. Rysunek 5: Kontrola stanu dokumentu 4.8 Zarzadzanie użytkownikami Administrator wybiera czy chce dodać nowego użytkownika, czy edytować dane istniejcego. Jeżeli wybrał dodawanie nowego, to wprowadza dane nowego użytkownika do Systemu, a nastęnie z listy grup wybiera te, do ktorych ma należeć nowoutworzony użytkownik. Następnie może nadać mu pewne uprawnienia. Jeśli Administrator wybrał edycję istniejącego użytkownika, to wskazuje użytkownika, którego chce edytować Administrator może edytować jego dane, dodać lub odebrać mu uprawnienia, dopisać do innej grupy, bd usunć z grupy lub Systemu. 5 Dekompozycja logiczna systemu Projekt SZOP został podzielony na warstwy zgodnie ze schematem Model View Presenter. Zapewnia to rozdzielenie interfejsu od logiki systemu oraz potencjalną wymianę części prezentacji. Dodatkowo ogranicza to zależności między niesąsiednimi warstwami. Taki wybór schematu podziału systemu zapewnia łatwą modyfikowalność systemu oraz powinien ułatwić implementację. 11
Rysunek 6: Diagram architektury logicznej systemu. 5.1 Omówienie architektury logicznej Wyróżniliśmy następujące warstwy : Prezentacja odpowiada za generowanie interfejsu użytkownika w sposób rozdzielony od reszty systemu, z założenia powinna być łatwo wymienialna. Interfejs użytkownika i administratora są całkowicie różne, stąd przewidzieliśmy dwa odrębne pakiety. Prawdopodobnie zostaną one odmiennie zaimplementowane. Aplikacja pełni rolę kontrolera interfejsu. Dzięki jej istnieniu reszta systemu nie bedzie posiadać żadnych zależności z warstwą prezentacji. Model to część systemu reprezentująca obiekty biznesowe w systemie, logikę działania przypadków użycia oraz zachowania się obiektów. Infrastruktura Biznesowa została wydzielona jako zbiór usług dzielonych między różnymi systemami reprezentującymi niskopoziomowe zapotrzebowania biznesowe. Szczególnie istotny jest tu system logów, na który może być zapotrzebowanie w innych podobnych aplikacjach. Moduły stąd będa wykorzystywne w warstwie modelu. Usługi techniczne to niskopoziomowe reprezentacje zewnętrznych obiektów, usług zewnętrznych systemów. Są one wprowadzone w celu zapewnienia niezależności od zewnętrznych dostawców i łatwego modyfikowania systemu. Adapter edytora pozwala na 12
abstrachowanie od konkretnego edytora dla danego formatu dokumentów, co jest konieczne ze względu na ich potencjalną różnorodność. Rysunek 7: Schemat komunikacji między modułami wewnątrz systemu oraz zewnętrznymi elementami 5.2 Najważniejsze komponenty Reprezentatywnym przypadkiem użycia dla funkcjonalności systemu jest edycja dokumentu. Pakiety związane z jego obsługą stanowią główną funkcjonalność systemu. Biorą w nim udział następujące ważne pakiety: archiwizacja do zapewnienia trwałości zmian. Sesja do sprawdzania ważności konta użytkownika. System uprawnień do kontrolowania zezwoleń na dokonanie operacji oraz inne wskazane na ponizszych diagramach. Przebieg edycji 13
14
Kluczowe komponenty i klasy biorące udział w edycji dokumentu z perspektywy modyfikacji stanu systemu. Kluczowym dla powodzenia projektu bedzie pakiet OptymalizacjaPrzebiegu, gdyż jest to funkcjonalność, która ma wyróżniać nasz projekt. 6 Dekompozycja na procesy System po stronie klienta składa sie z jednego procesu. System po stronie serwera będzie używał wątków do osługi równoległych tranzakcji, są one automatycznie zarządzane przez maszynę javy. 7 Instalacja systemu 1. Serwer Aplikacji: HP ProLiant ML310 2. Serwer Bazy Danych: HP ProLiant ML310 z 2 dyskami Seagate ST3250620AS połączonymi w macierz RAID 1 Zakładamy, że komputer użytkownika ma zainstalowany JRE w wersji conajmniej 5. Serwer również powinien posiadać zainstalowną J2EE w wersji conajmniej 5. Serwer bazy danych powinien mieć zainstalowany serwer Postgresql w wersji 8.1 15
8 Implementacja systemu Rysunek 8: Ogólny schemat systemu Implementacja systemu wynika z przedstawinej wcześniej architektury logicznej i realizacji przypadków użycia. 8.1 Warstwy Omówione wcześniej warstwy znajdą swoje odzwierciedlenie w implementacji następujących pakietów: Prezentacja - interfejs użytkownika, interfejs administratora. Aplikacja - aplikacja kliencka, aplikacja administratora, weryfikator danych Model - system logów, archiwum dokumentów, schematy obiegu, teczki dokumentów, moduł użytkownicy, projekty, statystki, optymalizacja schematu obiegu, uprawnienia użytkownika. Infrastruktura biznesowa - Archiwum logów Usługi techniczne - adapter edytora, adapter ocr, archiwizacja(adapter bazy danych), Obsługa powiadomień(za pomocą sms email). 9 Przechowywane dane W wersji podstawowej System ma być zdolny do przechowania co najmniej: 1. 1 000 000 dokumentów 2. 1 000 pracowników 16
3. 1 000 schematów obiegu 4. 100 grup użytkowników Poza tym System musi przechowywać dane o każdej edycji dokumentów, edycji metainformacji o dokumencie, edycji schematów obiegu, edycji składu grup. Dla większego bezpieczeństwa codziennie w godzinach nocnych przeprowadzany będzie zrzut nowych danych z Systemu, by utworzyć ich kopię zapasową na wypadek jego awarii, stąd wszystkie dane przechowywane będą niejako dwukrotnie. 10 Wydajność systemu System ma umożliwiać płynną pracę, gdy jednocześnie zalogowanych jest do stu pracowników. Rozumiemy przez to, że wówczas w 95% przypadków: 1. Czas wyszukiwania dokumentu musi być mniejszy niż 4s 2. Czas znajdowania następcy w schemacie obiegu nie przekroczy 4s 3. Czas weryfikacji schematu obiegu nie może przekraczać 10s W przypadku większej ilości zalogowanych pracowników czasy te mogą się wydłużyć, jednak nie na tyle, by spowodować paraliż działania Systemu. 11 Jakość Skalarność: System SZOP przewidziany jest do stosowania w małych i średnich firmach. Chcemy by w takim przypadku obsługiwany był przez co najmniej dwie maszyny, z których każda ma zapewniać możliwość zdeponowania wymaganej ilości miliona dokumentów (jedna może być wolniejsza i ma przechowywać kopie zapasowe stanu systemu). W przypadku zbliżania się do tego limitu (powyżej 950 000 dokumentów) System ma sygnalizować konieczność rozszerzenia. System ma być zbudowany w ten sposób, by w ciągu weekendu można było zwiększyć ilość możliwych do przechowania danych (przez dostawienie dodatkowych maszyn lub przez doinstalowanie dodatkowych dysków), przy czym pojemność dysków przeznaczonych na przechowywanie kopii zapasowej systemu ma być równa (z tolerancją 5%) pojemności tych dysków, które mają służyć przechowywaniu bieżącego stanu systemu. Dostępność: Dla systemu tego typu ważne jest by był on dostępny co najmniej w czasie pracy firmy, jednak nie musi być on dostępny 24h na dobę i 7 dni w tygodniu (taka potrzeba zachodzi jedynie w sytuacjach wyjątkowych). Minimalną dostępnością jest 10/5: 10 godzin dziennie, 5 dni w tygodniu 17
Docelową dostępnością jest 16/7: 16 godzin dziennie, 7 dni w tygodniu W godzinach nocnych odbywać musi się kopiowanie danych na zapasowy serwer tak, by zapewnić bezpieczeństwo, więc w ciągu doby należy na pewno nastąpić musi czasowe wstrzymanie pracy systemu Przenośność: Nasz system oparty będzie o technologię J2EE, co zapewni praktycznie niezależność od platformy sprzętowej i systemowej. Do uruchomienia aplikacji klienckiej potrzebny będzie komputer z wirtualną maszyną Javy oraz dostępem do internetu. Bezpieczeństwo: System ma zapewniać bezpieczeństwo poprzez autentyfikacje użytkowników (logowanie z użyciem nazwy użytkownika i hasła). Na podstawie przynależności użytkownika do grup, zapewniać ma użytkownikom będących ich członkami dostęp jedynie do tych dokumentów i edycji schematów obiegu, do których grupy te mają uprawnienia. Inne wymagania bezpieczeństwa to szyfrowanie dokumentów przy przesyłaniu od klienta do serwera, sprawdzanie autentyczności danych (kodowane unikalnym kluczem użytkownika, uniemożliwiającym podszywanie się pod niego, a także kody korekcyjne błędów), logowanie przez System wszystkich podjętych przez użytkowników akcji. Poza tym każdej nocy będą w celach bezpieczeństwa wykonywane kopie zapasowe stanu Systemu Zostanie użyty model bezpieczeństwa J2EE $Log: $ 18