Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Projektowanie systemowe. Wprowadzenie Wejście projektowania systemowego: model analizy Wyjście: –Cele projektowania – cechy systemu, które wymagają optymalizacji.

Podobne prezentacje


Prezentacja na temat: "Projektowanie systemowe. Wprowadzenie Wejście projektowania systemowego: model analizy Wyjście: –Cele projektowania – cechy systemu, które wymagają optymalizacji."— Zapis prezentacji:

1 Projektowanie systemowe

2 Wprowadzenie Wejście projektowania systemowego: model analizy Wyjście: –Cele projektowania – cechy systemu, które wymagają optymalizacji –Architektura oprogramowania – dekompozycja systemu na podsystemy –Brzegowe przypadki użycia – konfiguracja, start, zatrzymanie/restart, obsługa wyjątków

3 Podsystemy i klasy

4 Usługi i interfejsy podsystemów Usługa (podsystemu) – zbiór powiązanych operacji realizujących wspólne zadanie Interfejs podsystemu – zbiór operacji udostępnianych innym podsystemom; interfejs zawiera nazwy operacji, nazwy i typy parametrów i zwracanych wartości Rozwinięciem interfejsu podsystemu jest interfejs programisty aplikacji (Application Programmer Interface – API) – produkt projektowania obiektowego Określenie podsystemu przy pomocy dostarczanych usług pozwala skupić się na jego interfejsie a nie na implementacji

5 Sprzężenie a spójność Sprzężenie (coupling) – liczba zależności pomiędzy dwoma podsystemami Spójność (cohesion) – liczba zależności wewnątrz podsystemu Dekompozycja powinna zmniejszać sprzężenie i zwiększać spójność

6 Przykład

7 Przykład – rozwiązanie alternatywne

8 Dekompozycja hierarchiczna

9 Warstwy i partycje Warstwa – grupa podsystemów umiejscowionych na określonym poziomie abstrakcji, dostarczających pokrewnych usług, wykorzystujących ewentualnie usługi innej (niższej) warstwy Partycjonowanie – podział systemu na równoległe podsystemy odpowiedzialne za różne kategorie usług

10 Architektura warstwowa zamknięta (model OSI)

11 Architektura warstwowa otwarta (JFC)

12 Style architektoniczne (wzorce architektury) Repozytorium Model/widok/kontroler Klient/serwer Peer-to-peer Trójwarstwowy Czterowarstwowy Rury (potoki) i filtry

13 Repozytorium

14 Model/widok/kontroler

15 Klient/serwer

16 Peer-to-peer

17 Architektura trójwarstwowa

18 Architektura czterowarstwowa

19 Potoki i filtry (Pipes and Filters) Przykład: ps aux | grep apache | sort | less

20 Czynności projektowania systemowego Identyfikacja celów projektowania Identyfikacja podsystemów Odwzorowanie podsystemów na procesory i komponenty Identyfikacja i składowanie trwałych danych Określenie kontroli dostępu Projektowanie globalnego przepływu sterowania Identyfikacja warunków brzegowych Przegląd modelu projektowania systemowego

21 Identyfikacja celów projektowania Źródła celów projektowania Wymagania niefunkcjonalne Dziedzina aplikacji Klient i/lub dostawca Kategorie kryteriów projektowych Kryteria wydajnościowe Kryteria związane z pewnością (niezawodnością) Kryteria związane z kosztami Kryteria związane z utrzymaniem Kryteria użytkownika końcowego

22 Kryteria wydajnościowe Czas odpowiedzi (response time) – jak szybko żądania klienta są potwierdzane? Przepustowość (throughput) – jak dużo zadań system może zrealizować w ustalonej jednostce czasu? Pamięć – ile miejsca potrzebuje system do normalnej pracy?

23 Kryteria związane z pewnością Odporność (robustness) – zdolność przetrwania wprowadzenia niewłaściwych danych przez użytkownika Niezawodność (reliability) – różnica między zachowaniem specyfikowanym i obserwowanym Osiągalność (availability) – stosunek czasu, w którym system może być użyty do realizacji normalnych zadań do całkowitego czasu działania Tolerancja błędów (fault tolerance) – zdolność do pracy w nieoczekiwanych (błędnych) warunkach Zabezpieczenia (security) – zdolność odparcia złośliwych ataków Bezpieczeństwo (safety) – zdolność uniknięcia zagrożenia życia ludzi nawet jeśli wystąpią błędy lub awarie

24 Kryteria związane z kosztami Koszt wyprodukowania Koszt wdrożenia – instalacja i szkolenia użytkowników Koszt aktualizacji – translacja danych z poprzedniego systemu (zgodność wsteczna) Koszt utrzymania – usuwanie błędów i wprowadzanie ulepszeń Koszt administracji

25 Kryteria związane z utrzymaniem Rozszerzalność (extensibility) – łatwość dodawania funkcjonalności/klas do systemu Modyfikowalność (modifiability) – łatwość zmieniania funkcjonalności systemu Adaptowalność (adaptability) – łatwość przeniesienia systemu do innej dziedziny aplikacji Przenośność (portability) – łatwość przeniesienia systemu na inne platformy Czytelność (readability) – łatwość zrozumienia systemu na podstawie kodu Możliwość prześledzenia wymagań (traceability of requirements) – łatwość odwzorowania kodu na konkretne wymagania

26 Kryteria użytkownika końcowego Użyteczność (utility) – jak dobrze system wspiera pracę użytkownika? Używalność (usability) – jak łatwo jest użytkownikowi korzystać z systemu?

27 Przykładowe sytuacje wyboru Pamięć czy szybkość? Czas dostarczenia czy funkcjonalność? Czas dostarczenia czy jakość? Czas dostarczenia czy wykorzystanie personelu?

28 Przykład – System planowania drogi MyTrip Określenie problemu (fragment) Przy pomocy systemu MyTrip kierowca może wykorzystując domowy komputer zaplanować trasę komunikując się z usługą planowania trasy dostępną przez WWW. Trasa jest zachowywana na serwerze dla późniejszego odtworzenia. Usługa planowania trasy musi dopuszczać więcej niż jednego kierowcę. Kierowca następnie wsiada do samochodu i wyrusza na trasę, podczas gdy komputer pokładowy daje mu wskazówki oparte na informacjach o trasie otrzymanych od usługi planowania trasy i aktualnej pozycji wyznaczonej przez pokładowy odbiornik GPS.

29 MyTrip – przypadek użycia PlanowanieTrasy Przepływ zdarzeń: 1.Kierowca włącza komputer i loguje się do usługi planowania trasy. 2.Kierowca wprowadza ograniczenia dla trasy w postaci ciągu punktów docelowych. 3.Na podstawie bazy map usługa planowania wylicza najkrótszą drogę odwiedzającą punkty docelowe w określonej kolejności. Wynikiem jest ciąg odcinków łączących ciąg skrzyżowań oraz lista wskazówek. 4.Kierowca może zmodyfikować trasę przez dodanie lub usunięcie punktów docelowych. 5.Kierowca zachowuje w usłudze planowania trasy zaplanowaną drogę pod podaną nazwą dla późniejszego odtworzenia.

30 MyTrip – przypadek użycia PrzebycieTrasy Przepływ zdarzeń: 1.Kierowca uruchamia samochód i loguje się do pokładowego asystenta drogowego. 2.Po pomyślnym zalogowaniu Kierowca określa usługę planowania trasy i nazwę trasy, którą chce przejechać. 3.Pokładowy asystent drogowy otrzymuje od usługi planowania listę punktów docelowych, wskazówek, odcinków i skrzyżowań. 4.Na podstawie bieżącej pozycji asystent przekazuje Kierowcy kolejny zbiór wskazówek. 5.Kierowca dociera do celu i zamyka asystenta drogowego.

31 MyTrip – model analizy – diagram klas

32 MyTrip – model analizy – słownik danych AsystentDrogowy (RouteAssistant) AsystentDrogowy daje kierowcy Wskazówki związane z bieżącym Położeniem i zbliżającym się Skrzyżowaniem. Odcinek (Segment) Fragment drogi między Skrzyżowaniami. Położenie (Location) Pozycja samochodu określona albo przez pokładowy system GPS, albo na podstawie przebytej drogi. PunktDocelowy (Destination) Miejsce, do którego chce dotrzeć kierowca. Skrzyżowanie (Crossing) Geograficzny punkt zbiegu Odcinków. Trasa (Trip) Ciąg Wskazówek pomiędzy dwoma PunktamiDocelowymi. UsługaPlanowania (PlanningService) Usługa WWW, która pozwala przechować i odtworzyć trasę łączącą pewną liczbę punktów docelowych w postaci ciągu Skrzyżowań i Odcinków Wskazówka (Direction) Dla danego Skrzyżowania i sąsiadującego Odcinka opisuje w języku naturalnym jak skierować samochód na dany Odcinek.

33 MyTrip – wymagania niefunkcjonalne 1.MyTrip kontaktuje się z UsługąPlanowania przez bezprzewodowy modem. Zakładamy, że modem działa poprawnie w położeniu początkowym. 2.Po wyruszeniu na trasę MyTrip powinien udzielać prawidłowych wskazówek nawet w przypadku utraty połączenia z UsługąPlanowania. 3.MyTrip powinien minimalizować czas połączenia dla redukcji kosztów działania. 4.Zmiana planu jest możliwa tylko jeśli połączenie z UsługąPlanowania jest możliwe. 5.UsługaPlanowania ma dopuszczać przynajmniej 50 różnych kierowców i 1000 tras.

34 MyTrip – cele projektowe Niezawodność: MyTrip powinien być niezawodny [uogólnienie wymagania niefunkcjonalnego 2]. Tolerancja błędów: MyTrip powinien tolerować utratę połączenia z usługą planującą [przeformułowane wymaganie niefunkcjonalne 2]. Zabezpieczenia: MyTrip powinien być zabezpieczony, tzn. nie powinien udostępniać tras danego kierowcy ani innym kierowcom, ani użytkownikom nieautoryzowanym [wydedukowane z dziedziny aplikacji]. Modyfikowalność: MyTrip powinien dać się zmodyfikować tak, żeby używał różnych usług planujących [zmiana przewidywana przez deweloperów].

35 Identyfikacja podsystemów Przydziel obiekty zidentyfikowane w jednym przypadku użycia do tego samego podsystemu Stwórz dedykowany podsystem grupujący obiekty transportujące dane pomiędzy podsystemami Zminimalizuj liczbę powiązań przecinających granice podsystemów Wszystkie obiekty w danym podsystemie powinny być funkcjonalnie pokrewne

36 MyTrip – wstępna dekompozycja PodsystemDrogowy (RoutingSubsystem) PodsystemDrogowy jest odpowiedzialny za ściągnięcie Trasy z UsługiPlanowania i przebycie jej przez dawanie kierowcy Wskazówek na podstawie jego Położenia. PodsystemPlanowania (PlanningSubsystem) PodsystemPlanowania jest odpowiedzialny za skonstruowanie Trasy łączącej ciąg PunktówDocelowych. Jest także odpowiedzialny za odpowiadanie na żądania zmiany planu od PodsystemuDrogowego.

37 Określenie fasady podsystemu (wzorzec Facade)

38 Odwzorowanie podsystemów na procesory i komponenty Wybór konfiguracji sprzętu i platformy systemowo-sprzętowej (maszyny wirtualnej). Alokacja obiektów i podsystemów na węzłach. –Identyfikacja obiektów i podsystemów infrastruktury komunikacyjnej

39 Diagramy wdrożenia UML 1.x

40 Diagramy komponentów i wdrożenia UML 2

41 MyTrip – alokacja podsystemów

42 MyTrip – zrewidowany model projektowania PodsystemKomunikacyjny (CommunicationSubsystem) Podsystem odpowiedzialny za transport obiektów z PodsystemuPlanowania do PodsystemuDrogowego Połączenie (Connection) Reprezentuje aktywne łącze pomiędzy PodsystememDrogowym a PodsystememPlanowania. Obiekt Połączenia obsługuje sytuacje wyjątkowe związane z utratą łączności sieciowej Komunikat (Message) Reprezentuje Trasę wraz z jej PunktamiDocelowymi, Odcinkami, Skrzyżowaniami i Wskazówkami, zakodowaną w celu przetransportowania

43 Identyfikacja trwałych danych Dane (obiekty) trwałe – takie, których czas życia przekracza granice pojedynczego uruchomienia systemu –Obiekty encyjne o długim czasie życia –Część atrybutów obiektów brzegowych (preferencje interfejsu użytkownika, układ okien, itp.) –Obiekty sterujące, które dopuszczają zatrzymanie i wznowienie

44 Strategie składowania trwałych danych Pliki – binarne lub tekstowe (XML, CSV,...) Relacyjne bazy danych Obiektowe bazy danych Strategie mieszane

45 MyTrip – składy danych TripFileStoreSubsystem Podsystem odpowiedzialny za składowanie tras w plikach na komputerze pokładowym. Z uwagi na to, ze ta funkcjonalność jest dostępna tylko dla przechowywania tras kiedy samochód jest wyłączany, ten podsystem wspiera tylko szybki mechanizm składowania i ładowanie całych tras. MapDBStoreSubsystem Podsystem odpowiedzialny za składowanie map i tras PodsystemuPlanowania w bazie danych. Wspiera on wielu współbieżnych Kierowców i agentów planujących.

46 Określenie kontroli dostępu Uwierzytelnienie (authentication) – weryfikacja tożsamości aktora Autoryzacja – określenie uprawnień aktora do wykonania konkretnych operacji na konkretnych obiektach

47 Uwierzytelnienie Mechanizmy uwierzytelniania –Nazwa użytkownika + hasło –SmartCard –Dane biometryczne Sieciowe systemy ustalania tożsamości (LDAP, NIS) Unikanie podszywania się pod cudzą tożsamość –Szyfrowanie haseł –Szyfrowanie komunikacji (SSL)

48 Autoryzacja Statyczna kontrola dostępu –Macierz dostępu (access matrix) Wiersze – aktorzy Kolumny – klasy Elementy macierzy – prawa dostępu czyli listy operacji danej klasy dostępnych dla danego aktora Dynamiczna kontrola dostępu – kontrola uprawnień do wykonania operacji poszczególnych obiektów

49 Macierz dostępu - przykład Klasa Aktor KorporacjaLokalnyOddziałKonto Kasjer udzielMałegoKredytu() sprawdźSaldo() Kierownik sprawdźStatystykiOddziału()udzielMałegoKredytu() udzielDużegoKredytu() sprawdźSaldo() sprawdźHistorię() Analityk sprawdźGlobalneStatystyki()sprawdźStatystykiOddziału()

50 Reprezentacja macierzy dostępu Globalna tablica dostępu (global access table) – lista trójek (aktor, klasa, operacja) Lista kontroli dostępu (access control list, ACL) – odwzorowanie klasa lista par (aktor, operacja) Lista zdolności (capability list) – odwzorowanie aktor lista par (klasa, operacja) Zbiór reguł – reprezentacja zwarta

51 MyTrip – kontrola dostępu – rewizja modelu projektowania PodsystemKomunikacyjny (CommunicationSubsystem) Podsystem odpowiedzialny za transport obiektów z PodsystemuPlanowania do PodsystemuDrogowego. PodsystemKomunikacyjny używa obiektu Kierowcy związanego z transportowaną Trasą do wybrania klucza szyfrowania komunikacji. PodsystemPlanowania (PlanningSubsystem) PodsystemPlanowania jest odpowiedzialny za skonstruowanie Trasy łączącej ciąg PunktówDocelowych. Jest także odpowiedzialny za odpowiadanie na żądania zmiany planu od PodsystemuDrogowego. Przed przetwarzaniem jakichkolwiek żądań PodsystemPlanowania uwierzytelnia użytkownika przez PodsystemDrogowy. Uwierzytelniony Kierowca jest używany do określenia, które Trasy mogą być przesłane do odpowiedniego PodsystemuDrogowego. Driver (Kierowca) Reprezentuje uwierzytelnionego użytkownika. Jest używany przez PodsystemKomunikacyjny do zapamiętania kluczy związanych z użytkownikiem, a przez PodsystemPlanowania do powiązania Tras z użytkownikami

52 Projektowanie globalnego przepływu sterowania Możliwe mechanizmy przepływu sterowania Sterowanie proceduralne Sterowanie stymulowane zdarzeniami Wątki

53 Identyfikacja warunków brzegowych Konfiguracja – zarządzanie obiektami trwałymi Start i zatrzymanie komponentów systemu Obsługa wyjątków – określenie reakcji systemu na awarie komponentów

54 MyTrip – administracyjne przypadki użycia

55 MyTrip – przypadek użycia StartSerwera Warunek wejściowy: AdministratorUsługiPlanowania jest zalogowany na stacji serwerowej Przepływ zdarzeń: 1.AdministratorUsługiPlanowania wywołuje polecenie uruchomUsługęPlanowania. 2.Jeśli UsługaPlanowania była zamknięta normalnie serwer odczytuje listę uprawnionych Kierowców i indeks Tras i Map. Jeśli UsługaPlanowania uległa awarii, zawiadamia o tym AdministratoraUsługiPlanowania i wykonuje kontrolę spójności na podsystemie MapDBStoreSubsystem. Warunek wyjściowy: UsługaPlanowania jest dostępna i oczekuje na połączenia od AsystentówDrogowych.

56 MyTrip – rewizja modelu uwzględniająca warunki brzegowe MapDBStoreSubsystem Podsystem odpowiedzialny za składowanie map i tras PodsystemuPlanowania w bazie danych. Wspiera on wielu współbieżnych Kierowców i agentów planujących. Przy starcie MapDBStoreSubsystem sprawdza, czy był poprawnie zamknięty. Jeśli nie, wykonuje kontrolę spójności na Mapach i Trasach, i w razie potrzeby naprawia uszkodzone dane.

57 Przegląd projektowania systemowego Model projektowania systemowego jest poprawny jeśli Każdy podsystem ma źródło w przypadku użycia lub wymaganiu niefunkcjonalnym. Każdy przypadek użycia może być odwzorowany na zbiór podsystemów. Każdy cel projektowy ma źródło w wymaganiu niefunkcjonalnym (lub inne ale dobrze określone). Każde wymaganie niefunkcjonalne jest rozpatrzone w modelu. Każdy aktor ma politykę dostępu. Każda polityka dostępu jest spójna z wymaganiami niefunkcjonalnymi dotyczącymi zabezpieczeń.

58 Przegląd projektowania systemowego Model projektowania systemowego jest kompletny jeśli Warunki brzegowe są obsłużone. Przeprowadzono przegląd (przemierzanie) przypadków użycia dla identyfikacji brakującej funkcjonalności. Wszystkie przypadki użycia zostały sprawdzone i przypisano im obiekty sterujące. Wszystkie aspekty projektowania systemowego zostały rozpatrzone. Wszystkie podsystemy mają definicje.

59 Przegląd projektowania systemowego Model projektowania systemowego jest spójny jeśli Konfliktowym celom projektowym przydzielono priorytety. Żaden cel projektowy nie narusza wymagania niefunkcjonalnego. Nie istnieją różne podsystemy/klasy o takich samych nazwach. Kolekcje obiektów są wymieniane między podsystemami w spójny sposób.

60 Przegląd projektowania systemowego Model projektowania systemowego jest realistyczny jeśli Rzetelnie oceniono odpowiedniość i odporność nowych technologii/komponentów wykorzystanych w systemie. Wymagania wydajnościowe i niezawodnościowe zostały zweryfikowane w kontekście dekompozycji na podsystemy. Rozpatrzono zagadnienia związane z współbieżnością (współzawodnictwo, zakleszczenia).

61 Przegląd projektowania systemowego Model projektowania systemowego jest czytelny jeśli Nazwy podsystemów są zrozumiałe. Byty o podobnych nazwach określają podobne pojęcia. Wszystkie byty są opisane na tym samym poziomie szczegółowości.

62 Dokumentacja projektowania systemowego Dokument projektowania systemowego (System Design Document)


Pobierz ppt "Projektowanie systemowe. Wprowadzenie Wejście projektowania systemowego: model analizy Wyjście: –Cele projektowania – cechy systemu, które wymagają optymalizacji."

Podobne prezentacje


Reklamy Google