Modelowanie

z wykorzystaniem UML

Plan dnia

A1. Wprowadzenie do UML

A2. Modelowanie struktury statycznej

A3. Implementacja w Rational Rose

B1. Modelowanie zachowań i podziału

B2. Zaawansowane elementy UML

B3. Implementacja w Rational Rose

Wprowadzenie do UML

Obiektowe spojrzenie na świat

czyli o modelowaniu, obiektach i języku

Czym jest model?

Świat

rzeczywisty

Świat

rzeczywisty

System

komputero

System

komputero

Model to „

układ (...) możliwie mało

skomplikowany, działający analogicznie
do oryginału

” -

Słownik Języka Polskiego,

PWN 1998

Model

Analiza i modelowanie

systemów

Analiza i modelowanie

systemów

Elementy świata i modelu

– użytkownicy, systemy zewnętrzne;
– dane, ich struktura, sposób przetwarzania, zależności

statyczne i dynamiczne;

– procesy, ich struktura i rozmieszczenie;
– ....

Metodyka modelowania

jest opisem

czynności, sposobu i kolejności

ich

realizacji; czynności te mają prowadzić ku

MODELOWI

zapewniając jednocześnie metody utrzymania wysokiej
jakości (

spełnienia wymagań użytkownika

)

Istota modelowania

Czym jest analiza?

„analiza to

studium problemu

przed podjęciem działania”

Tom DeMarco, 1978

Sposoby zarządzania złożonością:

– abstrakcja:

omijanie rzeczy nieistotnych

– hermetyzacja:

ukrywanie rzeczy złożonych

– dziedziczenie:

uogólnianie wspólnych cech

– kojarzenie:

porównywanie analogii

– komunikacja:

jak porozumiewają się elementy modelu

– skalowanie:

dopasowanie optyki do rozmiaru problemu

– klasyfikacja:

grupowanie zachowań elementów modelu.

Cele modelowania

divide et impera

, czyli

dekompozycja

łatwiejsze

wyobrażenie systemu

specyfikacja

struktury i zachowania

dokumentacja decyzji

podjętych w

trakcie realizacji

Cztery zasady modelowania

wybrany model

determinuje

rozwiązanie

modelować można na

różnych

poziomach szczegółowości

najlepsze modele

odpowiadają

rzeczywistości

żaden model

nie jest wystarczający

W świecie obiektowym

Elementy świata

– świat składa się z

obiektów

– procesy i dane są

zintegrowane

Komunikacja między nimi

– obiekty komunikują się za pomocą

przekazywania zdarzeń

Ten model jest łatwy do zrozumienia!

Klasy i obiekty

Cel:

reprezentacja za pomocą pewnego

elementu

świata
zmiana cyklu rozwoju na bardziej elastyczny
dostosowanie metod analizy do języków OOP

Obiekt:

reprezentacja

konkretnego elementu

świata,

posiadająca pewne

cechy

i oferująca pewne

usługi

Klasa:

zbiór

obiektów podobnych lub o wspólnych

cechach

Czym jest UML?

UML jest językiem

wizualizacji,

specyfikacji, konstrukcji i
dokumentacji

artefaktów

związanych z tworzeniem
oprogramowania

UML oznacza

Zunifikowany Język

Modelowania

(Unified Modelling

Language)

UML abstrahuje od

obiektu

modelowania

metodologii

modelowania

Model UML jest wypadkową wielu

widoków

różnych aspektów

systemu.

Unifikować, czyli łączyć

UML łączy najlepsze cechy:

– modelowania

danych (EER)

czyli - jak przedstawić informację?

– modelowania

czynności (DFD)

czyli - co się dzieje w systemie?

– modelowania

obiektowego (OOA)

czyli - jak zrozumiale przedstawiać świat?

– zarządzania złożonością (komponenty)

czyli - divide et impera!

UML w skrócie

• 9 typów diagramów - perspektyw

– modelowanie wymagań
– modelowanie struktury statycznej koncepcji
– modelowanie zależności dynamicznych i

zachowań

– modelowanie struktury fizycznej

• mechanizm rozszerzeń

– stereotypy (ang. stereotypes)
– metki (ang. tags)
– ograniczenia (ang. constraints)

UML: typy diagramów

– przypadków użycia

(use-case diagram)

– klas i obiektów

(class diagram)

– stanu obiektów

(statechart diagram)

– współpracy

(collaboration diagram)

– sekwencji

(sequence diagram)

– czynności

(activity diagram)

– komponentów

(component diagram)

– rozmieszczenia

(deployment diagram)

Historia UML

Dawno temu...

– różnorodne, niespójne metodyki obiektowe

(OMT, OOSE, Fusion, OOA/OOD)

Początki UML i

Trzej Amigos

– 1994 - prace nad Metodą Zunifikowaną
– 1995 - wersja 0.9 UML

J. Rumbaugh

G. Booch

I. Jacobson

Historia UML (cd.)

Rozwój UML

– I.1997 - wersja 1.0 UML
– XI.1997 - standaryzacja przez OMG

Obecnie

– wersja 1.4 UML
– prace nad 2.0 UML

http://www.omg.org/uml/

http://www.rational.com/u

ml/

Wsparcie ze strony

przemysłu SW

Wsparcie ze strony

przemysłu SW

UML Partners Consortium

udział największych firm
produkujących oprogramowanie:

– DEC, HP, Microsoft, IBM, Oracle, Texas

Instruments

oraz producenci CASE

– Rational Software

Cykl tworzenia

oprogramowania

Cykl tworzenia

oprogramowania

UML jest

niezależny od procesu

ale twórcy sugerują proces;

– ukierunkowany na

przypadki użycia

zorientowany na

architekturę

– iteracyjny i przyrostowy

Przykład

–

Biblioteka

prowadzi wypożyczalnię wydawnictw:

książek i czasopism

. Korzystają z niej

czytelnicy.

–

Wszystkie wydawnictwa mogą występować

wielu egzemplarzach

–

Czytelnicy mogą

rezerwować i odwoływać

rezerwacje

na wydawnictwa.

–

Książka może być

dostępna, wypożyczona,

zaginiona, lub zniszczona.

Statyczne zachowanie

systemu

Statyczne zachowanie

systemu

Jak modelować funkcjonalność

czyli o przypadkach użycia

Aktor, czyli działacz

Aktor

Aktor

ktoś (coś),

kto (co) musi

współdziałać z modelowanym

systemem.

Aktor w UMLu

Aktor

w UMLu jest klasą

(nie

obiektem!)

o nadanym stereotypie

Actor.

Można go oznaczać poprzez

–

ikonę

–

klasę ze stereotypem

Czytelnik

<< Actor >>

Przypadek użycia

Przypadek użycia (

use-case

)

– jest sposobem

, w jaki aktorzy używają (chcą

używać) systemu

– jest podstawową jednostką funkcjonalności

– definiuje

wymagania

Czego potrzebują
użytkownicy?

– Bibliotekarz...

– Czytelnik...

Diagram

use-case

Diagram

use-case

Definiuje

– granice

systemu,

czyli jak daleko sięga model

– jego

kontekst

czyli co pozostaje na zewnątrz

– użytkowników

systemu,

czyli aktorów

– funkcje

systemu,

– zależności

między użytkownikami i

funkcjami

... i jest czytelny dla odbiorcy!

Przykład diagramu

use-case

Przykład diagramu

use-case

dodanie tytułu

aktualizacja tytułu

dodanie

administracja

Bibliotekarz

dodanie czasopisma

dodanie książki

<<extends>>

<<uses>>

Użycie funkcji

Aktor używa funkcji (wykonuje

funkcję)

– domyślny stereotyp

<<communicates>>

– od

użytkownika do funkcji

Bibliotekarz

rezerwacja

Zależności między funkcjami

(cd.)

Zależności między funkcjami

(cd.)

Funkcja uszczegóławia funkcję

– relacja dziedziczenia

– stereotyp

<<extends>>

– funkcje abstrakcyjna
– od

funkcji szczegółowej

funkcji

ogólnej

dodanie czasopisma

dodanie tytułu

<<extends>>

Zależności między funkcjami

(cd.)

Zależności między funkcjami

(cd.)

Funkcja wywołuje inną funkcję

– relacja zależności

funkcji

– ponowne użycie funkcji/komponentu
– stereotyp

<<uses>>

– od

funkcji wołającej

funkcji wołanej

dodanie

<<uses>>

administracja

Statyczne zachowanie

systemu

Statyczne zachowanie

systemu

Modelowanie struktury danych

czyli o diagramach klas i obiektów

Klasa w UML

Klasa

przedstawia elementy świata o

podobnej semantyce i podobnym

zachowaniu

Posiada

nazwę

operacje

atrybuty

– nazwa pochodzi z dziedziny zastosowania

– standard nazywania

klas

Jak wyodrębnić klasy?

Zakres widoczności

operacji i atrybutów

Zakres widoczności

operacji i atrybutów

+ publiczne

(public)

– widoczne dla wszystkich

# chronione

(protected)

– widoczne dla potomków

–

prywatne

(private)

– widoczne wewnątrz klasy (kontenera)

–

implementacyjne

(implementation)

– widoczne wewnątrz pakietu

(nadkontenera)

Operacje

Operacje to usługi oferowane przez

klasę

– argumenty i typ wartości

– interfejs i deklaracja

definicja

– operacje statyczne

ich zakres obejmuje

klasę

a nie

obiekt

– operacje abstrakcyjne

posiadają tylko

deklarację operacji

, definicje

są w klasach potomnych

Atrybuty

Atrybuty to

informacje

zawarte

klasie/obiekcie

– cechy

klasy/obiektu

– relacje

z innymi klasami/obiektami

– atrybuty

statyczne

– atrybuty

wywiedzione

(derived)

‘/’

– typy atrybutów

Jak odróżnić klasę od atrybutu?

Asocjacje

Reprezentują

relacje

, w jakich

znajdują się klasy/obiekty

– posiadają

liczność (krotność)

– wiążą

1 lub więcej

klas

– mogą być

nazwane

i posiadać

role

– mogą mieć

własności i ograniczenia

Książka

ID : String

podaj ID()

Tytuł

tytuł : String
ISBN : String

podaj tytuł()

1..1

1..*

+posiada

1..1

1..*

Krotność asocjacji

Oznacza

liczbę obiektów

(nie klas!)

które są ze sobą skojarzone

– określone przez

dolny i górny zakres

– określane

liczbą naturalną

(0, 1, 2, ...)

lub

gwiazdką

(* - dowolna liczba)

– mają duże znaczenie na etapie projektu

Jaka jest różnica między oznaczeniami:

1..*

Agregacje

Modelują relację

część-całość

– agregacja współdzielona

(shared) -

część

może

należeć do wielu całości

– agregacja składowa

(composition) -

część jest ściśle

uzależniona

całości

Tom

ID tomu : int

Książka
ID : String

podaj ID()

1..1

1..*

+składa się

1..1

1..*

Zależność

Jest ogólnym określeniem

zależności

(

dependency

)

dwóch klas/obiektów

– od klasy zależnej do nadrzędnej
– często używane

ze stereotypem

– powiązanie elementów

na różnych

poziomach abstrakcji

Tom

ID tomu : int

Książka
ID : String

podaj ID()

<<friend>>

Dziedziczenie

Potomek dziedziczy cechy przodka

– ułatwia

zarządzanie złożonością

– zakres widoczności

w dziedziczeniu

– klasa abstrakcyjna

jako przodek

dostarcza tylko definicji operacji

– polimorfizm

operacji

– tryby dziedziczenia:

overlapping,

disjoint, complete, incomplete

Dziedziczenie (cd.)

Książka

podaj ID()

Wydawnictwo

ID : String

podaj ID()

Czasopismo

podaj ID()

{complete}

przykładowy diagram dziedziczenia

Przykład diagramu klas

Tytuł książki

ISBN : String

Tytuł czasopisma

ISSN : String

Wydawnictwo

ID : String

Tytuł

nazwa
/ liczba rezerwacji

1..1

0..*

1..1

+jest kopią

0..*

Rezerwacja

data : Date

1..1

0..*

+jest rezerwowany przez

1..1

0..*

Dane czytelnika

imię
nazwisko
adres

0..*

1..1

0..*

+składa

1..1

Wypożyczenie

data : Date

1..1

0..1

1..1

+dotyczy

0..1

1..1

0..*

+jest związane

1..1

0..*

Diagram klas (cd.)

–

Tytuł

jest klasą abstrakcyjną

–

Książka

Czasopismo

są specjalizacjami

Tytułu

–

Czytelnik

może mieć wiele

Wypożyczeń

–

Wypożyczenie

dotyczy jednego

Czytelnika

Case Study

Biblioteka:

opis na załączonych kartkach

Case Study

wypożyczenie czasopisma

wypożyczenie książki

wypożyczenie

<<extends>>

wyszukanie obiektu

<<uses>>

rezerwacja

<<uses>>

rozliczenie

Bibliotekarz

Czytelnik

udostępnienie

Case Study

Katalog

Katalog rzeczowy

Katalog alfabetyczny

Katalog autorski

Katalog czytelników

Rozliczenia

kwota
data

Autor

imię
nazwisko

Katalog wydawnictw

Wypożyczenia

data

Karta czytelnicza

imię
nazwisko
adres
wiek

1..*

0..*

Tytuł

autor
tytuł
ISBN

1..*

Rezerwacje

data początkowa

1..*

0..*

Egzemplarz

sygnatura

0..1

1..*

0..1

1..*

0..*

1..*

0..*

1..*

0..*

Case Study

Nowa

zniszczona

wypożyczona

dostępna

zagubiona

zwrot

[ czas > 3 mies. ]

naprawa

zarezerwowana

wypożyczenie

przegląd[ uszkodzenie > 30% ]

rezerwacja

odwołanie rezerwacji

Case Study

: Bibliotekarz

: Katalog

: Tytuł

: Rezerwacje

: Katalog

czytelników

: Karta

czytelnicza

zamówienie

sprawdź

wypożycz

sprawdź stan

wypożycz

sprawdź

Literatura

• G. Booch i in. "UML –

przewodnik użytkownika", WNT
2001

• M. Fowler „UML w kropelce”,

LT&P 2002

• S.S. Alhir “UML in a nutshell”,

O’Reilly, 1998

• P. Coad, E. Yourdon “Analiza

obiektowa”, Read Me, 1991

• H. E. Eriksson, M. Penker “UML

Toolkit”, Wiley, 1998



Dynamiczne zachowanie

obiektu

Dynamiczne zachowanie

obiektu

Diagramy stanu obiektu

czyli z życia (obiektów) wzięte

Diagram stanu

Modeluje

cykl (fazy) życia

obiektu

– określa

dozwolone stanu

obiektu

– definiuje

dopuszczalne przejścia

– określa

zdarzenia

, na które obiekt reaguje

– określa

akcje

, jakie zachodzą podczas

przejścia

krojenie [nóż jest

ostry]

Stany obiektu i przejścia

Dopuszczalne stany

– stany

początkowy

końcowy

– jeden ze

stanów pośrednich

Przejście jest opisane przez

– zdarzenie

, które

wyzwala

przejście

– warunek

, który weryfikuje

dopuszczalność

przejścia

– akcję

, która jest wykonywana

momencie

przejścia

Stany obiektów w UML

Reprezentacja stanu

– nazwa
– zmienne stanu
– czynności

Reprezentacja przejścia

zdarzenie

[warunek] /

akcja

^ nowe-zdarzenie

zniszczona

entry: usuń z rejestru

zapisz [operacja dozwolona] / ^dysk.zapisz()

Zdarzenia w UMLu

Cztery rodzaje zdarzeń w UMLu

– warunek

staje się prawdziwy

– odbiór sygnału

od innego obiektu

– wywołanie operacji

przez inny obiekt

– upływ określonego czasu

– błędy (poza definicją UML)

Obsługa zdarzeń

Wywołania operacji

– wywołujący obiekt jest

aktywny

– wywoływany obiekt jest

pasywny

Obsługa sygnałów

– wywoływany i wywołujący

obiekt muszą

być

aktywne

– sygnał jest obiektem ze

stereotypem

<<signal>>

Stany i podstany

Stan może mieć podstany

– typu or

- aktywny jest

jeden

podstan

– typu and

- aktywnych może być

kilka

podstanów

zarezerwowana

wypożyczona

zarezerwowana

wypożyczona

zarezerwowana

zwrot

wypożyczenie

Dynamiczne zachowanie

obiektu

Dynamiczne zachowanie

obiektu

Diagramy zachowania obiektu

czyli z system w działaniu

Modelowanie dynamiczne w

UMLu

Modelowanie dynamiczne w

UMLu

Diagramy modelowania zachowania

– czynności

(activity diagram)

odwzorowują

akcje

wykonywane na obiektach

dokonują podziału

odpowiedzialności

za akcje

– współpracy

(collaboration diagram)

wiążą

współpracujące obiekty

z uwzględnieniem

kolejności

pokazują

zależności

między obiektami

słabo lub wcale wspierane przez Rational

Rose!

– sekwencji

(sequence diagram)

Modelowanie dynamiczne

w UMLu (cd.)

Modelowanie dynamiczne

w UMLu (cd.)

Diagram sekwencji

– jak obiekty współdziałają

ze sobą

– sposób

wysyłania i odbioru zdarzeń

– składowa

czasu

: Bibliotekarz

: Wydawnictwo

: Czytelnik

czy istnieje?

pobierz liczbę

zarezerwuj

Typy zdarzeń

UML rozróżnia typy zdarzeń

– synchroniczne

, np. wywołania metod

– asynchroniczne

, np. sygnały

– proste

, np. przekazanie kontroli

– synchroniczne z natychmiastowym

powrotem

Istnienie obiektu

Prostokąt na linii życia obiektu

początek

- aktywacja obiektu

koniec

- dezaktywacja obiektu

usunięcie obiektu

- znak X

iteracja

- prostokąt obejmujący zdarzenia

rekursja

- wywołanie własnych operacji

Fizyczna struktura systemu

Podział na komponenty

czyli małe jest piękne

Pakiety

Czym jest pakiet?

– podsystemem
– organizuje

związane ze sobą elementy

– jak

importować

z obcych pakietów

Pakiety (cd.)

Podział - i co dalej?

– relacje między pakietami

zależność, generalizacja, import elementów

– widoczność elementów w pakiecie

analogicznie do

widoczności cech klas

GUI

Obsługa

wypożyczeń

Baza danych

Usługi

katalogowe

Komponenty

Komponenty systemu

– są

fizyczną reprezentacją

elementu modelu

– relacja

zależności

komponentów

– relacje ze znacznikiem

{location}

przyporządkowanie

komponentów

zasobów

– dostęp do usług poprzez

interfejsy

relacja wywołania

(stereotyp <<calls>>)

Dialog
logowania

Menedżer
okien

Diagram rozmieszczenia

Rozmieszczenie

(deployment)

fizyczna architektura

systemu

przyporządkowanie

modułów do urządzeń

zależności

między zasobami

Serwer

aplikacji

Usługi

katalogowe

Usługi

katalogowe

Zaawansowane elementy

UML

Zaawansowane elementy

UML

Stereotypy

czyli szablony myślenia

Po co stereotypy?

Odpowiednie dać rzeczy - słowo...

brak elementu o

precyzyjnym znaczeniu

nie wiem, jak ci to wytłumaczyć...

zbyt ogólne znaczenia

istniejących

elementów

zegar

Nowe znaczenia

Dawniej...

dodajmy

nowy element

języka

– dużo symboli, dużo znaczeń

UML

wykorzystajmy

stary element

nowym znaczeniu

+ mało symboli, dużo znaczeń!

Dlaczego stereotypy?

Same zalety...

potężny

mechanizm rozszerzeń

stosowane do

wszystkich elementów

dowolna precyzja

znaczenia

proste i czytelne

diagramy

<<odkrycie>>

Jak wygląda stereotyp?

Przedstawianie stereotypu

sam łańcuch

<<stereotyp>>

łańcuch <<stereotyp>>

w/przy elemencie

ikona

stereotypu

Czytelnik

<< Actor >>

Standardowe stereotypy

UML ma kilkadziesiąt gotowych

stereotypów

<<actor>>

ta klasa reprezentuje aktora

<<import>>

ta zależność definiuje import elementu

<<signal>>

ten obiekt jest sygnałem

<<uses>>

przypadek użycia korzysta z innego

Zaawansowane elementy

UML

Zaawansowane elementy

UML

Własności i znaczniki

czyli jak być precyzyjnym

Atrybuty elementów

Jak opisać atrybut elementu modelu?

...klasa ma status ‘draft’...
...ten atrybut nie może zostać zmieniony...

Rodzaje atrybutów

logiczne (true lub false)

{abstract}, {invariant}

o podanej wartości

{status = ‘draft’}

Własności

Własność

(tagged value)

definicja własności elementu w postaci

wartość

zapis

łańcuch przy elemencie
komentarz

Bibliotekarz

chory

Znaczniki

Znacznik

(tagged value)

definicja własności elementu w postaci

nazwa = wartość

zapis

{nazwa1 = wartość1, nazwa2 = wartość2}
{nazwa1}

Są też znaczniki standardowe...

np.

abstract, precondition...

Ograniczenia

Ograniczenie

(constraint)

jest

własnością o wartości logicznej

jest określone w

pewnym języku

Obiektowy Język Ograniczeń (OCL)

propozycja

formalnego języka

dla UML

bibliotekarz.wiek > 25 AND bibliotekarz.wiek < 65

Zaawansowane elementy

UML

Zaawansowane elementy

UML

Relacyjne bazy danych

czyli łączenie światów

Relacyjnie czy obiektowo?

Relacyjne bazy danych

dobrze rozwinięte
szeroko stosowane
wiele rozwiązań

Obiektowe bazy danych

mało rozwiązań
niepopularne

UML?

RBD w UMLu

Baza danych

komponent z stereotypem

<<database>>

Schemat

przestrzeń użytkownika w bazie danych
pakiet ze stereotypem <<schema>>

Oracle

<<database>>

RBD w UMLu (cd.)

Tabela

klasa ze stereotypem <<table>>

Klucze podstawowe

znacznik {PK}

na atrybucie

ograniczenie integralnościowe

jako operacja

UŻYTKOWNIK

ID : INTEGER

OGR_INT_ID()

<<RelationalTable>>

RBD w UMLu (cd.)

Klucze obce

znacznik {FK}

na atrybucie

ograniczenie integralnościowe

jako

operacja

Ograniczenia

operacje ze odpowiednim stereotypem

np. <<check>>, <<unique>>

Wyzwalacze

operacje ze stereotypem

<<trigger>>

RBD w UMLu (cd.)

Relacje nie identyfikujące

FK potomka

jest podzbiorem

PK rodzica

relacja ze stereotypem

<<not-identifying>>

Relacje identyfikujące

FK potomka

jest równy

PK rodzica

potomek jest

ściśle zależny

od rodzica

relacja ze stereotypem

<<identifying>>

Podsumowanie

Unifikacja postępuje

czyli czy warto się przyłączyć?

Podsumowanie

+ Potęga

metod obiektowych

+ UML jest

de facto

standardem

+ Wsparcie ze strony

producentów

+ Możliwości

rozszerzeń

Literatura

• H. E. Eriksson, M. Penker

“UML Toolkit”, Wiley, 1998

• S.S. Alhir “UML in a

nutshell”, O’Reilly, 1998

• Rational Software “Rational

Rose Documentation”, 2000

• http://www.rational.com/uml/



Document Outline

Slide 1
Slide 2
Slide 3
Slide 4
Slide 5
Slide 6
Slide 7
Slide 8
Slide 9
Slide 10
Slide 11
Slide 12
Slide 13
Slide 14
Slide 15
Slide 16
Slide 17
Slide 18
Slide 19
Slide 20
Slide 21
Slide 22
Slide 23
Slide 24
Slide 25
Slide 26
Slide 27
Slide 28
Slide 29
Slide 30
Slide 31
Slide 32
Slide 33
Slide 34
Slide 35
Slide 36
Slide 37
Slide 38
Slide 39
Slide 40
Slide 41
Slide 42
Slide 43
Slide 44
Slide 45
Slide 46
Slide 47
Slide 48
Slide 49
Slide 50
Slide 51
Slide 52
Slide 53
Slide 54
Slide 55
Slide 56
Slide 57
Slide 58
Slide 59
Slide 60
Slide 61
Slide 62
Slide 63
Slide 64
Slide 65
Slide 66
Slide 67
Slide 68
Slide 69
Slide 70
Slide 71
Slide 72
Slide 73
Slide 74
Slide 75
Slide 76
Slide 77
Slide 78
Slide 79
Slide 80
Slide 81
Slide 82
Slide 83
Slide 84

Wyszukiwarka

Podobne podstrony:
Ewa St�posz J�zyk modelowania danych UML
Realizacja w Javie rodzajów dziedziczenia wykorzystywanych w UML
Język Modelowania Danych UML
L2 PAA Modelowanie układu regulacji automatycznej z wykorzystaniem pakietu MATLAB Simulink(1)
MODELOWANIE ENERGETYCZNEGO WYKORZYSTANIA BIOMASY
MOFS 3 Modelowanie funkcjonowania systemu w UML DPU
Modelowanie UML
Modelowanie przedsięwzięć budowlanych z wykorzystaniem sieci Petriego
Modelowanie i analiza generatora samowzbudnego, Na laboratorium korzystaliśmy z programu wykorzystuj
Zrozumiec UML 2 0 Metody modelowania obiektowego zrouml
2007 08 UML – modelowanie statycznych aspektów oprogramowania [Inzynieria Oprogramowania]
modelowanie układów przełączających z wykorzystaniem elementów pneumatycznych i elektrycznychx
2007 07 Wykorzystanie przypadków użycia do modelowania zachowania [Inzynieria Oprogramowania]
helion jezyk uml 2 0 w modelowa Nieznany
W5 UML jezyk modelowania
2007 11 UML – modelowanie dynamicznych aspektów oprogramowania [Inzynieria Oprogramowania]
Modelowanie oświetlenia z wykorzystaniem OpenGL

więcej podobnych podstron

Modelowanie z wykorzystaniem UML

Document Outline