Zespół io07-7e: Agata Chrobak Kornel Jakubczyk Tomek Klukowski Przemek Kosiak. Projekt SZOP SAD

Podobne dokumenty
System SZOP, Przypadki użycia: Szczegółowy opis modyfikacji dokumentu. Agata Chrobak Kornel Jakubczyk Tomasz Klukowski Przemek Kosiak

Zespół: Agata Chrobak Kornel Jakubczyk Tomek Klukowski Przemek Kosiak. Projekt SZOP Plan testów

IO - SAD. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

Software Architecture Document dla systemu USOSweb 2.0. Adam Radziwończyk-Syta Karol Sobczak Marcin Koziński Grzegorz Paszt

Opis Architektury Systemu Galileo

Instrukcja użytkownika

Współpraca z platformą dokumentacja techniczna

Plan. Wprowadzenie. Co to jest APEX? Wprowadzenie. Administracja obszarem roboczym

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

Przypadki użycia produktu USOSweb 2.0. Karol Sobczak Adam Radziwończyk-Syta Marcin Koziński Grzegorz Paszt

Posiada (TAK / NIE. Zrzut ekranu. Opis funkcji

Wykonać Ćwiczenie: Active Directory, konfiguracja Podstawowa

Dokumentacja techniczna. Młodzieżowe Pośrednictwo Pracy

Współpraca z platformą Emp@tia. dokumentacja techniczna

Świadczenie usługi hurtowej wysyłki wiadomości SMS dla Urzędu Miasta Torunia w latach

Mazowiecki Elektroniczny Wniosek Aplikacyjny

EXSO-CORE - specyfikacja

Platforma elektronicznego obiegu dokumentów dla klientów KBA. Copyright by Korycka, Budziak & Audytorzy Sp. z o.o.

Bazy danych 2. Wykład 1

Narzędzie wspierające zarządzanie organizacj. Parentis Sp. z o.o. Kartoszyno,ul.Przemysłowa 5, Krokowa, info@parentis.pl

Software Architecture Document czyli jak i dlaczego w 14 minut ;-)

Instrukcja użytkownika. Aplikacja Smart Paczka DPD

Migracja z programu Symfonia Kadry i Płace wer 3.x do Kadr i Płac Forte

1.2 Prawa dostępu - Role

Instalacja krok po kroku /instalacja programu, serwera bazy danych/

uplook z modułem statlook program do audytu oprogramowania i kontroli czasu pracy

Instalacja aplikacji

Kadry Optivum, Płace Optivum. Jak przenieść dane na nowy komputer?

Podręcznik użytkownika Obieg dokumentów

Wykład I. Wprowadzenie do baz danych

epuap Archiwizacja w Osobistym Składzie Dokumentów

Konfiguracja konta pocztowego w Thunderbird

Kadry Optivum, Płace Optivum. Jak przenieść dane na nowy komputer?

Poradnik zetula.pl. Jak założyć konto na zetula.pl. i zabezpieczyć dane na swoim komputerze?

Release Notes Process Data Flow ("PDF" )

Płace Optivum. 1. Zainstalować serwer SQL (Microsoft SQL Server 2008 R2) oraz program Płace Optivum.

Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki. Paweł Parys. Nr albumu: Aukcjomat

Galileo - encyklopedia internetowa Plan testów

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. Opis oferowanego przedmiotu zamówienia

VinCent Administrator

Sieciowa instalacja Sekafi 3 SQL

Przed przystąpieniem do czytania dokumentu, proszę o zapoznanie się z podstawowym dokumentem Instrukcja obsługi AZU dla użytkownika zewnętrznego.

OPIS JAKOŚCIOWY (wymagania minimalne) ZESTAWIENIE PARAMETRÓW GRANICZNYCH

DOKUMENTACJA ADMINISTRATORA SYSTEMU INFORMATYCZNEGO POLSKI FADN

RODO a programy Matsol

Załącznik nr 1. Specyfikacja. Do tworzenia Mapy Kompetencji

System CRM dla banku. Analiza i projekt. Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski

Nowa Netia administrator firmy Nagrywanie połączeń-zarządzanie

OfficeObjects e-forms

System CRM dla banku. Analiza i projekt. Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski

Memeo Instant Backup Podręcznik Szybkiego Startu

firmy produkty intranet handel B2B projekty raporty notatki

Przed przystąpieniem do czytania dokumentu, proszę o zapoznanie się z podstawowym dokumentem Instrukcja obsługi AZU dla użytkownika zewnętrznego.

11. Autoryzacja użytkowników

Panel administracyjny serwera: admin.itl.pl

Sage Migrator 2019.e Migracja do Sage 50c wersja 2019.a i 2019.b

KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED

Plan prezentacji. 1. Archer DMS. 2. Organizacja archiwum. 3. Organizacja pracy. 4. Funkcjonalność systemu. Quality Software Solutions 2

Opis zmian w wersji G Oprogramowania do Obsługi SR/FA/SW/ST/DM

Wykaz zmian w programie SysLoger

Instrukcja obsługi Zaplecza epk w zakresie zarządzania tłumaczeniami opisów procedur, publikacji oraz poradników przedsiębiorcy

Poziomy wymagań Konieczny K Podstawowy- P Rozszerzający- R Dopełniający- D Uczeń: - zna rodzaje sieci - zna topologie sieciowe sieci

X-CONTROL -FUNKCJONALNOŚCI

Overlord - specyfikacja uzupełniająca. Jakub Gołębiowski Adam Kawa Piotr Krewski Tomasz Weksej

WYPOŻYCZALNIA BY CTI INSTRUKCJA

ul. Pogodna Olsztyn codeit@codeit.pl

SysLoger. Instrukcja obsługi. maj 2018 dla wersji aplikacji (wersja dokumentu 2.5)

Specyfikacja SYSTEMU ELEKTRONICZNEGO OBIEGU DOKUMENTÓW zintegrowany z platformą E-PUAP

-Próba otworzenia pliku bezpośrednio z płyty CD także kończy się niepowodzeniem, pojawia się komunikat System Windows nie może otworzyć tego pliku.

TWÓJ BIZNES. Nasz Obieg Dokumentów

DOTYCZY KLIENTA PKO BIURO OBSŁUGI LEASING ZAPYTANIE O INFORMACJĘ OTYCZY: DOSTAWY PLATFORMY ELEKTRONICZNE DLA PKO

Koncepcja wirtualnej pracowni GIS w oparciu o oprogramowanie open source

- 1 Laboratorium fotografii cyfrowej Foto Video Hennig

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia r.

ZAPYTANIE OFERTOWE. Wsparcie projektów celowych

Microsoft Office 2016 Krok po kroku

Ćwiczenie. Temat: TeamViewer - zarządzanie komputerami na odległość.

MOJA FIRMA PLUS. bankowość elektroniczna dla małych i średnich firm

Archiwizacja baz MSSQL /BKP_SQL/ opis oprogramowania

System generacji raportów

Platforma e-learningowa

Backup Premium Podręcznik Szybkiego Startu

Wykaz zmian w programie SysLoger

Dokumentacja projektu QUAIKE Architektura oprogramowania

Opis komunikacji na potrzeby integracji z systemem klienta (12 kwiecień, 2007)

Nazwa, typ, model, producent oferowanego urządzenia...

Podręcznik instalacji i konfiguracji aplikacji 7 Office Ship Control dla Microsoft Office 2007 i Siódemka S.A. Warszawa, dnia r.

Dokumentacja aplikacji Szachy online

Instrukcja instalacji usługi Sygnity Service

Część 3 - Konfiguracja

FUNKCJONALNOŚ C PORTAL B2B KAMELEON.ŚQL

INSTRUKCJA ADMINISTRATORA KLIENTA

Opis oferowanego przedmiotu zamówienia

Elektroniczne Dzienniki Urzędowe

System automatycznego wysyłania SMSów SaldoSMS

System Kancelaris. Zdalny dostęp do danych

Produkty. MKS Produkty

Zmiany funkcjonalne i lista obsłużonych zgłoszeń Comarch DMS

Zarządzaj projektami efektywnie i na wysokim poziomie. Enovatio Projects SYSTEM ZARZĄDZANIA PROJEKTAMI

Transkrypt:

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