ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

notował R. Sobolewski

Celem analizy i projektowania jest stworzenie systemu informatycznego - informatyzacja.

Etapy powstawania systemu:

1. analiza

2. projektowanie

3. programowanie

4. testowanie

5. wdrażanie

6. konserwacja, pielęgnacja (maintenance)

Sposoby tworzenia systemu:

1. bottom-up (wstępujący, od szczegółu do ogółu)

2. top-down (zstępujący, od ogółu do szczegółu)

3. od środka

Literatura:

Współczesna analiza strukturalna E. Yourdon

UML w kropelce

UML przewodnik użytkownika

Wzorce projektowe w VB (design patterns)

Wzorce projektowe

Wzorce projektowe dla Javy i C++

Programowanie obiektowe w VB.NET dla każdego

Inżynieria oprogramowania pod red. Górskiego

Narzędzie projektowania:

UML - Unified Modeling Language

Architektura wielowarstowa systemu informatycznego (n-tier architecture)

Architektura trójwarstwowa - MCV-architecture - Model Controler View

M dane systemu, baza danych

C logika businesowa

V interfejs użytkownika

Analiza systemowa - model systemu można ująć w różnych aspektach E. Yourdon (Y)

Model jest abstrakcją systemu

Robinson & Robinson (RR) aspekty systemu (view points)

1. aspekt fizyczny istniejącego systemu (RR)

model fizyczny istniejącego systemu (Y)

2. aspekt istotny systemu (RR) - pokazuje wymagania systemu, abstrakcja od implementacji

model wymagań istotnych (Y)

3. aspekt danych (RR)

model danych (Y)

4. aspekt fizyczny nowego systemu (RR)

model fizyczny nowego systemu

Yourdon:

1. model podstawowy systemu

2. model środowiskowy

3. model implementacyjny użytkownika

Robinson&Robinson:

1. modele

2. aspekty

3. rzuty systemu

4. perspektywy (view)

Narzędzia modelowania (graficzne, opisowe, funkcjonalne):

1. diagramy przepływu danych (DFD - Data Flow Diagrams)

2. słowniki danych (modele danych), (DD - Data Dictionary)

3. specyfikacje procesów (PS - Process Specifications)

4. diagramy związków encji (ERD - Entity Relationships Diagrams)

5. diagramy sieci przejść (STD - State Trasition Diagrams)

6. uzupełniające

DIAGRAMY PRZEPŁYWU DANYCH (DFD)

Synonimy:

1. diagram bąbli

2. model procesów

3. model przepływu pracy

4. model funkcji

5. obraz / opis działania systemu

Elementy podstawowe schematu:

1. proces

2. przepływ

3. magazyn

4. terminator

/rysunek/

Pakiet - jednostka informacji przepływająca w diagramie

Proces jest nazywany pojedynczym słowem, frazą lub prostym zdaniem

Przepływ - reprezentuje dane w ruchu - nazwa reprezentuje znaczenie przenoszonego pakietu (są różne typy pakietów)

Magazyn - dane w spoczynku

/rysunek/

przepływ jednokierunkowy

przepływ dwukierunkowy - dialog - zapytanie i odpowiedź

przepływy mogą się rozchodzić i schodzić

1. kopie

2. rozdzielenie złożonego pakietu na elementy

/rysunek/

Specyfikacje opisują procesy.

Magazynem może być plik, baza danych.

2 powody stosowania magazynów:

• element systemu

• część implementacji systemu

magazyn implementacyjny systemu

/rysunek/

przepływy do magazynu - zapis pakietu, aktualizacja, usuwanie

terminatory są poza systemem (osoba, jednostka, inny system informatyczny)

zewnętrzne przepływy - to interfejsy systemu

terminator znajduje się poza dziedziną zmian - w otoczeniu systemu, żaden istniejący związek pomiędzy terminatorami nie jest pokazany na DFD - jeżeli jest, to wchodzi w skład systemu jako proces

Diagramy przepływu danych

1. Znaczące nazwy dla procesów, przepływów, magazynów i terminatorów

rola przepływu

nazwa procesu - czasowniki i dopełnienia, konkretność

2. Procesy powinny być jednolicie numerowane (oprócz nazw)

/rysunek/

diagram - sieć komunikujących się asynchronicznych procesów, służy do porawnego modelowania funkcji i interakcji, nie pokazuje sekwencji, kolejności, powinien zawierać maź. 6 procesów, magazynów, przepływów, terminatorów

diagram kontekstowy

/rysunek/

DFD stanowią hierarchiczną strukturę diagramu

1. Poziom kontekstowy

2. Poziom 0

3. Poziom 1

/rysunki/

zrównoważone diagramy przepływu danych

opis pojedynczego procesu - specyfikacja procesu

magazyn dzielony, inaczej magazyn lokalny

/rysunek/

rozszerzenia DFD dla czasu rzeczywistego (real-time systems)

/rysunek/

sygnały i przerwania - procesy sterowania

SŁOWNIKI DANYCH (DATA DICTIONARY)

struktura informacji, opis

/rysunek/

Słownik danych definiuje elementy danych w sposób:

1. Opis znaczenia (semantyki) przepływów i magazynów (aby było zrozumiałe dla użytkownika)

2. Opis budowy złożonych pakietów danych, przepływów (syntaktyka)

3. Budowa pakietów danych w magazynach (pragmatyka)

4. Określenie właściwych wartości i jednostek elementarnych procji informacji dla przepływów i magazynów

5. Opis szczegółów związków między magazynami (pokazanych na diagramie związków encji) - uściślić formę prezentacji informacji

Syntaktyczna notacja słownika danych:

= składa się z

+ oraz, i

coś = to + tamto

() opcjonalne wystąpienie (może być, ale nie musi)

[] alternatywa i jej możliwości

|

x = [a | b | c]

* ... * komentarz definicji

element = * komentarz *

{} iteracja, powtarzanie, krotność

Y = {a} albo puste, albo 1 a albo więcej a

0 lub większa liczba wystąpień

@ identyfikator, pole klucza dla magazynu

pełne_nazwisko = tytuł + imię + (drugie imię) + nazwisko

tytuł = [Pan | Pani | Panna | Dr | Prof. | ]

imię = {dozwolony_znak}

dozwolony_znak = {A - Z | a - z | 0 - 9 | ` | - | ]

Definicja musi zawierać:

1. Znaczenie elementu danych w kontekście aplikacji użytkownika

* ... *

2. Budowa elementu danych, gdy ma jakąś strukturę

3. Wartości, jakie może przybierać, przyjmować element i jednostki miary

waga = *waga pacjenta w chwili przyjęcia do szpitala*

*jednostki: kilogramy; zakres: 1 - 200*

terminy samodefiniujące (definiuje je sam napis)

adres_klienta = (adres_dostawy) + (adres_płatnika)

Ad. iteracji:

a = 1 {b} 1 lub więcej b

a = {b} 10 0 - 10 b

a = 3 {b} 7 3 - 7 b

Synonimy:

klient

zamawiający = *synonim klienta*

należy unikać synonimów!!!

implementacja słownika danych - średnie i duże systemy danych zawierają po kilka tysięcy pozycji (Excel, Acces)

SPECYFIKACJE PROCESÓW (PROCESS SPECIFICATIONS)

/rysunek/

definicja, co należy zrobić w celu przekształcenia we na wy, szczegółowy opis działania

typy narzędzi:

tablice decyzyjne

warunki początkowe i końcowe

diagramy przepływu

język strukturalny, naturalny

unika się opisowego języka naturalnego

nie można posługiwać się zbyt ścisłymi określeniami

Środki, narzędzia:

1. strukturalny język naturalny

1. używa się prostych struktur języka programowania

REPEAT IF WHILE SELECT CASES

... THEN ... CASE

UNTIL ELSE WEND END SELECT

END IF

graficznie:

/rysunek/

2. zestaw czasowników opisujących działania dotyczące systemu

40 - 50 czasowników, np. weź, umieść, znajdź, dodaj, usuń, sprawdź, sortuj, ...

3. proste instrukcje przypisania

c = a + b

2. Warunki początkowe i końcowe

proces jest funkcją

1. użytkownik może mieć tendencję do opisu jednostronnego

2. danie szansy programiście na rozważenie kilku algorytmów

3. tablice decyzyjne

Reguły

			1	2	3	4	5	6	7	8
Zmienne,	wiek	> 21 lat	T	T	T	T	N	N	N	N
Warunki,	płeć		M	M	K	K	M	M	K	K
Wejścia	waga	>150 kg	T	N	T	N	T	N	T	N
		lek_1	X					X		X
akcje	--	lek_2		X				X
		lek_3			X				X
		bez				X				X

X - zastosuj

Specyfikacje procesów:

przepływ - definicja działania procesów - przepływ - proces

DFD - przepływy, dynamika, asynchroniczność, nie mówimy o czasowej relacji, związanie danymi - pełna asynchroniczność między procesami

4. Grafy i wykresy

/rysunek/

5. Język opisowy - użycie języka naturalnego do określenia specyfikacji

Wady:

• brak ograniczeń na słownik - niejednoznaczność

• niejasne specyfikowanie alternatywnych akcji

• trudne definiowanie cykli, pętli

• struktury blokowe wyraża się, np. wcięciami

6. Diagramy przepływu sterowania

/rysunek/

wnętrze procesu - jak to funkcjonuje, jest zależność czasowa (gdy nic nie mówi o relacjach w czasie pomiędzy procesami - asynchroniczność)

7. Diagramy Nassi - Schneidermanna

są lepiej zorganizowane, ale duże ilości grafiki

PRZETWARZANIE INSTRUKCJI
	PĘTLA
	T	N

8. inne

Pisanie specyfikacji - poprawianie DFD i słownika

DIAGRAMY ZWIĄZKÓW ENCJI (ENTITY RELATIONSHIP DIAGRAM)

Model funkcji (DFD)

Model danych (ERD) - diagramy związków encji

Model czasowy (STD) - diagramy sterowania

entity - jednostka, byt, istnienie, rzecz, przedmiot

diagram związków - diagram relacji między typami obiektów

ERD - model sieciowy opisujący na wysokim poziomie układ danych w systemie (dane, powiązania, właściciel, dostęp)

DA - grupa administracji danymi - f. informacyjne

DBA - grupa administratorów baz danych - f. techniczne

/rysunek/

Składniki ERD:

1. Typy (obiektów); klasa - wzorzec dla obiektów

2. Związki (nazwanie relacji)

3. Wskaźniki asocjowanych typów (obiektów); typy dołączone

ZAMÓWIENIE (dołączenie)

typ pochodny, dopełniający informacje o tej relacji

4. Wskaźniki nadtypów, podtypów

/rysunek/

Typ:

1. egzemplarze - każdy obiekt musi być indywidualizowany

2. typ odgrywa rolę w systemie

3. każdy typ jest opisany 1 lub kilkoma elementami danych (atrybuty, własności, cechy)

zbiór powiązań między obiektami

/rysunek/

zbiór egzemplarzy

.egz1: klient1 kupuje towar_1

.egz2: klient2 kupuje towar_2 i towar_3

.egz3: klient3 kupuje towar_4

.egz4: klient4 nie kupuje towaru

.egz5: klient5 i klient6 kupuje towar_8

.egz6: klient7 i klient8 kupuje towar_5 i towar_7 i towar_12

miedzy dwoma typami może wystąpić więcej niż jeden związek:

/rysunek/

związek dotyczy dwóch typów i nie jest ukierunkowany

różne perspektywy widzenia związku, zbiór perspektyw opisuje związek

alternatywna notacja dla związków

/rysunek/

Ad. 3 Wskaźniki asocjowanych typów obiektów

/rysunek/

Ad. 4 Część wspólna w nadtypie

Jak wykrywać obiekty i związki w fazie analizy?

1. Analityk zna wymagania użytkownika - wywiady z użytkownikami - konsultacje

2. Wiadomości własne analityka

3. Inne techniki zbierania informacji

Uwagi dodatkowe o ERD

Po utworzeniu ERD przypisujemy typom elementy danych - budujemy strukturę rekordu, przypisujemy typom atrybuty

1. wspomagamy się słownikiem danych (DD) lub

2. wykorzystujemy informacje z firmy - wywiad i budujemy DD lub

3. użycie struktur z istniejących systemów informatycznych

4 powody tworzenia nowych typów danych:

1. Utworzenie podtypu - różne cechy

2. Utworzenie nadtypu - podobne cechy

3. Utworzenie typu asocjowanego, relacyjnego - nowy typ

4. Typ zanurzony (pracownik i dziecko)

Powody likwidacji zbędnych typów /związków/ powstałych w 1-szej fazie tworzenia ERD

1. Typy obiektów składające się tylko z identyfikatora

2. Typ obiektu mający jeden egzemplarz (stała systemu)

3. Zawieszone asocjowane typy obiektów

4. Związki wyprowadzalne

Ad. 1 /rysunek/

Ad. 2 /rysunek/

Ad. 3 /rysunek/

Ad. 4 /rysunek/

Słownik danych

W zasadzie obiekty na ERD odpowiadają magazynom na DFD.

KLIENT = {KLIENT}

KLIENT = @nazwisko + adres + nr_tel

typ obiektu z ERD, egzemplarz magazynu KLIENCI

definicje wszystkich związków pokazanych na ERD

odnawia -

opis znaczenia związku w aplikacji, łączone obiekty

jest dzieckiem = *związek dotyczy spraw socjalnych pracownika*

*związek łączy PRACOWNIKA i DZIECKO*

DFD - funkcje

ERD - dane, diagramy relacji między obiektami w systemie

DIAGRAMY SIECI PRZEJŚĆ (STATE TRANSITION DIAGRAMS - STD)

DFD DD ERD PS STD

| | | |

funkcje dane defin. zachowanie systemu w czasie

(flows) syst. algoryt-

asynchr. mów w

proces.

Sterowanie procesami - w systemach szybkiego zbierania informacji istotna jest sekwencja działań w systemie - STD

małe, specyficzne systemy systemy czasu rzeczywistego

SYSTEM BANKOMATU SYSTEM = maszyna stanowa, program

/rysunek/

Sub Automat

Dim Stan as Integer

Stan = 0

While...

Select Case Stan

Case 1

If... Then... Else

Case 2

...

End Select

Wend

End Sub

/warunek/

/akcja/

/nowy stan/

STAN - w jakim punkcie jest program i co może zrobić

stan początkowy jest jeden

stanów końcowych może być więcej

proces sterujący - może być najwyżej jeden, są one binarne, włączają lub wyłączają coś

STD specyfikuje wnętrze procesu sterującego, jest specyfikacją procesu (PS) dla procesu sterującego

/rysunek/

1. Narzędzia analizy

2. Modele

1. analiza klasyczna - proces modelowania DFD

/rysunek/

2. analiza strukturalna

/rysunek/

UML - współczesne narzędzie do tworzenia projektów

Nowy Model Logiczny - NML

3. Model podstawowy

1. model środowiskowy

2. model zachowania - właściwa analiza

4. Model środowiskowy

1. określenie celu

2. diagram kontekstowy

3. lista zdarzeń

Ad. a) Krótki, zwięzły opis tekstowy systemu, który ma powstać (1 strona), jest rozmyślnie niejasny (brak konkretnych informacji), podsumowanie wymiernych korzyści nowego systemu

Ad. b) Diagram kontekstowy

/rysunek/

1. osoby (organizacje, systemy)

2. dane z zewnątrz

3. dane wyprodukowane przez system

4. magazyny danych tworzone i użytkowane

5. granice między systemem a otoczeniem

Ad. c) Spis bodźców występujących w świecie zewnętrznym (w otoczeniu), na które system musi odpowiadać:

1. klient składa zamówienie (P)

2. klient anuluje zamówienie (P)

3. kierownictwo potrzebuje raportu sprzedaży (T)

4. zamówienie na dodruk książek przychodzi do magazynu (S)

podział zdarzeń:

P - sterowane przepływem

T - temporalne, generowane regularnie wewnątrz systemu, cyklicznie

S - zdarzenia sterujące - zdarzenia asynchroniczne, nie zachodzą regularnie, sygnał od innego procesu sterującego

dodatkowe składowe:

4. wstępny słownik danych

5. model związków encji dla magazynów zewnętrznych

model zachowania

UML - UNIFIED MODELING LANGUAGE

język projektowy do modelowania, tworzony w latach 1994 - 99

Object Management Group (www.omg.org)

grupa reprezentowała podejście obiektowe, system = zestaw klas

od 1994 r.

konferencja OOPSLA Portland

twórcy - Tres Amigos:

Grady Boock

Jim Rumbaugh

Ivar Jacobson

później dołączył Odell

w 1997 r. - ujednolicenie UML ver 1.0 Rational Software

UML jest językiem modelowania, a nie metodą projektowania

diagramy i inne techniki służą do analizy

UML jest narzędziem służącym do projektowania

metody projektowania są różne

proces projektowania jest sposobem budowania projektu

efektem jest model wyrażony w języku UML

technika projektowania - RUP - Rational Unified Process

Notacje i metamodele

metamodel - w sposób sformalizowany mówi, jak używać technik UML, zestaw definicji formalnych dla UML, jest wyrażany w jego notacji

narzędzie - diagramy klas (notacja) - sposób opisu formalnego

notacja UML - zawiera elementy graficzne, które widać w modelach oraz syntaktykę języka modelowania

Zestaw metod graficznych wyrażania modeli:

1. Przypadki użycia systemu (USE CASE)

2. Diagramy klas

3. Pakiety

4. Diagramy stanów

5. Diagramy czynności

6. Diagramy fizyczne

Rozwinięcie UML - wzorce projektowe (design patterns) w UML

Gang Of Four - GoF

www.hillside.net/patterns

MCV (architektura trójwarstwowa) jest rodzajem wzorca

PODSTAWOWE POJĘCIA PROGRAMOWANIA OBIEKTOWEGO

1. Pojęcie klasy

zestaw właściwości i zestaw metod (def. zmiennych i def. funkcji i procedur)

2. Paradygmaty programowania obiektowego

1. hermetyzacja

2. dziedziczenie

3. polimorfizm

Ad. a) Ukrywanie struktury stanu obiektu przed bezpośrednim dostępem przez użytkownika obiektu (zmienne wewnętrzne charakteryzują ten obiekt). Z punktu widzenia użytkownika obiekt powinien być widziany tylko przez jego interfejsy, czyli przez publiczne metody

funkcja = komunikat (jak w SMALL TALK)

zobowiązanie klasy - co ona robi dla użytkownika, pozwala jednolicie traktować obiekty różnych klas, pośrednio wiąże się z polimorfizmem

AD b) Klasa dziedziczy:

class PIES: TOWAR, ŻYWNOŚĆ, PRZYJACIEL, GATUNEK

dziedziczenie wielobazowe (wielokrotne) w C++

dziedziczenie jednobazowe

interfejs w Javie - specjalny typ klasy

w C++ klasa abstrakcyjna, kontraktowa - nie ma właściwości, zadeklarowane, ale nie zdefiniowane metody

Ad. c) Polimorfizm - w klasie podrzędnej funkcje

implements

przeciążenie funkcji - różne typy parametrów

4. kompozycja klasy

5. interfejs

Klasy Komponenty

poziom źródłowy poziom elementów

tworzenie systemu wykonywalnych

(gotowe podprogramy lub programy .dll, .exe)

CORBA

DCOM

są to 2 światowe normy budowy komponentów tak, aby mogły się komunikować

soap - interfejs XML, rodzaj protokołu

DIAGRAMY PRZYPADKÓW UŻYCIA SYSTEMU

przypadki użycia systemu - USE CASE

na początku w UML tego nie było

Tres Amigos - Ivar Jacobson (Ericsson)

Diagram kontekstowy

/rysunek/

oczekiwania, granice systemu

USE CASE - tworzenie

scenariusze interakcji

System - Użytkownik

Scenariusz - ciąg ponumerowanych kroków opisujących interakcje miedzy użytkownikiem a systemem.

Zestaw scenariuszy powiązanych ze sobą wspólnym celem użytkownika to przypadek użycia systemu.

Zazwyczaj mamy 1 główny scenariusz i scenariusze alternatywne

zapis scenariusza - jest to ciąg ponumerowanych kroków

diagram przypadków użycia (powinien być wspomożony scenariuszami)

DPU dla systemu maklerskiego

/rysunek/

aktor (rola) - jest to funkcja, jaką użytkownik pełni w stosunku do systemu, nie muszą być ludźmi, aktorzy wykonują P. U., są przydatni, gdy trzeba wykryć przypadki użycia systemu

relacje dodatkowe:

• zawieranie

• uogólnienie

• rozszerzenie

/rysunek/

Businessowe i systemowe przypadki użycia systemu

systemowy p. u. - interakcja aktora z oprogramowaniem

businessowy p. u. - jak przedsiębiorstwo reaguje na klienta lub zdarzenie

Przypadek użycia systemu jest to podstawowe narzędzie w uchwyceniu wymagań oraz w zarządzaniu i planowaniu iteracyjnym projektu tworzenia oprogramowania

Rodzaj diagramu UML

diagramy klas (analogia do ERD)

istnieją 3 perspektywy oglądu systemu, spojrzenia na system / podsystem

czynnik Ψ (PSI)

1) perspektywa pojęciowa ANALIZA

2) perspektywa specyfikacyjna PROJEKT

3) perspektywa implementacyjna OPROGRAMOWANIE

/rysunek/

interpretowanie asocjacji - związki pojęciowe między klasami, każda asocjacja ma 2 punkty końcowe, asocjacje reprezentują zobowiązania klas (w specyfikacji)

Zapis klas

Zapis atrybutów i operacji w klasie

KLASA X

atrybuty

operacje

atrybut: cena

specyfikator_dostępu nazwa: typ = wartość domyślna

+ publiczny dostęp (public)

# chroniony dostęp (protected)

• prywatny dostep (private)

• cena: waluta = 0

operacje są to procesy, akcje, które klas może wykonać

getCena, putCena - nie wymieniamy tego, bo to jest oczywiste

specyfikator dostępu nazwa (lista atrybutów): wyrażenie_typu_wyniku (+ - #)

sposób_przekazywania nazwa: typ

in out inout

byVal byRef

+ saldoZDnia (data: Data): Waluta

Diagram obiektów jest obrazem obiektów w danej chwili (diagram instancji)

/rysunek/

Klasyfikacja wielokrotna i dynamiczna

/rysunek/

dopuszczalne kombinacje:

(K, Pa, Pi) (M, F) (K, L, Ch)

niedopuszczalne kombinacje:

(P, L) (M, L, Pi)

/rysunek/

Agregacja i zawieranie

Agregacja a asocjacja

/rysunek/

Diagramy interakcji

/rysunek/

2 typy:

1. diagramy sekwencji

2. diagramy współdziałania (współpracy)

Są to modele opisujące, jak współpracują ze sobą grupy obiektów. Dotyczą jednego przypadku użycia.

1)/rysunek/

2)/rysunek/

Technika modelowania wg kart CRC - Class Responsibility Colaboration

nie jest to narzędzie UML

służy do określania klas systemu wg ich wzajemnych oddziaływań (burza mózgów)

stworzone przez twórców SMALL TALK'a

karty katalogowe

/rysunek/

interfejs CRC - zachowanie zewnętrzne

diagramy stanów - gdy mamy kilka przypadków uzycia systemu

diagramy czynności - współpraca funkcjonalna kilku klas

diagramy stanów - opisują działanie wewnętrzne klasy, opisują stany, zachowania obiektu, stany wewnętrzne i ich zmiany pod wpływem zdarzeń

/rysunek/

Diagramy czynności

modelowanie przepływu zadań work flow

opis procesów z dużą liczbą równoległych czynności

diagram stanów

stany = stany czynności

podobne do schematów blokowych z programowania

czasowe współdziałanie klas

algorytmiczny opis działania

/rysunek/

tory (swimlane)

Pakiety i współdziałanie

Problem: Jak rozbić duży system na mniejsze podsystemy, części składowe (problemy zrozumienia systemu i modyfikacji).

Pakiet - zgrupowanie klas w jednostki wyższego poziomu

/rysunek/

Pojęcie pakietu - nie tylko klasy, inne elementy modelu też można grupować

Bez zastosowania w grupowaniu heurystyki - byłoby ono arbitralne.

Zależność - sposób grupowania i związki między pakietami

/rysunek/

jedna klasa komunikuje się z drugą

jedna klasa zawiera drugą

jedna klasa wymienia drugą jako parametr opracyjny

zmiana interfejsu klasy

/rysunek/

Relacja ZALEŻNOŚĆ nie jest przechodnia!

Klasy w ramach pakietu mogą być publiczne, prywatne i chronione.

Ograniczenie interfejsu pakietu do niewielkiego podzbioru klas publicznych.

Klasy prywatne i publiczne do reprezentacji - klasy interfejsowe, fasady.

Fasada - klasa reprezentująca grupę klas na zewnątrz.

Diagramy pakietów są istotnym narzędziem do zarządzania ogólną architekturą systemu.

/rysunek/

Współdziałanie pakietów

Diagramy interakcji

Diagramy fizyczne

Diagramy komponentów Diagramy wdrożenia

(pokazuje różne składowe systemu (pokazuje fizyczne powiązania

i ich powiązania między składowymi w systemie)

węzeł - rodzaj jednostki obliczeniowej

(element sprzętowy)

komponent - fabryka obiektów

1 fizyczny moduł kodu systemu

COM - Component Object Module

/rysunek/

Diagram wdrożenia

(z diagramem komponentu na jednym rysunku)

/rysunek/

Symbole, ikony serwera, komputera, baz danych

ikona - stereotyp

Diagramy fizyczne - informacja fizyczna jest różna od logicznej.

6

---