DIAGRAMY SEKWENCJI I KOLABORACJI

Podobne dokumenty
TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Diagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

Diagramy klas. dr Jarosław Skaruz

Diagram przypadków użycia

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

Wymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji.

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

Projektowanie interakcji. Jarosław Kuchta

UML cz. III. UML cz. III 1/36

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Język UML w modelowaniu systemów informatycznych

Podstawy programowania III WYKŁAD 4

Zalety projektowania obiektowego

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Podstawy modelowania programów Kod przedmiotu

UML w Visual Studio. Michał Ciećwierz

Modelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig

Diagramy sekwencji. wymienianych między nimi

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Język UML w modelowaniu systemów informatycznych

Diagram sekwencji. Komunikaty mogą być opisane w sposób sformalizowany. poprz / [warunek] *[iter] nr sekw : wynik := operacja(lista)

koniec punkt zatrzymania przepływów sterowania na diagramie czynności

Świat rzeczywisty i jego model

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Źródło: S. Wrycza, B. Marcinkowski, K. Wyrzykowski Język UML 2.0 w modelowaniu systemów informatycznych Helion DIAGRAMY INTERAKCJI

Diagramy klas. WYKŁAD Piotr Ciskowski

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

Analiza i projektowanie obiektowe 2016/2017. Wykład 8: Przypisywanie obiektom odpowiedzialności (2)

Inżynieria oprogramowania

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

Język programowania PASCAL

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji. Materiały dla nauczyciela

Spis treúci. 1. Wprowadzenie... 13

APIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI.

UML - zarys 2007/2008

Podstawy Programowania Obiektowego

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Modelowanie i analiza systemów informatycznych

Rysunek 1: Przykłady graficznej prezentacji klas.

TECHNOLOGIE OBIEKTOWE. Wykład 3

DIAGRAMY IMPLEMENTACYJNE

Konfiguracja i obsługa modułu Service Desk

Tryby komunikacji między procesami w standardzie Message Passing Interface. Piotr Stasiak Krzysztof Materla

Programowanie obiektowe

Michał Adamczyk. Język UML

Laboratorium z przedmiotu: Inżynieria Oprogramowania INP

Plan. Formularz i jego typy. Tworzenie formularza. Co to jest formularz? Typy formularzy Tworzenie prostego formularza Budowa prostego formularza

12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Informatyka I. Klasy i obiekty. Podstawy programowania obiektowego. dr inż. Andrzej Czerepicki. Politechnika Warszawska Wydział Transportu 2018

PROJEKTOWANIE. kodowanie implementacja. PROJEKT most pomiędzy specyfikowaniem a kodowaniem

2017 Electronics For Imaging, Inc. Informacje zawarte w niniejszej publikacji podlegają postanowieniom opisanym w dokumencie Uwagi prawne dotyczącym

UML cz. I. UML cz. I 1/1

Programowanie obiektowe

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Technologie obiektowe

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

MODELOWANIE OBIEKTOWE Z UML

Modelowanie obiektowe

Diagramy maszyn stanowych, wzorce projektowe Wykład 5 część 1

Zakres tematyczny dotyczący kursu PHP i MySQL - Podstawy pracy z dynamicznymi stronami internetowymi

Język UML w modelowaniu systemów informatycznych

Zagadnienia Semestr IV Inżynieria Oprogramowania WSZiB

Zintegrowany model struktury

NIFIED M L ODELLING ANGUAGE. Diagramy czynności

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.

Diagramy przypadków użycia

WPROWADZENIE DO UML-a

Wykład I. Wprowadzenie do baz danych

Modelowanie i analiza systemów informatycznych Spis treści

Diagramy stanów tworzenie modeli analizy i projektowania Na podstawie UML 2.0 Tutorial

Tutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu.

MASZYNA STANOWA. Maciej Patan. Instytut Sterowania i Systemów Informatycznych Uniwersytet Zielonogórski. Techniki modelowania programowania.

Projekt z przedmiotu Specjalizowane języki programowania Temat: Zastosowanie programowania obiektowego w środowisku LabView

UML cz. II. UML cz. II 1/38

Programowanie w języku Python. Grażyna Koba

Budowa argumentacji bezpieczeństwa z użyciem NOR-STA Instrukcja krok po kroku

ALGORYTMY. 1. Podstawowe definicje Schemat blokowy

Język UML. dr inż. Piotr Szwed C3, pok

Język UML w modelowaniu systemów informatycznych

Diagramy czynności Na podstawie UML 2.0 Tutorial

SysML Tworzenie diagramu aktywności SysML005

Inżynieria oprogramowania. Część 5: UML Diagramy klas

Procesowa specyfikacja systemów IT

Delphi podstawy programowania. Środowisko Delphi

Programowanie obiektowe

Wprowadzenie do programowania

Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II

Język programowania. Andrzej Bobyk

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp Podziękowania...

Metodyki i techniki programowania

Faza analizy (modelowania) Faza projektowania

Aneks do Instrukcji obsługi wagi Basic Label 300 z dnia

Transkrypt:

DIAGRAMY SEKWENCJI I KOLABORACJI Maciej Patan Modelowanie behawioralne Model behawioralny: Opis systemu koncentrujący się na dynamicznym zachowaniu składników systemu, włączając w to wzajemne interakcje i współpracę pomiędzy nimi. Motywacje projektowanie oprogramowania dotyczy zachowania jego składników; projektowanie obiektowo zorientowane jest techniką używaną do rozdzielenia i enkapsulacji zachowań, model statyczny nie może być dowiedziony jako dokładny bez analizy związanych z nim procesów dynamicznych, modele dynamiczne, niezbyt precyzyjnie reprezentują strukturę systemu oraz zachodzące zależności, ukazanie kompletnego współdziałania elementów w zakresie relacji statycznych oraz dynamicznych, 1

Podstawowe pojęcia(1) Instancja (obiektu, struktury danych, komponentu, itp.) Wielkość z unikatową tożsamością do której można zastosować określony zbiór operacji lub wysłać zestaw sygnałów i która posiada stan odzwierciedlający efekty działania tych operacji lub sygnałów. Powiązanie Połączenie pomiędzy instancjami, będące realizacją asocjacji między klasami. Powiązanie atrybutu jest to nazwana pozycja tekstowa wewnątrz instancji przechowująca wartość atrybutu. Operacja Deklaracja usługi, która może być wymagana od instancji celem wpłynięcia na zachowanie się elementów systemu. Metoda jest ciałem operacji. 2 Powi¹zanie atrybutu Odcinek:Wielok¹t Œrodek : Punkt = (0.5,0.5) Wierzcho³ki : Punkt[2] = ((0,0),(1,1)) Powi¹zanie B:Punkt x : Integer = 1 y : Integer = 1 koniec pocz¹tek A:Punkt x : Integer = 0 y : Integer = 0 Wielok¹t Œrodek : Punkt Wierzcho³ki : Punkt[1..*] przesuñ(in d : Point) skaluj(in k : Real) for any v in Wierzcho³ki do v.x:=v.x+d.x; v.y:=v.y+d.y; for any v in Wierzcho³ki do v.x:=k*v.x; v.y:=k*v.y; 3

Podstawowe pojęcia(2) Bodziec Proces komunikacji pomiędzy instancjami nadającą i odbierającą. Komunikat jest analogicznym procesem komunikacji pomiędzy klasami(tzn. Bodziec jest instancją Komunikatu). Sygnał Specyfikacja asynchronicznego bodźca przekazywanego pomiędzy instancjami. Interakcja zbiór procesów komunikacji pomiędzy instancjami, włączając w to wszystkie sposoby oddziaływania,(np. operacje wywołania, tworzenia i niszczenia instancji), Uwaga: Procesy komunikowania się są chronologicznie częściowo uporządkowane. Modelowanie interakcyjne wyspecjalizowany typ modelowania behawioralnego, przeznaczony do analizy interakcji pomiędzy elementami wraz z upływem czasu. 4 Diagramy interakcyjne Pokazują interakcje pomiędzy instancjami występującymi w modelu. istniejące instancje wraz z możliwymi powiązaniami, komunikaty i bodźce, tworzenie i niszczenie instancji. Typy: diagramy sekwencji(podejście temporalne), diagramy kolaboracji(podejście strukturalne). 5

Diagramy sekwencji- podstawowe elementy oœ kategorii instancji O1: Klasa1 O2:Klasa2 O3:Klasa3 etykieta bodÿca oœ czasu nazwa1(...) nazwa2(...) aktywacja bodziec linia ycia Linia życia reprezentuje istnienie elementu w czasie. Aktywacja reprezentuje okres wykonywania operacji. 6 Typy komunikatów i bodźców Składnia Typ Opis komunikat prosty Bezpośredni przepływ sterowania z instancji do instancji komunikat synchroniczny Wstrzymanie operacji do czasu uzyskania odpowiedzi komunikat asynchroniczny Kontunuowanie operacji bez czekania na odpowiedź powrót Powrót z wywołania podprogramu 7

Różne typy komunikacji Przepływ prosty Przepływ zagnieżdzony nadajnik centrala odbiornik sprzedawca :Zamówienie :Artyku³ w³¹cz nadajnik() sygna³ wybierania() pobierzwartoœæ() wybierz numer() cena() sygna³ oczekiwania() dzwonek() po³aczenie odebrane() pobierzadres() 8 Etykiety komunikatów i bodźców pop/[warunek]*[iter] nr sekw: wynik:= operacja(lista) pop lista poprzedników(tzn. komunikatów poprzedzających), [warunek] warunek dozoru, który musi zostać spełniony żeby komunikacja nastąpiła, *[iter] liczba iteracji oznaczająca, ile razy komunikacja zostaje powtórzona, nr sekw etykieta określająca kolejność komunikacji, wynik nazwa zmiennej zwracanej przez operację, operacja(lista) nazwa wywoływanej operacji oraz jej lista argumentów. 9

Przykłady: przesuń(1,2) wywołanie proste, wyn1:=przesuń(5,5) zwrócenie parametru wyjściowego, *[1..5]: wyn1:= przesuń(5,7) iteracja, [z>0]: wyn1:= przesuń(5,7) warunek, A3,B4/[x<0]*[1..4] C3.1: wyn2:= pobierzlokację(wyn1) [Baza jest aktywna]*[dla każdego rekordu] 6: DaneWyj:=Formatuj(DaneWej,Sterowanie,3) Uwaga: UML pozwala przedstawiać komunikację za pomocą pseudokodu lub innego języka programowania. Komunikację można też opisać na lewym marginesie diagramu sekwencji. 10 Diagramy sekwencji- konstrukty calculator filter value [x>=0] getvalue() warunek new() [x<0] transform() getvalue() delete() tworzenie elementu buffer iterate() rekurencja 11

Diagramy sekwencji- pętle :DataBase :Table :Report *[For each record] warunek pêtli (opcja 1) res1:= getrecord() res2:=getindex() outdata:=formatdata(res1,res2) komunikacja zwrotna [No more record to process] warunek pêtli (opcja 2) 12 Zalety i wady niezwykle wyraźnie pokazują chronologię ciągów zdarzeń, bardzo dobrze opisują przetwarzanie równoległe, znakomite do wykrywania przypadków wyścigu zdarzeń, zajmują dużo miejsca, słabo przedstawiają wzajemne relacje pomiędzy instancjami. Kiedy modelować interakcje Do ustalenia w jaki sposób instancje oddziałują na siebie. Do zidentyfikowania interfejsów klasyfikatorów. Do rozłożenia i separacji wymagań. 13

Wskazówki do modelowania interakcyjnego Ustalić pełny kontekst rozważanej interakcji. Dołączać tylko te własności instancji, które są niezbędne i znaczące. Ustalaćprzepływwkierunkuzlewejdoprawejizgórynadół, umieszczać aktywne instancje z lewej strony(u góry), a pasywne z prawej (udołu), Używać diagramów sekwencji: do pokazania bezpośredniego uporządkowania komunikatów i bodźców, do modelowania w czasie rzeczywistym. Używać diagramów kolaboracji: kiedy struktura jest bardzo istotna, do skoncentrowania się na efektach wywieranych na instancje. 14 Podstawowe pojęcia(3) Kolaboracja opisuje jak operacja lub klasyfikator(np. przypadek użycia) są realizowane przez zbiór klas i asocjacji użytych w pewien określony sposób. Definiuje zbiór ról, odgrywanych przez instancje i powiązania oraz zbiór interakcji określających komunikację pomiędzy instancjami, kiedy odgrywają swoje role. Rola klasyfikatora jest specyficzną rolą odgrywaną przez współuczestnika w kolaboracji. Określa ograniczony widok na klasyfikator, zdefiniowany przez to co jest wymagane w kolaboracji. Rola asocjacji jest specyficznym użyciem asocjacji potrzebnej w kolaboracji. Modelowanie kolaboracyjne wyspecjalizowany typ modelowania behawioralnego, przeznaczony do modelowanie relacji pomiędzy elementami, pomiędzy którymi zachodzą interakcje w czasie. 15

Diagramy kolaboracji pokazują role klasyfikatorów i asocjacji(najlepiej razem) uzupełnione dodatkowymi elementami ograniczającymi, Typy: diagramy na poziomie specyfikacji(role klas, role asocjacji i ich komunikaty), diagramy na poziomie instancji(konkretne obiekty, powiązania i bodźce), dodatkowe diagramy statyczne są używane do bezpośredniego pokazania kolaboracji. Uwaga: Diagramy kolaboracji i sekwencji opisują te same informacje i mogą być przekształcane miedzy sobą. Wybór diagramu zależy od aspektu, który chce zilustrować projektant. 16 Klasyfikator Atrybut_1 Atrybut_2 Atrybut_3 Operacja_1() Operacja_2() Operacja_3() Relacje klasa-instancja-rola <<wywodzi siê z>> <<jest widokiem>> RolaKlasyfikatora Atrybut_1 Atrybut_2 Operacja_1() Operacja_3() <<odnosi siê do>> Klasyfikator jest opisem instancji Instancja Atrybut_1 Atrybut_2 Atrybut_3 Rola klasyfikatora definuje u ycie instancji Instancja jest wielkoœci¹ z unikatow¹ to samoœci¹ opisan¹ zachowaniem i stanem 17

Różne sposoby nazywania roli / NazwaRoliKlasyfikatora : NazwaKlasyfikatora /Rodzic:Osoba /Rodzic :Osoba NazwaInstancji / NazwaRoliKlasyfikatora : NazwaKlasyfikatora :Osoba Andrzej:Osoba Andrzej Andrzej/Rodzic Andrzej/Rodzic:Osoba 18 klasa Klasa_1 Asocjacje i role asocjacji asocjacja {zmienna} 0..5 klasa Klasa_2 <<jest widokiem>> <<jest widokiem>> <<jest widokiem>> /Rola_1 rola klasy {ustalona} rola asocjacji 3..4 /Rola_2 rola klasy Rola asocjacji precyzuje pożądane własności powiązania użytego w kolaboracji. Własności zakończeń asocjacji mogą zostać ograniczone poprzez zakończenia ról asocjacji. 19

Przykład 1. Prosta struktura uniwersytetu. pracownik /Nauczyciel:Osoba Pozycja:Text * 1 :Wydzia³ 1 1 promotor wyk³adowca Model ról * uczeñ /Student:Osoba Program:Text kurs wyk³adany * * * :Kurs uczestnik kurs pobierany kompletnyopis struktury Model klas pracownik * wyk³adowca Osoba Nazwa:Text Pozycja:Text Program:Text 1 * promotor 0..1 * uczestnik uczeñ opispojedynczego użycia 0..1 Wydzia³ kurs wyk³adany * * Kurs kurs pobierany 20 Model ról na poziomie instancji cz³onek wydzia³u Andrze/Nauczyciel promotor promotor uczeñ Alicja/Student uczestnik wydzia³ uczeñ :Wydzia³ Robert/Student wydzia³ cz³onek wydzia³u Krzysztof/Nauczyciel uczestnik kurs wyk³adowca wyk³adany kurs pobierany kurs pobierany UML :Kurs 21

Diagram kolaboracji z interakcjami Przykład 2. Załóżmy, że użytkownik pracując w edytorze tekstowym naciska znak na klawiaturze, który pojawia się na ekranie. Pokazać interakcje tego prostego procesu zachodzące między klawiaturą, interfejsem graficznym edytora, systemem operacyjnym, procesorem, kartą graficzną i monitorem. Najpierw tworzymy scenariusz przypadku użycia Naciśnij klawisz : 1. naciśnięcie klawisza jest wykrywane przez interfejs graficzny(gui), 2. GUI informuje system operacyjny(sys) o naciśnięciu klawisza, 3. SYS informuje o tym procesor(cpu), 4. SYS uaktualnia GUI, 5. CPU zawiadamia kartę graficzną(graph), 6. GRAPH wysyła komunikat do monitora, 7. monitor wyświetla znak alfanumeryczny. 22 Diagram sekwencji Diagram kolaboracji : Klawiatura : GUI : SYS : CPU : GRAPH : Monitor 1: 1: 2: : Klawiatura : GUI : SYS 3: 2: 3: 4: 4: 5: 6: 5: 6: : CPU : GRAPH : Monitor 23

Kiedy modelować kolaboracje Używać jako narzędzia do określenia Klasyfikatorów. Do przetworzenia przypadków użycia/operacji na Klasyfikatory. Do przekształcenia specyfikacji podsystemu na jego realizację. Wskazówki do modelowania kolaboracyjnego Kolaboracja powinna zawierać zarówno strukturę jak zachowanie odpowiednie dla rozważanego zadania. Rola jest pewną abstrakcją instancji, lecz nie stanowi klasy! Należy poszukiwać: elementów inicjujących(zewnętrznych), elementów obsługujących(ang. handler elementy aktywne), elementów obsługiwanych(elementy pasywne) 24 Uzupełnianie się modeli statycznych i dynamicznych Przykład 3. Telefon komórkowy. Rozważmy oprogramowanie sterujące bardzo prostym telefonem komórkowym. Telefon taki posiada przyciski do wybierania numeru, posiada specjalny przycisk Wyślij do inicjowania połączenia. Posiada także, połączeniowy hardware i software, który zbiera cyfry składające się na numer i emituje odpowiednie tony wybierania. Ponadto, musi zawierać radio komórkowe, które ustala połączenie z siecią komórkową. Dodatkowe składowe modelu to mikrofon, głośnik oraz wyświetlacz. Modu³Po³¹czeniowy Telefon RadioKomórkowe * Przycisk G³oœnik Mikrofon Wyœwietlacz 25

pierwsza wersja bardzo dobrze odpowiada specyfikacji, relacje kompozycji ściśle odpowiadają obiektowi rzeczywistemu, Pytania: Czy na pewno model statyczny jest prawidłowy? Jaksięotymprzekonać? Jakie kryteria oceny wybrać? Kryterium pierwsze: Zgodność modelu z obiektem rzeczywistym. Kryterium drugie: Zgodność zachowania się modelu z obiektem rzeczywistym. 26 Przypadek użycia: Ustal połączenie. Specyfikacja dynamiki modelu 1. Użytkownik wprowadza numer telefonu naciskając przyciski cyfr. 2. Dla każdej cyfry, wyświetlacz jest odświeżany. 3. Dla każdej cyfry, moduł połączeniowy generuje odpowiedni ton i emituje go przez głośnik. 4. Użytkownik naciska przycisk Wyślij. 5. Radio komórkowe realizuje połączenie z siecią. 6. Na wyświetlaczu pokazuje się ikona Zajęty. 7. Zgromadzone cyfry numeru są wysyłane do sieci. 8. Ustalane jest połączenie z odbiorcą. 27

W jaki sposób obiekty modelu statycznego współpracują ze sobą? :G³oœnik :Przycisk *1:Naciœnij(kod) :Modu³Po³¹czeniowy 3:EmitujTon(kod) 5:Po³¹cz(nr_tel) :RadioKomórkowe 2:WyœwietlCyfrê(kod) Wyœlij:Przycisk 4:Wyœlij() :Wyœwietlacz 6:Zajêty() 28 Zrekonfigurowany model statyczny G³oœnik +EmitujTon(kod:int) Przycisk Modu³Po³¹czeniowy RadioKomórkowe +Naciœnij(kod:int) +Wyœlij() +Po³¹cz(nr_tel:String) Wyœwietlacz +WyœwietlCyfrê(kod:int) +Zajêty() 29

Problemy dodatkowe: 1. Dlaczego klasa Przycisk miałaby posiadać pełną wiedzę o klasie ModułPołączeniowy? Powinna być to klasa, którą można by użyć w programach, które nie używają obiektów typu ModułPołączeniowy. Przycisk <<nterface>> Przycisk +PrzyciskNaciœniêty() AdapterPrzyciskuWyœlij AdapterPrzyciskuCyfry Modu³Po³¹czeniowy 30 2. Klasa Wyświetlacz jest celem asocjacji od dwóch różnych klientów(tzn. ModułuPołączeniowego i RadiaKomórkowego). Oznacza to istnienie nieoczekiwanej ukrytej zależności pomiędzy tymi klientami. Modu³Po³¹czeniowy RadioKomórkowe WyswietlaczMP WyœwietlaczRK +WyœwietlCyfrê(kod:int) +Zajêty() Wyœwietlacz 31

Zrekonfigurowany model kolaboracji :AdapterPrzyciskuC *1: kod:=przycisk Naciœniêty() 4:Przycisk Naciœniêty() Cyfra:Przycisk Wyœlij:Przycisk :G³oœnik 1.1:Naciœnij(kod) 3:EmitujTon(kod) 5:Po³¹cz(nr_tel) :Modu³Po³¹czeniowy :RadioKomórkowe 4.1:Wyœlij() 2:WyœwietlCyfrê(kod) 6:Zajêty() ekran:wyœwietlaczmp ekran:wyœwietlaczrk :AdapterPrzyciskuW 32 W pierwszej iteracji: Podsumowanie utworzone modele są tylko domysłem, model statyczny jest bardzo słabym przybliżeniem systemu, widoczna dysharmonia pomiędzy modelem statycznym i dynamicznym. W drugiej iteracji: rozdźwięk pomiędzy modelami został częściowo usunięty, nastąpiła eksploracja interesujących szczegółów projektu. Proces iteracyjny powinien trwać, aż projektant zsynchronizuje oba modele. Modele statyczne są niezbędne, ale powinny zostać wzmocnione analizą dynamiki systemu. statyczne relacje są bezpośrednim wynikiem dynamicznych potrzeb aplikacji, 33

Wykrywanie wyścigu zdarzeń :AdapterPrzycisku Wyœlij :Modu³Po³¹czeniowy :RadioKomórkowe :G³oœnik Po³_przychodz¹ce() Dzwonek() Wyœlij() OdpowiedŸ() :AdapterPrzycisku Wyœlij :Modu³Po³¹czeniowy :RadioKomórkowe :G³oœnik Wyœlij() Po³_przychodz¹ce() Dzwonek() Po³¹cz(nr_tel) 34