Warszawa,2018 Wykład3-ZastosowanienotacjiUMLwprojektowaniuaplikacjiPLC.Analizaprocesu.Maszynastanów.drinż.JakubMożaryn,drinż.PiotrWasiewicz ZaawansowaneUkładySterowaniaPLC

(1)

Zaawansowane Układy Sterowania PLC

Wykład 3 - Zastosowanie notacji UML w projektowaniu aplikacji PLC.

Analiza procesu. Maszyna stanów.

dr inż. Jakub Możaryn, dr inż. Piotr Wasiewicz

Instytut Automatyki i Robotyki

Warszawa, 2018

dr inż. Jakub Możaryn, dr inż. Piotr Wasiewicz Zaawansowane Układy Sterowania PLC

(2)

Czym jest UML

Język UML (ang. Unified Modeling Language) jest jednym z najbardziej znanych obecnie obiektowych języków modelowania. Jest to język służący do specyfikowania, konstruowania, obrazowania i dokumentowania składowych systemów oprogramowania.

Język UML powstał, aby połączyć zalety wcześniejszych rozwiązań użyteczność w projektowaniu oraz określaniu związków ze środowiskiem implementacji,

użyteczność w modelowaniu aspektu użytkowników i cyklu życiowego systemu,

użyteczność w modelowaniu dziedziny przedmiotowej.

W przypadku języków programowania PLC budowa diagramów UML (szcze- gólnie diagramów czynności i diagramów maszyny stanów) pozwala na wydajną implementację w językach grafowych (SFC), lub tekstowych (ST) [norma IEC 61131-1].

(3)

Część projektowa

Głównym założeniem modelowania UML jest usprawnienie komunikacji między klientem a analitykiem.

Często mamy do czynienia z klientami, którzy nie wiedzą na czym polega sterowanie układem za pomocą sterownika PLC. Język naturalny często jest nieprecyzyjny i może prowadzić do wielu rozbieżności jeśli chodzi o bardziej specjalistyczne i skomplikowane zagadnienia. Dzięki UML łatwiej można sprecyzować najważniejsze rzeczy i nie zgubić się w olbrzymiej ilości szczegółów.

Spojrzenie na diagram lub rysunek umożliwia globalne wyobrażenie sobie zarysu projektu.

(4)

Część projektowa

Do zaprojektowania programu sterownika potrzebne są różne informacje, m.in.

Jakie funkcje będzie on wykonywał i w jaki sposób będzie je wykonywał?

Jaka jest wymagana ilość linii sygnałowych i jakiego rodzaju są to sygnały?

Czy sterownik jest zintegrowany z HMI?

Czy układ sterowania jest obsługiwany manualnie?

(5)

Przykładowy opis zadania

Opis po stronie klienta

”Po włączeniu systemu (WŁ) i rozpoczęciu procesu (AT) następuje przygotowanie wózka, poprzez skierowanie do stanowiska zrzutu odpadów i otworzeniu klapy. Podczas opróżniania i napełniania transportera, konieczna jest wentylacja pomieszczenia (Y7). Po zakończeniu opróżniania wózek podjeż- dża do stanowiska napełniania (X1). Stanowisko napełniania wyposażone jest w wagę, która generuje sygnał X4 gdy zostanie pobrana właściwa ilość substancji. Napełniony wózek zostaje przekierowany do stanowiska wyła- dunku (X2) gdzie następuje jego opróżnienie.”

(6)

Przykładowy opis zadania - wózek do wyrzucania odpadów

Rysunek:Schemat procesu sterowania. Oznaczenia: Y7 - wentylacja, Y8 - lampka, T1 - timer, Y1/2 - ruch wózka w określoną stronę, Y4 - uruchomienie taśmociągu, Y5 - owarcie klapy, X1, X2, X3 - czujniki położenia wózka, X4 - waga

(7)

Przykładowy opis zadania

Wstępna analiza

Po włączeniu systemu (WŁ) i rozpoczęciu procesu (AT) następuje przygotowanie wózka, poprzez skierowanie do stanowiska zrzutu odpadów i otworzeniu klapy.

Podczas opróżniania i napełniania transportera, konieczna jest wentylacja pomieszczenia (Y7).

Po zakończeniu opróżniania wózek podjeżdża do stanowiska napełniania (X1).

Stanowisko napełniania wyposażone jest w wagę, która generuje sygnał X4 gdy zostanie pobrana właściwa ilość substancji.

Napełniony wózek zostaje przekierowany do stanowiska wyładunku (X2) gdzie następuje jego opróżnienie.

(8)

Wynik analizy - ogólny diagram stanów

Rysunek:Diagram stanu - program sterowania, uład ogólny

(9)

Wynik analizy - szczegółowe diagramy stanów

Rysunek:Diagram stanu - inicjowanie procesu, uład szczegółowy.

(10)

Wynik analizy - szczegółowe diagramy stanów

Rysunek:Diagram stanu - praca, uład szczegółowy.

(11)

Obiekt jako podstawa modelowania

Cechy obiektu:

Tożsamość (ang. identity ) obiektu jest cechą umożliwiającą jego identyfikację i odróżnienie od innych obiektów np. adres IP sterownika PLC w sieci zakładu produkcyjnego.

Stan (ang. state) obiektu jest określany przez aktualne wartości wszystkich jego właściwości. Zbiór właściwości się nie zmienia, zmieniają się ich wartości.

Wartościami stanu mogą być np. chwilowe wartości binarnych sygnałów wyjściowych obiektu.

Zachowanie (ang. behavior ) obiektu to zbiór działań (usług, ang. service), które obiekt potrafi wykonać na rzecz innych obiektów. Zachowanie obiektów określa dynamikę systemu – sposób komunikacji pomiędzy obiektami. Efektem wykonania usługi może być jakaś wartość zwracana obiektowi, który poprosił o wykonanie usługi. Wartość ta może zależeć od aktualnego stanu obiektu wykonującego usługę. Podczas wykonywania działań, obiekt może operować na swoim zbiorze wartości, w wyniku czego może ulec zmianie jego stan.

(12)

Obiekt jako podstawa modelowania

Identyfikacja potencjalnych klas obieków polega przede wszystkim na wyszukaniu w specyfikacji wymagań użytkownika rzeczowników (ogólnie: fraz rzeczownikowych) i okre- śleniu, które z nich mogą opisywać potencjalne klasy. Wyróżnia się:

przedmioty namacalne (np. samochód, czujnik);

grupy przedmiotów namacalnych (np. kartoteka, samochód jako zestaw części);

role pełnione przez osoby (np. pracownik, wykładowca, student);

zdarzenia, o których system przechowuje informacje (np. lądowanie samolotu, wysłanie zamówienia, dostawa);

interakcje pomiędzy osobami i/lub systemami, o których system przechowuje informacje (np. pożyczka, spotkanie, sesja);

lokalizacje, czyli miejsca przeznaczone dla ludzi lub przedmiotów (np. budynek, magazyn);

organizacje (np. firma, wydział, związek);

wydarzenia (np. posiedzenie sejmu, demonstracja uliczna);

koncepcje i pojęcia (np. zadanie, miara jakości);

dokumenty (np. faktura, prawo jazdy).

Dodatkowo należy zwrócić uwagę na obiekty stanowiące pogranicze konstruowanego systemu, np. obiekty dostępne dla innych systemów, linie komunikacyjne itp.

(13)

Sygnały analogowe i cyfrowe

W przypadku sterowników PLC ich stan określaby jest przez zbiór sygna- łów wejściowych, zbiór sygnałów wyjściowych, oraz zbór zmiennych wewnętrznych (np. licznki, timery).

Sygnały wejściowe i sygnały wyjściowe sterowników PLC dzielimy na Sygnały analogowe (ciągłe): sygnały mogące przyjmować wszystkie wartości w normalnym przedziale pracy (zmienne ciągłe).

Sygnały cyfrowe: sygnały, których dziedzina i zbiór wartości są dyskretne (zmienne dyskretne).

Sygnały binarne: sygnały mogące przyjmować tylko 2 wartości (zmienne dwuwartościowe).

(14)

Opis struktury i diagramy opisu struktury

Istnieją trzy podstawowe rodzaje diagramów opisu struktury: diagram struktury, diagram składowych oraz diagram wdrożenia.

Diagram struktury jest generalizacją czterech konkretnych diagramów:

diagramu klas, diagramu obiektów, diagramu pakietów oraz diagramu komponentów.

Rysunek:Klasyfikacja diagramów opisu struktury w języku UML.

(15)

Diagram klas

Na diagramach klas umieszczamy przede wszystkim klasy (wraz z atrybu- tami i operacjami) oraz związki (ang. relationship) między klasami. Naj- częstszym rodzajem związków są asocjacje (ang. association), oznaczające np. powiązanie znaczeniowe pomiędzy pojęciami reprezentowanymi przez klasy.

Rysunek:Diagram klas.

(16)

Diagram obiektów

Na diagramie obiektów pokazujemy pojedyncze obiekty będące instancjami określonych klas oraz łączniki, będące instancjami asocjacji pomiędzy tymi klasami. Jest to opis wybranej sytuacji (źdjęcie”), w której obiekty i ich powiązania przyjmują konkretną konfigurację.

Rysunek:Diagram obiektów.

(17)

Diagram pakietów

Pakiety (ang. package) służą do hierarchicznego organizowania elementów modelu w celu zapewnienia przejrzystości i czytelności. Pakiety stanowi zbiór klas, asocjacji lub innych elementów modelu. Analogia: przestrzenie nazw w C++.

Rysunek:Diagram pakietów.

(18)

Diagram komponentów

Komponent (ang. component) jest elementem, który oprócz grupowa- nia elementów modelu, dostarcza również pewnej funkcjonalności innym elementom, komunikując się z wykorzystaniem odpowiednich interfejsów.

Komponenty, ich interfejsy oraz zależności pomiędzy nimi umieszczamy na diagramach komponentów. Interfejsy udostępniane przez komponent zaznaczane są w postaci kółek wystających z komponentu.

Rysunek:Diagram komponentów.

(19)

Diagram składowych

Możliwość umieszczania elementów wewnątrz innych elementów, dają diagramy składowych oraz diagramy wdrożenia. Umożliwiają one pokazanie elementów składowych klas, komponentów lub fizycznych elementów pro- jektowanego systemu.

Rysunek:Diagram składowych.

(20)

Diagram wdrożenia

Diagramy wdrożenia służą do pokazania fizycznej struktury systemu. Umiesz- czane na nich są węzły (ang. node), połączenia między nimi oraz artefakty (ang. artifact). Węzły odpowiadają fizycznym elementom systemu.

Węzeł może reprezentować np. sterownik PLC, moduł HMI, lub wyspę We/Wy typu IIoT.

Artefakty, są to fizyczne elementy informacyjne używane w procesie wytwa- rzania oprogramowania np. schematy baz danych, dokumenty tekstowe.

Dzięki diagramom wdrożenia możliwe jest dodatkowo modelowanie fizycznej infrastruktury sprzętowej, na której oprogramowanie będzie wdrożone.

(21)

Diagram wdrożenia

Rysunek:Diagram wdrożenia.

(22)

Ogólne projektowanie diagramów struktury

Wszystkie przedstawione diagramy opisu struktury mogą być wykorzysty- wane podczas modelowania statycznych aspektów budowy systemów oprogramowania.

Nie zawsze jest jednak potrzeba stosowania wszystkich tych diagramów w projekcie. Do wielu zastosowań wystarczają jedynie podstawowe dia- gramy, takich jak diagramy klas, diagramy komponentów i diagramy wdrożenia.

Poziom szczegółowości rysowanych diagramów też powinien zależeć od tego, na jakim etapie projektowania systemu jesteśmy oraz od tego, kto będzie te diagramy czytał.

(23)

Opis dynamiki i diagramy opisu dynamiki

Modele dynamiki ukazują system w działaniu, dlatego też niezbędne jest pokazanie zmian w czasie. Powinny ukazywać kolejność czyn- ności wykonywanych przez system, bądź też kolejność interakcji za- chodzących pomiędzy systemem i jego użytkownikami.

Model dynamiki musi też mieć ścisły związek z modelem struktury, ponieważ modele dynamiki ukazują elementy struktury w działaniu.

Istnieją cztery podstawowe rodzaje diagramów opisu struktury: diagram przypadków użycia, diagram interakcji, diagram czynności oraz dia- gram maszyny stanów. Diagram interakcji jest on generalizacją czterech konkretnych diagramów: diagramu sekwencji, diagramu komunikacji, diagramu opisu interakcji oraz diagramu następstwa

(24)

Opis dynamiki i diagramy opisu dynamiki

Rysunek:Klasyfikacja diagramów opisu dynamiki w języku UML.

(25)

Diagram przypadków użycia

Diagram przypadków użycia opisuje funkcjonalność systemu z punktu widzenia jego użytkowników. Przypadki użycia (ang. use case) są jednostkami opisu dynamiki, które prezentują zewnętrzny sposób zachowania się systemu. Przypadek użycia jest zbiorem scenariuszy (ang. scenario). Scenariusze, z kolei, są sekwencjami interakcji, które prowa- dzą do celu określonego przez przypadek użycia. Sekwencję interakcji inicjuje zazwyczaj jakiś obiekt spoza systemu, zwany aktorem (ang. actor ). Sekwencja interakcji może skończyć się osiągnięciem celu przypadku użycia, bądź niepowodzeniem.

Rysunek:Diagram przypadków użycia.

(26)

Diagram czynności

Diagramy czynności przedstawiają graf opisujący czynności, które są po- dejmowane w zależności od warunków zewnętrznych lub stanu systemu.

Czynność (ang. activity ) jest opisem zachowania się jakiegoś obiektu w modelowanym systemie. W szczególności może to być opis zachowania się systemu jako całości. Czynność może zatem opisywać pojedynczą operację klasy lub jeden przypadek użycia systemu. Zasadniczo, czynność składa się z akcji (ang. action), węzłów decyzyjnych (ang. decision node) oraz połączeń reprezentujących przepływ sterowania (ang. control flow ).

Wykonywanie akcji rozpoczyna się od węzła początkowego (ang. initial node) oznaczonym jako czarna kropka i kończy na węźle końcowym (ang.

final node) oznaczonego jako czarna kropka otoczona okręgiem.

(27)

Diagram czynności

Rysunek:Diagram czynności.

(28)

Diagram sekwencji

Podczas modelowania systemu jako zbioru komunikujących się obiektów, potrzebujemy sposobu na pokazanie ciągów komunikatów wymienianych między obiektami. Komunikaty wymieniane są pomiędzy liniami życia obiek- tów, które określają czas życia obiektów. Ciąg komunikatów wymienianych pomiędzy liniami życia nazywamy interakcją (ang. interaction).

Na diagramach sekwencji możemy pokazać następstwo czasowe w sekwencji komunikatów. Linie życia są zaznaczone pionowymi przerywanymi liniami wychodzącymi z umieszczonych u góry obiektów lub aktorów. Ko- munikaty (wywoływane operacje) reprezentowane są przez poziome strzałki pomiędzy liniami życia. Komunikaty powrotne (zakończenie wykonywania operacji) oznaczane są przerywanymi strzałkami.

(29)

Diagram sekwencji

Rysunek:Diagram sekwencji.

(30)

Diagram komunikacji

Diagramy komunikacji niosą bardzo podobną zawartość informacyjną jak diagramy sekwencji, mają jednak inny układ. Komunikaty oznaczane są strzałkami i umieszczane obok łączników między obiektami. Komunikaty oznaczone są liczbami, które określają kolejność ich wykonania.

Rysunek:Diagram komunikacji.

(31)

Diagram opisu interakcji

Diagramy opisu interakcji pokazują następstwo interakcji. Przypominają one trochę diagramy czynności, gdyż bazują na notacji używanej na tam- tych diagramach. Różnica polega na tym, że poszczególne akcje zastąpione są interakcjami.

Diagramy opisu interakcji są przydatne w przypadku, kiedy chcemy zobrazować złożone czynności zawierające w sobie ciąg kolejnych interakcji między obiektami.

(32)

Diagram opisu interakcji

Rysunek:Diagram opisu interakcji.

(33)

Diagram następstwa

Diagramy następstwa używane są do pokazywania zmian stanu lub wartości jednego lub więcej elementów w czasie oraz pod wpływem komunikatów przesyłanych między obiektami.

Na diagramie następstwa możemy umieścić dwa rodzaje linii życia elemen- tów: linię życia stanu (ang. state lifeline) oraz linię życia wartości (ang.

value lifeline). Linia życia czasu pokazuje zmianę stanu obiektu w czasie.

Podziałka czasu jest pokazywana na osi poziomej. Oś pionowa zawiera możliwe stany obiektu.

(34)

Diagram następstwa

Rysunek:Diagram następstwa.

(35)

Diagram maszyny stanów

Diagramy maszyny stanów służą do pokazywania sposobu zachowa- nia się jakiegoś elementu modelu w postaci przejść pomiędzy jego stanami. Stan oznacza pewną stabilną sytuację elementu, w jakiej może się on znaleźć. Zmiany stanów elementu mogą następować pod wpływem określonych zdarzeń, np. komunikatów przesyłanych przez inne obiekty.

Diagramy takie zawierają przede wszystkim stany (ang. state) oraz przej- ścia (ang. transition) między stanami.

Stan jest reprezentowany przez zaokrąglony prostokąt, który zawiera w środku tekst opisujący stan. Przejścia pomiędzy stanami reprezentowane są poprzez strzałki. Obok przejścia można opcjonalnie umieścić nazwę komunikatu, który powoduje zmianę stanu oraz warunek zmiany stanu.

Stan początkowy określony jest przez węzeł początkowy a stan końcowy – przez węzeł końcow

(36)

Diagram maszyny stanów

Rysunek:Diagram maszyny stanów.

(37)

Ogólne projektowanie dynamiki

Model dynamiki pokazuje system w działaniu. Model dynamiki jest o tyle istotny, że podczas budowy oprogramowania staramy się zrealizować dy- namiczną funkcjonalność systemu odpowiadającą wymaganiom zamawia- jących.

Podobnie jak w przypadku diagramów statycznych, nie zawsze jest potrzeba stosowania podczas projektu wszystkich rodzajów diagramów dyna- micznych. Niektóre z nich używane są jedynie w specyficznych sytuacjach.

Np. diagram następstwa będzie najczęściej wykorzystywany do modelowania systemów czasu rzeczywistego (część układów sterowania PLC).

W przypadku większości systemów sterowania PLC, wystarczają je- dynie podstawowe diagramy, takie jak diagramy przypadków użycia, diagramy czynności czy diagramy sekwencji.

(38)

Analiza programu PLC przy pomocy języka UML

Analiza podzielona jest na kilka faz.

FAZA 1: określenie struktury systemu (klasy, obiekty, diagramy struktury) FAZA 2: określenie działania sterownika poprzez opisanie scenariuszy przypadków użycia.

FAZA 3: stworzenie diagramów przypadków użycia.

FAZA 4: określenie diagramów czynności, gdzie dokładniej analizuje się przepływ sygnałów sterujących i warunków rozdziału tych sygnałów.

FAZA 5: określenie diagramów sekwencji, które są połączeniem charakteru statycznego i dynamicznego potrzeb sterowania. Na diagramach tych w sposób przejrzysty widać interakcję pomiędzy instancjami programu.

FAZA 6: określenie diagramów maszyny stanów, które można bezpośrednio przełożyć na jezyki garfowe programowania PLC.

(39)

Przypadki użycia - budowa diagramu

Diagram przypadków użycia, reprezentowany jest przez zbiór przypadków użycia oraz zbiór aktorów wchodzących w interakcję z systemem za po- średnictwem tych przypadków, dostarcza opisu funkcjonalności systemu i jego kontekstu.

Na etapie tworzenia modelu przypadków użycia główny nacisk jest poło- żony na wymagania funkcjonalne, podczas gdy wymagania niefunkcjonalne stanowią warunki uzupełniające, wypełnieniem których należy zająć się na etapie projektowania.

Aby zapewnić używanie jednolitych terminów w trakcie tworzenia modelu, jednocześnie z nim musi powstawać słownik pojęć z dziedziny proble- mowej i/lub prosty model obiektowy dziedziny.

Tworzenie modelu przypadków użycia opiera się na czterech krokach i wymaga ścisłej współpracy z przyszłym użytkownikiem systemu.

Zasada: ”nie opisuj przypadków użycia w sposób, który nie jest łatwo zro- zumiały dla użytkownika”.

(40)

Przypadki użycia - budowa diagramu

Rysunek:Diagram maszyny stanów.

(41)

Przypadki użycia - Sporządzenie słownika pojęć

Krok 1: Sporządzenie słownika pojęć

Słownik pojęć dotyczy dziedziny problemowej, a tworząc go należy zwrócić uwagę na:

Wyłowienie z wymagań użytkownika tych pojęć, które odnoszą się do aktorów, przypadków użycia, obiektów, operacji, zdarzeń, itp.

Pojęcia w słowniku powinny być zdefiniowane w sposób precyzyjny i jednoznaczny.

Posługiwanie się pojęciami ze słownika powinno być regułą przy opisie każdego kolejnego problemu czy budowie każdego kolejnego modelu.

Kwalifikując pojęcia do słownika należy zwrócić uwagę na:

Rzeczowniki - mogą one oznaczać aktorów lub byty z dziedziny problemowej; np.

wózek, winda, przenośnik, operator etc.

Frazy opisujące funkcje, akcje, zachowanie - mogą one być podstawą do wyróżnienia przypadków użycia; np. przejazd do punktu X1, zrzut.

(42)

Przypadki użycia - Identyfikowanie aktorów

Krok 2: Identyfikowanie aktorów Pytania:

Jaka grupa użytkowników (procesów, systemów, urządzeń) potrzebuje wspomagania ze strony systemu (np. wysypisko, oczyszczalnia itp.)?

Jacy użytkownicy (procesów, systemów, urządzeń) są potrzebni do tego, aby system działał i wykonywał swoje funkcje (np. operator, wózek)?

Z jakich elementów zewnętrznych (innych systemów, czujników, sieci, procesów, urządzeń) musi korzystać system, aby realizować swoje funkcje (np. sieć wifi)?

Ustalanie potencjalnych aktorów musi być powiązane z ustaleniem zakresu odpowiedzial- ności systemu, co oznacza konieczność określenia granic systemu (tylko to co obejmuje).

Następnie ustala się

nazwę dla każdego aktora/roli;

zakresy znaczeniowe dla poszczególnych nazw aktorów oraz relacje pomiędzy wyspecyfikowanymi zakresami;

(niekiedy) hierarchię dziedziczenia dostępu do funkcji systemu, czyli strukturę generalizacji-specjalizacji dla aktorów.

(43)

Przypadki użycia - określanie przypadków użycia

Krok 3: określanie przypadków użycia

Dla każdego aktora określ zadania (funkcje), które powinien wykonywać w związku z działalnością w zakresie dziedziny problemowej i wspomagania działalności systemu. Nazwy powinny być krótkie, dotyczyć aktorów, i jednoznacznie określać charakter zadania.

Wyodrębnij ’zadania główne’, czyli te, które stanowią istotę współpracy z systemem. Pomiń czynności skrajne, wyjątkowe, uzupełniające lub opcjonalne.

Powiąż w jeden przypadek użycia zespół zadań realizujących podobne cele, unikając podprzypadków. Przeanalizuj podobieństwo nazw przypadków użycia.

Uporządkuj aktorów i przypadki użycia w postaci diagramu. Ustal, co jest zbędne, a co może być uogólnione.

Określ wzajemne relacje pomiędzy przypadkami głównymi, dla każdej relacji specyfikuj rodzaj zależności: podstawowa czy opcjonalna.

Dodaj zachowania skrajne, wyjątkowe, uzupełniające lub opcjonalne. Ustal powiązanie przypadków głównych z tego rodzaju zachowaniem; mogą być one także powiązane w pewną strukturę.

Tworząc podział każdego przypadku użycia na nazwane części (bloki) staraj się, aby nie były one, podobnie jak cały model, ani zbyt ogólne, ani zbyt szczegółowe.

Przeanalizuj istniejące przypadki pod kątem wyizolowania bloków ponownego użycia (funkcje).

(44)

Przypadki użycia - dokumentowanie przypadków użycia

Krok 4: dokumentowanie przypadków użycia Dokumentacja przypadków użycia powinna zawierać:

Diagramy przypadków użycia: aktorzy, przypadki użycia i relacje zachodzące między przypadkami.

Krótki, ogólny opis każdego przypadku użycia:

jak i kiedy przypadek użycia zaczyna się i kończy;

opis interakcji przypadku użycia z aktorami, m.in. kiedy interakcja ma miejsce i co jest przesyłane;

kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie, oraz jak i kiedy zapamiętuje dane w systemie;

wyjątki występujące przy obsłudze przypadku;

specjalne wymagania, np. czas odpowiedzi, wydajność;

jak i kiedy używane są pojęcia dziedziny problemowej.

Opis szczegółowy każdego przypadku użycia:

specyfikacja uczestniczących obiektów (opis, diagram klas - struktura).

scenariusz(e) (opis, diagram(y) interakcji, dynamika).

(45)

Przypadki użycia - Opis obiektów

Cechy obiektu:

Tożsamość (ang. identity ) obiektu jest cechą umożliwiającą jego identyfikację i odróżnienie od innych obiektów.

Stan (ang. state) obiektu jest określany przez aktualne wartości wszystkich jego właściwości.

Zachowanie (ang. behavior ) obiektu to zbiór działań (usług, ang.

service), które obiekt potrafi wykonać na rzecz innych obiektów.

Na tej podstawie buduje się przykładowe terminy ze słownika pojęć:

”Przenośnik - służy do przenoszenie odpadów z zakładu do wózka. Możliwy jest jego ruch w dwóch kierunkach, poziomo. Uruchamiany jest automa- tycznie lub ręcznie. Mozna go zatrzymać w dowolnym położeniu. Posiada czunkiki położenia (krańcówki). Nie można go obciązyć więcej niż ... .”

(46)

Przykładowy opis zadania - wózek do wyrzucania odpadów

(47)

Przypadki użycia - Scenariusze

Opis przypadków użycia przy pomocy zdań w języku naturalnym, używa- jąc terminów zdefiniowanych w słowniku pojęć. Podstawę do stwierdzenia, czy opis jest wystarczająco szczegółowy, stanowią odpowiedzi na pytania:

czy wszyscy uczestnicy projektu rozumieją znaczenie przypadku?; czy dokumentacja jest wystarczająco szczegółowa dla projektantów i testerów?

Scenariusz powinien zawierać Nazwa

Cele:

Warunek początkowy:

Sposób działania:

Wynik działania:

Błędy:

(48)

Przypadki użycia - Scenariusze

Przykład opisu scenariusza 4.1.1 Logowanie

Cele:

Uzyskanie dostępu do systemu.

Warunek początkowy:

Użytkownik nie jest zalogowany.

Osoba logująca się jest zarejestrowanym użytkownikiem systemu.

Scenariusz działania:

Wyświetlenie okna logowania.

Wpisanie nazwy użytkownika i hasła.

Program weryfikuje poprawność wprowadzonych danych.

Wynik działania:

Uzyskanie dostępu do funkcji programu.

Błędy:

Użytkownik podał błędne dane. (Wyświetlenie komunikatu. Powrót do okna logowania.)

(49)

Przykładowy opis zadania - wózek do wyrzucania odpadów

(50)

Zaawansowane Układy Sterowania PLC

Wykład 3 - Zastosowanie notacji UML w projektowaniu aplikacji PLC.

Analiza procesu. Maszyna stanów.

dr inż. Jakub Możaryn, dr inż. Piotr Wasiewicz

Instytut Automatyki i Robotyki

Warszawa, 2018