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

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

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

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

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki Promotor dr inż. Paweł Figat

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja

REFERAT O PRACY DYPLOMOWEJ

Cechy systemu X Window: otwartość niezależność od producentów i od sprzętu, dostępny kod źródłowy; architektura klient-serwer;

Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor

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

Instrukcja instalacji i obsługi programu Szpieg 3

Dokumentacja projektu QUAIKE Architektura oprogramowania

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

Opis Architektury Systemu Galileo

EXSO-CORE - specyfikacja

Forum Client - Spring in Swing

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

I. Informacje ogólne. Jednym z takich systemów jest Mambo.

Podstawowe możliwości programu Spectro Market Faktura

System Wniosków DWZ AGH

Aplikacja serwerowa Platformy Prezentacyjnej Opis produktu

Bazy danych 2. Wykład 1

Szpieg 2.0 Instrukcja użytkownika

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

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Dokumentacja aplikacji Szachy online

GS2TelCOMM. Rozszerzenie do TelCOMM 2.0. Opracował: Michał Siatkowski Zatwierdził: IMIĘ I NAZWISKO

REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i realizacja serwisu ogłoszeń z inteligentną wyszukiwarką

OFERTA NA SYSTEM LIVE STREAMING

Spis treści MONITOR PRACY... 4

AUREA BPM Oracle. TECNA Sp. z o.o. Strona 1 z 7

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

SPECYFIKACJA WYMAGAŃ. w zakresie migracji i uruchomienia nowego serwisu WWW na potrzeby PKP S.A.

IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

Biuletyn techniczny. CDN OPT!MA 8.5 Wskazówki dotyczące instalacji programu. Copyright 2006 COMARCH SA

OMNITRACKER Wersja testowa. Szybki przewodnik instalacji

Wykład I. Wprowadzenie do baz danych

Specyfikacja implementacyjna aplikacji serwerowej

AKADEMIA GÓRNICZO-HUTNICZA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki

Tomasz Grześ. Systemy zarządzania treścią

OMNITRACKER Wersja testowa. Szybki przewodnik instalacji

Szczegółowa specyfikacja funkcjonalności zamawianego oprogramowania.

ZAMAWIAJĄCY. CONCEPTO Sp. z o.o.

Podręcznik użytkownika Obieg dokumentów

Organizacja zajęć BAZY DANYCH II WYKŁAD 1. Plan wykładu. SZBD Oracle

System sprzedaŝy rezerwacji

Podręcznik Użytkownika LSI WRPO

Wykonać Ćwiczenie: Active Directory, konfiguracja Podstawowa

Narzędzie informatyczne do modelowania, zarządzania i dokumentowania procesów systemu zarządzania jakością

Portal wykładowco w. Jeżeli chcesz rozpocząć pracę z portalem, skontaktuj się ze swoim planistą. Planista utworzy konto logowania dla Ciebie.

E-commerce. Genialnie proste tworzenie serwisów w PHP i MySQL.

Platforma e-learningowa

Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B

I. Raport wykonywalności projektu

Kompleksowe tworzenie aplikacji klasy Desktop z wykorzystaniem SWT i

Sprawa numer: BAK.WZP Warszawa, dnia 16 sierpnia 2016 r.

11. Autoryzacja użytkowników

XQTav - reprezentacja diagramów przepływu prac w formacie SCUFL przy pomocy XQuery

Uniwersytet Mikołaja Kopernika w Toruniu. Profilowanie ruchu sieciowego w systemie GNU/Linux

Dokument Detaliczny Projektu

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>

Firma Informatyczna ASDER. Prezentacja. Serwer danych lokalnych. Przemysław Kroczak ASDER

Web frameworks do budowy aplikacji zgodnych z J2EE

Platforma e-learningowa

Tworzenie aplikacji Web Alicja Zwiewka. Page 1

PLAN WYNIKOWY PROGRAMOWANIE APLIKACJI INTERNETOWYCH. KL IV TI 6 godziny tygodniowo (6x15 tygodni =90 godzin ),

Dokumentacja systemu NTP rekrut. Autor: Sławomir Miller

LABORATORIUM 8,9: BAZA DANYCH MS-ACCESS

Tworzenie i obsługa wirtualnego laboratorium komputerowego

SZKOLENIE: Administrator baz danych. Cel szkolenia

Instalacja aplikacji

OPIS i SPECYFIKACJA TECHNICZNA

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Część 3 - Konfiguracja

Wzorce projektowe cz. II. Wzorce projektowe cz. II 1/35

Praca dyplomowa. Program do monitorowania i diagnostyki działania sieci CAN. Temat pracy: Temat Gdańsk Autor: Łukasz Olejarz

Ruby on Rails. Supersilnik WWW. Łukasz Włodarczyk

Elektroniczny. Obieg Dokumentów SPRAWNA WYMIANA INFORMACJI W FIRMIE SKUTECZNA APLIKACJA DO ZARZĄDZANIA OBIEGIEM DOKUMENTÓW SPRAWNA WYMIANA

ZAŁĄCZNIK NR 3 OPIS PRZEDMIOTU ZAMÓWIENIA DOTYCZĄCY WDROŻENIA PLATFORMY ZAKUPOWEJ

Rok szkolny 2015/16 Sylwester Gieszczyk. Wymagania edukacyjne w technikum. ADMINISTROWANIE BAZAMI DANYCH kl. 4c

REFERAT O PRACY DYPLOMOWEJ

Referat Pracy Dyplomowej

REFERAT PRACY DYPLOMOWEJ

Wykład 1 Inżynieria Oprogramowania

Samokontrola postępów w nauce z wykorzystaniem Internetu. Wprowadzenie

Programowanie obiektowe

SKRÓCONY OPIS systemu lojalnościowego

Wdrożenie modułu płatności eservice. dla systemu Magento

Wymagane jest podłączenie serwera do Internetu (konieczne do zdalnego dostępu).

Tom 6 Opis oprogramowania

Instrukcja składania wniosku o dofinansowanie w systemie informatycznym IP na potrzeby konkursu nr 1/1.1.1/2015

Spis treści 1. Oprogramowanie wizualizacyjne IFTER EQU Dodanie integracji CKD Wprowadzanie konfiguracji do programu EQU... 6 a.

Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC

SSI Katalog. Program do katalogowania zawartości dysków. Dariusz Kalinowski

DHL CAS ORACLE Wymagania oraz instalacja

Wdrożenie modułu płatności eservice. dla systemu Gekosale 1.4

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

Systemy obiegu informacji i Protokół SWAP "CC"

Projektowanie architektury systemu rozproszonego. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Transkrypt:

Software Architecture Document czyli jak i dlaczego w 14 minut ;-) Łukasz Bieniasz-Krzywiec Dariusz Leniowski Jakub Łącki 23 maja 2007 1

Spis treści 1 Wprowadzenie 3 1.1 Cel............................................. 3 1.2 Zakres........................................... 3 1.3 Definicje.......................................... 3 1.4 Załączniki......................................... 3 2 Prezentacja architektury systemu 3 3 Założenia i zależności 4 4 Dekompozycja logiczna systemu 4 4.1 Omówienie........................................ 4 4.2 Najważniejsze komponenty................................ 6 4.2.1 Obsługa użytkownika............................... 6 4.2.2 Obsługa formularza................................ 6 4.2.3 Kontrola Praw Dostępu.............................. 6 4.2.4 Wiadomości systemowe............................. 6 4.2.5 Wyszukiwanie.................................. 6 4.2.6 Obsługa błędów................................. 7 5 Przeglad przypadków użycia 7 5.1 Realizacja tworzenia formularza............................. 8 5.2 Diagram Zależności.................................... 9 5.3 Diagramy przebiegu.................................... 10 6 Dekompozycja na procesy 11 7 Instalacja systemu 12 8 Implementacja systemu 12 9 Przechowywane dane 13 10 Wydajność systemu 13 11 Jakość 13 11.1 Przenośność........................................ 13 11.2 Elastyczność....................................... 14 11.3 Łatwość obsługi...................................... 14 11.4 Niezawodność....................................... 14 11.5 Bezpieczeństwo...................................... 14 12 Historia zmian 14 2

1 Wprowadzenie 1.1 Cel Dokument ten ma na celu zaprezentowanie architektury systemu oraz przedstawienie najważniejszych założeń, które stworzą fundamenty YapS. Dodatkowo opisane zostaną najistotniejsze rozwiązania techniczne, a także jakościowe cele projektu. 1.2 Zakres Na dokument składają się: opis architektury systemu, opis założeń i zależności, przegląd najważniejszych podsystemów, przegląd przypadków użycia, opis wdrożenia i implementacji, schemat przechowywania danych oraz przepływu informacji, opis założeń wydajnościowych i jakościowych projektu. 1.3 Definicje Definicje używanych terminów i skrótów znajdują się w załączonym słowniku. 1.4 Załaczniki 1. Słownik 2 Prezentacja architektury systemu YapS jest zaprojektowany jako architektura klient-serwer, za cały system jest odpowiedzialny serwer, który samodzielnie przetwarza wszelkie zapytania od klienta. Klient odpowiada tylko za wizualizację i zgłaszanie zapytań do serwera. Oddzielona, relacyjna baza danych YapS korzysta z relacyjnej bazy danych, która nie musi być zainstalowana na tym samym komputerze co sam system. Serwer składa się z czterech warstw, które są rozszerzeniem schematu MVC. Widok odpowiada View w MVC Prezenter odpowiada Controller Asystent jest to warstwa pośrednia, która upraszcza komunikację między Aplikacją a Modelem Model odpowiada Model w MVC 3

Szczegółowy opis z perspektywy podziału logicznego znajduje się w rozdziale 4. Szczegółowy opis z perspektywy przypadków użycia znajduje się w rozdziałach 5. Szczegółowy opis z perspektywy wdrożenia i implementacji znajduje się w rozdziałach 7 i 8. 3 Założenia i zależności Bezpieczeństwo System musi być wystarczająco zabezpieczony, by możliwe było umieszczenie w formularzach informacji poufnych. Dostęp do YapS będzie wymagał autoryzacji, z wykorzystaniem nazwy użytkownika i hasła. YapS będzie umożliwiał szyfrowanie danych przesyłanych między systemem a użytkownikiem. Zostanie to zrealizowane poprzez wykorzystanie możliwości serwera WWW - protokołu TLS. Niezawodność Wykorzystywany framework nie pozwala na zapisywanie danych w bazie danych w transakcjach, dlatego, aby zachować spójność danych, należy użyć mechanizmu triggerów. Wielojęzyczność YapS napisany zostanie w polskiej wersji językowej, jednak jego budowa musi pozwolić na wybór języka interfejsu. Dodanie nowego języka musi sprowadzać się do przetłumaczenia informacji wyświetlanych przez system (oraz niewielkich zmian konfiguracji). Wydajność System napisany będzie w języku skryptowym. Poza tym dostęp do bazy danych realizowany będzie z wykorzystaniem wzorca projektowego Active Record, który zwalnia programistę z konieczności pisania zapytań SQL. Niestety, czasem prowadzi to do powstania nieoptymalnych zapytań. Z tego względu, należy zwrócić uwagę, by podczas implementacji nie stworzyć kodu posiadającego niepotrzebne narzuty czasowe. 4 Dekompozycja logiczna systemu 4.1 Omówienie YapS został podzielony na cztery warstwy: Widok, Prezentera, Asystenta (Fasadę) i Model. Jest to podział dość standardowy, który pozwala w łatwy sposób utrzymywać i rozszerzać budowany system. Wybrano to podejście, gdyż jest powszechnie stosowane i sprawdziło się ono w wielu podobnych projektach. Jego podstawowe zalety to: odseparowywanie niepowiązanych części systemu od siebie, duża elastyczność tworzonego kodu. 4

5

Wyjaśnienie funkcji poszczególnych warstw: Widok jest odpowiedzialny za wizualizację działania systemu, działa w połączeniu z przeglądarką internetową zainstalowaną na komputerze użytkownika, Prezenter jest to logika, która odpowiada za obsługiwanie poleceń użytkownika, Asystent (Fasada) pełni funkcję pomocniczą, stanowi swoiste spoiwo pomiędzy abstrakcyjnymi częściami systemu jakimi są Widok i Prezenter, a Modelem, realizuje większość poleceń użytkownika. Jego użyteczność jest widoczna na diagramach przebiegu w rozdziale 5. Zastosowanie asystenta do niskopoziomowych operacji na obiektach modelu znacząco upraszcza protokół komunikacji użytkownika z systemem i ułatwia pracę nad wysokopoziomowymi warstwami YapS. Model jest odpowiedzialny za logiczne modelowanie danych w systemie. 4.2 Najważniejsze komponenty 4.2.1 Obsługa użytkownika Klasy z tego pakietu modelują użytkownika YapS oraz pamiętają jego dane, preferencje. Klasa Sesja reprezentuje pojedyncze logowanie użytkownika w systemie. 4.2.2 Obsługa formularza Formularze są modelowane w systemie za pomocą obiektów klasy Formularz. Każdy formularz jest przydzielony do konkretnej kategorii (klasa Kategoria). Na pojedynczy formularz składa się zbiór odpowiednio zestawionych komponentów. Klasa Komponent jest klasą abstrakcyjną, formularze mogą zawierać jedynie instancje jej konkretnych podklas. Każdy formularz może zostać wypełniony raz lub wiele razy. Takie zdarzenie modeluje klasa Wypełnienie. Na jej podstawie możliwe jest generowanie statystyk odpowiedzi na konkretne pytania z formularza. 4.2.3 Kontrola Praw Dostępu Użytkownicy są zrzeszeni w grupy (klasa Grupa). Każda grupa ma swojego właściciela i pamięta swoich członków. Grupom można nadawać zasady dostępu do formularzy (klasa ZasadaDostępu), które określają prawa dostępu członków danej grupy do konkretnego formularza. 4.2.4 Wiadomości systemowe Użytkownicy mogą przesyłać między sobą wiadomości (modelowane przez obiekty klasy Wiadomość). Służą one m.in. do zgłaszania chęci zapisu do grupy, zadawania pytań administratorowi, rozgłaszania informacji członkom swojej grupy. 4.2.5 Wyszukiwanie Ten pakiet zawiera logikę i metody pozwalające wyszukiwać w systemie interesujące formularze i grupy. 6

4.2.6 Obsługa błędów Klasa Błąd reprezentuje błędy w systemie. Każdy błąd ma swój kod i jest powiązany z konkretnym komunikatem, który jest w razie konieczności prezentowany użytkownikowi. 5 Przeglad przypadków użycia Najważniejsze przypadki użycia YapS to: tworzenie formularza, wypełnianie formularza, usuwanie formularza, przeglądanie statystyk, dodawanie praw dostępu, usuwanie praw dostępu, wysyłanie wiadomości systemowych. Przedstawimy teraz sposób realizacji tworzenia formularza. Pozostałe przypadki użycia są wykonywane analogicznie. 7

5.1 Realizacja tworzenia formularza Użytkownik loguje się w systemie i wchodzi na stronę z edytorem formularzy. Wybiera opcję: Nowy Formularz. System wyświetla pusty formularz gotowy do edycji. Użytkownik cyklicznie wybiera komponent do wstawienia, ustawia jego parametry i dodaje do formularza. Na koniec użytkownik nadaje stworzonemu w ten sposób dokumentowi nazwę, przydziela go do wybranej kategorii oraz określa dla niego prawa dostępu. Potem formularz jest zapisywany w bazie danych i udostępniany wypełniającym. 8

5.2 Diagram Zależności 9

5.3 Diagramy przebiegu Poniższy diagram przedstawia szczegółowo interakcje użytkownika z systemem podczas tworzenia formularza. Koncentrujemy się tu tylko na wysokopoziomowych warstwach systemu. Komunikacja z obiektami modelu odbywa się poprzez wygodny interfejs Asystenta - Fasady: 10

Rysunek 1: realizacja metody stworzformularz Rysunek 2: realizacja metody zapiszformularz Dwa powyższe diagramy to przykłady niskopoziomowych realizacji metod modułu FasadaObsługiFormularza. Demonstrują one jak prosta staje się obsługa formularzy dzięki zastosowaniu fasad i technologii Ruby On Rails. 6 Dekompozycja na procesy Wykorzystywane przez nas technologie Apache, Ruby On Rails, PostgreSQL zapewniają dekompozycje systemu YapS na procesy. 11

7 Instalacja systemu Na rysunku powyżej przedstawiono schemat instalacji systemu. Możliwe jest uruchomienie zarówno serwera WWW i Aplikacji oraz serwera bazy danych na jednym komputerze i tej właśnie konfiguracji uruchomimy YapS. W przypadku samodzielnej instalacji, ważne by połączenie pomiędzy serwerem WWW a serwerem bazy danych odbywało się po sieci o przepustowości nie mniejszej niż 100Mbit (prędkość typowej sieci LAN). Przy zakładanym obciążeniu (por. rozdz. 10) połączenie serwera z internetem powinno mieć prędkość co najmniej 1Mbit (zarówno download jak i upload). Serwer WWW będzie obsługiwany przez Apache w wersji 2 z obsługą HTTPS. Na tym samym komputerze zainstalowane będzie interpreter języka Ruby (wersja co najmniej 1.8.5) z biblioteką Ruby Gems, a także pakiet ImageMagick. Serwer bazy danych będzie działać w oparciu o PostgreSQL. Na komputerze zainstalowany będzie system Linux. Przy samodzielnej instalacji możliwe jest użycie innego serwera WWW (o ile wspiera HTTPS, CGI, FCGI), a także dowolnego systemu operacyjnego zgodnego z POSIX. Do uruchomienia systemu (w przypadku instalacji Aplikacji jak i bazy danych na jednym komputerze) potrzebny będzie komputer wyposażony w procesor o zegarze 2Ghz, 1GB pamięci RAM oraz dysk o pojemności 100GB. 8 Implementacja systemu Implementację systemu można podzielić na kilka zadań o stosunkowo niewielkim sprzężeniu, zgodnie z podziałem systemu na warstwy (por. rozdz. 4). Zadania te można rozdzielić pomiędzy członków zespołu. Implementacja każdej z warstw polegać będzie głównie na stworzeniu plików źródłowych w języku Ruby. Poza tym, koniecznie będzie napisanie skryptu w języku SQL, który stworzy tabele w bazie danych, a także skryptu w języku YAML, pozwalającego skryptom języka Ruby na korzystanie z bazy danych zgodne ze wzorcem projektowym Active Record. Przy tworzeniu warstwy Widoku, trzeba będzie napisać szablony stron WWW oraz narysować obrazki na nich wyświetlane. 12

9 Przechowywane dane Zawartość bazy danych będzie uporządkowana według poniższego modelu. 10 Wydajność systemu Zakładamy następujące obciążenie systemu: ilość zarejestrowanych użytkowników: do 50000, ilość jednocześnie zalogowanych użytkowników: do 100. Takie obciążenie pozwoli na odpowiedź systemu w ciągu 2 sekund, w przypadku gdy interakcja z użytkownikiem nie wymaga przesłania dużej ilości danych (na przykład pliku o dużym rozmiarze). W przeciwnym razie, do czasu odpowiedzi należy dodać czas potrzebny na transmisję danych, w głównej mierze zależny od szybkości łącza internetowego. 11 Jakość 11.1 Przenośność YapS powinien być systemem przenośnym tak, aby do korzystania z pełnej funkcjonalności była potrzebna jedynie przeglądarka z dostępem do internetu i wbudowaną obsługą potrzebnej nam technologii AJAX. Przy projektowaniu nie ograniczyliśmy się tylko do upraszczania strony użytkownika. YapS nie powinien potrzebować egzotycznej konfiguracji dedykowanego systemu, ważne jest aby z łatwością można go było zainstalować na tradycyjnym serwerze. 13

11.2 Elastyczność YapS został zaprojektowany z myślą o dalszym rozwoju, nie jest zamknięty na innowację. Połączenia między komponentami są ograniczone do minimum, co powinno ułatwić modyfikacje i rozszerzenia systemu. Warto zwrócić uwagę na elastyczność stosowanych technologii, aby nie ograniczać potencjału YapS. 11.3 Łatwość obsługi Obsługa YapSpowinna być intuicyjna tak, aby niezaawansowany użytkownik posiadający podstawową wiedzę dotyczącą obsługi komputera i standardowej przeglądarki internetowej, był w stanie nie tylko wypełnić test lub ankietę, ale także stworzyć swoje własne egzaminy. Nie jest to podstawowa kwestia, jednak trzeba wspomnieć, że podjęte decyzje projektowe uwzględniały potrzebę bycia łatwym do instalacji i obsługi dla administratorów. Osiągnięte to będzie przez przygotowanie gotowych schematów, dzięki którym instalacja systemu nie będzie przysparzała problemów. 11.4 Niezawodność Ze względu na specyfikację projektu, ważne jest aby w trakcie działania system był stabilny i odporny na przeciążenia, przewidujemy jednak możliwość niedługich przerw technicznych w celu administracji systemu. 11.5 Bezpieczeństwo Ze względu na poufność danych przechowywanych w YapS system musi oferować wysoki poziom bezpieczeństwa. Będzie to osiągnięte dzięki zastosowaniu sprawdzonych schematów dotyczących szyfrowania i autoryzacji. 12 Historia zmian 0.1 - wersja z szablonu 0.2 - napisane rozdziały 7-9 0.3 - dodałem rozdziały 2 i 10 0.4 - dodano wprowadzenie 0.5 - dodano jakość 0.6 - dodano prezentacje architektury 0.7 - strona tytułowa i spis treści 0.8 - edycja tresci wszystkich rozdzia\l\,ow 0.9 - edycja grafiki 0.10 - spellchecking 0.11 - dostrojenie rozmiarów grafiki 14