Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta Instytut Podstaw Informatyki.

Podobne prezentacje


Prezentacja na temat: "K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta Instytut Podstaw Informatyki."— Zapis prezentacji:

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

2 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 2 Projektowanie SI jest bardzo złożone Czynniki od strony klienta: 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 Czynniki od strony projektanta: 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 3 Cztery światy inżynierii systemów informatycznych Świat przedmiotu SI Świat projektowania i rozwoju SI Świat użycia SI Świat SI Użycie informacji odnośnie przedmiotu SI wewnątrz SI Reprezentacja informacji odnośnie przedmiotu SI wewnątrz SI Interfejsy użytkownika Decyzje projektowe Uzasadnienie celów projektowania i rozwoju SI

4 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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) Partycje, topologia systemu Ustala (zwykle w pewnej formie graficznej) zależności pomiędzy podsystemami. pakiet aplikacyjny grafika okienkowa grafika ekranowa grafika pikselowa system operacyjny sprzęt sterowanie dialogiem użytkown. pakiet symulac. np.

9 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 9 Alokacja podsystemów do procesorów i zadań Każdy współbieżny podsystem musi być zaalokowany do pewnej jednostki sprzętu. Projektant systemu powinien: 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? 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 16 Podsumowanie metodologii:Projektowanie Systemowe 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 Podczas projektowania systemowego wybierana jest ogólna architektura systemu. Dokument Projektowania Systemowego = struktura podstawowej architektury systemu oraz decyzje dotyczące strategii wysokiego poziomu.

17 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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 K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 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


Pobierz ppt "K.Subieta. Projektowanie systemów informacyjnych, Wykład 11, Folia 1 Projektowanie systemów informacyjnych Kazimierz Subieta Instytut Podstaw Informatyki."

Podobne prezentacje


Reklamy Google