Projektowanie systemów informacyjnych

K.Subieta. Projektowanie systemów informacyjnych, Wykład 9, Folia 1

Projektowanie systemów informacyjnych

Kazimierz Subieta

Instytut Podstaw Informatyki PAN, Warszawa

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 9: OMT - Strategia rozwijania systemu (1)


Analiza i projektowanie pojęciowe - Cele

• 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


Podstawowe fazy cyklu życiowego SI

Studiumosiągalności

celów

Zbieraniei analiza wymagań

Projektowanie

Budowaprototypu

Implementacja

Ocena jakościi testowanie

Eksploatacja

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


Cykl życia systemu informatycznego (1)

Model wodospadowy

Analizawymagań

Wstępneprojektowanie

Szczegółoweprojektowanie

Programowanie

Testowanieskładowych

Integracja

Testowaniesystemu

Utrzymanie


Cykl życia systemu informatycznego (2)

Analiza

Integracja

Projektowanie

Implementacjai testowanieskładowych

Specyfikacja wymagań

Gotowawersja 1

Gotowawersja 2

Gotowawersja 3

Model spiralny


Rozkład prac w projekcie

Czas

Analiza

Projektowanie

Implementacja

Testowanie

Pracochłonność


Cykl życiowy realizacji SI

?

Kontrola jakości

Zarządzanie Projektem

Przygotowania do realizacji i wdrożenia SI

Analiza iProjektowanieOb. zast. - 1

Analiza iProjektowanieOb. zast. - N

Analiza iProjektowanieOb. zast. - 2

RealizacjaPrototypu

1

RealizacjaPrototypu

2

RealizacjaPrototypu

N

KonstrukcjaSystemu

1

KonstrukcjaSystemu

2

KonstrukcjaSystemu

N

UTRZYMANIE

SI

WdrożenieSystemu

1

WdrożenieSystemu

2

WdrożenieSystemu

N

Re-inżynieria

Studiumosiągalności

celów(Strategicznyplan rozwoju

informatyzacji)


OMT: Strategia rozwijania systemu (1)

Konceptualizacja: dokładne wyobrażenie sobie problemu do rozwiązania orazpodejścia systemowego, które go rozwiązuje. Sformułowanie wstępnych warunkówpoprzez 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 fazienależy unikać jakichkolwiek pojęć odnoszących się do wnętrza komputera, chyba żemają one być bezpośrednio widoczne dla użytkowników. Należy również unikać podejmowania decyzji projektowych, aby przedwcześnie nie przywiązywać się dorozwią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ę.


OMT: Strategia rozwijania systemu (2)

Projektowanie obiektowe: rozpracowanie modeli analitycznych poprzez rozwinięcieoperacji wysokiego poziomu w dostępne operacje. Poczynienie decyzji dotyczącychalgorytmó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. Uzyskaniemodelu implementacyjnego - prototypu (niekoniecznie efektywnego); następnie uściślanie go i optymalizacja krok po kroku (ew. z pomiarami wydajności dla uzyskania pogląduco do potrzebnych optymalizacji).

Programowanie obiektowe: odwzorowanie decyzji projektowych w konkretnym językuprogramowania. 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. metodyhermetyzują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.


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 rafinacjiasocjacji, dodaj nowe atrybuty związane z asocjacjami, sprecyzuj relacjezawierania się (agregacje).


Czwarty przebieg: dodaj operacje/metody do klas poprzez zbudowanie modeludynamicznego. Jeżeli jestes z siebie zadowolony(-a), przejdź do projektowania;w przeciwnym przypadku idź spowrotem do drugiego przebiegu.



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, zapytanieRole: matka, ojciec, nauczyciel, pasażerRzeczy dotykalne: samochód, czujnik, składnik, samolot


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ąć


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.


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 klasyKto/co usuwa obiekty klasKto/co modyfikuje obiekty klasyKto/co posiada lub zawiera obiekty klasyWypisz interfejsy wspomagane przez klasęWypisz widoczne publicznie atrybutyWypisz źródło wartości dla każdego atrybutu w klasieWypisz asocjacje klasy z innymi klasamiCel tej klasyOpisz tę klasę


OMT: Dodaj generalizacje/specjalizacjei usuń niepotrzebne obiekty i atrybuty

Wyciągnij przed nawias wszelkie wspólne własności (operacje i atrybuty) kilkupowiazanych 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żanaza 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.


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!


Rozwijaj model dynamiczny

Opracuj scenariusze typowych interakcji. Zidentyfikuj zdarzenia zachodzącepomię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 modelowaniawarstwy 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


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.

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.


Budowa Modelu OMT - Strategia TOP-DOWN

Kolejnerozwinięcia

coraz bardziej szczegółowe

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).


Strategia TOP-DOWN - Prymitywy (1)

KLASY => KLASY POWIĄZANE

KLASA => UOGÓLNIENIE

KLASA=> KILKA KLAS NIEZALEŻNYCH

POWIĄZANIE=> POWIĄZANIE RÓWNOLEGŁE


Strategia TOP-DOWN - Prymitywy (2)

POWIĄZANIE=> KLASA Z POWIĄZANIAMI

UZUPEŁNIENIE O ATRYBUTY PROSTE

ROZWINIĘCIE ATRYBUTÓW

AB

A1A2B1B2

UZUPEŁNIENIE O OPERACJE


Strategia TOP-DOWN - Przykłady (1)

UMYSŁOWY

PRACOWNIK

FIZYCZNY

PRACOWNIK

NAGRODY NAGRODANOBLA

NAGRODAOSCAR

MIEJSCE

WOJEWÓDZTWO

MIASTO


Strategia TOP-DOWN - Przykłady (2)OSOBA

MIASTO

Mieszka_w

Urodziła_się_w

OSOBA

MIASTO

PRACOWNIK

WYDZIAŁ

Pracuje_na

Pracuje z

Kieruje

Jest_związana_z

PRACOWNIK

WYDZIAŁ

KIEROWNIK



OSOBAAdres

OSOBAOSOBAImię

NazwiskoData_ur

OSOBAMiastoKodUlica

OSOBA.....

Data_ur

OSOBA.....

Data_ur

Wiek



MĘŻCZYZNA

Mieszka w

Urodziła się w

MIEJSCEOSOBA

DANEDEMOGRAFICZNE

DANE OMIESZKAŃCACH

DANE OTERENIE

KOBIETA ZAGRANICA MIASTO W KRAJU

WOJEWÓDZTWO

Znajduje się w


Budowa Modelu OMT - Strategia BOTTOM-UP

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.

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.

WYMAGANIA

WYMAGANIA nWYMAGANIA 1

POJĘCIE 11 POJĘCIE 1m POJĘCIE n1 POJĘCIE nk

DIAGRAM 11 DIAGRAM 1m DIAGRAM n1 DIAGRAM nk

DIAGRAM 1 DIAGRAM n

KOŃCOWYDIAGRAM

ZINTEGROWANY

. . . . .

. . . . .

.....

..........

.....


Strategia BOTTOM-UP - PrymitywySTWORZENIE KLASY

STWORZENIE ASOCJACJI

STWORZENIE GENERALIZACJI

ZAGREGOWANIE ATRYBUTÓW

.....

.

.

.

OSOBAAdres

OSOBAMiastoKodUlica


Strategia BOTTOM-UP - Przykład

MĘŻCZYZNA

MIEJSCE

OSOBA

KOBIETA ZAGRANICA

MIASTO W KRAJU WOJEWÓDZTWO

MĘŻCZYZNA KOBIETA

ZAGRANICA MIASTO W KRAJU

MIASTO W KRAJU

WOJEWÓDZTWO

OSOBA MIEJSCEZwiązana z

Znajduje się w


Strategia INSIDE-OUTRozprzestrzenianie (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.

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.

POJĘCIANAJWAŻNIEJSZE

DIAGRAMY(coraz szersze)

WYMAGANIA

DIAGRAMKOŃCOWY

Diagram wstępny

Diagramy pośrednie

W istocie, strategie projektowania są zwykle oparte na rozprzestrzenianiu, z inklinacją do top-down lub bottom-up.


Strategia MIESZANAMieszana- 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.

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.

WYMAGANIA

WYMAGANIA nWYMAGANIA 1

POJĘCIE 11 POJĘCIE 1m POJĘCIE n1 POJĘCIE nk

DIAGRAM 11 DIAGRAM 1m DIAGRAM n1 DIAGRAM nk

DIAGRAM 1 DIAGRAM n

KOŃCOWYDIAGRAM

ZINTEGROWANY

.....

..........

.....SZKIELETY

DIAGRAMÓW

Projektowanie systemów informacyjnych

Documents

Transcript of Projektowanie systemów informacyjnych