PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

Plan wykładu



Anatomia projektu informatycznego



Uszczegółowienie modelu



Składowe systemów, które nie są związane

z dziedziną problemu



Interakcja z użytkownikiem



Optymalizacja projektu



Poprawność projektu



Jakość modelu i projektu



Kluczowe czynniki sukcesu projektowania

Kontraktowanie

Procedury

Architektura

Konstrukcja

Wdrożenie

Jakość

Komunikacja

Równość stron
Precyzyjna specyfikacja

systemu

Rzetelna estymacja

kosztów

Rozsądny czas realizacji
Etapowanie

Zasady zarządzania
projektem
Dobrze zdefiniowany
proces
Standardy produktów
projektu
Procedury odbioru
produktów

Pełna specyfikacja
poziom systemu
informatycznego
poziom systemu
zarządzania
Spójność technologiczna
Zgodność z celami
projektu

Ponowne użycie
  wzorce projektowe
  komponenty
  środowiska aplikacyjne
Standardy

Utrzymanie poziomu
satysfakcji
Kontrola zmian
Ocena projektu
wyniki
proces

Anatomia projektu informatycznego

Zadania wykonywane podczas

projektowania



Uszczegółowienie opracowanego

modelu logicznego

; projekt musi być

wystarczająco szczegółowy, aby mógł być

podstawą implementacji, przy czym

stopień szczegółowości zależy od poziomu

zaawansowania programistów



Projektowanie składowych systemów, które

nie są związane z dziedziną problemu



Optymalizacja

systemu



Dostosowanie do ograniczeń

możliwości środowiska implementacji



Określenie

fizycznej struktury systemu

Uszczegółowienie modelu



Określenie poziomów

widoczności

atrybutów i dostępu

do nich



Podanie

reguł odwzorowania notacji

w struktury konkretnego języka

programowania (np. polegające na

dokładnym określeniu typów danych)



Wybór sposobu implementacji

konstrukcji

, które mogą być

zrealizowane na wiele sposobów (np.

zgodnie ze standardami przyjętymi w

firmie)

Uszczegółowienie modelu



Podanie

nagłówków metod

oraz ich parametrów



Określenie,

które z metod będą realizowane

jako funkcje wirtualne

a które jako zwyczajne

funkcje



Zastąpienie niektórych

prostych metod

bezpośrednim dostępem do atrybutów



Zastąpienie niektórych

atrybutów

redundantnych

przez odpowiednie metody, np.

Wiek = BieżącaData - DataUrodzenia;

Uszczegółowienie modelu

Określenie sposobów

implementacji

związków

(asocjacji), gdyż zwykle można

je zaimplementować na wiele sposobów, z

reguły poprzez wprowadzenie

dodatkowych atrybutów (pól):



obiekty powiązanej klasy



wskaźniki

(referencje) do obiektów

powiązanej klasy



identyfikatory obiektów

powiązanej

klasy

Uszczegółowienie modelu

W zależności od przyjętego sposobu

oraz od

liczności

związków (1:1, 1:n,

n:1, m:n) możliwe są bardzo różne

deklaracje w przyjętym języku

programowania



tablica obiektów



lista wskaźników



tablica wskaźników

Dodatkowe składowe systemu

(niezwiązane z dziedziną problemu)

Składowa zarządzania

pamięcią

operacyjną

(kompilator, syst.

operacyjny)

Składowa interfejsu

użytkownika

(do

niedawna nawet do 90%

nakładów; obecnie

realizowana zwykle

poprzez GUI)

Składowa zarządzania

zadaniami

(podział czasu procesora;

kompilator, syst.

operacyjny)

Składowa zarządzania

danymi

(przechowywanie

trwałych danych, SZBD)

Składowa

dziedziny

problemu

Narzędzi

a typy

RAD

Interakcja z użytkownikiem

Za pomocą linii komend

(w niektórych

sytuacjach szybsza od interfejsu

graficznego):



nieduże systemy lub prototypy



programy typowo obliczeniowe



dla zaawansowanych użytkowników

Za pomocą plików skryptowych:



celem automatyzacji powtarzanych

wielokrotnie tych samych działań

Przez graficzny interfejs okienkowy:



większe systemy



doceniane zwłaszcza przez początkujących i

średnio zaawansowanych użytkowników

Interakcja z użytkownikiem

Typowe sposoby wydawania przez

użytkownika poleceń:



wpisywanie poleceń

w postaci tekstowej

(np.

w linii komend)



wybór

opcji z menu

lub

przycisku

w dialogu



korzystanie z ikon

w paskach narzędziowych

lub ze skrótów (kombinacje klawiszy)



nawigacja przy użyciu urządzenia

wskazującego np.

myszy

(kursor, przyciski, ...)



dotykanie aktywnego ekranu



głosem

Złote

zasady projektowania interfejsu

użytkownika (1)



Spójność - wygląd oraz obsługa interfejsu powinny

być podobne podczas korzystania z różnych funkcji

;

poszczególne programy tworzące system powinny mieć

zbliżony interfejs

podobnie powinna wyglądać praca z

rozmaitymi

dialogami

, podobnie powinny być

interpretowane operacje wykonywane przy pomocy myszy;

przykładowe reguły

•

umieszczanie etykiet

zawsze nad lub obok pól

edycyjnych,

•

umieszczanie przycisków

zawsze od dołu lub od

prawej,

•

spójne tłumaczenie

nazw angielskich, spójne

oznaczenia pól

Złote zasady projektowania interfejsu

użytkownika (2)



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

- możliwość zastąpienia komend menu przez

kombinację klawiszy



Potwierdzenie przyjęcia polecenia

użytkownika

- realizacja niektórych operacji

może trwać stosunkowo długo; w takich

sytuacjach, aby użytkownik nie był

zdezorientowany, należy potwierdzić przyjęcie

polecenia, oraz informować o przebiegu

operacji (np. jakiś wskaźnik lub najlepiej czas

do zakończenia)

Złote zasady projektowania interfejsu

użytkownika (3)



Zrozumiała terminologia komunikacji

nawet (zwłaszcza) w sytuacjach krytycznych

oprogramowanie powinno posługiwać się

terminologią zrozumiałą dla użytkownika



Eliminacja prostych błędów edycji

oprogramowanie

nie powinno dopuszczać do

wprowadzenia niepoprawnych danych

; jeżeli

użytkownik wprowadzi dane, które dopiero po

zweryfikowaniu można zakwalifikować jako

błędne, wówczas należy zasygnalizować rodzaj

błędu oraz umożliwić poprawienia

wprowadzonych wartości lub umożliwić

powrótu do wartości startowych (poprzednich)

Złote zasady projektowania interfejsu

użytkownika (4)



Odwoływanie poprzednio wykonanych

operacji

- możliwość cofnięcia ostatnio

wykonanej operacji lub cofnięcie się „dowolnie”

daleko (w granicach rozsądku)



Wrażenie kontroli nad systemem

- nikt nie

lubi, kiedy system sam zaczyna robić coś, czego

użytkownik nie zainicjował, lub kiedy akcja

systemu nie daje się przerwać; system nie

powinien inicjować długich akcji (np.

składowania) nie informując użytkownika co w

tej chwili robi oraz powinien możliwie szybko

reagować na sygnały przerwania akcji (Esc,

Ctrl+C, Break,...)

Złote zasady projektowania interfejsu

użytkownika (5)



Dostępność powiązanych informacji

- w

momencie wypełniania konkretnej informacji,

użytkownik powinien zawsze mieć możliwość

podejrzenia (lub wyboru z listy)



Nieobciążanie pamięci krótkotrwałej

użytkownika

- użytkownik może zapomnieć o

tym po co i z jakimi danymi uruchomił dialog;

system powinien w miarę możliwości

wyświetlać stale te informacje, które są

niezbędne do tego, aby użytkownik wiedział, co

aktualnie dzieje się, i w którym miejscu

interfejsu znajduje się.

Reguła Millera 7(±2)

Reguła Millera 7(±2) - reguła psychologiczna określająca

liczbę obiektów nad którymi człowiek może jednocześnie

pracować w sposób efektywny

Złote zasady projektowania interfejsu

użytkownika (6)



Grupowanie powiązanych operacji

-jeżeli zadanie nie da się zamknąć w

prostym dialogu lub oknie, wówczas trzeba

je rozbić na szereg powiązanych dialogów;

użytkownik powinien być prowadzony przez

ten szereg, z możliwością łatwego powrotu

do wcześniej wprowadzanych informacji



Ograniczenie powyższe można

przełamywać poprzez grupowanie

powiązanych ze sobą elementów w

wyraźnie wydzielone zespoły

Określenie fizycznej struktury systemu

Obejmuje:



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



podział systemu

na poszczególne aplikacje



fizyczne rozmieszczenie danych i

aplikacji

na stacjach roboczych i serwerach

Pomocne mogą być

diagramy



komponentów



wdrożenia

Optymalizacja (rozumiana jako

poprawa efektywności) może być

dokonana na poziomie:

•

projektu

•

implementacji

Kluczowe zagadnienia na etapie

projektowania



Zmiana algorytmu przetwarzania

- np. zmiana

algorytmu sortującego poprzez wprowadzenie

pośredniego pliku zawierającego tylko klucze i

wskaźniki do sortowanych obiektów może

przynieść

nawet 100-krotny zysk



Wykrycie potencjalnych “

wąskich gardeł

” w

przetwarzaniu i staranne ich zaprojektowanie;

stosuje się tutaj twierdzenie, że

20% kodu jest

wykonywane przez 80% czasu

; możliwe jest

również rozwiązanie polegające

na zleceniu

implementacji kluczowego

przetwarzania na

niższym poziomie

Kluczowe zagadnienia na etapie

projekowania:



Świadoma denormalizacja relacyjnej bazy

danych

- wprowadzenie nadmiarowości danych w

celu zwiększenia efektywności (np. łączenie

dwóch lub więcej tablic w jedną)



Stosowanie struktur pomocniczych

- indeksów,

tablic wskaźników, ...



Analiza mechanizmów buforowania danych

pamięci operacyjnej i ewentualna zmiana tego

mechanizmu (np. zmniejszenie liczby poziomów)

Poprawność projektu

Poprawność oznacza jedynie, że

opis

projektu jest zgodny z notacją

;

nie

gwarantuje

, że projekt jest zgodny

wymaganiami użytkownika

Poprawny projekt musi być:



kompletny



niesprzeczny



spójny



zgodny z przyjętą notacją

Poprawność projektu

Kompletność

zdefiniowane są wszystkie

klasy

, pola, metody oraz dane złożone i

elementarne, a także

opisany jest sposób

realizacji wszystkich wymagań funkcjonalnych

Spójność

- semantyczna zgodność informacji

zawartych na diagramach i w specyfikacji

Jakość modelu i projektu

Kryteria jakości:



spójność

- określa, na ile poszczególne elementy

składowe „

pasują” do siebie

; jeżeli

poszczególne składowe większych całości będą

ze sobą spójne to wtedy potencjalne zmiany

zamkną się w ramach ściśle określonych części

systemu



stopień powiązania składowych

- należy dążyć

do tego, aby stopień powiązania pomiędzy

składowymi był

minimalny

(można go mierzyć),

dotyczy:

•

przepływu komunikatów

•

dziedziczenia

•

związków klas

Jakość modelu i projektu



przejrzystość

(czytelność, łatwość zrozumienia):

•

odzwierciedlenie rzeczywistości

•

spójność oraz stopień powiązania składowych

•

zrozumiałe nazewnictwo

•

czytelna i pełna specyfikacja

•

odpowiednia złożoność składowych na danym

poziomie abstrakcji



Istotne jest

spełnienie kryteriów formalnych

jakości, które w dużym stopniu

rzutują na efektywną

jakość, chociaż w żadnym stopniu

jej nie gwarantują

Kluczowe czynniki sukcesu

projektowania



Wysoka

jakość modelu

projektowego



Dobra

znajomość środowiska

implementacji



Zachowanie przyjętych

standardów

(konsekwentne stosowanie notacji i

formularzy)



Sprawdzenie poprawności projektu

w ramach zespołu projektowego

Kluczowe czynniki sukcesu

projektowania



Optymalizacja projektu we

właściwym zakresie

(powinna być

ograniczona do istotnych,

krytycznych miejsc, gdzie

rzeczywiście jest potrzebna)



Poddanie projektu ocenie przez

niezależne ciało

oceniające jego

jakość pod względem formalnym i

merytorycznym

O czym był wykład ?



Anatomia projektu informatycznego



Uszczegółowienie modelu



Składowe systemów, które nie są związane

z dziedziną problemu



Interakcja z użytkownikiem



Optymalizacja projektu



Poprawność projektu



Jakość modelu i projektu



Kluczowe czynniki sukcesu projektowania

Literatura:

1. Z. Szyjewski, Metodyki

zarządzania projektami

informatycznymi

Wydawnictwo

Placet,

Wydawnictwo

Placet,

Warszawa 2004

2. Booch G., Raumbaugh J., Jacobson I.,

UML:

Przewodnik

użytkownika,

Przewodnik

użytkownika,

Wydawnictwa

Naukowo- Techniczne

Warszawa 2001

Document Outline