1 / 30

Projektowanie systemów informacyjnych

Projektowanie systemów informacyjnych. Wykład 9: OMT - Strategia rozwijania systemu (1). Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa. Opisanie rzeczywistości istniejącej objętej obszarem zastosowań:

wells
Télécharger la présentation

Projektowanie systemów informacyjnych

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Projektowanie systemów informacyjnych Wykład 9: OMT - Strategia rozwijania systemu (1) Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

  2. Opisanie rzeczywistości istniejącej objętej obszarem zastosowań: analiza obszaru zastosowania stanowiąca kontekst proponowanego S.I. (problem domain) analiza zakresu systemu informacyjnego (modele: obiektów, dynamiczny, funkcjonalny) Stworzenie nowego systemu informacyjnego dla rozpatrywanego obszaru zastosowań w instytucji usprawniającego jej działanie Wyspecyfikowanie wszystkich wymagań użytkowych, które muszą zostać spełnione przez system poprzez opisanie rzeczywistości projektowanej objętej obszarem zastosowań: opis architektury systemów informatycznych (funkcje użytkowe, procesy, model danych, schematy zewnętrzne, scenariusze) opis ilościowy danych i funkcji opis wymagań eksploatacyjnych opis wymagań technologicznych Analiza i projektowanie pojęciowe - Cele

  3. Podstawowe fazy cyklu życiowego SI Studium osiągalności celów Zbieranie i analiza wymagań Projektowanie Implementacja Budowa prototypu Ocena jakości i testowanie Model “wodospadowy” (waterfall): następna faza zaczyna się po zakończeniu poprzedniej. Często jest mało realistyczny. Model “spiralny” (spiral) - powtarzanie się tych samych czynności w kolejnych fazach rozwoju projektu Eksploatacja

  4. Cykl życia systemu informatycznego (1) Analiza wymagań Wstępne projektowanie Szczegółowe projektowanie Programowanie Testowanie składowych Integracja Testowanie systemu Model wodospadowy Utrzymanie

  5. Cykl życia systemu informatycznego (2) Analiza Projektowanie Specyfikacja wymagań Gotowa wersja 1 Implementacja i testowanie składowych Gotowa wersja 3 Gotowa wersja 2 Model spiralny Integracja

  6. Rozkład prac w projekcie Pracochłonność Testowanie Implementacja Projektowanie Analiza Czas

  7. Cykl życiowy realizacji SI Analiza i Projektowanie Ob. zast. - 1 Realizacja Prototypu 1 Konstrukcja Systemu 1 UTRZYMANIE S I Re - inżynieria Wdrożenie Systemu 1 Studium osiągalności celów (Strategiczny plan rozwoju informatyzacji) Analiza i Projektowanie Ob. zast. - 2 Realizacja Prototypu 2 Konstrukcja Systemu 2 Wdrożenie Systemu 2 ? Wdrożenie Systemu N Konstrukcja Systemu N Realizacja Prototypu N Analiza i Projektowanie Ob. zast. - N Przygotowania do realizacji i wdrożenia SI Kontrola jakości Zarządzanie Projektem

  8. OMT: Strategia rozwijania systemu (1) Konceptualizacja: dokładne wyobrażenie sobie problemu do rozwiązania oraz podejścia systemowego, które go rozwiązuje. Sformułowanie wstępnych warunków poprzez rozrysowanie scenariuszy (use cases) oraz wylistowanie wymagań. Analiza:opisanie zewnętrznego zachowania się systemu jako “czarnej skrzynki” poprzez budowę modeli OMT w terminologii i pojęciach użytkowników. W tej fazie należy unikać jakichkolwiek pojęć odnoszących się do wnętrza komputera, chyba że mają one być bezpośrednio widoczne dla użytkowników. Należy również unikać podejmowania decyzji projektowych, aby przedwcześnie nie przywiązywać się do rozwiązań dopóki nie są znane wszystkie wymagania.Należy starać się zweryfikować model poprzez badanie jego spójności i “ręczną” symulację jego funkcji. Projektowanie systemowe: podejmowanie decyzji wysokiego poziomu dotyczących implementacji systemu, włączając w to jego ogólną strukturę.

  9. OMT: Strategia rozwijania systemu (2) Projektowanie obiektowe: rozpracowanie modeli analitycznych poprzez rozwinięcie operacji wysokiego poziomu w dostępne operacje. Poczynienie decyzji dotyczących algorytmów i struktur danych, bez wplątywania się w szczegóły języka programowania. Większość decyzji powinna być wyrażona w sposób niezależny od języka. Uzyskanie modelu implementacyjnego - prototypu (niekoniecznie efektywnego); następnie uściślanie go i optymalizacja krok po kroku (ew. z pomiarami wydajności dla uzyskania poglądu co do potrzebnych optymalizacji). Programowanie obiektowe: odwzorowanie decyzji projektowych w konkretnym języku programowania. Kodowanie powinno być podzielone i lokalne, ponieważ wszystkie globalne decyzje projektowe powinny być podjęte na poprzednim etapie. W tej fazie wiele spontanicznych metod może być dodane dla wygody i hermetyzacji: np. metody hermetyzujące dostęp do atrybutów, dodatkowe asocjacje dla przeglądania, obiekty konstrukcyjne, wygodne odwołania do podstawowych operacji. Te elementy nie powinny być składową projektowania obiektowego, ponieważ mogą one być wygenerowane automatycznie lub zaprogramowane w rutynowy sposób.

  10. OMT: Proces Analizy Pierwszy przebieg: zidentyfikuj obiekty i atrybuty. Udokumentuj je w modelu obiektowym i słowniku danych Drugi przebieg: Usuń niepotrzebne klasy i dodaj dziedziczenie. Udokumentuj to w modelu obiektowym i słowniku danych Trzeci przebieg: Dadaj asocjacje, oznaczenia liczności asocjacji, dokonaj rafinacji asocjacji, dodaj nowe atrybuty związane z asocjacjami, sprecyzuj relacje zawierania się (agregacje). Udokumentuj to w modelu obiektowym i słowniku danych Czwarty przebieg: dodaj operacje/metody do klas poprzez zbudowanie modelu dynamicznego. Jeżeli jestes z siebie zadowolony(-a), przejdź do projektowania; w przeciwnym przypadku idź spowrotem do drugiego przebiegu. Udokumentuj to w modelu obiektowym i słowniku danych

  11. OMT: Metody identyfikacji klas obiektów (1) Zidentyfikuj kandydujące rzeczowniki ze sformulowania problemu i wymagań jako potencjalne klasy. Szukaj transakcji, zdarzeń, ról, i rzeczy dotykalnych, np. Sklasyfikuj rzeczowniki jako: ludzie, miejsca, rzeczy, organizacje, pojęcia (zasady, pomysły, reguły), zdarzenia (rzeczy, które się zdarzają). Zidentyfikuj rzeczowniki, które nie mają kompletnej definicji. Przypisz je do kategorii atrybutów lub klas obiektów. Transakcje: pożyczka, spotkanie, sprzedaż Zdarzenia: lądowanie, zapytanie Role: matka, ojciec, nauczyciel, pasażer Rzeczydotykalne: samochód, czujnik, składnik, samolot

  12. OMT: Metody identyfikacji klas obiektów (2) Zidentyfikuj potencjalne kolekcje (zbiory). Pewne rzeczowniki implikuja kolekcje i mogą stać się kontenerami (container). Kolekcje wymagają bazy danych i specjalnego programowania. Zidentyfikuj obiekty stanowiące pogranicze systemu: obiekty dostępne dla innych systemów, linie komunikacyjne, urzadzenia peryferyjne, obiekty wejścia/wyjścia,.. Np.: Każdy dostęp jest rejestrowany w dzienniku. Ergo: dziennik jest kolekcją. • Charakterystyczne cechy obiektów we/wy: • Ich atrybuty lub stan są ulotne (niestabilne) • Zmieniają się pod wpływem bodźców zewnętrznych • Są źródłem/przechowalnią komunikatów z zewnątrz • Nie można ich usunąć

  13. OMT: Identyfikacja potencjalnych atrybutów Rzeczownik może być atrybutem, jeżeli nie można przypisać mu zachowania i atrybutów. Rzeczownik może być atrybutem, jeżeli wyjaśnienie jego znaczenia zmusza do odwołania się do jakiegoś innego rzeczownika (oznaczającego obiekt). Np. rzeczownik “kolor” zmusza do zadania pytania “kolor czego?”. Zastanów się czy coś, co może byc atrybutem, nie jest asocjacją między klasami. Zidentyfikuj klasę lub asocjację, która jest najlepszym kandydatem jako “właściciel” atrybutu.

  14. Udokumentuj twoje ustalenia! Utwórz zarys projekt w postaci diagramu obiektowego wysokiego poziomu (najlepiej, przy użyciu narzędzia CASE). Twórz nowy diagram obiektowy dla każdego kroku iteracyjnego. Staraj się równolegle budować model dynamiczny. Pracuj nad słownikiem danych. Dla każdej klasy ustal: Kategorię obiektów klasy (ludzie, miejsca, rzeczy, ...) Kto/co tworzy obiekty klasy Kto/co usuwa obiekty klas Kto/co modyfikuje obiekty klasy Kto/co posiada lub zawiera obiekty klasy Wypisz interfejsy wspomagane przez klasę Wypisz widoczne publicznie atrybuty Wypisz źródło wartości dla każdego atrybutu w klasie Wypisz asocjacje klasy z innymi klasami Cel tej klasy Opisz tę klasę

  15. OMT: Dodaj generalizacje/specjalizacjei usuń niepotrzebne obiekty i atrybuty Wyciągnij przed nawias wszelkie wspólne własności (operacje i atrybuty) kilku powiazanych klas. Zgrupuj te wspólne własności w jedną super-klasę Nazwij tę superklasę w taki sposób, aby każda pochodna klasa mogła byc uważana za podklasę. Np. pies jest superklasą, pekińczyk, jamnik, pudel są podklasami klasy pies. Podklasy moga mieć puste lub niepuste przecięcie. Oznacz je odpowiednio. Obiekt należący do przecięcia dziedziczy z obu pod-klas.

  16. Dodaj asocjacje • Asocjacje są dowolnymi związkami pomiędzy obiektami. Jakakolwiek zależność • pomiędzy obiektami może być zaimplementowana jako asocjacja. • Model dynamiczny może sugerować wiele asocjacji między obiektami. • Przetestuj ścieżki dostępu; niekiedy dostęp do obiektu wymaga dostępu do innego • obiektu, co implikuje asocjację. • Dodaj oznaczenia liczności do asocjacji. • Zidentyfikuj role dla asocjacji rekurencyjnych (w ramach tej samej klasy), ternarnych, itd. • Sprawdź, czy asocjacja ma prowadzić do danej klasy, czy tez raczej do podklasy lub • superklasy. • Dodaj nowe atrybuty związane z wprowadzoną asocjacją. • Jeżeli asocjacja ma charakter “część-całość”, zamień ją na agregację • Udokumentuj te ustalenia w modelu obiektowym i w słowniku danych!

  17. Rozwijaj model dynamiczny Opracuj scenariusze typowych interakcji. Zidentyfikuj zdarzenia zachodzące pomiędzy obiektami i narysuj diagram tropów zdarzeń (event trace diagram) dla każdego scenariusza. Opracuj diagram przepływu zdarzeń dla systemu Diagramy interakcji obiektów i diagramy stanów są używane do modelowania warstwy komunikatów i zachowania się systemu. 1. Opracuj diagram stanów dla każdej klasy która ma istotne zachowanie dynamiczne. 2. Sprawdź kompletność i spójność zdarzeń na takich diagramach

  18. OMT: Modelowanie zdarzeń i stanów Zdarzenia są czymś występującym spontanicznie w czasie. Zdarzenia mogą byc powiązane (synchroniczne). Moga też występować losowo, niezależnie od innych zdarzeń (asynchronicznie). Zdarzenia mogą być generalizowane w typy. Zdarzenia mogą miec parametry. Zdarzeniom można przypisać pewne warunki ich występowania. Np. zielone światło dla pociągu pojawia się tylko wtedy, jeżeli tor jest wolny. OMT nie rozrożnia zdarzeń i komunikatów. Interakcja obiektów następuje poprzez zdarzenia. Zewnętrzne środowisko może generować zdarzenia, które są przechwytywane przez obiekty we/wy. Obiekty we/wy mogą generować (wysyłać) zdarzenia do srodowiska zewnętrznego. Zdarzenia powodują zmiany stanów obiektów. Stan jest czymś co trwa przez jakiś czas. Stany są abstrakcjami obejmującymi wartości atrybutów, powiązań i innych cech.

  19. Budowa Modelu OMT - Strategia TOP-DOWN Od ogółu do szczegółu (top-down) - najpierw definiuje się ogólne pojęcia, a następnie rozwija się je poprzez dodawanie szczegółów stosując elementy podstawowe (prymitywy). Kolejne rozwinięcia coraz bardziej szczegółowe

  20. Strategia TOP-DOWN - Prymitywy (1) KLASY => KLASY POWIĄZANE KLASA => UOGÓLNIENIE KLASA=> KILKA KLAS NIEZALEŻNYCH POWIĄZANIE=> POWIĄZANIE RÓWNOLEGŁE

  21. Strategia TOP-DOWN - Prymitywy (2) POWIĄZANIE=> KLASA Z POWIĄZANIAMI UZUPEŁNIENIE O ATRYBUTY PROSTE A1 A2 B1 B2 A B ROZWINIĘCIE ATRYBUTÓW UZUPEŁNIENIE O OPERACJE

  22. Strategia TOP-DOWN - Przykłady (1) MIASTO MIEJSCE WOJEWÓDZTWO PRACOWNIK PRACOWNIK FIZYCZNY UMYSŁOWY NAGRODY NAGRODA OSCAR NAGRODA NOBLA

  23. Strategia TOP-DOWN - Przykłady (2) OSOBA OSOBA Mieszka_w Urodziła_się_w Jest_związana_z MIASTO MIASTO PRACOWNIK PRACOWNIK Pracuje z Pracuje_na KIEROWNIK Kieruje WYDZIAŁ WYDZIAŁ

  24. Strategia TOP-DOWN - Przykłady (3) OSOBA Imię Nazwisko Data_ur OSOBA OSOBA Miasto Kod Ulica OSOBA Adres OSOBA ..... Data_ur OSOBA ..... Data_ur Wiek

  25. Strategia TOP-DOWN - Przykłady (4) DANE DEMOGRAFICZNE DANE O TERENIE DANE O MIESZKAŃCACH Mieszka w MIEJSCE OSOBA Urodziła się w ZAGRANICA MIASTO W KRAJU MĘŻCZYZNA KOBIETA Znajduje się w WOJEWÓDZTWO

  26. Od szczegółu do ogółu (BOTTOM-UP) - najpierw definiuje się pojęcia elementarne, a następnie buduje się z nich struktury w celu stworzenia pojęć ogólnych. Budowa Modelu OMT - Strategia BOTTOM-UP WYMAGANIA WYMAGANIA n WYMAGANIA 1 . . . . . POJĘCIE nk POJĘCIE 1m POJĘCIE 11 POJĘCIE n1 ..... ..... DIAGRAM nk DIAGRAM n1 DIAGRAM 1m DIAGRAM 11 ..... ..... . . . . . DIAGRAM n DIAGRAM 1 KOŃCOWY DIAGRAM ZINTEGROWANY

  27. Strategia BOTTOM-UP - Prymitywy STWORZENIE KLASY STWORZENIE ASOCJACJI . . . STWORZENIE GENERALIZACJI ..... OSOBA Miasto Kod Ulica OSOBA Adres ZAGREGOWANIE ATRYBUTÓW

  28. Strategia BOTTOM-UP - Przykład MIASTO W KRAJU WOJEWÓDZTWO KOBIETA ZAGRANICA MĘŻCZYZNA OSOBA Związana z MIEJSCE OSOBA MĘŻCZYZNA KOBIETA MIASTO W KRAJU MIEJSCE Znajduje się w ZAGRANICA MIASTO W KRAJU WOJEWÓDZTWO

  29. Rozprzestrzenianie (INSIDE-OUT) - najpierw definiuje się pojęcia, które wydają sie najważniejsze, a następnie rozwija się je poprzez dobudowywanie kolejnych pojęć, które stanowią ich uzupełnienie. Strategia INSIDE-OUT WYMAGANIA W istocie, strategie projektowania są zwykle oparte na rozprzestrzenianiu, z inklinacją do top-down lub bottom-up. POJĘCIA NAJWAŻNIEJSZE Diagram wstępny DIAGRAMY (coraz szersze) Diagramy pośrednie DIAGRAM KOŃCOWY

  30. Mieszana- stosuje się różne z wcześniej wymienionych strategii projektowania. Najpierw top-down, następnie bottom-up, potem inside-out, potem znowu top-down, itd. budując szkielety diagramów, które są następnie konsolidowane i uszczegóławiane. Strategia MIESZANA WYMAGANIA WYMAGANIA n WYMAGANIA 1 POJĘCIE nk POJĘCIE 1m POJĘCIE n1 POJĘCIE 11 ..... ..... SZKIELETY DIAGRAMÓW DIAGRAM nk DIAGRAM n1 DIAGRAM 11 DIAGRAM 1m ..... ..... DIAGRAM n DIAGRAM 1 KOŃCOWY DIAGRAM ZINTEGROWANY

More Related