Modelowanie i analiza Modelowanie i analiza systemów informatycznychsystemów informatycznych

prof. A.Katkow

Email aleandrkatkow@gmail.com

LiteraturaLiteratura 1. S.Wrycza, B.Marcinkowski, K.Wyrzykowski, Język UML 2.0 w modelowaniu

systemów informatycznych, Helion, 2005.

2. W. Dąbrowski, A.Stasiak, M.Wolski, Modelowanie systemów informatycznych w

języku UML, MIKOM, Warszawa, 2007.

3. M.Weisfeld, Myślenie obiektowe w programowaniu, Helion, 2010.

4. GradyBooch, James Rumbaugh, Ivar Jacobson, UML, Przewodnik użytkownika,

WNT, 2003.

5. B.Stroustrup, Język C++, WNT, Warszawa, 1993.

6. G.Grębosz, Symfonia C++, W-wa, 1996.

7. K. Jamsa, Wygraj z C++,W-wa,1996.

8. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Inżynieria

oprogramowania: Wzorce projektowe (Wyd. II). Warszawa: WNT, 2008.

9. GradyBoochUMLpdf

2

3

1. Środowiska modelowania

komputerowego i języki

programowania

2. Systemy złożone

metody projektowania

obiektowo orientowany

paradygmat

3. UML (Unified Modeling Language)

Historia

Podstawy

Model pojęciowy UML

4. Zastosowanie UML

ATM (Automated Teller Machine)

Tworzenie Apletów

Internet

Analiza procesów przejściowych

Symulacja automatów skończonych

Projektowanie sterowników

5. Technika modelowania CRC

( ang. class-responsibility-collaboration

cards)

6. Modelowanie obiektowe ekologii

oceanu.

Projekt przykładowy

4

Edytor UML :

Preferowany Edytor UML Violet (violet.jar)

Dołączony do Wykładu

1. Środowiska modelowania 1. Środowiska modelowania komputerowego i języki komputerowego i języki

programowaniaprogramowania

Rozwój systemów modelowania Rozwój systemów modelowania komputerowego komputerowego

Charles Babbage (1791-1871)

Projekt maszyny analitycznej

6

•Lady Augusta Ada Lovelase (Augusta Ada

King, hrabina Lovelace) (1815-1852)

Pierwsze programy

•Alan Mathison Turing (1912-1954)

Maszyna Turinga

Test Turinga

•John von Neumann (1903-1957)

Architektura von Neumana

Los Alamos

7

Automaty komórkowe

Sieci neuronowe

Los Alamos

Księga „Przygody

matematyka”

•Stanisław Ułam (1909-1984)

Języki programowaniaJęzyki programowania

• COBOL (Common Business Oriented Language) -(1959) (do przekształcania zbiorów danych alfanumerycznych i tworzenia raportów)

• PASCAL (l 970-N.Wirth)

(do celów dydaktycznych- nauczania podstaw programowania)

8

FORTRAN (FORmulaTRANslator)-(l954-J.Backus)

FORTRAN 77, FORTRAN 90/95, (do rozwiązywania

problemów obliczeniowych)

• ALGOL 58 (ALGOrithmic Language) (1958 ),

ALGOL60, ALGOL 66 (dla celów naukowych, przy

opisie algorytmów) Peter Naur Peter Naur

Niclaus Wirth

J.Backus

Języki programowaniaJęzyki programowania C (1972 - Dennis M.Ritchie, B.W.Kernighan) (do opracowania systemu

operacyjnego UNIX)

Dennis M.Ritchie B.W.Kernighan

C - standard K&R;

1983 - ANSI (American National Standard Institute) Standard C;

C++ (1986 - Bjarne Stroustrup)

Bjarne Stroustrup

ADA 83 (1980), Ada 95 (1990) (Departament Obrony USA)

(do tworzenia dużych systemów oprogramowania i systemów czasu rzeczywistego)

9

KLASYFIKACJA JEZYKOW (BEGNER)KLASYFIKACJA JEZYKOW (BEGNER)

Pierwsza generacja (1954-1958) FORTRAN I (John Backus z IBM) Formuly matematyczne ALGOL-58 Formuly matematyczne FLOW-MATIC Formuly matematyczne IPL V Formuly matematyczne Druga generacja (1959-1961) FORTRAN II Podprogramy, rozdzielna kompilacja ALGOL-60 Struktura blokowa, typizacja danych COBOL Opis danych, praca z plikami BASIC Składnia zbliżona do języku angielskiego Lisp Opracowanie wyrazów, wskażniki

10

Lisp czyta (ang. read) wprowadzone wyrażenie, ewaluuje je (ang. evaluate) i

wypisuje (ang. print loop) wynik.

Trzecia generacja (1962-1970) PL/1 Fortran + ALGOL+COBOL ALGOL-68 Rozbudowany ALGOL-60 Pascal (Niclaus Wirth) Rozwój ALGOL-60 C Wskaźniki (ang. Pointers) Simula Klasy, abstrakcyjne typy danych Czwarta generacja (1970-1980) Smalltalk Klasy, abstrakcyjne typy danych C++ Object Pascal CLOS ADA (Jean Ichbiah)

11

Języki obiektowe i

obiektowo-orientowane

Common Lisp Object System (CLOS)

Sądzę, że jest to jedyny język programowania który można szanować pod

względem matematycznym, gdyż tylko o nim jestem w stanie udowadniać twierdzenia!

— Gregory Chaitin

12

Projekt GNU – przedsięwzięcie

mające na celu stworzenie

kompletnego, wolnego,

uniksopodobnego systemu

operacyjnego GNU,

zapoczątkowane w

styczniu 1984 roku przez Richarda

Matthew Stallmana

z Massachusetts Institute of

Technology (MIT)

GNU projekt na General Public License –

licencja wolnego i otwartego oprogramowania (open-source

software) stworzona w 1989 roku przez Richarda

Stallmana i Ebena Moglena na potrzeby Projektu GNU

(rekurencyjny akronim „GNU’s not Unix”).

Open-source software

13

Celem licencji GNU GPL jest przekazanie użytkownikom

czterech podstawowych wolności:

(wolność 0) wolność uruchamiania programu w dowolnym celu

(wolność 1) wolność analizowania, jak program działa i

dostosowywania go do swoich potrzeb

(wolność 2) wolność rozpowszechniania niezmodyfikowanej

kopii programu

(wolność 3) wolność udoskonalania programu i publicznego

rozpowszechniania własnych ulepszeń, dzięki czemu może z

nich skorzystać cała społeczność.

Języki programowania na licencji GPLJęzyki programowania na licencji GPL

14

Licenzja: Python rozwijany jest jako projekt Open Source,

zarządzany przez Python Software Foundation

Perl (Larry Wall, 1987). Interpretowany język

programowania. Perl to wolne oprogramowanie,

dostępne pod licencjami GPL. Początkowo

przeznaczony głównie do pracy z danymi

tekstowymi.

Standardowa implementacja to CPython (pisany w C), ale istnieją też inne, takie

jak JPython (w Javie), IronPython (na platformę .NET) i PyPy (w Python).

Python (Guido van Rossman, 1990). Python

wspiera różne paradygmaty programowania:

obiektowe, imperatywne, w mniejszym stopniu

również programowanie funkcyjne. Podtrzymuję

dziedziczenie typów wbudowanych. Dziedziczenie

wielu bazowe.

W latach dziewięćdziesiątych powstał cały szereg

imperatywno-obiektowych języków:

Larry Wall

Guido van Rossman

15

Z tego powodu że linia poleceń Lisp jest nazywana „Read-Eval-Print Loop„ lub

w skrócie REPL – tak nazywa się interaktywne środowisko programowania,

które w tym lub innym stopniu zawiera prawie każde środowisko

interpretowanych języków programowania.

Ruby (Yukihiro Matsumoto, 1995). Ruby to interpretowany, w

pełni obiektowy i dynamicznie typowany język programowania.

Ruby on Rails (często nazywany RoR lub po prostu Rails) –

framework open source do szybkiego tworzenia aplikacji

webowych.

PHP autorstwa Rasmusa Lerdorfa (1995). PHP obiektowy

język programowania zaprojektowany do generowania stron

internetowych w czasie rzeczywistym. Implementacja PHP

wraz z serwerem WWW Apache oraz serwerem baz danych

MySQL określana jest jako platforma AMP (w środowisku

Linux – LAMP, w Windows – WAMP)

Interaktywne środowisko programowania

Yukihiro Matsumoto

Rasmus Lerdorf

IDE (IDE (IntegratedIntegrated Development Environment)Development Environment) do projektowania wizualnegodo projektowania wizualnego

Visual C++

Visual Basic

Visual Fortran

Visual Java

Visual C#

Delphi

Builder C++

Microsoft .NET (IDE CLR (Common Language Runtime))

(C++/CLI, C#, J#,Visual Basic, F#).

16

I wielu innych …

CommonCommon Language Language InfrastructureInfrastructure (CLI)(CLI)

17

Wspólny język

pośredni (CIL)

Środowisko

uruchomieniowe (CLR)

Polecenia maszynowe,

kod bitowy

.NET Framework

Wspólna platforma

programistyczna

(Microsoft)

18

Microsoft

Intermediate

Language (MSIL)

Głównym twórcą C# jest Anders Hejlsberg, czyli nie kto inny jak projektant

produkowanego przez firmę Borland pakietu Delfi a także TurboPascal.

W Microsoft A.Hejlsberg rozwijał m.i. środowisko Visual J++.

Anders Hejlsberg

19

Taksonomia Flynna

Michael Flynn

2. Systemy złożone2. Systemy złożone

metody projektowania obiektowo orientowany paradygmat

21 R. Muszynski

PIĘĆ CECH SYSTEMÓW ZŁOŻONYCH

22

3. Związki wnętrz podsystemu są mocniejsze niż związki

między podsystemami.

1. Systemy złożone zwykle składają się z współzależnych

podsystemów, które z kolej także mogą być rozdzielone na

podsystemy, tworzą takim czynom hierarchie podsystemów.

2. Wybór najniższego poziomu abstrakcji nie określony z góry i w

dużym stopniu określa się badaczem.

23

4. W procesie rozwoju systemu podsystemy, które od początku liczą się

jako złożone, z czasem są rozpatrywane jako elementy niższego

poziomu abstrakcji i wykorzystują się jako elementy przy

konstruowaniu bardziej złożonych systemów.

5. Pracujący system złożony koniecznie jest rezultatem rozwoju

pracującej prostej systemy. Praktyka pokazuje, że

system złożony, zaprojektowany ot początku do końca na

papierze, nigdy nie pracuję i jego nie można uruchomić.

UPORZĄDKOWANIE CHAOSU UPORZĄDKOWANIE CHAOSU

1.Dekompozycja (divide et impera) Rozdzielenie systemu złożonego na części składowe (podsystemy)

dekompozycja algorytmiczna (dekompozycja w sensie rozdzielenia algorytmów, koncentracja na

kolejności oddziaływania);

dekompozycja obiektowo orientowana (świat obiektów, które są między sobą oddziaływają, koncentracja na procesie wzajemnego oddziaływania);

dekompozycja algorytmiczna i obiektowo orientowana (korzystniej na początku wykorzystać podejście obiektowo zorientowane a potem algorytmiczne)

24

(Wprowadzenie porządku w chaos)

- ignorowanie detali przy rozpatrywaniu systemów złożonych na

domniemanym poziomie analizy względem możliwości człowieka;

- organizacja pamięci człowieka narzuca twarde ograniczenia na ilość

informacji, którą my możemy dostrzec, przeanalizować i pamiętać;

- ludzie mają bardzo wydajne mechanizmy opracowania informacji

złożonych, dzięki umiejętności ignorowania mniej ważne informacje.

25

2.Abstrakcja

26

- organizacja wnętrz systemu hierarchii klas i obiektów;

-klasyfikacja obiektów do grup powiązanych abstrakcji

(np. rodzaje komórek roślinnych i komórek zwierzęcych).

- klasyfikacja wyraźnie dzieli wspólne i charakterystyczne

właściwości różnych obiektów i pomagają nam odtworzyć ich własne

skomplikowane struktury.

3. Hierarchia

METODY PROJEKTOWANIA SYSTEMÓW METODY PROJEKTOWANIA SYSTEMÓW ZŁOŻONYCH ZŁOŻONYCH

1.Metoda projektowania strukturalnego

projektowanie od góry do dołu;

dekompozycja dużych zagadnień na mały;

27

2.Metoda organizacji potoków danych

struktura systemu sterowania opiera się na procesie

przekształcenia wejściowego potoku danych w potok danych

wyjściowy;

3. Projektowanie orientowane obiektowo

projektowany system – całokształt

obiektów wzajemnie oddziaływających się;

obiekty to egzemplarze określonych klas;

klasy tworzą hierarchie;

28

CEL PROJEKTOWANIACEL PROJEKTOWANIA

Rezultatem projektowania są modele systemu

informatycznego, pozwalające:

zrozumieć strukturę systemu,

utrzymać równowagę wymagań

określić schemat jej realizacje;

29

Obiektowo Obiektowo -- orientowana analiza orientowana analiza (OOA)(OOA)

30

Obiektowo-orientowana analiza skierowana na stworzenie modelów,

najbliżej odpowiadających realnemu światowi, na podstawie

wykorzystania obiektowo-orientowanego ujęcia;

To jest metodologia, zgodnie z której wymagania są formują się na

podstawie pojęć klasów i obiektów, które tworzą słownik odpowiedniej

dziedziny.

Obiektowo - orientowane ujęcie

ObjektowoObjektowo--orientowane projektowanie (OOD)orientowane projektowanie (OOD)

31

Objektowo-orientowane programowanie (OOP)

Objektowo-orientowane projektowanie - to metodologia projektowania,

która opiera się na dekompozycji obiektowej i na sposoby

przedstawienia jak logicznych i fizycznych, tak statycznych i

dynamicznych modelów systemu w postaci hierarchii podsystemów.

Obiektowo - orientowane programowanie - to metodologia

programowania, która opiera się na przedstawieniu programu w

postaci połączenia obiektów, każdy z których jest przedstawicielem

określonej klasy, a one są tworzą hierarchie na podstawie dziedziczenia.

Abstrahowanie;

Ograniczenie dostępu;

Dzielenie na moduły;

Hierarchie abstrakcji.

Elementy dopełniające:

Typizacja;

Równoległość;

Odporność.

32

Główne elementy koncepcji programowania obiektowo orientowanego:

Abstrakcja istoty obiektu;

Abstrakcja zachowania;

Abstrakcja w postaci maszyny wirtualnej;

Dowolna abstrakcja

Przykłady.

Abstrakcja istoty rzeczy:

Klient - obiekt, wykorzystujący resursy (zasoby) innych obiektów.

33

Abstrahowanie

Protokół - Pełna lista operacji, które obiekt może

wykonywać nad innymi obiektami.

Operacja (operation ) - Ada

Metoda ( method ) - Smalltalk

Funkcja (member-function) - C++

34

Abstrakcja zachowania

Abstrakcja w postaci maszyny wirtualnej:

Przykład:

Emulacja - modelowanie wszystkich operacji maszyny (mikroprocesora) na innej maszynie ( z wykorzystaniem innego mikroprocesora ).

35

Ograniczenie dostępu:

W C++

private:

protected:

public:

B. Stroustrup - „Ograniczenie dostępu zabezpiecza od

ingerencji ale nie od oszustwa”

Modelowanie obiektoweModelowanie obiektowe

36

Algorytmiczny punkt widzenia.

W takim podejściu podstawowym blokiem konstrukcyjnym jest procedura

lub funkcja.

Programiści koncentrują się na przepływie sterowania i podziale

algorytmów na mniejsze części.

Obiektowy punkt widzenia.

W takim podejściu podstawowym blokiem konstrukcyjnym jest obiekt lub

klasa.

Obiekt i klasa pochodzi z danej dziedziny problemu lub z przestrzeni

dopuszczalnych rozwiązań.

Obiektowo Orientowany ParadygmatObiektowo Orientowany Paradygmat

37

1. Według obiektowo orientowanego ujęcia program dzieli się na

mnóstwo małych części (obiektów) które są niezależne jeden od

drugiego. Obiektowo-orientowana dekompozycja pomaga bardzo

skutecznie stworzyć program, wykorzystując obiekty.

2. Jedna z głównych zalet obiektowo orientowanego paradygmatu jest to

że komponenty czyli obiekty trzeba opracować tylko jeden raz a potem

ich można wykorzystywać wielokrotnie.

Tradycyjne ujęcie orientowane na informacje ( data-centric) jest

bardzo skuteczne przy projektowaniu baz danych i systemów

gromadzenia informacji, czyli takich systemów gdzie mogą zmieniać się

dane ale nie reguły ich opracowania lub zachowanie systemu.

Obiektowo orientowany paradygmat to sposób zapisu programów.

38

3. Obiektowo orientowane ujęcie przewiduję w każdym opracowanym

obiekcie umiejscowienie jak informacje tak i sposób jej opracowania.

To pozwala tworzyć systemy , które są podatne na łatwe wprowadzenie

zmian jak w treści informacji tak i w zachowaniu systemu.

Główne składowe obiektowo orientowanego ujęcia:

Hermetyzacja, dziedziczenie i polimorfizm.

Hermetyzacja (ang. Encapsulation): W systemach obiektowo orientowanych obiekty są zawierają jak dane,

czyli informację, tak i sposoby jej opracowania. Na tym i polega

hermetyzacja.

Przykład z kontem bankowym :

(konto kredytowe, operacji na koncie kredytowym).

Ograniczony dostęp do danych (private, protected, public)

39

Dziedziczenie:

class pracownik

{

public:

string imię;

string nazwisko;

private:

int wiek;

….

int ID;

};

W obiektowo-orientowanych systemach dziedziczenie to mechanizm, który pozwala

na tworzenie nowych obiektów na podstawie istniejących. Nowy obiekt: obiekt-

potomek ( ang. child) dziedziczy właściwości rodzicielskiego obiektu (ang. parent).

class pracownik_czasowy

{

public:

string imię;

string nazwisko;

int długosc_umowy

private:

int wiek;

….

int ID;

}; class pracownik_czasowy: public pracownik

{

public:

int długosc_umowy;

};

Dziedziczenie

40

Obiekt BirdController prostu działa z ogólnym obiektom ptak i nie wie, jaki

dokładnie typu są. Jest to wygodne z punktu widzenia BirdController, bo nie trzeba

pisać specjalny kod, aby określić jak dokładny typ Ptak działa lub jakie zachowanie

ptaka. Co się dzieje, że gdy move() jest wywoływana pomijając specyficzny rodzaj

ptaka. Jakie prawo zachowania nastąpi ( Goose rusza się, lata lub pływa, a Pingwin

rusza się lub pływa)?

Polimorfizm

41

nadpisywanie funkcji

Rozważmy przykład rodziny klas Shape (Figura geometryczna) . Klasy mają ten sam

jednolity interfejs. Używając polimorfizm, możemy napisać pojedynczy kawałek

kodu, który ignoruje konkretne szczegóły typu i mówi tylko do klasy bazowej.

Rozszerzalność programu.

Jeśli nowy typ - sześciokąt, na przykład - dodamy w drodze dziedziczenia, nasz kod

będzie działać równie dobrze na nowy typ kształtu, jak to miało miejsce dla

istniejących typów. W ten sposób, program jest łatwo rozszerzalny.

42

Wirtualna funkcja w C ++

void doStuff(Shape& s)

{ s.erase();

// ...

s.draw(); }

Funkcja ta przemawia do każdego kształtu figury, więc jest niezależna od

konkretnego typu obiektu, z którym odbywa się rysowanie i kasowanie ( "&"

oznacza „Weź adres obiektu, który jest przekazywany do doStuff”).

W innej części programu używamy funkcji doStuff ():

Circle c;

Triangle t;

Line l;

doStuff(c);

doStuff(t);

doStuff(l);

Wywołania funkcji doStuff () automatycznie

działają dobrze, zgodnie z dokładnym typem

obiektu.

43

KLASY

Klasa to opis zbioru obiektów, które mają takie same

atrybuty i funkcje.

Symbolem graficznym jest prostokąt.

nazwa klasy prosta - Klient, Sciana, Wykład …

nazwa klasy ścieżkowa - java::awt::Rectangle

Nazwa klasy może być tekstem zawierającym dowolną liczbę liter, cyfr i

znaków przestankowych (z wyjątkiem dwukropka oddzielającego

nazwę klasy od nazwy jej pakietu), zapisanym w wielu wierszach.

3. Funkcji - modyfikatory określają się odpowiednimi czasownikami.

Na przykład: draw, move;

4. Funkcji - selektory określają się pytaniami lub odpowiednimi formami

czasownika to be.

Na przykład: extendOf, isOpen;

44

1. Klasę nazywają się jak ogólne rzeczowniki.

Na przykład:

Sensors, Shapes, Flowers;

2. Obiekty nazywają się odpowiednimi zdaniami.

Na przykład :

TheSensor, Ashape, Aflower;

Konwencja nazewnictwa klas, obiektów i funkcji:

45

ATRYBUTY KLASY

Atrybut to nazwana właściwość klasy. Określa zbiór wartości, jakie

można przypisać do poszczególnych egzemplarzy tej klasy

Klient

nazwisko adres telefon dataUrodzenia

Atrybuty

Działka

szerokość: float długość: float cena: float jestZalesiona: bool = false

Atrybuty

Wartości domyślne

46

OPERACJE

Operacja to implementacja pewnej usługi,

której wykonania można zażądać od każdego obiektu klasy.

Nazwa operacji może być dowolnym tekstem.

Każdy wyraz w nazwie - poza pierwszym - zaczyna się zwykle wielką literą

(np. move lub isEmpty).

Rectangle

+kolor: black

+add() +dodajKolor() +move() +isEmpty()

Operacje

Drzewo

+wiek: int

+dodajKolor() +grow() +ustawWiek(t: Wiek) +odczytajWiek(): Wiek -przesuń()

Wartości domyślne

47

47

Organizacja atrybutów i operacji

Symbol klasy nie musi zawierać wszystkich atrybutów i operacji.

Pusta sekcja symbolu klasy, dotycząca atrybutów lub

operacji, nie oznacza wcale, że nie ma ich w klasie, a

jedynie to, że nie zdecydowano się ich przedstawić na

diagramie.

Fotel

„konstruktor” Fotel{} … „gatunek” +wybierzZKolekcji() … „przetwarzanie” +wstaw() +przesuń() +zmieńKolor() +usuń() …

Stereotyp

Dla zaznaczenia, że klasa ma więcej atrybutów i

operacji, niż wynikałoby to z symbolu, wystarczy na

końcu każdej listy elementów umieścić wielokropek

(...).

Długie listy atrybutów i operacji,

można podzielić na grupy za pomocą

stereotypów

48

48

ODPOWIEDZIALNOŚĆ KLASY

Odpowiedzialność (ang. responsibility) klasy to specyfikacja pewnych działań,

które muszą być w stanie wykonać obiekty klasy.

Zobowiązania

Drzewo

Wiek Gatunek …

dodajKolor() ustawWiek(t: Wiek) podajWiek(): Wiek przesun() +grow() …

Resposibilities powinno rosnąć powinno zmieniać kolor liści powinno podawać „wiek”

Operacje

Podczas udoskonalania

modelu trzeba

przełożyć

zobowiązania na

najlepiej je realizujący

zbiór atrybutów i

operacji.

Atrybuty

Nazwa klasy

49

WIDOCZNOŚĆ ATRYBUTÓW I OPERACJI KLASY

Widoczność to jedna z najważniejszych cech, jakie można określić dla

atrybutów i operacji klasy.

private (prywatna) Tylko dana klasa ma dostęp

do jej składnika. Na diagramie zaznaczamy ten

fakt znakiem -.

public (publiczna) Każda klasa, która ma

dostęp do danej klasy, ma także dostęp do jej

składnika. Na diagramie ten fakt zaznacza się

znakiem +.

protected (chroniona) Każdy potomek klasy

ma dostęp do jej składnika. Na diagramie

zaznacza się znakiem #.

#

+

-

PasekNarzędzi

# bieżącyWybór # liczbaNarzędzi

+ wybierzEgzemplarz() + dodajNarzędzie() + usuńNarzędzie() + pobierzNarzędzie() # odszukajNarzędzie() - poukładaj()

Widoczność w UML odpowiada podobnym pojęciom

zdefiniowanym w większości języków

programowania, takich jak C++, Java, Ada, Eiffel.

Typy Typy relacjirelacji

50

1. inheritance - relacja dziedziczenia;

2. association - relacja wykorzystania;

3. aggregation - relacja zawierania (część składowa);

Przykład:

Relacja zawierania Relacja zawierania

(ang. (ang. AggregationAggregation).).

class Motors {..... public: int power, voltage, number_of_rotation; ..... }; class Sensors {... public: int number_inputs; float sensitive, time_delay; .... };

51

class Escalators

{.....

public:

int rok;

float price, weight;

Motors aMotor;

Sensors aSensor;

....

};

Relacja wykorzystaniaRelacja wykorzystania

(ang. (ang. associationassociation) .) .

class Escalator_controller

• {....

• public:

• int number_outputs;

• char turn_off;

• char turn_off_motor(Motors &Mt)

• {... //cialo funkcji

• return turn_off};

• ......

• };

• ......................................

52

Główny program. main( ) {

Escalators AnEscalator;

AnEscalator.aSensor.number_inputs = 16;

AnEscalator.aMotor.voltage = 380;

}

53

3. UML (Unified Modeling Language)

Historia

Podstawy

Model pojęciowy UML

54

Architektura oprogramowania dotyczy:

struktury,

zachowania,

zastosowania

efektywności,

odporności,

możliwości ponownego użycia,

ograniczeń ekonomicznych

ograniczeń technologicznych

systemów informatycznych

UML jest znormalizowanym językiem zapisywania projektu systemu.

Historia. Diagramy Gantta, 1917Historia. Diagramy Gantta, 1917

55

H. L. Gantt po raz pierwszy zastosował do przedstawienia planu produkcji w formie

graficznej w roku 1917. Wykres Gantta jest graficznym sposobem planowania i kontroli.

Wykres ten został wymyślony przez

pułkownika Gantta podczas I Wojny

Światowej i służył w początkowej fazie do

zarządzania służbami medycznymi w

armii brytyjskiej.

56

Diagramy Kaoru Ishikawy, 1962

Wzorce projekWzorce projektowe, 1979towe, 1979

57

Erich Gamma, Richard Helm, Ralph Johnson, John

Vlissides: Inżynieria oprogramowania: Wzorce projektowe

(Wyd. II). Warszawa: WNT, 2008. Banda Czterech

Wzorce projektowe w architekturze (Christopher Alexandr, 1979)

Wzorce projektowe stanowią abstrakcyjny opis zależności pomiędzy

klasami.

Nazwa wzorca : opisowa oraz unikalna nazwa.

Przeznaczenie: opis celu, który stoi za wzorcem.

Inne nazwy: jeżeli istnieją inne, dobrze znane nazwy wzorca, należy je podać.

Motywacja: scenariusz zawierający problem powiązany z kontekstem.

Struktura: graficzna reprezentacja wzorca, zwykle jako diagram klas

Uczestnicy: lista klas i obiektów stosowanych w tym wzorcu oraz ich zobowiązania.

Współpraca: opis wzajemnej interakcji klas i obiektów wykorzystywanych we

wzorcu.

Konsekwencje: wykaz wyników, efektów ubocznych.

Implementacja: wskazówki dotyczące implementacji wzorca.

Przykładowy kod: przykład zastosowania wzorca w jednym z języków

programowania.

58

Obserwator (ang. observer) – w informatyce: wzorzec należący do grupy

wzorców czynnościowych. Używany jest do powiadamiania zainteresowanych

obiektów o zmianie stanu pewnego innego obiektu.

Strategia (ang. strategy) to jeden z czynnościowych wzorców projektowych, który

definiuje rodzinę algorytmów i kapsułuje je w postaci klas. Umożliwia wymienne

stosowanie każdego z nich w trakcie działania aplikacji niezależnie od

korzystających z nich klientów.

Kompozyt (ang. composite) jest jednym ze strukturalnych wzorców projektowych,

którego celem jest składanie obiektów w taki sposób, aby klient widział ich jako

pojedynczy obiekt.

Pyłek (ang. flyweight) znany także jako Waga Piórkowa jest jednym ze

strukturalnych wzorców projektowych. Jego celem jest zmniejszenie

wykorzystania pamięci poprzez efektywną obsługę wielu małych obiektów za

pomocą współdzielenia (przetwarzanie równolegle).

Przykłady wzorców projektowych

59

IBM Rational Rose Developer for Visual Studio oferuje zestaw narzędzi do

programowania w oparciu o model w języku UML, umożliwiający tworzenie

aplikacji działających w środowisku Microsoft Visual Studio. Narzędzie pozwala

na skrócenie czasu tworzenia aplikacji dzięki generowaniu kodu na podstawie

modeli wizualnych w oparciu o język Unified Modeling Language (UML).

Skraca czas tworzenia aplikacji — środowisko modelowania wizualnego pozwala

uprościć proces tworzenia aplikacji.

Integruje procesy projektowania i tworzenia aplikacji — sprzyja integracji zespołu

projektowego, udostępniając wspólny, obsługujący wykonywanie i notację modelu

język UML.

IBM Rational Rose Developer for Visual Studio

Główne cechy UMLGłówne cechy UML

60

UML nadaje się do modelowania

systemów informatycznych

oprogramowanie WWW

systemów wbudowanych czasu rzeczywistego

rzeczywistości

Model pojęciowy UML. Trzy składniki pojęciowe UML

podstawowe bloki pojęciowe:

reguły określającymi sposoby używania bloków pojęciowych

mechanizmy językowe.

elementy konstrukcyjne,

związki,

diagramy

61

elementy konstrukcyjne,

związki,

diagramy

Bloki pojęciowe

strukturalne,

czynnościowe,

grupujące,

komentujące.

klasa

interfejs

kooperacja

przypadek użycia

klasy aktywne

komponenty

węzły

interakcja

maszyna stanowa

elementy konstrukcyjne

czynnościowe,

strukturalne

62

zależność (ang. association)

dziedziczenie (ang. inheritance)

agregacja (ang. aggregation)

17 rodzaje zależności

bind (powiązać),

derive (pochodzić z)

friend (zaprzyjaźniony)

instanceOf (przypadek)

…

send (wysłać)

trace (rejestrować)

związki

nazwa,

role

liczebność

agregacja

agregacja

elementy konstrukcyjne,

związki,

diagramy

Bloki pojęciowe

dziedziczenie

-private

# protected

+ public

zależność

63

elementy konstrukcyjne,

związki,

diagramy

Bloki pojęciowe

Perspektywa projektowa

Aspekty statyczne tej perspektywy wyraża się za pomocą diagramów komponentów. Aspekty dynamiczne za pomocą: diagramów interakcji, diagramów stanów, diagramów czynności.

Perspektywa implementacyjna

diagramy

Aspekty statyczne tej perspektywy wyraża się za pomocą: diagramów wdrożenia, Aspekty dynamiczne za pomocą diagramów interakcji diagramów stanów diagramów czynności

perspektywie wdrożeniowej

Aspekty statyczne tej perspektywy wyraża się za pomocą: diagramów przypadków użycia, Aspekty dynamiczne za pomocą: diagramów interakcji, diagramów stanów diagramów czynności.

perspektywa przypadków użycia

Aspekty statyczne tej perspektywy wyraża się za pomocą: diagramów klas diagramów obiektów, Aspekty dynamiczne za pomocą: diagramów interakcji, diagramów stanów, diagramów czynności.

64

W UML istnieją cztery rodzaje

elementów konstrukcyjnych:

Elementy strukturalne są w modelach UML wyrażone rzeczownikami.

Stanowią najbardziej statyczne części modelu, reprezentujące składniki

pojęciowe albo fizyczne.

Łącznie istnieje siedem rodzajów elementów strukturalnych.

strukturalne,

czynnościowe,

grupujące,

komentujące.

elementy konstrukcyjne,

związki,

diagramy

Bloki pojęciowe

Elementy konstrukcyjneElementy konstrukcyjne strukturalnestrukturalne

65

65

Klasa

Interfejs

Kooperacja

Przypadek użycia

Klasy aktywne

Komponenty

Węzły

Klasa

Interfejs

Klasa to opis zbioru obiektów, które mają takie same

atrybuty, operacje, związki i znaczenia.

Interfejs to zestaw deklaracji operacji, które wyznaczają

usługi oferowane przez klasę lub komponent.

Samochód

rokProdukcji typ

załaduj() ruszaj() zatrzymaj() rozładuj() podajRok() ustawRok()

IPrzewózCiężaru

66

Jedną z kluczowych umiejętności, które należy opanować, aby tworzyć

niezawodne projekty obiektowe, jest odróżnianie interfejsów od implementacji.

Zatem podczas projektowania klasy największe

znaczenie ma decyzja dotycząca tego, co udostępnić

użytkownikowi a co przed nim ukryć. Mechanizm

ukrywania nieistotnych informacji jest hermetyzacją.

Na

Abstrakcyjny interfejs

Na lotnisko, proszę!

Konkretny interfejs

Różnica między interfejsem a implementacją

67

Po zadecydowaniu o składzie interfejsu publicznego należy przejść

do implementacji.

Gdy klasa jest już zaprojektowana i wszystkie metody, które są

potrzebne do jej prawidłowego działania, są na miejscu, kolejnym

etapem jest napisanie kodu umożliwiającego jej działanie.

Z technicznego punktu widzenia wszystko, co nie jest interfejsem

publicznym, można uznać za implementację.

Oznacza to, że użytkownik nigdy nie zobaczy żadnej z metod

wchodzących w skład implementacji.

Dotyczy to także ich sygnatur (które składają się z nazwy metody i

listy parametrów) oraz znajdującego się wewnątrz kodu.

Identyfikowanie implementacji

68

68

Elementy konstrukcyjne strukturalne

68

Kooperacja

Kooperacja to zestaw bytów, współdziałających w

celu wywołania pewnego zespołowego zachowania

niemożliwego do osiągnięcia w pojedynkę.

Kooperacja to porcja pojęciowa systemu.

Aspekt czynnościowy Aspekt strukturalny

KomunikacjaMiejska

Diagramy interakcji Diagramy klas

KomunikacjaMiejska

Klasa

Interfejs

Kooperacja

Przypadek użycia

Klasy aktywne

Komponenty

Węzły

Elementy konstrukcyjne Elementy konstrukcyjne strukturalnestrukturalne

69

Przypadki użycia

Przypadki użycia służą do określenia w modelu zachowania

systemu. Są realizowane przez kooperację.

Klasa

Interfejs

Kooperacja

Przypadek użycia

Klasy aktywne

Komponenty

Węzły

Przypadki użycia to opis zbioru akcji wykonywanych przez

system w celu dostarczenia klientowi oczekiwanego wyniku.

Położyć pieniądze na konto

Zmienić kod identyfikacyjny

Dokonać wypłatę

Elementy konstrukcyjne Elementy konstrukcyjne strukturalnestrukturalne

70

Klasy aktywne

Klasa aktywna jest podobna do zwykłej klasy, z tym że

jej obiekty reprezentują elementy działające

równolegle z innymi.

Klasa aktywna zawiera obiekty, w skład których

wchodzi co najmniej jeden proces lub wątek. Takie

obiekty mogą samodzielnie rozpocząć przepływ

sterowania.

ZarządcaZdarzeń

wstrzymaj() rozeszlij()

Klasa

Interfejs

Kooperacja

Przypadek użycia

Klasy aktywne

Komponenty

Węzły

SterowanieProcesami

uruchom() zamknij()

71

Elementy konstrukcyjne strukturalne

71

Komponent to wymienna część systemu, która

wykorzystuje i realizuje pewien zbiór interfejsów.

Komponent to programowe opakowanie elementów,

takich jak klasy, interfejsy i kooperacje np. komponenty

Java Beans, Borland C++.

Komponent

Klasa

Interfejs

Kooperacja

Przypadek użycia

Klasy aktywne

Komponenty

Węzły

Elementy konstrukcyjne Elementy konstrukcyjne strukturalnestrukturalne

72

Węzeł to fizyczny składnik działającego systemu.

Reprezentuje zasoby obliczeniowe. Ma pewną ilość

pamięci i zdolność przetwarzania.

Węzły

Klasa

Interfejs

Kooperacja

Przypadek użycia

Klasy aktywne

Komponenty

Węzły

Interakcja to proces wymiany komunikatów między

obiektami i zespołami obiektów.

Elementy konstrukcyjne Elementy konstrukcyjne czynnościoweczynnościowe

73

Elementy czynnościowe to dynamiczna część modelu w

UML. Są wyrażone czasownikami opisującymi

zachowanie w czasie i w przestrzeni. Wyróżnione dwa

rodzaje takich elementów: interakcja i maszyna

stanowa.

Wyróżnia się dwa rodzaje takich elementów:

komunikaty i połączenia.

wyświetl

komunikat połączenie

interakcja

maszyna stanowa

strukturalne,

czynnościowe,

grupujące,

komentujące.

74

Elementy konstrukcyjne czynnościowe

Maszyna stanowa określa ciąg stanów, jakie obiekt

przyjmuje w odpowiedzi na zdarzenia zachodzące w czasie

ich życia.

Oczekiwanie

Stany

Dozór

Przejścia

Maszyna stanowa składa się z elementów, takich jak

stany, przejścia między stanami, zdarzenia, które

powodują przejścia, i czynności, odpowiedzi na

zdarzenia.

interakcja

maszyna stanowa

Alarm

niesankcjonowanyDostęp

Zdarzenie

powiadomieniePolicji

Czynność

Elementy konstrukcyjne Elementy konstrukcyjne grupującegrupujące

75

Elementy grupujące odgrywają w UML rolę

organizacyjną. Są to bloki, na które dany model może

być rozłożony.

Podstawowym rodzajem tego typu elementu jest pakiet.

Pakiet służy do grupowania elementów. Może zawierać

elementy strukturalne, czynnościowe, a nawet inne

elementy grupujące.

W odróżnieniu od komponentu (który istnieje w czasie

wykonania programu) pakiet jest bytem pojęciowym, to

znaczy istnieje jedynie w czasie tworzenia oprogramowania.

Istnieją też inne elementy tego typu, takie jak zręby,

modele i podsystemy (rodzaje pakietów).

Reguły przedsiębiorstwa

Pakiet

strukturalne,

czynnościowe,

grupujące,

komentujące.

Elementy konstrukcyjne Elementy konstrukcyjne komentującekomentujące

76

Elementy komentujące odgrywają w UML rolę

objaśniającą. Są to adnotacje, których można użyć w celu

opisania, uwypuklenia lub zaznaczenia dowolnych

składników modelu. Podstawowym rodzajem tego typu

elementu jest notatka.

notatki

strukturalne,

czynnościowe,

grupujące,

komentujące.

77

Bloki konstrukcyjne związki

Związki są podstawowymi blokami

konstrukcyjnymi UML, służącymi do

łączenia elementów.

Zależność to związek znaczeniowy między dwoma

elementami.

SterownikGłówny

poziomAutoryzacji: int

+uruchom(): void +monitoruj() : void +zakończ() : void +podłącz() : void

Zmiany dokonane w definicji jednego z tych elementów (niezależnego) mogą

mieć wpływ na znaczenie drugiego (zależnego).

Iteratorkanałów

numerKanalu: int

+dodaj() : void -usuń() : void +przeglądaj() : void

„friend”

Zależność

Wyróżnia się łącznie 17

rodzaje zależności,

przykłady :

bind (powiązać),

derive (pochodzić z)

friend (zaprzyjaźniony)

instanceOf (przypadek)

…

send (wysłać)

trace (rejestrować)

zależność (ang. association)

dziedziczenie (ang. inheritance)

agregacja (ang. aggregation)

78

Bloki konstrukcyjne związki Nadklasa (przodek)

Dziedziczenie (uogólnienie)

to związek między

elementem ogólnym

(zwanym nadklasą lub

przodkiem) a pewnym

specyficznym jego rodzajem

(zwanym podklasą lub

potomkiem).

Podklasa (potomek)

Dziedziczenie także

nazywane związkiem

„jest-rodzajem„.

Potomek dziedziczy wszystkie właściwości

przodka, a w szczególności jego atrybuty i

operacje.

Jeśli klasa ma wielu przodków,

to mówimy o dziedziczeniu

wielobazowym.

zależność (ang. association)

dziedziczenie (ang. inheritance)

agregacja (ang. aggregation)

79

Bloki konstrukcyjne związki

Miano związku Nazwa

Agregacja

pracownik pracodawca

Role

Agregacja to związek strukturalny, który wskazuje,

że obiekty jednego elementu są połączone z

obiektami innego.

Agregacja może być

zastosowana nie tylko w tej

podstawowej formie, ale też

z czterema dodatkami: nazwa,

role

liczebność

rodzaj agregacji

zależność (ang. association)

dziedziczenie (ang. inheritance)

agregacja (ang.aggregation)

elementy pojęciowe

80

Bloki konstrukcyjne związki

Podanie ile obiektów może być połączonych przez

jeden egzemplarz powiązania nazywane liczebnością

roli powiązania.

Zapisuje się w postaci wyrażenia, którego wartością

jest przedział liczbowy lub pojedyncza liczba.

1…*

pracownik pracodawca

1

Liczebność można ustalić na dokładnie jeden (1), zero lub

jeden (0 . . 1), dowolnie wiele (0 . . *) albo co najmniej jeden

(1. . *). Może to być także pewna ustalona liczba

Bardziej złożone liczebności można określić za pomocą listy. Zapis 0..1, 3..4, 6..*

oznacza „dowolną liczbę obiektów inną niż 2 lub 5"

nazwa,

role

liczebność

rodzaj agregacji

zależność (ang. association)

dziedziczenie (ang. inheritance)

agregacja (ang.aggregation)

81

Może się jednak zdarzyć, że trzeba zapisać związek

„całość-część", w którym klasa reprezentuje

większy element („całość") składający się z

mniejszych („części").

Ten rodzaj związku nazywany agregacją,

wyrażony zależnością „ma":

obiekt-całość ma obiekty-części.

Samochód

Kierownica Kolo Silnik

1

4 Agregacja

całkowita

Okno

Ramka

Całość

Część

nazwa,

role

liczebność

rodzaj agregacji

Bloki konstrukcyjne związki

zależność (ang. association)

dziedziczenie (ang. inheritance)

agregacja (ang.agregation)

Agregacja

82

Diagram klas Przedsiębiorstwo (Class Diagram)

Notacja UML

Bloki konstrukcyjne diagramy

83

Projekt Farma

Diagram klas

84

Projekt Farma

Diagram sekwencji

85

Projekt Agencja

Diagram klas

86

Projekt Park Samochodów

Diagram klas

Diagramy czynnościDiagramy czynności (activities)(activities) używają się używają się do przedstawienia: do przedstawienia:

wysoko poziomowych procesów biznesowych

scenariuszy przypadków użycia,

procesów systemowych,

operacji,

algorytmów.

87

Diagramy czynności składają się z Diagramy czynności składają się z podstawowych elementów podstawowych elementów

czynności,

akcji

przepływu sterowania,

początku,

końca,

zakończenie przepływu

88

CzynnośćCzynność

89

Nazwa Notacja graficzna Definicja

Czynność Czynność to wykonanie pewnego procesu

Opracuj

repertuar

Zbadaj warunki

techniczne

Akcja

Nazwa Notacja graficzna Definicja

Akcja Akcja reprezentuje przetwarzanie informacji w

modelowanym systemie

n

i

iiiiiin ttfttS1

11 ][),()(

Przepływ

sterowania

Nazwa Notacja graficzna Definicja

Przepływ sterowania

Wskazuję kierunek

przekazywania sterowania po zakończeniu czynności lub

akcji.

Początek, koniec i zatrzymanie przepływu sterowania

Nazwa Notacja graficzna Definicja

Początek Punkty inicjacji, końca i zatrzymania

funkcjonowanie diagramu czynności. Może być więcej niż jeden punkt inicjacji, końca i zatrzymania .

Koniec

Zatrzymanie

Decyzja, złączenie i integracja przepływu sterowania

(nie synchronizowanego)

Nazwa Notacja graficzna Definicja

Decyzja Wybór przepływu sterowania określa warunek logiczny

Złączenie Złączenie nie ma funkcji

synchronizowania

Integracja decyzji i złączenia

[Warunek logiczny2]

[Warunek logiczny1] [Warunek logiczny3]

91

92

Decyzja, złączenie i integracja przepływu sterowania (nie synchronizowanego)

[a=true, b=true;]

a

b

c

[b=true, c=true;]

a

b

c

[a=true, b=true, c=true;]

a b c

a b c

abc

ab bc

93

Wybierz kwotę z

listy

Wprowadź inną kwotę

Weryfikuj stan konta

[kwota>200] [kwota niezdefiniowana]

Aktualizuj stan konta

Wyświetl odmowę

[else]

[kwota<=dotępne środki

Przykład zintegrowanego oznaczenia decyzji i złączenia

94

Rozwidlenie, scalenie i integracja przepływu sterowania procesów współbieżnych (synchronizowanych)

Nazwa Notacja graficzna Definicja

Rozwidlenie

Wybór przepływu sterowania określa warunek logiczny

Scalenie Złączenie ma funkcji synchronizowania

Integracja rozwidleni

a i scalenie

a b

{join Spec= a && b}

95

a b c

a b c

abc

ab bc

[clock]

[clock] a

a=1 a=0

[a=true]

a

[a=false]

[clock]

Rozwidlenie, scalenie i integracja przepływu sterowania procesów współbieżnych (synchronizowanych)

b a c

abc

b a c

ab bc

96

Notacja algorytmiczna

n

s=1; i=0;

s=s*i; i=i+1;

[i= =n;]

Wyświetl s

[i!=n;]

Notacja UML

Przykład diagramu czynności (obliczenie silni n!)

97

Opracowanie zamówienia

w dziale sprzedaży firmy

98

Założenie konta.

99

Diagramy maszyny stanowej

Maszyna stanowa służy do modelowania dynamicznych aspektów systemu.

Maszyna stanowa określa ciąg stanów przyjmowanych przez obiekt w

odpowiedzi na zdarzenia zachodzące z czasie jego życia, a także reakcje

obiektu na te zdarzenia

Maszyna stanowa służy do modelowania życia jednego obiektu, którym

może być egzemplarz klasy, przypadek użycia, a nawet system jako całość.

Maszyna stanowa służą do modelowania zachowania obiektu.

100

UML. Stany. Przejścia

Układ naprowadzenia

101

Słowa kluczowe:

entry wejście

exit wyjście

do wykonać

defer odroczyć

send wysłać

UML. Stany. Złożone elementy.

102

UML. Podstany sekwencyjne

Bankomat. Podstany.

Podstany sekwencyjne (Weryfikacja, Realizacja)

103

UML. Stany wznowienia

Stany płytkiego wznowienia. Litera H oznacza płytkie

wznowienie, to znaczy powrót do ostatniego aktywnego

podstanu w maszynie stanowej zagnieżdżonej. H*-

wznowienie głębokie.

maszyna stanowa

zagnieżdżona

104

Zagnieżdżona współbieżna maszyna stanowa nie ma stanu

początkowego, końcowego lub stanu wznowienia. Natomiast

podstany sekwencyjne jej stanów współbieżnych mogą takie

stany mieć

UML. Podstany współbieżne

105

UML . Modelowanie historii życia obiektu

Sterownik systemu alarmowego

1. Określ otoczenie maszyny stanowej

2. Ustal stan początkowy i końcowy

3. Określ zdarzenia

4. Zapisz stany

5. Zidentyfikuj akcji

6. Rozwiń stany złożone w podstanach

7. Uzgodnij zdarzenia a interfejsy

8. Wyeliminuj stany izolowane

106

Diagramy interakcji (sekwencyjne)

Modelowanie przepływu sterowania z uwzględnieniem kolejności

komunikatów w czasie.

Modelowanie przepływu sterowania z uwzględnieniem organizacji

strukturalnej obiektów

Inżynieria do przodu i wstecz (ang. reengineering)

107

Diagramy interakcji

Diagramy interakcji składają się z diagram sekwencji i diagram kooperacji,

służących do modelowania dynamicznych aspektów systemu.

Diagram sekwencji uwypukla kolejność komunikatów, którymi obiekty

wymieniają się na osi czasu.

Diagram kooperacji wyświetla organizację strukturalną obiektów

wymieniających się komunikatami.

Diagram sekwencji i kooperacji są miedzy sobą znaczeniowo

równoważne – można przekształcić jeden w drugi bez gróżby utraty

informacji.

108

Diagram interakcji obrazuje interakcje jako zbiór obiektów i związków między

nimi, w tym też komunikaty, jaki obiekty przekazują między sobą.

Diagram sekwencji jest diagramem interakcji, który ma postać tabeli,

w której obiekty są ułożone wzdłuż osi X, a komunikaty wzdłuż osi Y,

uporządkowane według czasu ich wydania.

Diagram kooperacji jest diagramem interakcji, na którym

przedstawione są związki strukturalne między obiektami

wysyłającymi i odbierającymi komunikaty. Graficznie to jest zestaw

wierzchołków i krawędzi.

109

Diagram sekwencji

linii życia,

ośrodek sterowania

„create”, „destroy”,

{transient}, (ang. Open Data Base Connectivity)

Wykonanie transakcji

110

Diagram kooperacji

Wykonanie transakcji nie ma linii życia,

nie ma ośrodków sterowania

„create”, „destroy”,

{transient}, „local”, „global”, ciąg komunikatów 2.1:, 2.2:

111

Diagram sekwencji (przebiegu). Nawiązanie połączenia telefonicznego

Iteracja reprezentuję ciąg

powtarzających

się komunikatów (znak *, lub

[i:=1..n])

Warunek logiczny [Time<30 sek.]

„copy”, „become”

{transient}

112

Diagram kooperacji. Rejestrowanie studentów na wykłady.

Składowe przepływu sterowania są ponumerowane jawnie.

113

Modelując dynamiczne aspekty systemu, diagramy interakcji używamy dla

osiągnięcia dwóch celów:

Modelowanie przepływu sterowania z uwzględnieniem kolejności

komunikatów w czasie. W tym przypadku wybieramy diagramy

sekwencji. Diagramy sekwencji są znacznie wygodniejsze niż diagramy

kooperacji do przedstawienia prostych iteracji i rozgałęzień.

Modelowanie przepływu sterowania z uwzględnieniem organizacji

strukturalnej obiektów. W tym przypadku wybieramy diagramy

kooperacji. Diagramy kooperacji są znacznie wygodniejsze niż diagramy

przebiegu do przedstawienia złożonych iteracji i rozgałęzień oraz wielu

współbieżnych przepływów sterowania.

114

Inżynieria do przodu (generowanie kodu na podstawie modelu).

Możliwa jest jak na podstawie diagramu sekwencji, jak i na podstawie diagramu

kooperacji:

Przykładowy kod dla operacji zarejestrujSię( ) klasy Student:

public void zarejstrujSię( ) {

ZestawWykładów w = odczytajPlanZajęć( );

for (int i =0; i< w.rozmiar( ); i++)

w.element (i).dodaj(this);

this.zarejestrowany = true; }

Inżynieria wstecz, jest znacznie bardziej skomplikowana.

Najtrudniejszym zadaniem jest selekcja tego, co powinno być utrwalone

w modelu.

PerspektywyPerspektywy 115

Perspektywa przypadkówPerspektywa przypadków

116

W perspektywie przypadków użycia bierze się pod uwagę zachowanie systemu, widziane oczyma: użytkowników, analityków, osób wykonujących testy.

Aspekty statyczne tej perspektywy wyraża się za pomocą: diagramów przypadków użycia, Aspekty dynamiczne za pomocą: diagramów interakcji, diagramów stanów diagramów czynności.

Perspektywa projektowaPerspektywa projektowa

117

Perspektywa projektowa opiera się na: klasy, interfejsy , kooperacje, które razem składają się na słownictwo danego zadania i na rozwiązanie tego zadania.

Aspekty statyczne tej perspektywy wyraża się za pomocą: diagramów klas diagramów obiektów, Aspekty dynamiczne za pomocą: diagramów interakcji, diagramów stanów, diagramów czynności.

Perspektywa procesowaPerspektywa procesowa

118

Perspektywa procesowa zwraca uwagę na: wątki i procesy, które kształtują mechanizmy współbieżności i synchronizacji w systemie. Dotyczy : efektywności, skalowalności, przepustowości systemu.

W UML aspekty statyczne i dynamiczne perspektywy procesowej są przedstawiane na takich samych diagramach jak w wypadku perspektywy projektowej. Główny aspekt to klasy, które reprezentują procesy i wątki.

Perspektywa implementacyjnaPerspektywa implementacyjna

119

Perspektywa implementacyjna opiera się na: komponenty, węzły, użyte do scalenia i udostępnienia systemu fizycznego. Wiąże się ona z zarządzaniem konfiguracją poszczególnych wersji systemu.

Aspekty statyczne tej perspektywy wyraża się za pomocą diagramów komponentów. Aspekty dynamiczne za pomocą: diagramów interakcji, diagramów stanów, diagramów czynności.

Perspektywa wdrożeniowaPerspektywa wdrożeniowa

120

W perspektywie wdrożeniowej główne elementy to: węzły składające się na sprzęt, na którym system będzie uruchamiany. Perspektywa wdrożeniowa wiąże się z: rozmieszczeniem dostarczeniem instalacją części systemu fizycznego.

Aspekty statyczne tej perspektywy wyraża się za pomocą: diagramów wdrożenia, Aspekty dynamiczne za pomocą diagramów interakcji diagramów stanów diagramów czynności

4. Zastosowanie UML4. Zastosowanie UML

121

ATM (Automated Teller Machine)

Tworzenie Apletów

Internet

Analiza procesów przejściowych

Symulacja automatów skończonych

Projektowanie sterowników

Przykład systemu sterowania Przykład systemu sterowania automatem ATMautomatem ATM

AUTOMATED TELLER MACHINE

Modelowanie systemy sterowania automatem bankowym

122

To są diagramy pomagające zrozumieć treść zadania i

opracować strukturę modelu.

Diagram wariantów wykorzystania

Diagram sekwencji (Sequence Diagram)

Diagram czynności (Activities Diagram )

Diagram klas (Class Diagram)

Klient

Diagram wariantów wykorzystania

123

Przekazać pieniądze

Położyć pieniądze na konto

Zmienić kod identyfikacyjny

Pobrać pieniądze z konta

Dokonać wypłatę

Tom:

Klient Czytnik

kartek

Ekran

ATM

Konto

Toma

Aparat

kasowy

1: Otrzymanie kartki przez urządzenie odczytu

2: Czytanie numeru kartki

3: Inicjalizacja ekranu

5: Zapytanie o numer rejestracyjny(PIN)

6: Wprowadzenie numeru rejestracyjnego(1234) 7: Sprawdzanie numeru rejestracyjnego

8: Zapytanie o transakcje

9: Wybór transakcji(otrzymanie )

10: Zapytanie o zapotrzebowanej sumie

11: Wprowadzenie zapotrzebowanej sumy(20$)

12: Zdejmowanie pieniądz z konta (20$)

13: Sprawdzanie sumy

14: Zmniejszenie stanu konta o 20$

15: Wydanie gotówki(20$)

17: Zwrot kartki do klienta 16: Wydanie czeku

Diagram sekwencji (Sequence Diagram) 124

5: Zapytanie o numer rejestracyjny

6: Wprowadzenie numeru rejestracyjnego (1234)

8: Zapytanie o transakcje

9: Wybór transakcji ( otrzymanie )

10: Zapytanie o zapotrzebowanej sumie

11: Wprowadzenie zapotrzebowanej sumy (20$)

1. Otrzymanie kartki przez urządzenie

odczytu.

2. Czytanie numeru kartki.

15. Wydanie gotówki (20$)

16. Wydanie czeku

17. Zwrot kartki do klienta

4. Otwieranie konta

7. Sprawdzanie numeru rejestracyjnego

12. Zdejmowanie pieniądz z konta

13. Sprawdzanie sumy

14. Zmniejszenie stanu konta 3. Inicjalizacja ekranu

Diagram kooperacji (Cooperation Diagram ) 125

Klient Ekran

ATM

Aparat

kasowy

Konto

klienta Urządzenie do

czytania

kartek

Klasy projektu ATMKlasy projektu ATM

126

CzytnikKart

numerKarty

czytanieKarty() akceptacjaKarty() zwrotKarty()

EkranATM

…

akceptacja() prompt()

AparatKasowy

bilansWypłaty

wydanieGotówki() wydanieCzeku() zwrotKarty()

Notacja UML

Konto

numerKonta pin bilans

otwieranieKonta() odtwarzanieKonta() zmianaKonta() sprawdzanieKonta()

Nazwa klasy

Atrybuty klasy

Operacji (funkcji) klasy

Nazwa klasy

Atrybuty klasy

Operacji (funkcji) klasy

127

127

CzytnikKart

numerKarty

czytanieKarty() akceptacjaKarty() zwrotKarty()

EkranATM

…

akceptacja() prompt()

AparatKasowy

bilansWypłaty

wydanieGotówki() wydanieCzeku() zwrotKarty()

Notacja UML

Konto

numerKonta pin bilans

otwieranieKonta() odtwarzanieKonta() zmianaKonta() sprawdzanieKonta()

Diagram klas (Class Diagram)

128

Diagram klas obiektów (przykład notacji)Diagram klas obiektów (przykład notacji)

129

import java.awt.Graphics;

class HelloWorld extends java.applet.Applet

{

public void paint (Graphics g) {

g.drawString ("Hello, World!", 10, 10);

}

}

Pisząc w pierwszym wierszu

import java.awt.Graphics;

sprawiamy, że w dalszej części programu można bezpośrednio używać klasy

Graphics. Przedrostek java.awt określa pakiet Javy, w którym tę klasę

zdefiniowano.

awt (The Abstract Window Toolkit)

Projektowania Apletu WWW

Pisząc w drugim wierszu:

class HelloWorId extends java.applet.Applet { }

wprowadzamy nową klasę o nazwie HelloWorld i określamy,

że jest to potomek klasy Applet zdefiniowanej w pakiecie java. Applet.

Pisząc w następnych trzech wierszach:

public void paint (Graphics g) {

g.drawString ("Hello, World!", 10, 10);

}

deklarujemy operację paint i tworzymy obiekt g klasy Graphics.

Dalej zostaje wywołana operacja drawString( ) na korzyść obiektu

g klasy Graphics odpowiedzialna za wyświetlenie "Hello, World! "

w miejscu o podanych współrzędnych.

130

Na tym diagramie klas są przedstawione podstawowe elementy

programu „Hello, World!", ale brakuje innych - niemniej ważnych.

131

klasa notatka

Klasa HelloWorld jest liściem w większej hierarchii klas w Javie.

Klasa Object jest klasą macierzysta (przodkiem) dla wszystkich klas

zdefiniowanych w Javie.

ImageObserver jest w bibliotece Javy interfejsem. Interfejs jest w UML

obrazowany jako okrąg. Fakt implementacji przez klasę Component

interfejsu ImageObserver jest przedstawiony w postaci linii ciągłej. 132

Główny pakiet w środowisku Javy ma nazwę java.

Klasa Applet składowa pakietu applet.

Klasy Panel, Container i Component są składowymi pakietu awt.

Interfejs ImageObserver jest zdefiniowany w pakiecie image, który jest

elementem pakietu awt, ścieżka dostępu:

java.awt.image.ImageObserver.

Klasa Object to element pakietu lang, ścieżka dostępu:

java.lang.Object. 133

Diagram sekwencji W UML egzemplarze klas są przedstawiane tak samo jak klasy, tylko ich

nazwy są podkreślone.

Obiekt klasy Thread uruchamia (run )obiekt klasy Toolkit.

Obiekt klasy Toolkit uruchamia operacje callbackLoop.

Operacja callbackLoop uruchamia operacje handleExpose obiektu

ComponentPeer.

Obiekt ComponentPeer wywołuje operację paint.

Pierwsze trzy obiekty na tym diagramie są anonimowe, nie maja

unikatowej nazwy. Obiekt klasy HelloWorld ma nazwę target.

Start

134

Diagram Komponentów

Do modelowania struktury komponentów służy diagram komponentów.

Komponent hello.java reprezentuje kod źródłowy klasy HelloWorld.

Kompilator Javy transformuje aplet do postaci binarnej HelloWorld.class .

Wirtualna maszyna interpretuje kod w postaci binarnej.

Symbol, przedstawiający aplet binarny HelloWorld.class jest wariantem symbolu

komponentu.

Symbole komponentów hello.java , hello.html, hello,jpg są niestandardowe,

przedstawione ikonami z napisami. 135

symboli niestandardowe

(rozszerzenie notacji UML!)

W programie są używane jeszcze dwie klasy: Applet i Graphics.

Klasa Applet jest przodkiem klasy HelloWorId, a klasa Graphics

występuje w sygnaturze oraz implementacji operacji paint.

Strzałka z niewypełnionym grotem, od HelloWorId do Applet, przedstawia

dziedziczenie, które w tym wypadku oznacza, że HelloWorId jest potomkiem klasy

Applet. Przerywana strzałka od HelloWorld do Graphics obrazuje związek

asocjacyjny , który polega na tym, że HelloWorld korzysta z klasy Graphics. 136

Sygnatura-

Nazwa

operacji

wraz z jej

parametrami

Implementacja-

definicja sposobu

tworzenia lub

wyliczania czegoś

uogólnienie zależność

(korzystanie z klasy Graphics)

137

Projektowania Apletu WWW. Dział firmy programistycznej

Diagram klas

138

internaut

Internet. Diagram wariantów wykorzystania.

Wysłać e-mail

Wykonać rozmowę Pobrać e-mail

Oglądać stronę WWW

Wysłać plik,

Pobrać plik

{POP-3}

{FTP} {HTTP}

{VoIP}

{SMTP}

{RTP}

{RTSP}

Real Time Streaming Protocol

Voice over Internet Protocol

139

Warstwy i ProtokołyWarstwy i Protokoły

140

W metodzie bezpołączeniowej nadajnik przyjmuje założenie, że

odbiornik otrzyma poprawnie przesyłaną informację.

Odbiornik musi poinformować nadajnik o tym, że część datagramów nie

dotarła lub są uszkodzone i zażądać ich powtórzenia oraz odtworzyć

właściwą kolejność datagramów

Typy protokołów: Bezpołączeniowe (IP, UDP) i Połączeniowe (TCP)

W metodzie połączeniowej między dwoma węzłami sieciowymi ustanawiany jest

kanał komunikacyjny. W czasie transmisji węzły pozostają ze sobą w stałym

kontakcie.

Protokół TCP służy do przekazywania informacji w sieci Internet na poziomie

warstwy transportowej modelu OSI.

141

HE

X

00

: 0

F

10

: 1

F

20

: 3

F

40

: 5

F

60

: 6

7

68

: 6

9

6A

6B

6C

6D

6E

6F

70

: 7

F

80

: 8

F

90

: 9

F

A0

: …

…

…

ZN

AC

ZE

NIE

PO

RT

ŻR

ÓD

ŁO

WY

PO

RT

P

RZ

EZ

NA

CZ

EN

IA

NU

ME

R S

EK

WE

NC

JI

NU

ME

R P

OT

WIE

RD

ZE

NIA

DŁ

UG

OŚ

Ć N

AG

ŁÓ

WK

A

RE

ZE

RW

A

FŁAGI

RO

ZM

IAR

OK

NA

SU

MA

KO

NT

RO

LN

A

PR

IOR

YT

ET

OP

CJ

I (J

EŻ

EL

I S

Ą)

DA

NE

F

I

N

S

YN

RS

T

P

SH

A

CK

U

RG

Nagłówek protokołu TCP

Protokół TCP służy dla przekazywania segmentu danych miedzy gniazdem (ang.

Socket) hostu Nadawcy i gniazdem hostu Odbiorcy. Dla adresowania i sterowania

procesem przekazywania danych protokół posługuje się nagłówkiem. Nagłówek

składa się z pól.

142

Tryby pracy:

• Nawiązywanie połączenia

• Realizacja połączenia

• Zakończenie połączenia

TCP (Transport Control Protocol)

Host A w pierwszym segmencie nadaje sygnał sterujący <CTL=SYN>, za

pośrednictwem pola flagi SYN i nadaje numer w polu numer sekwencji <SEQ=100>

mówiący o tym, że będzie zaczynał nadawać oktety danych zaczynając od numeru

np. 100 (ISN) ze strumienia oktetów danych, przygotowanych do nadawania.

Host B otrzymując segment z ustawioną flagą SYN przechodzi w stan <SYN-

RECEIWED> mówiącym o tym, że on zaakceptował sygnał SYN. W odpowiedź

Host B przygotowuję segment z ustawionymi w 1 flagami SYN i ACK

<CTL=SYN,ACK> mówiącymi o tym, że Host B zaakceptował sygnał SYN

nadawcy ustawiając flagę ACK w 1 i wysyła własny sygnał SYN.

Nawiązywanie połączenia Hostu A z Hostem B

143

STAN TCP A FRAGMENT SEGMENTU / KIERUNEK STAN TCP B

CLOSED LISTEN

SYN-SENT <SEQ=100><CTL=SYN> SYN-RECEIVED

ESTABLISHED <SEQ=300><ACK=101><CTL=SYN,ACK> SYN-RECEIVED

ESTABLISHED <SEQ=101><ACK=301><CTL=ACK> ESTABLISHED

ESTABLISHED <SEQ=101><ACK=301><CTL=ACK><DATA>

ESTABLISHED

Sekwencja sygnałów przy nawiązywaniu połączenia TCP

144

ProtocolTCP class, SocketTCP class

145

TCP Flag class

146

x2x3 z=~(x0x1)x2x3

x0

x1

x2

x3

x ~x

B A C

~ (x0x1)

z

Modelowania procesów przejściowych w układach kombinacyjnych

147

realny proces ustawienia sygnału wyjściowego C

wartość

napięcia

progowego

sygnał wyjściowy C

sygnał wejściowy A

B

148

t

+60%

e)

-60% UB

UB

UB

τ10 τ01

τ01 τ10

A2 UA1

UA2

Ѳ

0

0

0

0

c)

A1

A2

A1 B

a)

τ01 τ10

Ѳ

+60%

-60%

t

d)

b)

UB

UB

UB

A2 A1 UA1

UA2

0

0

0

0

Fig. 2

Procesy przejściowe wyścigowe

149

Ub(t)+ U

T

Ua(t)- U

[Ua(t)]

[UP]

[UP]

Określ warunki

[Ua(t)=1, Ub(t)=0, a=1, b=0, t=0, U, T]

[Ub(t)]

[Ua(t) <UP] [a=0]

[c=1]

[Ub(t) < UP] [b=0]

[Ua(t) > UP] [a=1]

[T0]

Ua(t)

Ub(t) Uc(t)

[Ub(t) > UP] [b=1]

Suma T Diagram czynności. Modelowanie procesu przejściowego w

bramce logicznej AND

[ T&c]

[∑ T]

[UP]

150

Diagram klas: BramkaLogiczna

151

Diagram klas. Proces przejściowy

152

Diagramy maszyny stanowej

q0/t0

q2/t2 q1/t1

x0

x0

x2

x0

x1 x1 x2

x2

Symulacja automatów skończonych

153

Termostat.

Diagram maszyny stanowej

Sterownik układu klimatyzacji

154

154

Termostat. Kodowanie.

kodowanie

stany

bezczynność q0

chłodzenie q1

grzanie q2

kodowanie

wejścia

temperaturaOK x0

zaCiepło x1

zaZimno x2

155

kodowanie

stany

bezczynność q0

chłodzenie q1

grzanie q2

kodowanie

wejścia

temperatura OK

x0

zaCiepło x1

zaZimno x2

wejścia stany

x0 x1 x2 wyjścia

q0 q0 q1 q2 t0

q1 q0 q1 q2 t1

q2 q0 q1 q2 t2

q0/t0

q2/t2 q1/t1

x0 x0

x2

x1

x0

x1 x1 x2

x2

Graf. Diagram stanów Tablica przejść-wyjść

Termostat.

156

156

Termostat. Tablica przejść-wyjść

kodowanie

podstany

czuwanie q3

rozpalanie q4

ogrzewanie q5

wyłączanie q6

kodowanie

wejścia

x3 x4

czuwaj (1) 0

włącz (1) 0

grzej (1) 0

wyłącz (1) 0

czuwanie

rozpalanie

ogrzewanie

wyłączanie

włącz

grzej wyłącz

czuwaj

157

czuwanie

rozpalanie

ogrzewanie

wyłączanie

włącz

grzej wyłącz

czuwaj

wejścia stany

x3 x4 wyjścia

q3 q4 q3 t3

q4 q5 q4 t4

q5 q6 q5 t5

q6 q3 q6 t6

kodowanie

podstany

czuwanie q3

rozpalanie q4

ogrzewanie q5

wyłączanie q6

kodowanie

wejścia

x3 x4

czuwaj (1) 0

włącz (1) 0

grzej (1) 0

wyłącz (1) 0

q3/t3

q4/t4

1 1

0

0

Graf, diagram stanów

q5/t5

q6/t6

1

0

0

Notacja UML

Termostat.

x1

x2

x3

A

B z = f(x1, x2, x3 )

z

Projektowanie sterownika poziomu.

Jest rezerwuar dla wody R. On ma dwa zawory A i B.

A to jest zawór do wpływu wody a zawór B dla odpływu.

Trzeba zaprojektować system sterowania zaworem A

tak ażeby w nocy był utrzymywany poziom wody x1 ,

a w dzień poziom x2 . Odpływ przez zawór B jest mniejszy niż dopływ przez

zawór A.

Stan zaworu A

z

zamknięty 0

otwarty 1

Pora doby

x3

noc 0

dzień 1 R

158

Kodowanie

x

3 x

2 x

1 z

0 0 0 1

0 0 1 0

0 1 0 0

0 1 1 0

1 0 0 1

1 0 1 1

1 1 0 0

1 1 1 0

x1

x2

x3

1

0

f(x1, x2, x3 ) = ~x1 ~ x2 ~ x3 +

~x1 ~ x2 x3 +

x1 ~ x2 x3

A

B

z = f(x1, x2, x3 ) z

R

159

Koniukcja Alternatywa

x * x = x x + x = x

x * ~x = 0 x + ~x = 1

x * 0 = 0 x + 0 = x

x * 1 = x x + 1 = 1

Własności

f(x1, x2, x3 ) = ~x1 ~ x2 ~ x3 + ~x1 ~ x2 x3 + x1 ~ x2 x3 =

~x1 ~ x2 (~ x3 + x3) + x1 ~ x2 x3 = ~x1~ x2 + ~ x2 x3 =

= ~x2 *(~ x1 + x3) 1

160

161

0

~x1 1 x1

0 0 ~x3~

x2

1 0

0 1 ~x3 x2

0 0

1 1 x3x2

0 0

1 0 x3 ~x2

1 1

x3 x2 x1 z

0 0 0 1

0 0 1 0

0 1 0 0

0 1 1 0

1 0 0 1

1 0 1 1

1 1 0 0

1 1 1 0

1

2

2

x3 ~x2~x1

x3 ~x2 x1

x3 ~x2

1 ~x3 ~x2~x1

x3 ~x2 ~x1

~x2 ~x1

2

f(x1, x2, x3 ) x2

x1

x3 z

f(x1, x2, x3 ) = ~x2 (~ x1 + x3)

x2

x1

x3

~x1

~x2

(~ x1 + x3)

z = ~x2 (~ x1 + x3)

Układ modelowania funkcji sterującej

z

162

x1

x2

A

B

z

Stan zaworu A z

zamknięty 0

otwarty 1

Pora doby x3

noc 0

dzień 1

f(x1, x2, x3 ) x3

Układ sterowania

R czujniki poziomu

163

164

Układ sterowania. Tablica przejść-wejść

kodowanie

stany zawora A

otwarty q0

(1)

zamknięty

q1

(0)

kodowanie

wejścia

zamknij 0

otwórz 1

wejścia stany

0 1 wyjścia

q0 q0 q1 1

q1 q1 q0 0

q0 /1

q1 /0

1

0

1

0

[f(x1, x2, x3 )]

warunek dozoru

zdarzenie uruchamiające

akcja

G. Booch

UML

Przejścia Automat Moore’a

5. Technika modelowania 5. Technika modelowania CRC CRC

( ang. ( ang. classclass--responsibilityresponsibility--collaboration cardscollaboration cards))

165

166

Gra Black Jack powstała we Francji na początku XVIII wieku.

Kronika gry:

1956r. – pierwsze próby zwyciężenia w BackJacku poprzez matematyczne

podejścia do gry.

Roger Baldwin, opublikował artykuł „Optymalna Strategia BlackJacka”.

1962r. – powstaje pierwsza strategie liczenia kart. Zaproponowana była

przez profesora Edwarda O. Thorp’a.

1963r. - Książka Edwarda O. Thorp’a „Beat the Dealer: Strategy for the

Game of Twenty-One” staje się bestsellerem i sprawia, że wiele kasyn

zmienia reguły gry.

1970r. – powstanie pierwszej strategii komputerowej gry BlackJack

Matematyczne podstawy gry Black Jack

167

Wartości punktowe:

król, dama, walet i dziesiątka mają po dziesięć punktów;

as ma 1 punktów lub 11 w zależności od sytuacji (As może mieć

wartość równa jedenastu punktów tylko wtedy, gdy gracz nie

przekroczy limitu 21 punktów. W momencie, gdy gracz przekroczył

określony limit, As ma wartość w jeden punkt);

karty od 2 do 9 mają wartość równą wartości karty

Liczenie kart ( metoda Hi-Lo) – obecnie najbardziej

rozpowszechniona i najczęściej stosowana metoda.

• karty 2,3,4,5,6 mają wartość +1

• karty 7,8,9 mają wartość 0

• karty 10, walet, dama, król, as mają wartość (-1) W ten sposób

gracz otrzymuje tzw. wartość bieżącą, lub prawdziwą

Matematyczne strategii gry

168

Strategia krupiera:

polega na takim dobieraniu kart, aby liczba oczek wynosiła nie

więcej, ani nie mniej niż 17.

Wtedy przewaga kasyna jest równa 5.48%.

Strategia „bez fury” – bardzo zbliżona do strategii krupiera, jednak tutaj

liczba oczek jest równa 11, a przewaga kasyna ma wartość 3.91%.

Strategia podstawowa - zmniejsza przewagę kasyna do 0,5%

Po otrzymaniu dwóch pierwszych kart, gracz decyduje, czy powinien on brać

dodatkowe karty.

Krupier musi brać dodatkowe karty w każdym przypadku, jeśli ma karty o

łącznej wartości mniej niż 17.

169

Celem projektu jest implementacja gry karcianej w BlackJack.

W grze tej gra się przeciwko krupierowi. Liczba graczy jest

dowolna, ale nie grają oni przeciwko sobie, a wyłącznie

przeciwko krupierowi.

Gra Black Jack

Krótki opis gry

Celem gracza jest uzbieranie takiej sumy wartości kart, które dobiera

kolejno z talii, aby była jak najbliższa 21 (idealnie równa 21). Suma nie

może jednak przekroczyć tej wartości. Jeśli tak się stanie, gracz przegra.

Jeśli suma dwóch pierwszych kart, które gracz pobierze, wyniesie 21,

nazywa się to BlackJackiem. Każda karta ma określoną wartość (nie ma na

nią wpływu kolor). Wartość asa to 11. Wszystkie figury maja wartość 10.

Pozostałe karty mają wartości odpowiadające ich rodzajowi.

170

Zadania krupiera są

podawanie graczom kolejnych kart,

pokazywanie części lub wszystkich kart,

obliczanie wartości kart na ręku,

sprawdzanie liczby kart na ręku,

określanie wygrywającego oraz rozpoczynanie nowej partii.

Zgodnie z zasadami gry gracz wygrywa i zabiera pulę zakładów wówczas,

gdy suma wartości jego kart jest bliższa 21 niż suma krupiera. Jeśli gracz

ma BlackJacka, zgarnia pulę w wysokości 3:2 oryginalnego zakładu

(zakładając, że krupier nie ma BlackJacka). Jeśli suma wartości kart

gracza przekroczy 21, gracz przegrywa. BlackJack (as i figura lub

dziesiątka) bije inne kombinacje kart, które dają sumę 21.

171

znać swoją wartość

dzielić się informacją o swojej wartości

znać swój kolor

należeć do talii

Zadania karty są

żądać kolejnej karty

umieć sprawdzać jaką kartę otrzymał od krupiera

umieć obliczać wartości kart na ręku

znać ile ma aktualnie kart na ręku.

decydować czy podać następną kartę, czy zacząć nową partię.

Zadania gracza są

Zadania ręki są

znać , ile ma kart.

znać wartość posiadanych kart.

pokazywać karty.

172

Zadania talii są

umożliwiać podawanie kolejnych kart

informować o tym, ile jeszcze kart zostało nierozdanych.

tasowanie kart.

Wytyczne do projektu: interesuje nas tylko to, co system robi, a nie jak to robi.

Jedną z najpopularniejszych metod identyfikacji i kategoryzowania klas jest

użycie kart CRC (ang. class-responsibility-collaboration cards). Każda taka

karta reprezentuje zadania i kolaboracje jednej klasy.

Każda karta CRC powinna być podzielona na trzy sekcje:

• nazwa klasy,

• zadania klasy,

• kolaboracje klasy.

173

Karta CRC

Klasa: Gracz

Zadania klasy: Kolaboracje klasy:

Zacznij nową grę Ręka, Krupier

Daj kartę Krupier

Każda karta powinna być podzielona na trzy sekcje:

• nazwa klasy,

• zadania klasy,

• kolaboracje klasy.

174

Identyfikacja klas gry w BlackJacka

Rzeczowniki

Rzeczowniki zazwyczaj określają klasy ale nie są jedynym ich źródłem

Gra

Blackack

Krupier

Gracze

Gracz

Karty

Karta

Talia

Ręka

Wartość

Kolor

As

Figura

Król

Dama

Walet

Gra

Zakład

175

Gra — nazwa gry to BlackJack. A więc będziemy ją traktować tak samo jak

rzeczownik BlackJack.

Blackjack — w tym przypadku uznajemy, że utworzymy klasę Gra, która tutaj

jest synonimem rzeczownika BlackJack.

Krupier — ponieważ bez krupiera nie można się obejść, zostawimy go.

Gracze i Gracz — gracze są potrzebni, a więc klasa ta jest niezbędna. Powinna

ona jednak reprezentować jednego gracza, a nie grupę graczy. Pozostawiamy

Gracz.

Karty i Karta — komentarz taki sam jak dla gracza.

Tal ia — ponieważ jest wiele czynności właściwych talii (np. tasowanie i

pobieranie kart), uznajemy, że jest to dobry pomysł na klasę.

Ręka — każdy gracz będzie miał określony zestaw kart, zatrzymamy tę klasę.

Wartość — wartość karty najlepiej zaprezentować w postaci atrybutu klasy.

Kolor — w grze w BlackJacka nie trzeba znać koloru karty. Może być

atrybutem klasy Karta.

Identyfikacja klas

176

As — figurę lepiej zdefiniować jako atrybut klasy Karta.

Figura — figurę lepiej zdefiniować jako atrybut klasy Karta.

Król — króla lepiej zdefiniować jako atrybut klasy Karta.

Dama — damę lepiej zdefiniować jako atrybut klasy Karta.

Zakład —dobrym pomysłem jest wyodrębnienie zakładu jako osobnej

klasy, ponieważ postawić w grze można różne rzeczy. Można postawić

pieniądze, paczkę chipsów, zegarek, konia, a nawet akt własności domu.

Identyfikacja klas

Karta Talia Ręka

Krupier Gracz Zakład

Początkowy zestaw klas dla gry BlackJack

177

Zadania klasy odpowiadają działaniom, które ona wykonuje. Listę zadań

można sporządzić na podstawie czasowników użytych w oświadczeniu

podsumowującym wymagania.

Identyfikowanie zadań klasy

Czasowniki dla określenia zadania poszczególnych klas:

Karta

Zna swoją wartość.

Zna swój kolor.

Wie, czy jest figurą.

Wie, czy jest asem.

Talia

Tasowanie kart.

Udostępnianie kart.

Wie, ile kart zostało do rozdania.

Wie, czy jest pełna, aby zacząć nową grę.

178

Ręka

Wie, ile ma kart.

Zna wartość posiadanych kart.

Pokazuje karty.

Identyfikowanie zadań klasy

Krupier

Rozdaje karty.

Zleca tasowanie kart.

Podaje karty graczom.

Pokazuje swoje karty na ręku.

Oblicza wartość kart.

Zna liczbę kart na swoim ręku.

Żąda kart (pobiera lub nie).

Decyduje, kto wygrał.

Zaczyna nową partię.

179

Gracz

Żąda kart (pobiera lub nie).

Pokazuje swoje karty na ręku.

Oblicza wartość kart na ręku.

Wie, ile ma kart na ręku.

Wie, czy wartość kart na ręku jest wyższa od 21.

Wie, czy wartość kart na ręku jest równa 21 (i czy jest to BlackJack).

Wie, czy wartość kart na ręku jest niższa od 21

Identyfikowanie zadań klasy

Zakład

Wie, jaki to jest rodzaj zakładu.

Zna bieżącą wartość zakładu.

Wie, ile gracz postawił.

Wie, czy zakład może zostać pokryty.

180

Analiza szczegółowa wymienionych zadań:

Karta

Zna swoją wartość (wyświetlanie wartości karty).

Zna swój kolor (wyświetlanie koloru).

Wie, czy jest figurą. (to samo można osiągnąć za pomocą zwracania

wartości).

Wie, czy jest asem (podobnie jak powyżej).

Talia

Tasowanie (talia musi dać się potasować).

Rozdawanie kart (musi być możliwość rozdawania kart graczom).

Wie, ile kart zostało do rozdania (krupier musi wiedzieć, czy zostały mu jeszcze

jakieś karty do rozdania).

Wie, czy jest pełna, aby zacząć nową grę (talia musi wiedzieć, czy jest pełna).

181

Ręka

Wie, ile ma kart (informacja o liczbie kart na ręku).

Zna wartość posiadanych kart (informacja o wartości kart na ręku).

Pokazuje karty.

Identyfikowanie zadań klasy

Zakład

Wie, jaki to jest rodzaj zakładu.

Zna bieżącą wartość zakładu.

Wie, ile pieniędzy graczowi zostało.

Wie, czy zakład może zostać pokryty.

Informacja ta jest potrzebna, aby

znać, jaka jest aktualnie pula

zakładu.

Informacja ta pozwala krupierowi

zorientować się, czy gracz ma

wystarczającą ilość środków, aby

pokryć zakład.

Gracz nie będzie mógł

postawić więcej, niż ma.

Gracz musi mieć możliwość obejrzenia kart,

które ma na ręku.

182

Krupier

Zleca tasowanie kart.

Rozdaje karty.

Podaje karty graczom.

Pokazuje swoje karty na ręku.

Oblicza wartość kart krupiera (pokazywanie wartości kart na ręku krupiera).

Zna liczbę kart na swoim ręku (pokazywanie liczby kart na ręku krupiera).

Żąda kart (pobiera lub nie).

Decyduje, kto wygrał.

Zaczyna nową partię.

Identyfikowanie zadań klasy

Gracz

Żąda kart (pobiera lub nie).

Pokazuje swoje karty na ręku.

Oblicza wartość kart na ręku (pokazywanie wartości kart gracza).

Wie, ile ma kart na ręku (pokazywanie liczby kart na ręku gracza).

Wie, czy wartość kart na ręku jest wyższa, równa, czy niższa od 21

(generowanie raportu o wartości kart na ręku).

183

-Breaking hand – układ kart, którego suma równa się 12

- Bust ( fura) – przekroczenie 21 oczek – przegrana

- Double down – podwojenie stawki

- High-Low – najpopularniejsza metoda liczenia kart

- Hit – dobrać kartę

- Pass – nie dobierać karty

- Pat hand – układ kart, którego suma wynosi 17 ( lub więcej)

- Remis – ma miejsce, gdy wartość kart gracza jest równa wartości kart krupiera

- Soft hand – układ kart, gdzie występuje as, lecz suma oczek po otrzymaniu kart

nie wynosi więcej niż 21

- Stach – pula żetonów, które znajdują się przed graczem

- Upcard – odsłonięta karta

- Wartość bieżąca (ręki)– występuje, gdy jest ona wyższa niż 0

- Wartość prawdziwa – podzielenie wartości bieżącej przez sumę pozostałych do

rozdania w talii.

Słowniczek

184

Przypadki użycia w UML — identyfikowanie kolaboracji

Do zidentyfikowania kolaboracji można wykorzystać scenariusze

przypadków użycia.

Przypadek użycia (ang. use-case) to transakcja lub sekwencja

wzajemnie powiązanych operacji, które system wykonuje w

odpowiedzi na żądanie użytkownika lub jakieś zdarzenie

Dla każdego przypadku użycia należy zidentyfikować obiekty i komunikaty.

Karty CRC pomagają w określeniu zestawu klas.

Scenariusze przypadków użycia pomagają w odkrywaniu kolaboracji.

185

Gracz

Diagram wariantów wykorzystania

185

Karta CRC

Gracz ma BJ,

Krupier ma BJ

Remis

Gracz ma BJ,

Krupier ma K < 21

Gracz wygrywa

Krupier ma BJ,

Gracz ma G < 21

Gracz przegrywa

Gracz ma G < 21,

Krupier ma K < 21

G > K

Gracz wygrywa

Gracz ma G < 21,

Krupier ma K < 21

G < K

Gracz przegrywa

Gracz ma G < 21,

Krupier ma K < 21

G = K

Remis

186

Krupier i jeden gracz. Przykład

•Krupier zleca tasowanie kart.

• Gracz robi zakłady.

• Krupier rozdaje po jednej karcie.

• Gracz dodaje kartę do swojej ręki.

• Krupier dodaje kartę do swojej ręki.

• Ręka zwraca graczowi wartość znajdujących się w niej kart.

• Ręka zwraca krupierowi wartość znajdujących się w niej kart.

• Krupier pyta, czy gracz chce kolejną kartę.

• Krupier daje graczowi kolejną kartę.

• Gracz dodaje kartę do swojej ręki.

• Ręka zwraca graczowi wartość znajdujących się w niej kart.

• Krupier pyta, czy gracz chce kolejną kartę.

• Gracz nie bierze więcej kart.

• Krupier dodaje karty do swojej ręki.

• Ręka zwraca krupierowi wartość znajdujących się w niej kart.

• Krupier decyduję, czy chce kolejną kartę.

• Krupier odbiera wartość kart na ręku gracza.

• Krupier decyduje o tym kto przegrał.

• Krupier wysyła do gracza wartość zakładu lub jej od niego żąda.

Przebieg gry:

187

Rozpoczęcie gry

Program Krupier

Diagramy kolaboracji

StartNewGame

Załóżmy, że mamy jedną główną aplikację, która zawiera wszystkie

obiekty (tzn. nie ma klasy Game).

Zgodnie z założeniami projektowymi grę rozpoczyna krupier.

188

Tasowanie i rozdanie pierwszych kart

Krupier Talia resetDesk

Krupier Talia shuffledDesk

Krupier Gracz moreCards

189

Sprawdzanie wartości kart na ręku Gracza

Gracz Ręka

getHandValue( )

returnValue( )

Krupier Talia getCard

returnCard

Pobranie karty z Talii

Gracz Krupier getCard

190

Krupier Gracz

Wydanie kolejnej karty, dopóki Gracz nie spasuje.

Gracz Ręka getHandValue( )

returnValue( )

getCards()

191

Krupier Ręka getHandValue( )

returnValue( )

Krupier gra do swoją rękę

Gracz Krupier playerPass

192

Krupier Talia getCard

returnCard

Wydanie Krupierowi karty na żądanie

Krupier Ręka getHandValue

returnValue( )

Czy Krupier pasuje?

193

Krupier Gracz krupierPass

Krupier Gracz getValueCards

Krupier pasuje i prosi podać wartość kart na Ręku Gracza

Gracz Ręka returnValue( )

194

Krupier Gracz

Krupier Gracz playerWiner

returnValue( )

Krupier porównuje wartości kart na swojej Ręki i na Ręki Gracza.

Krupier Gracz transferFacility

Krupier decyduje o wygraniu Gracza.

195

Krupier Gracz playerBusts

Krupier Gracz getFacility

Krupier decyduje o przegraniu Gracza.

196

Mając określony początkowy zestaw klas i kolaboracji, można

przystąpić do wypełniania kart CRC dla tych klas.

Analiza kart CRC

Klasa: Karta

Zadania (ang. Responsibility): Współpraca (ang. Collaboration)

Pobierz nazwę Talia

Pobierz wartość

197

Klasa: Talia

Zadania (ang. Responsibility): Współpraca (ang. Collaboration)

Reset Talii Krupier

Sprawdź rozmiar Talii Krupier

Pobierz kolejną kartę Krupier

Potasuj talię Krupier

Sprawdź wartość prawdziwą Talii Karta

Klasa: Krupier

Zadania (ang. Rresponsibility): Współpraca (ang. Collaboration)

Zacznij nową grę Ręka

Podaj kolejną kartę Gracz

Pobierz kolejną kartę Talia

198

Klasa: Gracz

Zadania (ang. Rresponsibility): Współpraca (ang. Collaboration)

Chcę kolejną kartę? Ręka

Pobierz kolejną kartę Krupier

Pokarz kartę Ręka

Pokarz karty Krupier

Sprawdź wartość kart na Ręku Ręka

Klasa: Ręka

Zadania (ang. Rresponsibility): Współpraca (ang. Collaboration)

Zwróć wartość Gracz, Krupier

Dodaj kartę Gracz, Krupier

Pokarz kartę Gracz, Krupier

Pokarz karty Krupier

Diagram klas (Class Diagram)

199

Gracz

limit:int

+moreCard:boolean +showHand:void +getHandValue:int +getCard():Krupier +playerBusts():boolean +playerPass():boolean

Notacja UML

Reka

-value:int -hand:vector

+getValue:int +addToHand:void +showHand:void

Krupier

+startNewGame:void +getCard:Card +krupierPass():boolean +getFacility():int +krupierBust():boolean Karta

-name:string -value:int

+get Name:string +getValue:int +setName:void +setValue:void

Talia

-cards:vektor -shufledCards:vektor random:Random

+resetDesk:void +getDeskSize:int +getNextCard:Card +shuffledDesk:void +showDesk:void +showShuffledDesk:void +setSuit:void Reka RekaK = new Reka();

Reka RekaG = new Reka();

Java, C#

200

Diagram klas (Class Diagram)

Gracz

-limit:int

+moreCard:boolean +showHand:void +getHandValue:int +getCard():Krupier +playerPass():boolean +playerBusts():boolean

Reka

-value:int -hand:Vector

+getValue:int +addToHand:void +showHand:void

Krupier

-limit:int

+startNewGame:void +getCard:Card +krupierPass():boolean +getFacility():int +krupierBust():boolean

Karta

-name:string -value:int -suit:string

+getName:String +getValue:void +getSuit:String +setName:void +setValue:void

Talia

-cards:Vektor -shufledCards:Vektor random:Random

+resetDesk:void +getDeskSize:int +getNextCard:Card +shuffledDesk:void +showDesk:void +showShuffledDesk:void +setCard:void

RekaK

+getValue:int

RekaG

+getValue:int

Wariant

Krupier Talia Gracz Karta RękaK

: startNewGame : shufledDesk

: getCard

: getHandValue

Diagram sekwencji (Sequence Diagram)

201

:moreCards

:getHandValue : getCard

: setCard : getCard

RękaG

: resetDesk

: playerBusts :getFacility

:moreCards

:getHandValue

: playerPass

:setCard

:setCard

: setCard

: getHandValue

:getHandValue

202

6. MODELOWANIE OBIEKTOWE EKOLOGII OCEANU.

Projekt przykładowy

203

2. określić początkowe obiekty systemu, opierając się na ogólnym opisie

systemu. Rozszerzyć zależności w terminach hierarchii klas

(aggregation, association);

Istota pracy tworzenia projektu obiektowo - orientowanego polega na

wykonywaniu następujących kroków:

1. podać ogólny opis systemu, zidentyfikować jego kierunki i

ograniczenia;

3. określić zmienne dla pierwotnych obiektów.

One stanowią egzemplarze zmiennych w

opisanych klasach;

204

5. opracować początkowy projekt, wykorzystując wyrażenia

wysokiego poziomu. W tych wyrażeniach powinny wykonywać się

operacje na pierwotnych obiektach;

6. drogą detalizacji udoskonalić wyrażenia

wysokiego poziomu, dopóki nie będą

gotowy projekt roboczy.

4. określić kluczowe komunikację na które powinny odpowiadać

pierwotne obiekty. Zaznaczyć, jeśli jest to możliwe, komunikaty, które

powodują następne inne komunikację przez „hierarchię komunikacji„;

20

5

OGÓLNY OPIS SYSTEMU MODELOWANIA EKOLOGII OCEANU

Ocean zawiera określoną ilość przeszkód, drapieżników i ofiar.

Podstawowe kierunki modelowania są :

Celem programu jest modelowanie w trybie interaktywnym systemu

ocean wirtualny.

• przeszkody są statyczne i nie mogą się przemieszczać;

• ofiara i drapieżnik przemieszczają się w przestrzeni oceanu.

• ofiara i drapieżnik rozmnażają się w zależności od warunków życia.

Liczebność każdego z nich może wzrastać i zmniejszać się.

206

• drapieżnik może atakować drugiego drapieżnika. W początkowym

wariancie drapieżnik atakuje tylko ofiary.

• drapieżnik ginie, kiedy nie zje w określonym czasie żadnej ofiary.

• ofiara ginie, kiedy zje ją drapieżnik.

207

POCZĄTKOWA HIERARCHIA KLAS

Ocean - Ocean składa się z dwuwymiarowej tablicy komórek.

Cell - Komórka to klasa abstrakcyjna, która jest pusta. Jej podklasy

zawierają różne obiekty, które występują w oceanie. Komórka powinna

wiedzieć, co zawiera w sobie ocean.

Model oceanu - to zbiór wszystkich komórek.

Prey - ofiara jest odmianą komórki. Może się ona poruszać. Ofiara

rozmnaża się tylko wtedy, kiedy jej czas rozmnażania osiągnął zero i ona

przemieściła się.

208

Predator - drapieżnik jest odmianą komórki. Może się on poruszać.

Drapieżnik rozmnaża się tylko wtedy, kiedy jego czas rozmnażania

osiągnął zero i on przemieścił się.

Predator woli się poruszać i jeść sąsiednie ofiary. Jeśli w sąsiedniej

komórce nie ma ofiary, będzie on poruszać się po pustych

komórkach.

Predator powinien umrzeć, jeżeli nie zje on w ciągu określonego

czasu.

Obstacle - przeszkoda jest odmiana komórki. Ona nie może się poruszać.

Coordinate - dwuwymiarowe współrzędne.

209

HIERARCHIA KLAS OBIEKTÓW SYSTEMU

Zgodnie z opisem obiektów i hierarchii klas

ofiary, drapieżniki i przeszkody są specjalnymi komórkami i mogą być

obiektami odpowiednich klas.

Cell - Komórka zna swoje położenie (offset - egzemplarz klasy

Coordinate) w oceanie.

Ocean zawiera kolejne komórki: komórka zna ocean do którego należy.

Wszystkie komórki są części jednego oceanu (myOcean). Można

określić tablicę komórek myOcean jak zmienną cells w definicji

obiektów klasy Ocean.

Zależność między obiektem a jego komórkami określą się przy pomocy

egzemplarzy klasy Ocean i zmiennej klasy Cell.

210

PROJEKT POCZĄTKOWY

Dla obiektów klasy Ocean :

Komentarz: Obiekty tej klasy przedstawiają ocean jako dwuwymiarową

tablicę komórek.

• W oceanie znajduje się określona ilość przeszkód, drapieżników i ofiar.

• System kontroluje każdą komórkę i porównuje ją z ofiarą lub

drapieżnikiem i określa czy osobnik ma się poruszać, rozmnażać czy ginie

zgodnie z regularni modelowania.

Przeszkody i puste komórki nie robią niczego.

211

Egzemplarze zmiennych:

• cells - dwuwymiarowa tablica komórek. Przemieszczenie komórki –

to operacji arytmetyczne nad odpowiednimi dwuwymiarowymi wskaźnikami;

• numRows - ilość wierszy w oceanie (domyślnie MaxRows =25),

• numCols - ilość kolumn w oceanie (domyślnie MaxCols = 70),

• size - ilość elementów w cells (numRows * numCols):

• numPrey - określa początkową ilość ofiar w oceanie (domyślnie - 150);

• numPredators - określa początkową ilość drapieżników w oceanie

(domyślnie = 20);

• numObstacles - określa ilość przeszkód w oceanie (domyślnie 75);

• random - generator liczb losowych.

212

Dla obiektów klasy Cell

Komentarz:

• Cell to klasa określająca wygląd wszystkich komórek, które znajdują

się w oceanie. Komórki przydzielone jednemu oceanowi nazywają się

myOcean. Domyślnie przedstawienie komórki obiektu :

DefaultImage=” „

• myOcean - obiekt klasy Ocean, myOcean to ten, który zawiera

wszystkie komórki danego modelu.

213

Egzemplarze zmiennych :

• offset – zmienna klasy Coordinate, która zawiera współrzędne komórek w

obiekcie Ocean1 klasy Ocean.

• image - graficzny wygląd komórki - symbol identyfikujący dany obiekt.

Na przykład :

symbol 'f 'oznacza ofiarę,

symbol 'S' — drapieżnika

symbol # - przeszkodę.

Konkretny wygląd może być określony w odpowiedniej podklasie.

214

Dla obiektów klasy Prey

Komentarz: Prey jest podklasa klasy Cell przedstawiającą

ofiarę. Ofiara może przemieszczać się, rozmnażać i zostać zjedzona.

Domyślnie dla obiektów ofiary przyjęto wygląd :

DefaultPreyImage = „f”.

Egzemplarze zmiennych:

• timeToReproduce - dostępny czas potrzebny do tego, aby obiekt

podklasy Cell stworzył siebie podobnego.

Domyślnie przyjęto timeToReproduce = 6.

215

Egzemplarze zmiennych :

• timeToFeed = czas podczas którego drapieżnik musi zjeść ofiarę, bo

inaczej ginie. Domyślnie timeToFeed == 6.

Dla obiektów klasy Predator

Predator - podklasa klasy Cell, przedstawia drapieżników.

Drapieżnik może przemieszczać się, rozmnażać się i jest zdobywcą ofiar

Domyślnie dla obiektów drapieżników przyjęto wygląd :

DefaultPredatorImage = „S”.

216

Komentarz • Obstacle - podklasa klasy Cell, przedstawia przeszkody w

oceanie (nie mogą zmieniać położenia). Domyślnie dla przeszkód

przyjęto symbol:

ObstacleImage – „ #”.

Komentarz Klasa przedstawiająca współrzędne. Obiekty Coordinate

przedstawiają współrzędne wszystkich obiektów klasy Cell,

Atrybuty :

x - współrzędna x;

y - współrzędna y.

Dla obiektów klasy Obstacle

Dla obiektów klasy Coordinate

217

MINIMALNA SPECYFIKACJA

Ocean1, egzemplarz klasy Ocean, składa się z dwuwymiarowej tablicy

komórek, które są egzemplarze klasy Cell lub jego podklas - Prey,

Predator, Oblacle.

Maksymalny rozmiar oceanu - 70 kolumn i 25 wierszy. Domyślnie ,

parametry oceanu maksymalne (wierszy-25, kolumny-70).

Egzemplarz myOcean tworze się w Cell, jako zmienna klasy, z

parametrami domyślnymi.

Użytkownik interakcyjnie wprowadza ilość przeszkód, drapieżników i

ofiar.

Komentarz: Powinna być zabezpieczona ochrona przed wprowadzeniem

wielkości, które są większy od ilości komórek w oceanie

(MaxNumCols*MaxNumRows).

Modelowanie wykonuje się dla wprowadzonej przez użytkownika ilości iteracji

(domyślnie 1000).

218

Iteracja składa się z następujących kroków:

Każdej komórce Cell w myOcean wysyła się komunikat process.

Wykonanie komunikatu process przebiega następujące:

• Sąsiednie Cells znajdują się w północnym, półdniowym, wschodnim,

zachodnim kierunkach ot bieżącego stanu.

• Komórki, znajdujące się koło granicy oceanu, mają za sąsiedni tylko z

lewej i prawej strony lub od góry i od dołu.

•Prey przemieszczają się w sposób losowy, jeżeli to jest możliwe do

sąsiedniej pustej komórki Cell lub zostają się na miejscu.

•Predators umierają, jeżeli timeToFeed stało zero, lub jedzą sąsiednie

losowo wybraną ofiarę, lub w losowo dobierany sposób przemieszczają się

do sąsiedniej pustej komórki, lub zostają się na miejscu.

MODELOWANIE

• Kiedy Predator przemieszcza się i je Prey to jego timeToFeed przyjmuje

początkową wartość.

219

• Przy przemieszczeniu Prey lub Predator, timeToReproduce których

równo zero, tworzą się nowe Prey lub Predator w tym miejscu, z

którego oni przemieszczają się.

•Każdy process zmniejsza timeToRerpoduce każdego Prey i

Predator o 1.

• Ilości Prey, Predator i Obtacles i ilość wykonanych iteracji

wyprowadza się po każdej iteracji.

Modelowanie dobiega do końca jeżeli:

•wykonano określone ilość iteracji,

• ilość Prey stało równym zero,

• ilość Predators stało równym zero.

220

GŁÓWNE KOMUNIKACJE: POCZĄTKOWA HIERARCHIA

Dla obiektów klasy Ocean

Metody dostępu (dla otrzymania odpowiedzi lub inicjalizacji zmiennych):

- getNumPrey( ) - zwraca ilość ofiar:

- set NumPrey (aNumber) - ustala ilość ofiar

- getNumPredators ( ) - zwraca ilość drapieżników

-setNumPredators(aNumber) - ustala ilość drapieżników.

getNumObstacles ( ) - zwraca ilość przeszkód

- setNumObstacles (aNumber) - ustala ilość przeszkód.

221

initialize( ) - inicjalizuje generator liczb losowych i rozmiar oceanu.

Ustala domyślne wartości ilości przeszkód, ofiar i drapieżników.

initCells - Odczytuje, wprowadzone przez użytkownika ilości przeszkód,

ofiar i drapieżników, i wstawia je w ocean.

addObstacles (numObstacles) - ustala numObstacles przegród w oceanie;

addPredators (numPredators) - ustala numPredators drapieżników w

oceanie.

addPrey (numPrey) - ustala numPrey ofiar w oceanie.

Metody inicjalizacji

222

myOcean-> displayStats( ) - pokazuje numer iteracji, ilość

drapieżników, ofiar i przeszkód.

Cell->process( ) - przemieszcza komórki zgodnie z

regułami każdej podklasy i odnawia tablice Cells w Ocean1.

Cell->displayCell( ) odwzorowuje wszystkie komórki

Ocean* myOcean = new Ocean;

myOcean -> run ( ) program główny,

określa ilość iteracji,

potem wywołuje iteracje :

Cell-> process,

Cell->displayStats( ),

Cell->displayCells( ),

Cell->displayBorder( ).

223

UŚCIŚLENIE POCZĄTKOWEGO PROJEKTU

1. virtual ~Cell( void) destructor (klasa Cell)

virtual ~Prey( void) destructor (klasa Prey)

virtual ~Predator (void) destructor (klasa Predator)

W modeli stworzona dwuwymiarowa tablica wskaźników na

obiekty klasy Cell lub jego podklas (Prey, Predator). Jeżeli

destruktor klasy

rodzicielskiej ogłosimy wirtualnym, operator delete może

zwalniać pamięć, przydzieloną pod obiekty klasy Cell

lub jego podklasy we wszystkich wystąpieniach programu.

Funkcji wirtualne w projekcie

224

2. funkcja virtual process( )

Wszystkie podklasy klasy Cell w różne sposoby wykonują

komunikat process. Obiekty klas Cell i Obstacle nie robią nic.

Obiekty podklasy Prey próbują przemieszczać się i rozmnażać się.

Obiekty podklasy Predator próbują jeść ofiary, przemieszczać się i

rozmnażać się.

Dlatego funkcja process( ) powinna być wirtualna.

225

3. funkcja virtual reproduce (anOffset)

Funkcja reproduce (anOffset) wykonuje się w czasie

modelowania, kiedy komórka (Prey, Predator) powinna odtworzyć się w

przedstawionych współrzędnych tablicy cells. Ponadto zależy od

konkretnej podklasy Cell.

Dlatego funkcja reproduce (anOffset) powinna być wirtualna.

226

funkcja getEmptyCellCoord ( ) ( klasa Ocean )

Komentarz:

funkcja getEmptyCellCoord ( ) stworzona po to, aby zmieścić nowe

obiekty klas Obstacle, Predator i Prey w oceanie. Trzeba w sposób

losowy wybrać współrzędne w tablice cells i sprawdzić, czy jest to

pusta komórka.

Ten powtarzający się proces jest zdefiniowany w

funkcji getEmptyCellCoord( ).

Member function ( metody)

227

funkcja getNeighborWithImage (anImage) ( klasa Cell )

Podklasy Cell przy próbie przemieszczenia podporządkowują się rożnym

ustalonym algorytmom.

Prey i Predator sprawdzają sąsiednie komórki na obecność różnych

obiektów w nich w sposób podobny (niezależnie od tego czy to pusta komórka

lub komórka, zawierająca Prey ). Wykorzystując porównanie

wyglądu komórek, można znaleźć sąsiednie komórki, spełniające

żądanie sąsiada i zwrócić losową wybraną z nich.

Funkcja getNeighborWithImage(anImage) zwraca wskaźnik do przypadkowo

wybranej sąsiedniej komórki spośród tych, które zawierają animację

anImage.

228

funkcja getCellAt(aCoord) (klasa Cell )

Liczne funkcji, uczestniczące w obróbce komórek i

obiektów podklas żądają otrzymania dostępu do komórki o

współrzędnej aCoord w tablice Ocean1. Funkcja

getCellAt(aCoord) zwraca wskaźnik do takiej komórki.

funkcja assignCellAt(aCoord, aCell) (klasa Cell )

Liczne funkcji uczestniczące w obróbce komórek i

obiektów podklas żądają rozmieszczenia nowej komórki w miejsce

współrzędnych aCoord w tablice cells Ocean1.

Funkcja assignCellAt( aCoord, aCel1) przemieszcza aCell w miejsce

współrzędnych aCoord w tablice cells Ocean1.

229

funkcja moveFrom (from, to) ( podklasa Prey )

Metody obróbki klas Prey i Predator często żądają

przemieszczenia obiektu z jego bieżącego miejsca w tablice cells

Ocean1 w miejsce o nowych współrzędnych. Funkcja

moveFrom(from, to) przemieszcza obiekty z komórki o

współrzędnych from do komórki o współrzędnych to.

randReal( ) (klasa Random)

Funkcja randReal( ) (klasa Random) w założeniu algorytmu

bazowego generacji liczb losowych uszeregowanych pomiędzy 0.0 a 1.0,

wykonuje generację liczb losowych rzeczywistych.

230

funkcja nextIntBetween(Low, High)

Komentarz:

Funkcja nextIntBetween(Low, High) najpierw wywołuje

randReal(), a potem przemieszcza, skaluję i transformuję

otrzymaną liczbą rzeczywistą w liczbę całkowitą w określonym

zakresie.

231

KOŃCOWA HIERARCHIA KLAS

Pomimo klas przedstawiających pierwotnie obiekty, które omówione

zostały wcześnie, w oddzielnej klasie wyróżniono generator liczb losowych.

Końcowa hierarchia klas przedstawiona poniżej. Dla każdej klasy w

nawiasach okrągłych podano ich zmienne składowe.

Ocean_Sim (główny program, nie klasa)

Ocean (numRows, numCols, size, numPrey, numPredators,

numObstacIes, random, cells)

Cell (static Ocean1, offset, image)

Prey (timeToReproduce)

Predator (timeToFeed)

Obstacle ( )

Coordinate (x. y)

Random (seed1, seed2)

232

badacz

Diagram wariantów wykorzystania systemu modelowania

ekologii oceanu

Wykonać symulacje:

W1

Wykonać symulacj

e: W5 Wykonać

symulacje: W2

Wykonać symulacje

: W4 Wykonać symulacj

e: W3

233

Diagram klas

234

Diagram sekwencji: inicjalizacja

:myOcean

:aCell

:random

:aPrey

:aPredator

:aObstacle

1. random.initialize( )

2. myOcean.InitCells( )

3. myOcean.addEmptyCell( )

4. cell.addPrey( )

5. cell.displayPrey( )

6. cell.addPredator( )

7. cell.displayPredator( )

8. cell.addObstacle ( )

9. cell.displayObstacle( )

„local”

„global”

„global”

„global”

„global”

Diagram kooperacji: inicjalizacja

236

Diagram maszyny stanowej: Prey

Inicjalizacja modelowanie

wait

move

reproduce

237

Diagram maszyny stanowej: Predator

Inicjalizacja modelowanie

wait

move

search

reproduce

238

N imagePrey==imageOst;

[yes;]

Przykład diagramu czynności: poszukiwanie Prey

[not]

imagePrey==imageWest;

imagePrey= =imageNord;

imagePrey==imageSouth;

[yes;]

[yes;]

[yes;]

[not]

[not]

[not]

eat

move i++

i< =N;

[yes;]

[not]

239

240

241

242

243