plik

Projekt Informatyczny: Faza projektowania

4 Faza projektowania

Podstawowym celem fazy projektowania jest stworzenie wizji, w jaki sposób

projektowany system ma zostać zaimplementowany. Wynikiem tej fazy jest kompletny opis

sposoby implementacji oraz harmonogram fazy implementacji.

Mając już wykonaną fazę analizy, w tej fazie należy zdecydować jakiego typu

oprogramowanie mamy zamiar wytworzyć, a co za tym idzie wybrać konkretną technikę

projektowania, z którą nierozerwalnie związane są konkretne języki programowania.

4.1. Decyzje strategiczne

Rozpatrując sposób implementacji, należy wziąć pod uwagę:

a) hardware

b) system operacyjny

c) język programowania

d) narzędzia programistyczne

e) biblioteki

Należy wybrać technikę projektowania:

a) projektowanie strukturalne:

- zorientowane na akcje

- zorientowane na dane

b) projektowanie obiektowe

Należy wybrać strategię budowy modelu:

a) top – down

Od ogółu do szczegółu - najpierw definiuje się ogólne pojęcia, a następnie rozwija

się je poprzez dodawanie szczegółów stosując elementy podstawowe (prymitywy).

Projekt Informatyczny: Faza projektowania

b) bottom – up

Od szczegółu do ogółu - najpierw definiuje się pojęcia elementarne, a następnie

buduje się z nich struktury w celu stworzenia pojęć ogólnych.

c) inside – out

Rozprzestrzenianie - najpierw definiuje się pojęcia, które wydają się być

najważniejsze, a następnie rozwija się je poprzez dobudowywanie kolejnych pojęć,

które stanowią ich uzupełnienie.

4.2. Rezultaty fazy projektowania

1. Poprawiony dokument opisujący wymagania

2. Poprawiony model analityczny

3. Uszczegółowiona specyfikacja projektu

4. Dokument opisujący projekt

5. Zasoby interfejsu użytkownika (menu, dialogi)

6. Projekt bazy danych

7. Projekt fizycznej struktury systemu

8. Wstępny plan testów

9. Harmonogram fazy implementacji

4.3. Projektowanie strukturalne

Metodyka strukturalna wykorzystuje:

a) tablice decyzyjne

b) drzewa decyzyjne

c) schematy decyzyjne

d) diagramy przepływu danych

e) słownik danych

Projekt Informatyczny: Faza projektowania

Metody strukturalne opierają się na wyróżnieniu dwóch rodzajów składowych:

●

pasywnych – odzwierciedlających fakt przechowywania danych w systemie

●

aktywnych – odzwierciedlających fakt wykonywania pewnych operacji

Analiza strukturalna zaczyna się od budowy dwóch różnych modeli systemu:

modelu, będącego opisem pasywnej części systemu oraz modelu funkcji opisującego

aktywną część systemu. Te dwa modele są następnie integrowane i wynikiem jest model

przepływów danych.

4.3.1 Analiza przepływu danych

Analiza ta bazuje na diagramach przepływu danych. Dla każdego ciągu akcji

wyznacza punkty o najwyższej abstrakcji danych i rozdziela w nich moduły.

Cele:

●

Określenie kluczowych obiektów zewnętrznych będących w interakcji z systemem

(systemem);

●

Określenie kluczowych procesów występujących w systemie;

●

Określenie sposobu przepływu informacji i danych pomiędzy procesami;

●

Identyfikacja pakietów danych na tyle istotnych, że powinny być przechowywane

w magazynach danych.

Tworząc diagram przepływu danych, należy uwzględnić i stosować się do

wytycznych przedstawionych w prezentacji dotyczącej modeli i diagramów, wygłoszonej

na drugim spotkaniu (prezentacja znajduje się w dziale: Prezentacje IO). Przykładowy

diagram przepływu danych na poziomie kontekstowym został zilustrowany poniżej.

Diagram został wykonany za pomocą programu Visio 2003.

Projekt Informatyczny: Faza projektowania

Należy pamiętać, że diagramy powinny być zbalansowane. Wszystkie przepływy,

które pojawiły się na diagramie poziomu wyższego powinny się znaleźć na diagramie

poziomu niższego. Ponadto na niższym poziomie pojawiają się dodatkowe przepływy

pomiędzy procesami i magazynami danych oraz pomiędzy nowymi procesami, które

pojawiły się w wyniku dekompozycji procesów wyższego poziomu.

4.3.2 Analiza transakcji

Transakcja - pojedyncza operacja z punktu widzenia użytkownika systemu, np.

realizacja przelewu za fakturę, wydrukowanie listy zamówień.

Problem projektowy - realizacja podobnych transakcji (ciąg podobnych akcji

różniących się jedynie szczegółami).

Zalecany początkowy podział akcji:

1. analizator rodzaju transakcji

2. realizator wybranej transakcji.

4.4. Projektowanie obiektowe

System jest analizowany w sposób obiektowy jeśli:

●

Jest dzielony na obiekty posiadające:

Tożsamość, Stan, Zachowanie

Projekt Informatyczny: Faza projektowania

●

Obiekty są grupowane w klasy złożone z obiektów o podobnych stanach

i zachowaniu

Metody obiektowe są wygodnym narzędziem analizy złożonych systemów,

w szczególności systemów o dużej stronie pasywności i złożonej funkcjonalności

Proces tworzenia modelu obiektowego:

●

Identyfikacja klas i obiektów

●

Identyfikacja związków pomiędzy klasami

●

Identyfikacja i definiowanie pól (atrybutów)

●

Identyfikacja i definiowanie metod i komunikatów

Podstawowe zasady obiektowo

ś ci:

●

obiekt - struktura danych, występująca łącznie z operacjami dozwolonymi do

wykonywania na niej, odpowiadająca bytowi wyróżnialnemu w analizowanej

rzeczywistości

●

tożsamość obiektu - wewnętrzny identyfikator (wskaźnik), który pozwala na

odróżnienie go od innych obiektów.

●

hermetyzacja - rozróżnienie pomiędzy interfejsem do obiektu opisującym co obiekt

robi, a implementacją definiującą, jak jest zbudowany i jak robi, to co ma zrobić

●

klasa - zgrupowanie obiektów o tych samych charakterystykach

●

dziedziczenie - wielokrotne użycie tego, co wcześniej zostało zrobione:

definiowanie klas, które mają wszystkie cechy zdefiniowane wcześniej (z nadklasy)

plus cechy nowe

●

polimorfizm - wybór nazwy dla operacji jest określony wyłącznie semantyką

operacji. Decyzja o tym, która metoda implementująca daną operację, zależy od

przynależności obiektu do odpowiedniej klasy

Kolejne kroki analizy obiektowej:

●

Zidentyfikuj klasy i ich atrybuty

●

Usuń niepotrzebne klasy i dodaj dziedziczenie

●

Wyszukaj ewentualne relacje zawierania się: agregacje, kompozycje.

●

Dodaj operacje (metody) do klas poprzez zbudowanie modelu dynamicznego.

Projekt Informatyczny: Faza projektowania

Identyfikacja klas - typowe klasy:

●

odrębne przedmioty materialne (np. samochód),

●

zbiory przedmiotów materialnych (np. marka samochodu),

●

zdarzenia istotne dla systemu (np. przegląd gwarancyjny, dostawa),

●

role społeczne osób (np. pracownik, wykładowca),

●

organizacje (np. serwis samochodowy, firma),

●

interakcje między osobami lub systemami (np. pożyczka, spotkanie),

●

miejsca przebywania osób lub przedmiotów (np. adres, magazyn),

●

dokumenty (np. faktura, prawo jazdy)

Modelowanie świata rzeczywistego jest ułatwione dzięki zastosowaniu podejścia

obiektowego. Klasy, grupujące obiekty świata rzeczywistego, są najbardziej stabilnym

elementem dziedziny problemu.

Hermetyzacja wspomaga redukcję złożoności poprzez zachęcanie użytkowników,

by opierali się raczej na interfejsie do obiektu niż jego wewnętrznej organizacji.

Abstrahowanie od szczegółów implementacyjnych znacząco ułatwia proces rozumienia.

4.5. Interfejs użytkownika

Organizacja interakcji z u

ż ytkownikiem:

●

Za pomocą linii komend - dla niewielkich systemów, dla prototypów, dla

zaawansowanych użytkowników. Zazwyczaj jest szybszy od interfejsu

pełnoekranowego.

●

W pełnoekranowym środowisku okienkowym – tworzenie takiego interfejsu ma sens

dla dużych systemów. Jest wygodny dla początkujących i średnio zaawansowanych

użytkowników

Uwaga na ograniczenia możliwości psychofizycznych użytkownika:

Człowiek może się jednocześnie skupić na 5 - 9 elementach

Projekt Informatyczny: Faza projektowania

Zasady projektowania interfejsu u

ż ytkownika:

●

Spójność. Wygląd oraz obsługa interfejsu powinna być podobna w momencie

korzystania z różnych funkcji. Poszczególne programy tworzące system powinny

mieć zbliżony interfejs. Taka sama kolorystyka. Umieszczanie pól i przycisków w

tych samych miejscach

●

Skróty dla doświadczonych użytkowników

●

Potwierdzenia przyjęcia zlecenia użytkownika (dla niebezpiecznych, dla

długotrwałych, dla nietypowych operacji) Prosta obsługa błędów – czytelne

wskazanie przyczyny błędów, możliwość poprawnego wprowadzenia bez potrzeby

ponownego wprowadzania innych pól które były poprawne.

●

Możliwość odwoływania-cofnięcia ostatniej (lub kilku ostatnich) akcji.

●

Wrażenie kontroli nad systemem. Użytkownicy nie lubią, kiedy system sam robi

coś, czego użytkownik nie zainicjował, lub kiedy akcja systemu nie daje się

przerwać

4.6. Określenie fizycznej struktury systemu

a) Określenie struktury kodu źródłowego, tj. wyróżnienie plików źródłowych,

zależności pomiędzy nimi oraz rozmieszczenie składowych projektu w plikach

źródłowych

b) Podział systemu na poszczególne aplikacje

c) Fizyczne rozmieszczenie danych i aplikacji na stacjach roboczych i serwerach.

4.7. Dokument Detali Projektu — DDP

Informacje organizacyjne: Streszczenie (max 200 słów), spis treści,

Status dokumentu (autor, firmy,daty,..), zmiany względem poprzedniej

wersji

Część 1 — Opis ogólny

1. Wprowadzenie

1.1. Cel

1.2. Zakres

Projekt Informatyczny: Faza projektowania

1.3. Definicje, akronimy i skróty

1.4. Referencje i odsyłacze do innych dokumentów

1.5. Krótkie omówienie

2. Standardy projektu, konwencje, procedury

2.1. Standardy projektowe

2.2. Standardy dokumentacyjne

2.3. Konwencje nazewnicze

2.4. Standardy programistyczne

2.5. Narzędzia
Część 2 — Specyfikacja komponentów

n. Identyfikacja komponentu

n.1. Typ

n.2. Cel

n.3. Funkcja

n.4. Komponenty podporządkowane

n.5. Zależności

n.6. Interfejsy

n.7. Zasoby

n.8. Odsyłacze

n.9. Przetwarzanie

n.10. Dane
Dodatek A. Wydruki kodu źródłowego

Dodatek B. Macierz zależności miedzy wymaganiami, a komponentami

Document Outline