Metody analityczne projektowania systemów informatycznych umożliwiają

zdefiniowanie formalnego (abstrakcyjnego) modelu systemu przez jego rozbiór na
części składowe. Projektowany system jest rozpatrywany w trzech aspektach:
architektury[1] (oprogramowanie i sprzęt), dynamiki (zachowania) i struktur
logicznych (struktury danych i struktury funkcjonalnej), w których jest
dekomponowany na zasadzie poziomów abstrakcji Dijkstry. Zasada ta polega to na
podziale systemu na poziomy tworzące hierarchię. Każdy poziom w hierarchii
uwzględnia tylko istotne dla niego aspekty projektowanego systemu (Flasiński
1997).

Projektowanie systemu informatycznego polega głównie na kolejnym budowaniu

modeli systemu na różnych poziomach abstrakcji. Proces ten przebiega zgodnie ze
schematem przedstawionym na rys. 1. Najpierw tworzony jest mentalny model
ś

wiata rzeczywistego w umyśle projektanta, następnie wykonywany jest

sformalizowany model pojęciowy, który z kolei zamieniany jest na model logiczny
dostosowany do ograniczeń i możliwości środowiska implementacji.

[1]

Architektura systemu informatycznego również może być rozpatrywana w różnych kontekstach, dlatego w projektowaniu wyróżnia się architekturę

sprzętową, architekturę konceptualną (np. trójwarstwowa, czterowarstwowa w systemach typu klient/serwer) i architekturę logiczną (np. podział wszystkich
obiektów systemu na obiekty interfejsu, obiekty sterujące i obiekty aplikacji).

PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

(konspekt wykładu)

...
...

...

...

...

...

...

...

...

...
...

...

...

...

...

...

...

...

...
...

...

...

...

...

...

...

...

...
...

...

...

...

...

...

...

...

Mentalny

model świata

rzeczywistego

Sformalizowany

abstrakcyjny

model pojęciowy

Schemat

przechowywania

struktur danych

PROCES PROJEKTOWANIA SYSTEMU

Na podstawie (Subieta 1998)

Definiowanie wymaga

ń

Analiza

Proj. wła

ś

ciwe

Implementacja

Implementacja

Projektowanie

.......

.......

.......

FAZY REALIZACJI SYSTEMU INFORMATYCZNEGO.

MODELOWANIE POJĘCIOWE.

Modelowanie

pojęciowe

wymaga

przede

wszystkim

zidentyfikowania

i

zdefiniowania tego fragmentu świata rzeczywistego, dla którego buduje się model
(np. topografia terenu, kataster), a następnie zidentyfikowania i sklasyfikowania
obiektów wchodzących w jego skład, ustalenia ich cech oraz sformułowania ich
wzajemnych współzależności (Pachelski 1996).

Wybór obiektów i ich cech musi podlegać określonym zasadom modelowania.
Zasady te sprowadzają się przede wszystkim do idealizacji danego obiektu czy
zjawiska z określonego punktu widzenia, czyli – do odrzucenia cech z tego punktu
widzenia nieistotnych, a uwzględnienia cech, które uznamy za istotne
(Adamczewski 1998).

KONWENCJE NOTACYJNE.

Modelowanie pojęciowe jest wspomagane przez odpowiednie częściowo
lub całkowicie sformalizowane środki wzmacniające ludzką pamięć i
wyobraźnię. Środki te z reguły oparte są na graficznym przedstawieniu
obrazów mentalnych rzeczywistości opisywanej przez dane oraz na
przedstawianiu graficznym struktur danych, procesów i algorytmów
składających się na konstrukcję systemu (Subieta 1998).

Stosowanie formalnych lub pół-formalnych metod projektowania systemu
ma na celu m.in. umożliwienie interpretacji modelu z pomocą komputera i
w efekcie zautomatyzowanie generowania schematu bazy danych (z
poziomu narzędzi CASE – Computer Aided System Engineering).

KONWENCJE NOTACYJNE.

Ś

wiat rzeczywisty

Model

pojęciowy

Schemat

koncepcyjny

Formalizm

koncepcyjny

Język (i) schematów pojęciowych

Języki leksykalne

Notacje graficzne

Rozważany podzbiór
ś

wiata rzeczywistego

definiowany w

podstawą dla jednego lub więcej

umożliwia zapis formalny

formalnie reprezentowany przez

dostarcza pojęć do opisu

Proces modelowania pojęciowego wg CEN na podstawie (Pachelski 2000).

METODY I NOTACJE

Do najbardziej znanych metod strukturalnych należy metoda Encja-
Związek (w różnych odmianach: Chena, Yourdona, Oracle Case
Method).

Wśród znanych metod obiektowych wymienić można metodę Boocha
(Object Oriented Analysis & Design), Martina/Odella, Rumbaugha
(Object Modelling Technique), Coada/Yourdona (Object Oriented
Analysis), Shlaera-Mellora (Object Oriented System Analysis),
Jacobsona (Objectory), THE SELECT Perspective, UML (Unified
Modelling Language) oraz język Express.

METODY I NOTACJE

METODY I NOTACJE

DIAGRAM KLAS

DIAGRAM KLAS

ID[1] : SL_IDENTYFIKATOR
KAT_ZARZ[0..1] : SL_KAT_ZARZ_DR
KLASA_DR[1] : SL_KLASY_DR_TW
POLOZENIE[1] : SL_RODZ_POLOZ
NAWIERZCHNIA[1] : SL_RODZ_NAW
SZER_NAWIERZCHNI[1] : Double
SZER_KORONY_DR[0..1] : Double
SZER_PASA_DR[0..1] : Double
LICZBA_PASOW[1] : Integer
NAZWA_DR[0..1] : String
ULICA[1] : Boolean
ID_ULICY[0..1] : SL_IDENTYFIKATOR

«type»

TBDTopoGeom::Typ_SKJT_L

«type»

TBDTopoGeom::Typ_BazowyTBD_PODST

1

1

geometrycznie_reprezentowany_przez

1

1

geometrycznie_reprezentowany_przez

ID[1] : SL_IDENTYFIKATOR
KAT_ZARZ[0..1] : SL_KAT_ZARZ_DR
KLASA_DR[1] : SL_KLASY_DR_GR
POLOZENIE[1] : SL_RODZ_POLOZ
NAWIERZCHNIA[1] : SL_RODZ_NAW
SZER_KORONY_DR[0..1] : Double
NAZWA_DR[0..1] : String
ULICA[1] : Boolean
ID_ULICY[0..1] : SL_IDENTYFIKATOR

«type»

TBDTopoGeom::Typ_SKJG_L

ID[1] : SL_IDENTYFIKATOR
NUMER[1] : String
X_KAT_DOK_ATRYB[1] : Integer
X_AKTUALNOSC_ATRYB[1] : Date

«type»

TBDTopoNGeom::Typ_SZLAK_DROGOWY

interpolacja[1] : METODA_INTERPOLACJI
kierunek_styczny_na_poczatku[0..1] : KIERUNEK
kierunek_styczny_na_koncu[0..1] : KIERUNEK

«type»

Geometria::Krzywa

1

1..*

sklada_sie_z

ID[1] : SL_IDENTYFIKATOR
KLASA_CRP[1] : SL_KLASY_CRP
POLOZENIE[1] : SL_RODZ_POLOZ
NAZWA_CRP[0..1] : String
NAWIERZCHNIA[0..1] : SL_RODZ_NAW
SZEROKOSC[0..1] : Double
RUCH_ROWER[0..1] : SL_RUCH_ROWER
ID_ULICY[0..1] : SL_IDENTYFIKATOR

«type»

TBDTopoGeom::Typ_SKRP_L

1

1

geometrycznie_reprezentowany_przez

«type»

TBDTopoNGeom::Typ_ULICA

0..*

0..1

0..*

0..1

0..*

0..1

ID[1] : SL_IDENTYFIKATOR
RODZAJ_P_SZYN[1] : SL_RODZ_P_SZYN
RODZAJ_TRAKCJI[1] : SL_RODZ_TRAKCJI
LICZBA_TOROW[1] : Integer
RODZAJ_TOROW[1] : SL_RODZ_TOROW
POLOZENIE[1] : SL_RODZ_POLOZ

«type»

TBDTopoGeom::Typ_SKKL_L

1

1

geometrycznie_reprezentowany_przez

«type»

TBDTopoNGeom::Typ_LINIA_KOLEJOWA

1..*

1..*

sklada_sie_z

ID[1] : SL_IDENTYFIKATOR
RODZAJ[1] : SL_RODZ_PRZEPRAW
FUNKCJA_TRANS[0..1] : SL_FUN_TRANS

«type»

TBDTopoGeom::Typ_SKPP_L

1

1

geometrycznie_reprezentowany_przez

DIAGRAM KLAS

ID[1] : SL_IDENTYFIKATOR
ID_CIEKU[0..1] : SL_IDENTYFIKATOR
RODZAJ[1] : SL_RODZ_RZEK_K
STATUS_EKSPLOATACJI[0..1] : SL_ST_EK_CIEKOW
PRZEPLYW[0..1] : Double
SZEROKOSC[0..1] : Double
PRZEBIEG[1] : Integer
OKRESOWOSC[1] : Byte
POLOZENIE[1] : Byte

«type»

TBDTopoGeom::Typ_SWRK_L

«type»

Geometria::Krzywa

1

1

geometrycznie_reprezentowany_przez

ID[1] : SL_IDENTYFIKATOR
RODZAJ[1] : SL_RODZ_ROW_M
SZEROKOSC[0..1] : Double
OKRESOWOSC[1] : Byte
POLOZENIE[1] : Byte

«type»

TBDTopoGeom::Typ_SWML_L

«type»

TBDTopoGeom::Typ_BazowyTBD_PODST

ID[1] : SL_IDENTYFIKATOR
ID_HYDRO[0..1] : SL_IDENTYFIKATOR
NAZWA[0..1] : String
DLUGOSC[0..1] : Double
X_KAT_DOK_ATRYB[1] : SLX_KAT_DOKL
X_AKTUALNOSC_ATRYB[1] : Date

«type»

TBDTopoNGeom::Typ_CIEK

1

1

geometrycznie_reprezentowany_przez



0..1

1..*

sklada_sie_z

DIAGRAM KLAS

«type»

TBDTopoGeom::Typ_KUAA_A

«type»

TBDTopoGeom::Typ_BazowyTBD_PODST

«type»

Geometria::Powierzchnia

1

1

geometrycznie_reprezentowany_przez

{(SZEROKOSC >= 50m) AND (POWIERZCHNIA >= 5000m2)}

DIAGRAM KLAS

«type»

TBDTopoGeom::Typ_BazowyTBD_PODST

ID[1] : SL_IDENTYFIKATOR
FUNKCJA_OGOLNA[1] : SL_FUN_OG_BUD
FUNKCJA_SZCZEGOLOWA[1] : SL_FUN_SZ_BUD
KOD_KST[0..1] : String
NAZWA[0..1] : String
L_KONDYGNACJI[0..1] : Integer
WYSOKOSC_M[0..1] : Integer
NUMER[0..1] : String
ZABYTEK[0..1] : Integer
ID_ULICY[0..1] : SL_IDENTYFIKATOR
INFORM_DODATKOWA[0..1] : String

«type»

TBDTopoGeom::Typ_BBBD_A

«type»

TBDTopoNGeom::Typ_ULICA

0..*

0..1

ID[1] : SL_IDENTYFIKATOR
RODZAJ[1] : SL_RODZ_BUD_ZIEM
MATERIAL[0..1] : SL_MAT_BUD_ZIEM
SZER_KORONY[0..1] : Double
SZER_PODSTAWY[0..1] : Double
WYSOKOSC[0..1] : Double
ID_CIEKU[0..1] : SL_IDENTYFIKATOR
ID_ZBIORNIKA[0..1] : SL_IDENTYFIKATOR

«type»

TBDTopoGeom::Typ_BBZM_L

«type»

Geometria::Powierzchnia

«type»

Geometria::Krzywa

1

1

geometrycznie_reprezentowany_przez

1

1

geometrycznie_reprezentowany_przez

«type»

TBDTopoNGeom::Typ_CIEK

«type»

TBDTopoNGeom::Typ_ZBIORNIK_WODNY

0..*

0..1

0..*

0..1

ID[1] : SL_IDENTYFIKATOR
RODZAJ[1] : SL_RODZ_ZB_TECH
GR_SUBSTANCJA[0..1] : String
POJEMNOSC[0..1] : Integer
RODZAJ_KONSTRUKCJI[0..1] : String

«type»

TBDTopoGeom::Typ_BBZT_A

ID[1] : SL_IDENTYFIKATOR
RODZAJ[1] : SL_RODZ_BUD_MOST
KONSTRUKCJA[0..1] : SL_KON_BUD_MOST
LICZBA_POZIOMÓW[1] : Integer
MOBILNOSC_PRZESLA[1] : Integer
MATERIAL_KON_PODPOR[0..1] : SL_MAT_KON_BUD_MOST
MATERIAL_KON_POMOST[0..1] : SL_MAT_KON_BUD_MOST
NOSNOSC[0..1] : Double
WYSOKOSC[0..1] : Integer
SZEROKOSC[0..1] : Integer
DLUGOSC[0..1] : Integer
NAZWA[0..1] : String

«type»

TBDTopoGeom::Typ_BBMO_L

1

1

geometrycznie_reprezentowany_przez

ID[1] : SL_IDENTYFIKATOR
RODZAJ[1] : SL_RODZ_URZ_TRANSP
SZEROKOSC[0..1] : Integer
DLUGOSC[0..1] : Integer
INFORM_DODATKOWA[0..1] : String

«type»

TBDTopoGeom::Typ_BBTS_L

1

1

ID[1] : SL_IDENTYFIKATOR
RODZAJ[1] : SL_RODZ_BUD_TECH
PRZEZNACZENIE[0..1] : String
WYSOKOSC[0..1] : Integer
SZEROKOSC[0..1] : Integer
RODZAJ_KONSTRUKCJI[0..1] : String

«type»

TBDTopoGeom::Typ_BBWT_A

1

1

1

ID[1] : SL_IDENTYFIKATOR
RODZAJ[1] : SL_RODZ_BUD_HYD
W YS_KORONY_ZAPORY[0..1] : Double
POZIOM_WODY_MIN[0..1] : Double
POZIOM_WODY_MAX[0..1] : Double
LICZBA_KOMOR[0..1] : Integer
INFORM_DODATKOWA[0..1] : String

«type»

TBDTopoGeom::Typ_BBHY_L

1

1

geometrycznie_reprezentowany_przez

1

ID[1] : SL_IDENTYFIKATOR
RODZAJ[1] : SL_RODZ_UM_WOD
MATERIAL[0..1] : SL_MAT_UM_WOD
SZEROKOSC[0..1] : Double
WYSOKOSC[0..1] : Double

«type»

TBDTopoGeom::Typ_BBUW_L

1

1

geometrycznie_reprezentowany_przez

ID[1] : SL_IDENTYFIKATOR
RODZAJ[1] : SL_RODZ_UM_DR_KOL
MATERIAL[0..1] : SL_MAT_UM_DR_KOL

«type»

TBDTopoGeom::Typ_BBUD_L

1

1

geometrycznie_reprezentowany_przez

1

1

1

1

1

1

1

DIAGRAM KLAS

MOST_DROGOWY

Primary Key

ID_MOSTU_DROGOWEGO [PK1]

Non-Key Attributes

NAZWA
STATUS
NAZWA_DROGI
TYP_DROGI
KLASA_DROGI
NUMER_SZLAKU

TUNEL_DROGOWY

Primary Key

ID_TUNELU_DROGOWEGO [PK1]

Non-Key Attributes

NAZWA
NAZWA_DROGI
TYP_DROGI
KLASA_DROGI
NUMER_SZLAKU

MOST_RUCHU_PIESZEGO

Primary Key

ID_MOSTU_PIESZEGO [PK1]

Non-Key Attributes

NAZWA
NAZWA_TRAKTU_PIESZEGO

DROGA

Primary Key

ID_drogi [PK1]

Non-Key Attributes

NAZWA_DROGI
TYP_DROGI
KLASA_DROGI
NUMER_SZLAKU

LINIA

Primary Key

ID_LINII [PK1]

Non-Key Attributes

WEZEL_POCZATKOWY
WEZEL_KONCOWY
POLIGON_LEWY
POLIGON_PRAWY

TRAKT_PIESZY

Non-Key Attributes

ID_TRAKTU_PIESZEGO
NAZWA

WEZEL

Primary Key

ID_WEZLA [PK1]

PUNKT

Primary Key

ID_PUNKTU [PK1]

jeden i tylko jeden

Sposób oznaczania krotno

ś

ci zwi

ą

zków

jeden lub wiele

zero lub jeden

zero lub wi

ę

cej

DIAGRAM KLAS

DIAGRAM AKTYWNOŚCI

Znajd

ź

budynki

w zadanej strefie

Pobierz kategori

ę

budynków

Zaznacz budynki

na mapie

Generowanie bufora

Pobierz nazw

ę

rzeki

Pobierz

odległo

ść

Wyszukaj rzek

ę

Generuj raport

[nie ma budynków]

[budynki znalezione]

Przebieg analizy:
„Wyszukiwanie budynków
w zadanej strefie od wybranej rzeki”.

DIAGRAM
PRZYPADKÓW
UŻYCIA

Operator SZBDT

Wykonanie wydruku

Wykonanie wydruku

Autoryzacja dost

ę

pu do SZBDT

Wizualizacja danych

Utworzenie legendy

Okre

ś

lenie opisu pozaramkowego

«zawiera»

«zawiera»

«zawiera»

«zawiera»

DIAGRAM
PRZYPADKÓW
UŻYCIA

8. Przypadek użycia: Wykonanie wydruku

Warunki początkowe:

Określony przez Klienta TBD zakres i typ wydruku.

Aktorzy:

·

Operator SZBDT (Użytkownik Zwykły, Użytkownik Uprzywilejowany lub

Administrator SZBDT)

Scenariusz:

·

Autoryzacja dostępu do SZBDT.

·

Wizualizacja danych TBD.

·

Określenie opisu pozaramkowego (opcjonalnie).

·

Utworzenie legendy dla wybranej treści wydruku (opcjonalnie).

·

Wydruk przygotowanej kompozycji.

Wyniki:

Wydruk wybranej kompozycji danych.

Uwagi:

Wizualizacja danych do wydruku może być wykonana z wykorzystaniem kompozycji
graficznej w standardzie TBD (wydruk w standardzie MTP10BDT) lub z
wykorzystaniem dowolnej innej kompozycji danych (wydruki niestandardowe).