Projektowanie systemów informacyjnych

Prezentacja na temat: "Projektowanie systemów informacyjnych"— Zapis prezentacji:

1 Projektowanie systemów informacyjnych
Wykład 11: Elementy cyklu projektowania SI (1) Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2 Projektowanie SI jest bardzo złożone
Czynniki od strony klienta: Czynniki od strony projektanta: 1. Procesy zachodzących w przedsiębiorstwie lub organizacji 2. Kadry: pracownicy i kierownictwo 3. Zarządzanie i struktura organizacyjna 4. Dokumenty 5. Stan prawny; pragmatyka służbowa 6. Infrastruktura informatyczna 1. Uczestnicy projektu 2. Metody i fazy projektowania 3. Dokumentacja projektowa 4. Dokumentacja użytkowa 5. Zarządzanie projektem 6. Wydajność techniki 7. Efektywność ludzka 8. Dynamika rozrostu skali SI 9. Zgodność ze standardami 10.Ocena jakości

3 Cztery światy inżynierii systemów informatycznych
przedmiotu SI Reprezentacja informacji odnośnie przedmiotu SI wewnątrz SI Użycie informacji odnośnie przedmiotu SI wewnątrz SI Świat użycia SI Świat SI Interfejsy użytkownika Świat projektowania i rozwoju SI Uzasadnienie celów projektowania i rozwoju SI Decyzje projektowe

4 Składowe modelu SI System informacyjny Środowisko operacji SI
Środowisko rozwoju SI Środowisko użytkownika Środowisko organizacji Środowisko zewnętrzne Środowisko użycia Środowisko rozwoju Proces eksploatacji System przetwarzania informacji; określony poprzez zawartość, formę i czas prezentacji Zasoby niezbędne do działania SI: oprogramowanie, sprzęt, procedury, dokumentacja, organizacja i zarządzanie operacjami SI Metody i techniki rozwoju SI oraz ich cechy; zespół projektowy i jego cechy, organizacja i zarządzanie rozwojem SI Podstawowi użytkownicy SI, tacy jak decydenci i pośrednicy Cele organizacji, struktura zadań, zmienność, styl i kultura zarządzania Aspekty prawne, socjalne, polityczne, ekonomiczne, edukacyjne, przemysłowe i handlowe Użycie SI przez podstawowego użytkownika Wybór i zastosowanie zasobów organizacyjnych które utworzą SI Fizyczne działanie SI, podstawowa funkcja jego zasobów operacyjnych

5 Złożoność problemu a ludzkie ograniczenia
Z jednej strony, ogromna złożoność problemu zaprojektowania SI, często przekraczająca możliwości ogarnięcia wszystkich aspektów przez jednego człowieka. Z drugiej strony, naturalne ograniczenia ludzkiego umysłu, pojemność i trwałość pamięci, skłonność do błędów, niedostatek wyobraźni, itp. Rozwiązanie tego problemu polega na znalezieniu metody która z jednej strony uwzględni możliwości współczesnej techniki, zaś z drugiej strony uwarunkowania psychologiczno-intelektualne gatunku biologicznego homo sapiens.

6 Projektowanie systemowe
Decyzje: Organizacja systemu, określenie jego podsystemów Zidentyfikowanie procesów współbieżnych inherentnych dla problemu Przydzielenie podsystemów do procesorów i zadań Wybranie podejścia do zarządzania składem (nośnikami) danych Ustalenie dostępu do zasobów globalnych Implementacja sterowania w oprogramowaniu Ustalenie warunków brzegowych Ustalenie priorytetów obowiazujacych przy kompromisach Dość często cała architektura systemu może być wybrana na podstawie podobieństwa do poprzednich systemów.

7 Organizacja systemu, określenie jego podsystemów
Pierwszym krokiem jest podział systemu na niewielką liczbę składowych podsystemów. Każda podsystem obejmuje pewien aspekt systemu, realizując pewne wspólne własności. podobne funkcje, ta sama lokalizacja fizyczna, ten sam sprzęt, .... Podsystem jest pakietem klas, asocjacji, operacji, zdarzeń, ograniczeń, które są ze sobą powiązane i posiadają relatywnie małą interakcję (interfejs) z innymi podsystemami. Podsystem jest zwykle identyfikowany poprzez usługi, które dostarcza. Usługa jest grupą związanych funkcji posiadających wspólny cel, np. wejście/wyjście, edycja grafiki lub wykonywanie funkcji arytmetycznych. Np. podsystem zarządzania plikami w systemie operacyjnym. Każdy podsystem powinien posiadać dobrze zdefiniowany interfejs do innych podsystemów. Interfejs specyfikuje formę wszystkich interakcji z podsystemem oraz przepływ danych. Interfejs nie specyfikuje wewnętrznej implementacji podsystemu. Dobre wyspecyfikowanie interfejsów umożliwia niezależne rozwijanie podsystemów. Podsystemy mogą być hierarchicznie rozwijane w pod-podsystemy. Dolnym poziomem hierarchii podsystemów są moduły.

8 Relacje pomiędzy podsystemami
Relacja klient-dostawca (klient-serwer). Serwer wykonuje usługi zlecane przez klienta. Klient musi znać interfejs serwera, ale serwer nie musi znać interfejs klienta. Relacja kolega-kolega (peer-to-peer) Podsystemy są równoważne, każdy może wywołać usługę i może jej dostarczać. Jest to architektura trudniejsza, ponieważ prowadzi do cykli komunikacujnych i związanych z nimi problemów synchronizacji i trudności projektowych. Podział systemu na poziome warstwy Architektura zakłada istnienie wielu warstw podsystemów, przy czym pewien podsystem musi znać interfejs do warstwy poniżej, ale nie musi znać interfejs do warstwy powyżej. - zamknięta: głębsze warstwy są niedostępne (zalecana) - otwarta: głębsze warstwy są dostępne (trudniejsza) pakiet aplikacyjny grafika okienkowa grafika ekranowa grafika pikselowa system operacyjny sprzęt np. Partycje, topologia systemu sterowanie dialogiem użytkown. pakiet symulac. Ustala (zwykle w pewnej formie graficznej) zależności pomiędzy podsystemami.

9 Alokacja podsystemów do procesorów i zadań
Istotne jest określenie, czy podystemy są współbieżne i w jaki sposób są synchronizowane. Czy ich akcje są wyzwalane przez niezależne zdarzenia? Czy istnieje wymaganie, aby pewien podsystem był zrealizowany na niezależnym sprzęcie? Każdy współbieżny podsystem musi być zaalokowany do pewnej jednostki sprzętu. Projektant systemu powinien: Oszacować potrzeby w zakresie wydajności i zasoby, które je zrealizują, Wybrać implementacje sprzętowe lub programowe dla podsystemów Zaalokować podsystemy do procesorów tak, aby spełnić wymagania wydajności i zminimalizować komunikację pomiędzy procesorami Określić sposób połaczenia jednostki, która ma implementować podsystem. Konieczny jest wybór topologii połączeń pomiędzy jednostkami, określenie protokółów połaczeń, zminimalizowanie kosztów połączeń i transmisji

10 Zarządzanie nośnikami danych (1)
Nośniki danych mogą być (nie muszą) wydzielone z podsystemów. W takim przypadku stanowią coś w rodzaju interfejsu pomiędzy podsystemami, umożliwiającego komunikację. Bardzo często nośniki danych (baza danych) jest jedynym sposobem komunikacji pomiedzy podsystemami. Typowe nośniki fizyczne: pamięć wewnętrzna, dysk RAM (wirtualny), dysk twardy. Typowe nośniki logiczne: pliki zapisów, pliki tekstowe (dokumenty), bazy danych. Najbardziej uniwersalnym nośnikiem jest baza danych. Niestety, systemy zarządzania bazami danych mają ograniczenia (np. w zakresie przechowywania dokumentów) i czesto dość złożony interfejs programistyczny. Np. relacyjne bazy danych. Obiektowe bazy danych mają mniej ograniczeń, ale (na razie) są dość mało popularne. Repozytoria (repositories) są to bazy danych umożliwiające przechowywanie mniej regularnych danych (np. dokumentów) oraz posiadające bardziej przyjazny interfejs użytkownika. Kiedy warto zastosować relacyjną bazę danych: Jeżeli dane wymagają precyzyjnego, spójnego dostępu wielu użytkowników Jeżeli dane wymagają złożonego przetwarzania poprzez komend RSZBD Jeżeli dane mają byc przenaszane pomiędzy wieloma platformami sprzętowymi i syst.oper. Jeżeli dane mają być dostępne dla więcej niż jednego programu aplikacyjnego

11 Zarządzanie nośnikami danych (2)
Dane nie kwalifikujące się do zastosowania relacyjnej bazy danych: Duże objętościowo, ale nie dające się dobrze sformatować (np. dokumenty, tekst, strony Web, programy, grafika) Duże objętościowo, ale o małej wadze informacyjnej (np. pliki archiwalne, zapisy dziennika testowania, itd.) “Surowe” dane, przed ich kontrolą i sformatowaniem Dane tymczasowe, które istnieją przez krótki czas i następnie są kasowane Zalety stosowania baz danych Zapewniają infrastrukturę dla zapewnienia spójności, bezpieczeństwa, wielodostępu, rozproszenia, itd. Zapewniają wspólny interfejs dla wielu zastosowań. Zapewniają wspólny język dostępu (szczególnie SQL) Wady stosowania baz danych Narzut na wydajność. Dla krytycznych zastosowań czasu rzeczywistego może być nieakceptowalny. Niewystarczająca funkcjonalność dla zaawansowanych zastosowań (np. wymagających grafiki, nieregularnych danych, itd.) Niezręczny interfejs z językami programowania (niezgodność impedancji)

12 Globalne zasoby, warunki brzegowe
Projektant musi określić z jakich globalnych zasobów będzie korzystać i jakie zasoby systemu będzie udostępniać globalnie. Zasób globalny: taki który może być przydzielony dla innych systemów, generowany przez inne systemy lub używany przez inne systemy. Mogą to być np.: jednostki sprzętowe (procesory, napędy dyskowe, napędy taśmowe, okablowanie, ...) przestrzeń dyskowa, ekran stacji roboczej, klawiatura, mysz logiczne nazwy, nazwy plików, nazwy klas, identyfikatory obiektów bazy danych, zasoby tekstowe Web, usługi oferowane lub adoptowane Zasoby globalne muszą często podlegać generalnemu “strażnikowi”, który określa kiedy dany zasób może być przydzielony/odebrany. Mogą być też przedmiotem ustaleń lub umów z innymi użytkownikami lub innymi zespołami projektowymi. Warunki brzegowe systemu/podsystemu: Inicjalizacja: zadbanie o to, aby system wznowił pracę ze stanu początkowego lub po błędzie. Inicjalizacja dotyczy ustalenia wartości początkowych, danych stałych, itd. Zakończenie: zadbanie o to, aby system mógł byc bezpiecznie zawieszony lub wyłączony Błąd: Nie istnieją systemy bez błędu. Projektant musi przewidzieć spójną reakcję na wystąpienie błędu, zawieszenie lub dowolną niepoprawną pracę systemu.

13 Podsumowanie metodologii
Metodyka zakłada szereg kroków. Kolejność ich jest istotna, ale: - doświadczeni projektanci mogą wykonać niektóre kroki równolegle - iteracje są niezbędne dla uwzględnienia różnych poziomów abstrakcji i rafinacji szczegółów - po analizie całości na pewnym poziomie abstrakcji możliwe jest wydzielenie podsystemu i rozwijanie tych podsystemów niezależnie Różnica pomiędzy analizą i projektowaniem jest czasami trudno uchwytna. Istnieją proste reguły dla ich rozróżnienia: - Model analityczny zawiera informację istotną z punktu widzenia opisywanego świata i powinien prezentować zewnętrze systemu. Model analityczny powinien być zrozumiały dla przyszłego uzytkownika systemu i powinien wyrażać zewnętrzne wymagania na system. - Model projektowy jest zorientowany na implementację komputerową. W związku z tym musi być rozsądnie efektywny i praktyczny do zakodowania. W praktyce, większość informacji z modelu analitycznego może być pozostawiona bez zmian w modelu projektowym. Dokumentacja modeli powinna być odpowiednio zróznicowana, aby uwzględnić te dwie perspektywy.

14 Podsumowanie metodologii: Analiza (1)
Model jest wyrażony w terminach obiektów, związków, dynamicznego przepływu sterowania, i transformacji funkcjonalnych. Kroki są następujące: 1. Napisz lub uzyskaj wstepny opis problemu (Ustalenie Problemu) 2. Zbuduj model obiektów: zidentyfikuj klasy obiektów załóż słownik danych zawierający opisy klas, atrybutów i asocjacji połącz klasy asocjacjami dodaj atrybuty do obiektów i powiązań zorganizuj i uprość klasy obiektów używając dziedziczenia przetestuj ścieżki dostępu używając scenariuszy; powtórz powyższe kroki jeżeli potrzeba zgrupuj klasy w moduły, bazując na powiązaniach klas i związanych funkcjach  Model Obiektów = diagram modelu obiektów + słownik danych 3. Rozwiń model dynamiczny przygotuj scenariusze typowych sekwencji interakcji zidentyfikuj zdarzenia między obiektami i przygotuj trop zdarzeń dla każdego scenariusza przygotuj diagram przepływu zdarzeń dla systemu rozwiń diagram stanów dla każdej klasy, która ma istotne dynamiczne zachowanie sprawdź spójność i kompletność zdarzeń występujących pomiędzy diagramami stanów  Model Dynamiczny = diagram stanów + globalny diagram przepływu zdarzeń

15 Podsumowanie metodologii: Analiza (2)
4. Skonstruuj model funkcjonalny zidentyfikuj wartości wejściowe i wyjściowe użyj diagramu przepływu danych dla pokazania zależności pomiędzy funkcjami opisz co robi każda funkcja zidentyfiku ograniczenia wyspecyfikuj kryteria optymalizacji  Model Funkcjonalny = diagram przepływu danych + ograniczenia 5. Weryfikuj, powtarzaj i uściślaj wymienione trzy modele Dodaj kluczowe operacje odkryte podczas przygotowania modelu funkcjonalnego do modelu obiektów. Nie pokazuj w nim wszystkich operacji, gdyż mogą zaciemnić model. Zweryfikuj klasy, asocjacje atrybuty i operacje na wzajemną spójność i kompletność. Porównaj trzy modele na wybranym poziomie abstrakcji. Porównaj je z Ustaleniem Problemu oraz z wiedzą dziedzinową. Przetestuj modele używając scenariuszy Rozpracuj bardziej szczegółowe scenariusze (właczając w to warunki błędów) jako warianty scenariuszy podstawowych. Użyj te “Co, jak...?” scenariusze do dalszej weryfikacji trzech modeli Powtórz powyższe kroki zgodnie z potrzebą, aż do zakończenia analizy.  Dokument Analizy = Ustalenie Problemu + Model Obiektów + Model Dynamiczny + Model Funkcjonalny

16 Podsumowanie metodologii:Projektowanie Systemowe
Podczas projektowania systemowego wybierana jest ogólna architektura systemu. 1. Organizacja systemu, określenie jego podsystemów 2. Zidentyfikowanie procesów współbieżnych inherentnych dla problemu 3. Przydzielenie podsystemów do procesorów i zadań 4. Wybranie podejścia do zarządzania składem (nośnikami) danych: strukturą danych, plikami, bazą danych 5. Ustalenie dostępu do zasobów globalnych 6. Implementacja sterowania w oprogramowaniu - użyj pewnych zmiennych programu do przechowywanbia stanu, lub - bezpośrednio zaimplementuj automat ze stanami, lub - użyj techniki zadań współbieżnych 7. Ustalenie warunków brzegowych 8. Ustalenie priorytetów obowiazujacych przy kompromisach  Dokument Projektowania Systemowego = struktura podstawowej architektury systemu oraz decyzje dotyczące strategii wysokiego poziomu.

17 Podsumowanie metodologii: Projektowanie obiektowe (1)
Podczas projektowania obiektowego rozpracowujemy model analizy zapewniając szczegółową podstawę dla implementacji. Decyzje implementacyjne określamy bez nadmiernego wchodzenia w detale języka programowania lub systemu bazy danych. Projektowanie obiektów przesuwa orientację ze świata rzeczywistego będącego przedmiotem modelu analitycznego na świat komputerowy, będący przedmiotem implementacji. 1. Odzyskaj operacje modelu obiektowego z innych modeli - Znajdź operację dla każdego procesu w modelu funkcjonalnym - Zdefiniuj operację dla każdego zdarzenia w modelu dynamicznym, w zależności od implementacji sterowania 2. Opracuj algorytmy implementujące operacje - Wybierz algorytmy minimalizujące koszt operacji - Wybierz struktury danych właściwe dla algorytmów - Zdefiniuj nowe wewnętrzne klasy i operacje, jeżeli są potrzebne - Przypisz odpowiedzialność do operacji które nie są związane z pojedynczą klasą 3. Zoptymalizuj ścieżki dostępu do danych - Dodaj redundantne asocjacje dla zminimalizowania kosztów dostępu i zmaksymalizowania wygody - Zmień układ obliczeń dla większej efektywności - Określ zapamiętywanie wartości pochodnych dla uniknięcia ponownego wykonywania skomplikowanych operacji

18 Podsumowanie metodologii: Projektowanie obiektowe (2)
3. Zoptymalizuj ścieżki dostępu do danych - Dodaj redundantne asocjacje dla zminimalizowania kosztów dostępu i zmaksymalizowania wygody - Zmień układ obliczeń dla większej efektywności - Określ zapamiętywanie wartości pochodnych dla uniknięcia ponownego wykonywania skomplikowanych operacji 4. Zaimplementuj sterowanie oprogramowaniem poprzez zmaterializowanie założeń przyjetych podczas projektowania systemu 5. Popraw strukture klas dla zwiększenia stopnia dziedziczenia - Zmień i popraw aranżację klas i operacji dla zwiększenia stopnia dziedziczenia - Zwiększ abstrakcję poprzez wyciągnięcie przed nawias wspólnych metod - Użyj delegacji dla dzielenia metod jeżeli dziedziczenie jest semantycznie niepoprawne 6. Zaprojektuj implementację asocjacji - Przeanalizuj przejścia po asocjacjach - Zaimplementuj każdą asocjację jako odrębny obiekt lub dodaj do jednej lub dwóch klas atrybuty przechowujące obiekty (referencje, wskaźniki) 7. Określ dokładną reprezentację atrybutów obiektów 8. Umieść klasy i asocjacje w modułach  Dokument Projektowy = Szczegółowy Model Obiektów + Szczegółowy Model Dynamiczny + Szczegółowy Model Funkcjonalny