Projektowanie architektury systemu Jarosław Kuchta
Zagadnienia Typy architektury systemu Rozproszone przetwarzanie obiektowe Tworzenie modelu sieci Tworzenie specyfikacji sprzętowej i programowej Problemy globalizacji Problemy ochrony Projektowanie architektury systemu 2/28
Typy architektury systemowej Architektura bazująca na serwerze Architektura bazująca na kliencie Architektura klient-serwer Projektowanie architektury systemu 3/28
Podział funkcji systemu Logika prezentacyjna Logika aplikacyjna Klient Logika dostępu do danych Przechowywanie danych Serwer Projektowanie architektury systemu 4/28
Typy serwerów Mainframe Koszt: 1 mln $ i więcej Wiele równocześnie wykonywanych operacji Minikomputer Koszt: od 10 tys. $ do 1 mln $ Zarządzanie bazą danych, sterowanie procesami produkcyjnymi Mikrokomputer Koszt: od 1 tys. $ do 50 tys. $ Mała baza danych Projektowanie architektury systemu 5/28
Typy klientów Komputer osobisty Terminal Terminal specjalnego przeznaczenia bankomat kiosk palmtop telefon komórkowy Projektowanie architektury systemu 6/28
Architektura bazująca na serwerze Stosowana w latach 1960-1980 Prosta w projektowaniu Duże prawdopodobieństwo przeciążenia serwera Bardzo kosztowna modernizacja Klient (terminal) Serwer (mainframe) Logika prezentacyjna Logika aplikacyjna Logika dostępu do danych Przechowywanie danych Projektowanie architektury systemu 7/28
Architektura bazująca na kliencie Stosowana od lat 1980 Łatwa aplikacja Intensywna wymiana danych między klientami Duże prawdopodobieństwo przeciążenia sieci (lokalnej) Klient (komputer osobisty) Logika prezentacyjna Logika aplikacyjna Logika dostępu do danych Serwer (mikrokomputer) Przechowywanie danych Projektowanie architektury systemu 8/28
Architektura klient-serwer Stosowana od lat 1990 Logika aplikacyjna może być dzielona między klienta i serwer Łatwo skalowalna Możliwość stosowania różnych typów klientów i serwerów Duża odporność na awarie sieci Ograniczona złożoność aplikacji 1000 x niższy koszt niż architektury bazującej na serwerze przy tym samym poziomie wydajności Klient Logika prezentacyjna Logika aplikacyjna Serwer Przechowywanie danych Logika dostępu do danych Projektowanie architektury systemu 9/28
Podział logiki aplikacyjnej Architektura dwupienna (two-tiered) cała logika aplikacyjna u klienta Architektura trójpienna (three-tiered) logika aplikacyjna na wydzielonym serwerze aplikacji Architektura wielopienna (n-tiered) wiele serwerów aplikacji i/lub wiele serwerów bazy danych Projektowanie architektury systemu 10/28
Architektura dwupienna Stosunkowo łatwe rozwiązanie Małe prawdopodobieństwo przeciążenia serwera Wymaga specjalnej aplikacji u klienta Duże zagrożenie dla klienta przy kontakcie z nieznanym serwerem Klient Logika prezentacyjna Logika aplikacyjna Serwer Przechowywanie danych Logika dostępu do danych Projektowanie architektury systemu 11/28
Architektura trójpienna Łatwa aplikacja u klienta (wystarczy przeglądarka) Klient bezpieczny Duże prawdopodobieństwo przeciążenia serwera aplikacji Klient Logika prezentacyjna Serwer aplikacji Logika aplikacyjna Serwer bazy danych Przechowywanie danych Logika dostępu do danych Projektowanie architektury systemu 12/28
Architektura wielopienna Logika aplikacyjna podzielona na wiele serwerów Łatwa skalowalność Duży ruch w sieci między serwerami Klient Web-serwer Serwer aplikacji Serwer bazy danych Logika prezentacyjna Logika aplikacyjna Logika aplikacyjna Przechowywanie danych Logika dostępu do danych Projektowanie architektury systemu 13/28
Kryteria wyboru architektury Bazująca na serwerze Bazująca na kliencie Klient-serwer Koszt infrastruktury Bardzo wysoki Średni Niski Kosz opracowania Średni Niski Wysoki Łatwość opracowania Możliwości interfejsu Kontrola i bezpieczeństwo Niska Wysoka Średnio niska Niskie Wysokie Wysokie Wysokie Niskie Średnie Skalowalność Niska Średnia Wysoka Projektowanie architektury systemu 14/28
Rozproszone przetwarzanie obiektowe (DOC) Rozproszone przetwarzanie obiektowe (Distributed Object Computing) obiekt rezydujący u klienta żąda wykonania usług przez obiekt rezydujący na serwerze Middleware warstwa oprogramowania pośrednicząca między aplikacją klienta a serwerami w rozproszonym przetwarzaniu obiektowym. Umożliwia lokalizację właściwego serwera i odpowiednie skierowanie żądań klienta. Corba (Common Object Request Broker Architecture) stworzony przez OMG niezależny od platformy (systemu, języka) standard DOC bazujący na języku IDL. DCOM (Distributed Component Object Model) produkt Microsoftu realizujący DOC w oparciu o model COM i COM+. Projektowanie architektury systemu 15/28
Stworzenie modelu sieci Model sieci jest diagramem pokazującym główne komponenty systemu informatycznego (serwery, linie komunikacyjne, sieci) Brak uznanego standardu notacji Narzędzia: Visio, PowerPoint Cele: opanowanie złożoności systemu pokazanie współpracy elementów systemu Projektowanie architektury systemu 16/28
Model sieci (1) Oddział w Gdańsku Oddział w Poznaniu Polpack Oddział w Warszawie Oddział w Krakowie Projektowanie architektury systemu 17/28
Model sieci (2) Podsieć 10 Serwer A switch Podsieć 20 Serwer b Projektowanie architektury systemu 18/28
Specyfikacja sprzętu i oprogramowania Wymagania dla stacji roboczych Wymagania sprzętowe: Procesor x86 2 GB RAM 128 GB HDD Monitor 1280 x 1024 (erg.) Liczba stacji roboczych: 20 Wymagania na oprogramowanie: Windows 7 Internet Explorer v.10 Microsoft Office v. 2010 Projektowanie architektury systemu 19/28
Problemy globalizacji Tłumaczenie komunikatów Specjalistyczny słownik Tłumaczenie gramatyczne Napisy na ekranie Dostępność czcionek Długość napisów Napisy od prawej do lewej Formaty danych Format liczb (separator dziesiętny, separator tysięcy) Format daty i czasu Wsparcie 24/7 Projektowanie architektury systemu 20/28
Problemy ochrony Identyfikacja zagrożeń Oszacowanie ryzyka dla każdego zagrożenia Minimalizacja ryzyka Projektowanie architektury systemu 21/28
Procent organizacji zgłaszających straty spowodowane przez Wirus Awaria urządzenia Włamanie z zewnątrz Kradzież wyposażenia Włamanie z wewnątrz Katastrofa naturalna Szpiegostwo przemysłowe 0 10 20 30 40 50 60 70 80 90 100 Denis, Wixom, Tegarden: Systems Analysis & Design Projektowanie architektury systemu 22/28
Kategorie zagrożeń Zakłócenie Uszkodzenie Katastrofa Nieautoryzowany dostęp Projektowanie architektury systemu 23/28
Oszacowanie ryzyka Ryzyko (z) = Prawdopodobieństwo (z) Ewentualna strata (z) Projektowanie architektury systemu 24/28
Plan ochrony (1) Zagrożenie Zakłócenie, uszkodzenie, katastrofa Nieautoryzowany dostęp Komponenty Ogień Woda Utrata zasilania Awaria połączeń Wirus Włam. zewn. Serwery 1, 2 1, 3 4 1, 5, 6 7, 8 9, 10, 11, 12 Komputery klieckie Włam. wewn. 9, 10 Podsłuch Połączenia komunikacyjne Osprzęt sieci Oprogramowanie sieci Personel Projektowanie architektury systemu 25/28
Plan ochrony (2) 1. Plan odtworzenia po katastrofie 2. System przeciwpożarowy 3. Lokalizacja serwerów na wyższych piętrach 4. UPS przy wszystkich serwerach sieciowych 5. Gwarancje kontraktowe od firmy telekomunikacyjnej 6. Dodatkowy światłowód między głównymi serwerami 7. Oprogramowanie antywirusowe dla ochrony sieci 8. Szkolenie antywirusowe personelu i comiesięczne przypomnienia 9. Stosowanie silnych haseł 10. Szkolenia personelu do do stosowanie silnych haseł i comiesięczne przypomnienia 11. Zwrotny system modemowy 12. Zapora ogniowa na warstwie aplikacji Projektowanie architektury systemu 26/28
Zapory ogniowe Internet Zapora Serwer Web Zapora LAN Serwer wewnętrzny Projektowanie architektury systemu 27/28
Literatura Dennis A., Wixom B.H., Tegarden D., Systems Analysis & Design. An Object-Oriented Approach with UML, John Wiley and Sons, USA, 2002 Projektowanie architektury systemu 28/28