Projektowanie systemów

informatycznych – diagramy UML

dr inż. Elżbieta Zamiar

ezamiar@wsb.gda.pl
Agenda
 Przypomnienie
 Różnice w podejściu strukturalnym a
obiektowym
 Co to jest model
 Charakterystyka języka UML
 Diagramy interakcji
 Diagram stanów
 Diagramy aktywności
 Quiz
Model
 Spójny opis systemu
 Stanowi kompletny obraz systemu utworzony z
określonej perspektywy na pewnym poziomie
szczegółowości, co oznacza, że niektóre elementy
systemu są ukryte, a inne wyeksponowane
 Pojedynczy model zazwyczaj nie wystarcza ani do
zrozumienia wszystkich aspektów systemu
jednocześnie, ani do jego implementacji
 Proces projektowania systemu informatycznego
polega na kolejnym tworzeniu i wzajemnym
przekształcaniu wielu modeli
Podejście strukturalne a
obiektowe
STRUKTURALNE
 dane i procesy modelowane
osobno,
 wykorzystanie w zasadzie
tylko prostych typów danych,
 dobrze dostosowane do
relacyjnego modelu danych,
 podstawowe techniki
 diagramy hierarchii funkcji
(FHD),
 diagramy związków encji
(ERD),
 diagramy przepływu danych
(DFD).
OBIEKTOWE
 dane i procesy modelowane
łącznie,
 wykorzystują złożone typy
danych,
 dostosowane do obiektowego
modelu danych,
 podstawowe techniki:
 diagramy opisu struktury
(diagramy klas UML)
 diagramy opisu dynamiki
(przypadki użycia (DPU),
modele dynamiczne UML:
interakcji , czynności i
stanów).
Diagram a model

 Diagram służy do opisania modelu

 Model może być opisywany przy
pomocy wielu diagramów
Nazwij ten diagram
Jaki to diagram
Jaki to diagram
Jaki to diagram?
Różne notacje DFD
Jaki to diagram?
UML
 Służy do modelowania systemów
 Jest graficznym językiem wizualizacji,
specyfikowania, tworzenia i dokumentowania
składników i systemów …. informatycznych
 UML nie jest metodyką projektowania
 Jest notacją, opierającą się o podstawowe pojęcia
obiektowości
 Notacja, która może być użyta w dowolnej
metodyce
 Zapewnia semantykę ułatwiającą wymianę danych
modelu pomiędzy wieloma narzędziami CASE
(polecam https://prezi.com/p/zu19htr1ldn7/narzedzia-case/ )
Obiekt, klasa, enkapsulacja

 Obiekt – instancja klasy (byt)

enkapsulująca:
 strukturę danych (cechy)
 zachowanie (metody)
 Klasa – zbiór obiektów
 Klasa wzorcowa (bez instancji) – klasa
abstrakcyjna
Klasa abstrakcyjna
Klasa abstrakcyjna

Polimorfizm metod
Rodzaje diagramów

 Diagramy opisu
struktury

 Diagramy opisu
dynamiki
Diagramy UML
Diagram struktury
Delegowanie i przejmowanie
zadań przez klasy
 Związki
pomiędzy
diagramami
UML - Diagram aktywności

(ang. Activity diagram – ad)

Inaczej - Diagram czynności
Cel: Modelowanie procesów biznesowych,
scenariuszy,
przypadków użycia
lub algorytmów
Diagram aktywności

 Diagram aktywności (czynności) - służy

do modelowania czynności i zakresu
odpowiedzialności elementów bądź
użytkowników systemu.
 Nie opisuje działań związanych z jednym
obiektem a wieloma, pomiędzy którymi
może występować komunikacja przy
wykonywaniu czynności.
DPU a diagram aktywności

 Przypadki użycia pokazują, co

powinien robić system
 Diagramy aktywności umożliwiają
określenie tego, w jaki sposób system
będzie osiągał swoje zamierzone cele
 Jakie akcje?
 Jak te akcje są połączone?
Diagram aktywności

 Służy przede wszystkim do

modelowania przepływów operacji
wykonywanych w celu realizacji zadań
zlecanych systemowi przez jego
aktorów
Diagram aktywności/czynności

 (schematy blokowe) przedstawiają przepływ

sterowania od czynności do czynności
 większość diagramów czynności
przedstawia kroki procesu obliczeniowego
 łączą idee pochodzące z trzech źródeł:
 diagramów zdarzeń J.Odell'a,
 technik modelowania stanów,
 modelowania sieci Petriego.
Diagram aktywności/czynności
 Nie pokazuje wszystkich szczegółów przetwarzania.
 Prezentuje aktywności bez pokazywania bytów,
realizujących daną aktywność
 Jest punktem startowym dla procesu modelowania
zachowań obiektów
 Dla skompletowania projektu każda aktywność powinna być
zdekomponowana na szereg operacji (akcji/metod), z
których każdą trzeba będzie na późniejszym etapie
przydzielić do odpowiedniej klasy.
 Służy do:
 modelowanie przepływu czynności
 modelowanie operacji
Zastosowanie diagramów
aktywności / czynności

 Prezentacji
 wysoko poziomowych procesów biznesowych
 systemów oraz podsystemów
 scenariuszy przypadków użycia
 procesów systemowych charakteryzujących się
dużą liczbą równoległych czynności i sytuacji
decyzyjnych
 operacji
 algorytmów
Czynność vs. akcja
 Czynność:
 z perspektywy pojęciowej - to zadanie do wykonania i to
zarówno przez człowieka, jak i przez komputer
 z perspektywy projektu informatycznego - pojedyncza
metoda
 przejścia między stanami nie są związane z nadejściem
zdarzenia, ale są związane z zakończeniem
przetwarzania wyspecyfikowanego dla danego stanu.
 Akcje są już niepodzielne, trwanie ich nie podlega
przerwaniu.
Czynność vs. akcja
 Czynności na diagramach mogą cechować się
rozbudowaną funkcjonalnością, tj. mogą
reprezentować niezwykle złożone procesy
biznesowe bądź algorytmy przetwarzania
 Dla osiągnięcia precyzyjnego ich opisu niezbędna
staje się dekompozycja czynności.
 Czynności mogą być i są zwykle dekomponowane
na zhierarchizowane podczynności
 Diagram aktywności/czynności
 Zawartość:
 stany aktywności:
 Aktywność/czynność
 przejścia
 decyzje -
rozgałęzienia
(branch)
 rozwidlanie (fork)
 scalanie (join)
 tory (swimlane)
 przepływ obiektów
 obiekty,
 notatki i ograniczenia.
Przykład diagramu aktywności
Znaczniki sterowania
 utworzenie znacznika
sterowania

 zniszczenie
wszystkich
znaczników
sterowania

 zniszczenie danego
znacznika sterowania
Decyzje

 Wyjście decyzji
stanowią dwa lub
więcej przepływów,
z których tylko
jeden może być
zrealizowany
Warunek logiczny
 kolejne warunki
muszą się wykluczać,
aby zapewnić
jednoznaczny
przepływ sterowania

 Rozgałęzienie
(decyzja)
Ścieżki współbieżne

 Rozwidlenie (1in –
2 out, fork)

 Akcje współbieżne

 Scalenie
sterowania (2 in-
1out, join)
Przerywanie akcji
Złączenia

 Każdy przypływ
sterowania
docierający do
wejścia inicjuje
proces wyjściowy
Przykład

diagram aktywnosci -
logowanie.pdf
UML - Diagram interakcji

(ang. Interaction diagram)

Modelowanie interakcji pomiędzy
obiektami, pakietami
lub elementami systemu
Interakcja - definicja

 to zbiór komunikatów wysyłanych w

obrębie pewnego zbioru obiektów, w
ustalonym otoczeniu i w ściśle
określonym celu
 obrazuje przepływ sterowania w
systemie
 opisuje komunikaty wysyłane
pomiędzy obiektami
Interakcje - powiązania
 Muszą istnieć powiązania między obiektami, aby
możliwe było wysyłanie komunikatów pomiędzy
nimi.
 Stereotypy powiązań:
 <<association>> - widoczność obiektów przez
powiązanie,
 <<self>> - obiekt jest widoczny, bo sam odebrał
komunikat,
 <<global>> - obiekt o globalnym zasięgu,
 <<local>> - obiekt w lokalnym zasięgu,
 <<parameter>> - obiekt jest widoczny, ponieważ jest
parametrem.
Diagramy interakcji -
zadania
 Formalizacja dynamicznego zachowania się
systemu
 Każdy obiekt mający związek z konkretnym
przypadkiem użycia to obiekt uczestniczący
 Diagram interakcji obrazuje związki pomiędzy
obiektami uczestniczącymi
 Modelowanie przepływu sterowania z
uwzględnieniem:
 kolejności komunikatów w czasie
 organizacji strukturalnej obiektów
Rodzaje komunikatów
Rodzaje diagramów interakcji

Diagram interakcji

Diagram
Diagram sekwencji Diagram następstw
komunikacji
Operatory interakcji
 alt (od alternative ) - określający warunek wykonania bloku operacji,
odpowiadający instrukcji if-else ; warunek umieszcza się wówczas
wewnątrz bloku w nawiasach kwadratowych
 opt (od optional ) - reprezentujący instrukcję if (bez else )
 par (od parallel ) - nakazujący wykonać operacje równolegle
 critical - blok atomowy, oznaczający obszar krytyczny
 loop - definiujący pętlę typu for (o określonej z góry liczbie iteracji)
lub while (wykonywanej dopóki pewien warunek jest prawdziwy)
 break - wykonanie fragmentu i zakończenie interakcji
 seq - słaba sekwencja (podobnie do współbieżności) dotyczy
zdarzeń z kilku linii
 ignore/consider - ignore(komunikat1, komunikat2, ...) oznacza, że
na diagramie nie pokazano wymienionych komunikatów, choć mogą
wystąpić. Consider = odwrotnie
Diagram interakcji –
diagram sekwencji

(ang. Sequence Diagram –SD)

Modelowanie czasowej sekwencji
wymiany komunikatów podczas
współpracy obiektów, pakietów
lub komponentów
Diagram sekwencji (SD)
 Opisuje interakcje pomiędzy częściami systemu w postaci
sekwencji komunikatów wymienianych między nimi.
 Uczestnikami diagramów sekwencji najczęściej są obiekt
(opisane nazwą obiektu i jego klasą), które wymieniają między
sobą komunikaty.
 Obrazuje kolejność w czasie wysyłania komunikatów
pomiędzy różnymi obiektami w systemie.
 Prezentuje kolejność wywołań operacji, przepływ oraz szablon
realizowanego algorytmu.
 Pomija aspekt dostępu i operacji na danych, związany z
komunikacją.
Rodzaje komunikatów w SD
Diagramy sekwencji

 Uwypuklają kolejność komunikatów w

czasie
 Jego elementy to
 linie życia (time)
 ośrodki sterowania (objects, user,
moduł)
 upływ czasu
 stereotypy <<create>> ,<<destroy>>
Graficzna prezentacja SD
 Składa się z:
 pionowych linii życia (ang. lifelines) poszczególnych obiektów
uczestniczących w interakcji
 wymienianych między nimi komunikatów (wywołań operacji).
 czasu - jest reprezentowany w postaci pionowej osi diagramu
 Linia życia obiektu to:
 czas, w którym konkretna instancja obiektu jest w stanie
przyjmować komunikaty i wysyłać je
 symbolizuje czas istnienia obiektu w systemie
 białe prostokąty umieszczone na linii życia obiektu oznaczają,
że obiekt jest zajęty wykonywaniem pewnej czynności
(natomiast nie mają bezpośredniego związku z istnieniem
obiektu).
Prezentacja interakcji w SD

 Interakcja w SD jest opisywana na

dwóch poziomach:
 Poziomym – jako oś na której
umieszczono instancje obiektów
biorących udział w interakcji (charakter
statyczny)
 Pionowym – jako oś czasu
reprezentująca ułożone chronologicznie
komunikaty (charakter dynamiczny)
Technika tworzenia diagramu
sekwencji
 Ustalenie otoczenia (operacja, scenariusz, PU itp.)
 Zidentyfikowanie obiektów biorących udział w operacji (od
lewej umieszczane obiekty najważniejsze)
 Narysowanie linii życia obiektów (jeśli są tworzone i niszczone
- dodanie odpowiednich komunikatów)
 Dodanie komunikatu inicjującego, kolejne komunikaty pod nim
(dodanie parametrów do komunikatów, tam gdzie potrzeba)
 Dodanie aktywacji (ośrodka sterowania)
 Dodawanie ograniczeń
 Obiekt jest tworzony poprzez wysłanie do niego komunikatu-
konstruktora, natomiast niekoniecznie jest fizycznie usuwany
na końcu linii życia (raczej przestaje być istotny)
 Fizycznie usunięcie obiektu (destroy) można wprost
oznaczyć jako znak X na linii życia.
 Zasady i praktyka tworzenia
diagramu sekwencji
 Nazywaj aktorów w sposób spójny z diagramami przypadków użycia
 Nazywaj obiekty/klasy w sposób spójny z diagramami klas
 Po lewej stronie umieszczaj aktorów, którzy są ludźmi lub organizacjami
 Po prawej stronie umieszczaj aktorów, którzy są innymi systemami reagującymi na działanie modelowanego systemu
 Po lewej stronie umieszczaj aktorów, którzy są systemami inicjującymi interakcją z modelowanym
 Aktor może mieć tą samą nazwę co klasa
 Jeżeli nie jest to niezbędne - nie umieszczaj niszczenia (destroy) obiektu
 Umieszczaj nazwę obiektu jeżeli występuje odwołanie do niej w komunikacie
 Umieszczaj nazwę obiektu jeżeli istnieje wiele obiektów tej samej klasy
 Jeżeli umieszczono kilka obiektów o tej samej nazwie, muszą pochodzić z różnych klas
 Przy aktorach i obiektach/klasach umieszczaj stereotypy informujące o warstwie systemu, w której one działają
 Umieszczaj najważniejsze komunikaty (zwykle)
 Jeżeli komunikat jest wysyłany do obiektu/klasy, który jest implementowany jako składnik oprogramowania (klasa,
interfejs, komponent), nazywaj komunikat z użyciem składni języka programowania
 Jeżeli komunikat wymaga przekazania parametrów, podaj ich nazwy, a nie same typy danych
 Komunikaty wychodzące od aktorów, którzy są osobami lub organizacjami, nazywaj w sposób opisowy (zdaniem)
 Komunikaty przesyłane do klas (nie obiektów) implementowane są jako metody statyczne
 Komunikat tworzący obiekt oznaczaj stereotypem << create >>
 Aktywacja nie jest obowiązkowym elementem linii życia, ale ułatwia zrozumienie diagramu - podkreśla czas trwania danej
operacji
 Obiekt jest tworzony poprzez wysłanie do niego komunikatu-konstruktora
 Na końcu linii życia obiekt niekoniecznie jest fizycznie usuwany (raczej przestaje być istotny)
 Fizycznie usunięcie obiektu można wprost oznaczyć jako znak X na linii życia.
Diagram sekwencji - przykład
Diagram sekwencji-logowanie
Diagram opisu interakcji (ref)
Diagram interakcji - Diagram
komunikacji

(ang. Communication
Diagram - CD)
Diagram komunikacji - CD
 Specyfikują strukturalne związki pomiędzy
biorącymi udział w interakcji częściami oraz
wymianę komunikatów pomiędzy tymi instancjami.
 Akcja spowodowana przekazaniem komunikatu jest
instrukcją wykonywalną.
 Rodzaje akcji:
 <<call>> - wywołanie operacji,
 <<return>> - przekazanie wartości wywołującemu,
 <<send>> - wysłanie sygnału do obiektu,
 <<create>> - utworzenie nowego obiektu,
 <<destroy>> - zniszczenie obiektu.
Komunikat
 Forma kontaktu pomiędzy obiektami, której
efektem ma być podjęcie przez docelowy
obiekt pewnej akcji.
 Otrzymanie komunikatu przez obiekt wiąże
się z wykonaniem przez niego jego
własnego kodu lub wysłaniem kolejnego
komunikatu do innego obiektu w celu
wykonania przez niego pewnej akcji:
 aktywacja obiektu
 tworzenie obiektu
 niszczenie obiektu.
Komunikaty – notacja
graficzna
 Komunikaty w UML są reprezentowane
przez strzałki łączące linie życia
poszczególnych obiektów.
 Każdy komunikat wewnątrz interakcji
opatrzony jest kolejnym numerem, co
pozwala na łatwe śledzenie jej przebiegu.
 Podstawowe komunikaty:
 wywołanie procedury,
 powrót z wywołania
 wywołanie asynchroniczne.
Diagram komunikacji - zasady
 Obiekty na diagramie komunikacji są umieszczone tak, aby łatwo
można było opisać ich relacje pomiędzy sobą.
 Komunikacje są przedstawiane za pomocą linii łączących obiekty,
natomiast przesyłane między obiektami komunikaty i dane są
umieszczane obok tych linii.
 Każdy komunikat jest opatrzony etykietą liczbową, wskazującą na
kolejność ich wysyłania.
 Etykieta ta ma postać liczb oddzielonych kropkami. W przypadku
rozdzielenia sterowania każdy krok powoduje dodanie do etykiet
kroków następnych kolejnych pól z liczbami, np. krok 2 powoduje
utworzenie kroków 2.1, 2.2 leżących bezpośrednio za nim. Krok 2.1
posiada kroki 2.1.1 i 2.1.2, itd.
 Nie mogą przekazać wielu informacji dotyczących interakcji, np.
bloków komunikatów. Prezentują rzeczywiste powiązania obiektów i
ich relacji, co może ułatwić zrozumienie interakcji.
Diagram komunikacji
Diagram komunikacji
Zasady tworzenia diagramu
komunikacji
1. Określ jakie obiekty wejdą w jego skład
2. Zdefiniuj związki pomiędzy nimi
3. Wprowadź symbole (opisy wraz ze strzałkami) komunikatów
zapisywane równolegle do linii asocjacji, bądź w poziomie
4. Grot strzałki wskazuje kierunek przepływu komunikatu
5. Nanieś numerację określającą kolejność komunikatów
6. W przypadku dużej ilości komunikatów płynących w tym
samym kierunku i pomiędzy tymi samymi obiektami
dozwolone jest używanie jednej strzałki z kilkoma etykietami.

Po zakończeniu tworzenia diagramu, każdy komunikat musi

mieć numer swojej kolejności, nazwę operacji, oraz strzałkę
ustalającą kierunek przepływu.
Diagram interakcji (sekwencji i
komunikacji)
Diagram interakcji

 Diagram interakcji.pdf
UML - Diagram stanów

Diagramy stanów stanowią graficzną

reprezentację
maszyn stanów
Diagram maszyny
stanowej
Maszyna stanów

 Określa:
 ciągi stanów przyjmowanych przez obiekt
w odpowiedzi na zdarzenia zachodzące
w czasie jego życia,
 reakcje obiektu na te zdarzenia.
Diagramy stanów (czasowe)

 Służą do modelowanie historii życia:

 instancji klasy
 przypadku użycia
 całego systemu
 Reprezentują na osi czasu zmiany
dopuszczalnych stanów, jakie może
przyjmować uczestnik w interakcji
Diagram stanów
 Graficzne odzwierciedlenie dyskretnego
zachowania systemów stan-przejście
 Wykorzystuje 2 notacje – klasyczną i
zakładkową
 Podstawowe pojęcie:
 stan,
 przejście,
 stan początkowy,
 stan końcowy.
Podstawowe pojęcie maszyny
stanów (MS)
 Stan - okoliczność lub sytuacja w jakiej znajduje się obiekt w cyklu
swojego życia spełniając określony warunek, wykonując czynność
lub czekając na zdarzenie
 Przejście - (transition) relacja między dwoma stanami wskazująca,
że obiekt znajdujący się w pierwszym z nich wykona pewne akcje i
przejdzie do drugiego stanu, ilekroć będą spełnione określone
warunki
 Stan początkowy – (initial state) to zainicjowanie maszyny
stanowej. Reprezentuje obiekt w momencie jego utworzenia. Każdy
diagram stanu może zawierać tylko jeden taki stan. Do stanu
początkowego nie dochodzą żadne przejścia
 Stan końcowy – reprezentuje usunięcie obiektu z systemu. Stan ten
jest opcjonalny (nie wszystkie obiekty są usuwane), w systemie także
może występować wiele różnych stanów końcowych. Ze stanów
końcowych nie można przejść do innych stanów
Pseudostany diagramów stanu
 (initial) – pokazuje na domyślny stan początkowy
 (fork) – rozdziela przejście na ortogonalne składowe
 (join) – łączy ortogonalne składowe
 (junction) – łączy składowe
 (choice) – oznacza miejsce dokonywania wyboru
 (entry) – wejście do maszyny stanowej lub stanu złożonego
 (exit) – wyjście z pod-maszyny stanowej lub stanu złożonego
 (terminate) – zakończenie działania maszyny stanowej
 (deep history, shallow history) – oznaczają przejście maszyny
w ostatni aktywny stan, wskazują na stan domyślny przy braku
stanów poprzednich
Przejście, decyzja
 Przejście (transition) to
relacja pomiędzy dwoma
stanami wskazująca, że obiekt
znajdujący się w pierwszym
stanie wykona pewne akcje i
przejdzie do drugiego stanu.

 Decyzja (decision),
przedstawiająca wybór
pomiędzy dwiema wartościami
logicznymi pewnego
wyrażenia. Warto zauważyć,
że odpowiednio korzystając z
warunków przejść można
pominąć ten pseudostan,
jednak często jego użycie
zwiększa czytelność modelu.
Rozwidlenie (fork)
 pozwala na
rozdzielenie
wejściowego
przejścia na dwa
lub więcej przejść
wyjściowych do
różnych obszarów
współbieżnych,
stanów lub maszyn
stanowych.
 Węzeł (junction)

 Pozwala na złączenie wielu przejść wejściowych oraz

ich rozdzielenie na szereg przejść wyjściowych
 Jest on tzw. statycznym rozgałęzieniem warunkowym,
co oznacza, że realizacja przejść wejściowych nie
determinuje natychmiastowej realizacji przejść
wyjściowych. Szczególnymi przypadkami punktu
węzłowego są decyzja oraz złączenie.
Scalenie (join)

 Integruje kilka
przejść
wychodzących z
różnych
źródłowych
obszarów
współbieżnych,
stanów lub maszyn
stanowych.
Zaawansowane kategorie
maszyny stanowej
 sekcje symbolu graficznego stanu,
 klasyfikacja stanów,
 obszary współbieżne,
 pseudostany (elementy pozwalające na two-
rzenie złożonych przejść między stanami ),
 rodzaje przejść,
 protokołowe maszyny stanowe,
 maszyny stanowe zachowania,
 zdarzenia.
Etapy procesu tworzenia
diagramu stanów
 określenie rodzaju tworzonej maszyny stanowej i
identyfikacja jej obiektów;
 zidentyfikowanie poszczególnych stanów maszyny
stanowej;
 określenie hierarchii stanów, podstanów oraz
obszarów współbieżnych;
 powiązanie stanów oraz ich podstanów przejściami;
 zastosowanie adekwatnych pseudostanów;
 opracowanie specyfikacji sekcji stanów i przejść
zgodnie z przyjętymi składniami.
Diagram stanów
 Opis przejścia może mieć postać:
wyzwalacz [warunek sprawdzający]/czynność
 wyzwalacz (trigger) jest tym co uruchamia
przejście
 czynność (activity) opisuje, co realizowane jest
w trakcie przejścia
 warunek sprawdzający (warunek dozoru, guard)
musi być prawdziwy, aby doszło do przejścia
(dzięki temu można wprowadzać sterowanie za
pomocą warunków)
 oznaczenie przejść parami wyzwalacz-warunek
musi być jednoznaczne
Diagram stanów - faktura
Diagram stanów - przykłady

 Aukcja - Diagram stanów_Aukcja.pdf

Przerwa

Zapraszam
za 5 min
Główne diagramy UML
 Diagramy przypadków użycia (reprezentują
funkcjonalność z perspektywy użytkownika, definiują granice systemu)

 Diagramy klas (reprezentują statyczną strukturę systemu w

kategoriach obiektów, ich atrybutów, operacji i powiązań)

 Diagramy aktywności (prezentują przepływ sterowania

lub danych w systemie)

 Diagramy interakcji (przedstawiają obraz zachowań z

perspektywy interakcji między obiektami)
 Diagram sekwencji
 Diagram komunikacji
 Diagram następstw

Diagramy stanów (prezentują zachowanie każdego z istotnych

obiektów)
Quiz: Wskaż różnice

 Diagram przypadków użycia a diagram

aktywności a scenariusz
Przydatne informacje

 http://www.uml.org/ strona główna UML-a

organizacji OMG
 specyfikacja OMG dla UML
 specyfikacja języka OCL (formalne ograniczenia
w UML)
 kompletny zestaw artykułów opisujących
elementy UML 2.0 (ang.)
 opis najczęściej stosowanych diagramów UML
 Darmowe narzędzie – StarUML, Modelio
Złote myśli
 Można napisać zły kod, w każdym stylu
programowania.
 OOP nie powoduje, że zły kod staje się
dobry tak samo podejście proceduralne
czy funkcyjne nie jest w żaden sposób
lepsze czy gorsze.
 Czy przy pisaniu kodu naprawdę musimy
zahaczać o filozofię bytów i ich platoniczny
esencjalizm?
 Czy po prostu programujemy maszynę aby
zrobiła to co chcemy?
 Problem z językami zorientowanymi
obiektowo polega na tym, że mają całe
to ukryte środowisko, które “noszą” ze
sobą. Chciałeś banana, ale masz
goryla trzymającego banana i całą
dżunglę.
Joe Armstrong “Coders at work – Reflections on the
Craft of Programming”
Strukturalnie czy obiektowo?

 Używajmy podejścia OOP tam, gdzie

jest to konieczne lub uzasadnione, a
korzyści przewyższają wady takiego
rozwiązania.
 https://youtu.be/eEBOvqMfPoI
 https://youtu.be/IRTfhkiAqPw
Podsumowanie

 Niezależnie jaki projekt piszemy i

jakiego używamy języka,
programowanie od lat pięćdziesiątych
sprowadza się do trzech zasadniczych
działań:
 przypisania
 instrukcji warunkowych if
 pętli while
Programowanie obiektowe
 Program to zbiór porozumiewających się ze sobą
obiektów, czyli jednostek zawierających pewne
dane (cechy) i umiejących wykonywać na nich
pewne operacje (metody)
 Ważną cechą jest tu powiązanie danych (czyli
stanu) z operacjami na nich (czyli poleceniami) w
całość, stanowiącą odrębną jednostkę — obiekt.
 Cechą nie mniej ważną jest mechanizm dziedziczenia,
czyli możliwość definiowania nowych, bardziej złożonych
obiektów, na bazie obiektów już istniejących.
 Paradygmat dobrze odzwierciedla sposób, w jaki
ludzie myślą o świecie
Programowanie imperatywne
 Program postrzegany jest jako ciąg poleceń dla komputera.
Ściślej, obliczenia rozumiemy tu jako sekwencję poleceń
zmieniających krok po kroku stan maszyny, aż do uzyskania
oczekiwanego wyniku.
 Stan maszyny należy z kolei rozumieć jako zawartość całej
pamięci oraz rejestrów i znaczników procesora.
 Ten sposób patrzenia na programy związany jest ściśle z
budową sprzętu komputerowego ,poszczególne instrukcje (w
kodzie maszynowym) to właśnie polecenia zmieniające ów
globalny stan.
 Np.instrukcje podstawiania działają na danych pobranych z
pamięci i umieszczają wynik w tejże pamięci, zaś abstrakcją
komórek pamięci są zmienne.
 To najbardziej pierwotny sposób programowania, w którym
Programowanie funkcyjne
 Program to złożona funkcja (w sensie matematycznym), która
otrzymawszy dane wejściowe wylicza pewien wynik
 Zasadniczą różnicą w stosunku do poprzednich
paradygmatów jest brak stanu maszyny: nie ma zmiennych, a
co za tym idzie nie ma żadnych efektów ubocznych.
 Nie ma też imperatywnych z natury, tradycyjnie rozumianych
pętli (te wymagają np. zmiennych do sterowania ich
przebiegiem).
 Konstruowanie programów to składanie funkcji, zazwyczaj z
istotnym wykorzystaniem rekurencji. Charakterystyczne jest
również definiowanie funkcji wyższego rzędu, czyli takich, dla
których argumentami i których wynikami mogą być funkcje (a
nie tylko „proste” dane jak liczby lub napisy).
Bibliografia
 S. Wrycza, B. Marcinkowski, K.
Wyrzykowski, ,,Język UML 2.0 w
modelowaniu systemów informatycznych'',
Helion, 2005
 P. Graessle, H. Baumann, P. Baumann,
,,UML 2.0 w akcji. Przewodnik oparty na
projektach'', Helion, 2006
 B.Bruegge, A.H.Dutoit „Inżynieria
oprogramowania z ujęciu obiektowym”,
Helion, 2005
Ankieta

 Proszę o wypełnienie ankiety

Dziękuję za uwagę

dr inż. Elżbieta Zamiar

ezamiar@wsb.gda.pl