Metodyka RUP i język UML w projektowaniu inżynierskim

Pomiary Automatyka Robotyka 2/2005
Metodyka RUP i język UML
w projektowaniu inżynierskim
Zbigniew Mrozek*
Metodyka RUP (Rational Unified Process) i język UML pozwalają na
zidentyfikowanie i usunięcie na wstępnych etapach projektowania znacznej
części zagrożeń, które mogłyby spowodować fiasko projektu, względnie
znaczne przekroczenie jego budżetu i czasu realizacji.
Z
asadniczym celem projektanta jest przygotowanie nowego lub ulepszonego produktu, który
będzie konkurencyjny na rynku. Realizacja tego celu wymaga stosowania odpowiednich narzędzi
wspomagających projektowanie. Szybkie wprowadzenie na rynek produktu o wymaganych właściwościach
i odpowiedniej jakości daje szansę uzyskania dodatkowego zysku (first to market premium), jeśli tylko konkurenci nie zaoferują podobnego wyrobu.
Projektowanie złożonego produktu (systemu) może
stanowić poważne wyzwanie organizacyjne, naukowe
i logistyczne [6]. Typowymi zagrożeniami są: przekroczenie budżetu i/lub terminu zakończenia prac, a nawet
kompletne fiasko projektu. Niechlubnym przykładem
był wadliwy system zarządzania bagażami na lotnisku
Denver International Airport, otwartym w lutym 1995,
z 16-miesięcznym opóźnieniem. Spowodowane tymi
błędami przekroczenie budżetu wyniosło około 300 milionów USD [1].
Projektowanie jako element cyklu życia
produktu
usprawnienia wczesnych etapów projektowania, to jest
przygotowania specyfikacji wymagań oraz projektowania koncepcyjnego.
Projektowanie systemów
z wykorzystaniem RUP
W wielu firmach już w latach 90. ubiegłego wieku opracowywano zalecenia i procedury pozwalające zmniejszyć ryzyko związane z realizacją dużych projektów.
Analiza przebiegu realizacji dużych systemów informatycznych pozwoliła stwierdzić, że istotne jest precyzyjne określenie rzeczywistych wymagań zleceniodawcy
oraz wczesne eliminowanie zagrożeń wystąpienia poważniejszych przeszkód w realizacji projektu. Weryfikacja wymagań zleceniodawcy (pod kątem ich kompletności, braku wzajemnych konfliktów i możliwości
realizacji) powinna być niezwykle staranna i możliwie
wcześnie prowadzona.
RUP i powstanie języka UML
Jednym z udanych rozwiązań wspomagających projektowanie jest metodyka i środowisko RUP (Rational Unified Process) [16, 2]. Stworzono ją poprzez zintegrowanie metodyki Rational Approach opracowanej przez
Boocha i Rumbaugha z metodyką
Objectory process Ivara Jacobsona
ze Szwecji.
Do projektowania wykorzystuje
się narzędzia wspomagające modelowanie i symulację na wysokim poziomie abstrakcji. Istotne jest też zaplanowanie i śledzenie postępów
realizacji projektu oraz wspomaganie pracy zespołowej projektantów
— szczególnie, jeśli reprezentują oni
różne specjalności. Ponadto poprzez
Rys. 1. Typowy cykl życia wyrobu
serwery WWW udostępnia się modele i automatycznie tworzone ra* dr inż. Zbigniew Mrozek – Wydział Inżynierii Elektrycznej
porty.
i Komputerowej, Politechnika Krakowska
Twórcy RUP dostrzegli potrzebę
stworzenia nowego języka, który by
Typowy cykl życia produktu obejmuje jego projektowanie, implementację, produkcję, eksploatację oraz utylizację (rys. 1). W artykule przedstawiono propozycje
18
Pomiary Automatyka Robotyka 2/2005
uporządkował niespójną notację odziedziczoną po wcześniej stosowanych metodykach. Rezultatem ich pracy
była wstępna wersja języka UML. Jego specyfikacja została powszechnie udostępniona poprzez dobrowolne
jej zgłoszenie jako odpowiedź na RFP (request for proposal) ogłoszone przez niekomercyjną organizację OMG
(object managment group). W 1997 roku UML 1.1 został
ogłoszony jako jedna z technologii zaadoptowanych
przez OMG [12]. Aktualnie każdy może bez opłat wykorzystywać specyfikację i diagramy tego języka, a dalszy jego rozwój jest koordynowany przez OMG. W rezultacie język UML jest rozwijany przez wiele firm, a oferta
narzędzi wspomagających projektowanie z wykorzystaniem języka UML szybko wzrasta. W ubiegłym roku oferowano ponad 100 takich produktów komercyjnych
i bezpłatnych. Wykaz takiego oprogramowania znajduje się na stronie http://www.objectsbydesign.com/
tools/umltools_byProduct.html
Zalecenia dobrej praktyki inżynierskiej
Istotnym elementem RUP są zalecenia dobrej praktyki
inżynierskiej (best practices) [15, 13]. Większość tych
zaleceń może być z powodzeniem wykorzystana w projektowaniu procesów technologicznych, systemów sterowania, wyrobów mechatronicznych i innych [5, 7–10].
Najważniejsze z nich to:
1. Zarządzaj wymaganiami. Jak najwcześniej wdrażaj
konieczne zmiany i badaj ich skutki
2. Określ główne zagrożenia i wcześnie im zapobiegaj, a pomoże to ochronić się przed fiaskiem projektu
3. Wykorzystuj gotowe elementy i podzespoły
4. Modeluj system graficznie (np. z użyciem UML)
5. Projektuj iteracyjnie, zapewnij wysoką jakość już
podczas projektowania, a nie dopiero po badaniu
lub awarii prototypu
6. Pracuj zespołowo
7. Zadowolenie klienta i odbiorcy to twój cel nadrzędny.
RUP: fazy i aktywności projektu
W RUP określa się cztery fazy realizacji projektu: faza
wstępna (inception), projektowanie koncepcyjne (elaboration), projektowanie szczegółowe z prototypowaniem (construction) oraz wdrożenie, produkcja i przygotowanie do dystrybucji (transition). Przejście do
każdej następnej fazy projektowania jest uzależnione
od spełnienia warunków określonych przez „kamień
milowy” (milestone). Na przykład przejście do fazy wdrożenia może być uwarunkowane spełnieniem wszystkich
następujących warunków:
uzyskanie pełnej funkcjonalności i stabilności opracowanych wcześniej rozwiązań
nieprzekroczenie budżetu poprzedniej fazy projektu i brak istotnych opóźnień w realizacji projektu
uzyskanie zgody sponsorów na dalszą realizację projektu.
Użyteczność diagramów UML w projektowaniu
systemów i wyrobów
Język UML pozwala na opisanie (na wysokim poziomie
abstrakcji) funkcji, zadań i wzajemnej współpracy różnych elementów projektowanego systemu — niezależnie od ich natury fizycznej. Diagramy UML pozwalają
na tworzenie modeli projektowanego systemu na różnych poziomach szczegółowości oraz na skuteczne komunikowanie się i wzajemne zrozumienie projektantów, nawet specjalistów z różnych dziedzin.
Wizualizacja i animacja pracy projektowanego systemu (np. za pomocą diagramów UML) pozwala zweryfikować jego działanie i zbadać zgodność ze specyfikacją
wymagań. Co ważniejsze, weryfikację tę wykonuje się zanim zostanie podjęta decyzja o budowie kosztownego
prototypu systemu lub jego części. Tworzenie modeli
na wysokim poziomie abstrakcji umożliwia badanie i poprawianie koncepcji projektowanego produktu bez ponoszenia dużych kosztów i bez straty czasu na budowę
i poprawianie modelu szczegółowego (czy też prototypu fizycznego). Prototyp fizyczny powinien być zbudowany dopiero po wszechstronnym zweryfikowaniu modeli przygotowanych w UML oraz po zbudowaniu
i przetestowaniu modeli szczegółowych. Modele szczegółowe buduje się z wykorzystaniem narzędzi specjalistycznych jak MATLAB/Simulink, pakiety CAD/CAM
i EDA (electronic design automation) oraz inne — zgodnie z potrzebami. Istotnym elementem projektowania
i weryfikacji produktu może też być wirtualne modelowanie fizyczne, opisane w [11].
Przygotowanie specyfikacji wymagań
dla projektowanego produktu
Opis tekstowy wymagań dla projektowanego produktu może być trudny do zweryfikowania pod kątem kompletności, precyzji opisu i braku wewnętrznych sprzeczności. Duża objętość dokumentacji tekstowej i liczne,
szczegółowe rysunki mogą skutecznie utrudnić weryfikację takiej dokumentacji. Ponadto pewna dowolność
interpretacji użytych pojęć i fragmentów tekstu może być
powodem nieporozumień podczas realizacji projektu.
Zalecanym podejściem jest sformalizowanie opisu
wymagań poprzez przygotowanie scenariuszy i diagramów przypadków użycia w języku UML. Mogą być one
tworzone przy czynnym udziale klienta. Klient może
nie mieć żadnego przygotowania w zakresie modelowania, ale po krótkim objaśnieniu powinien prawidłowo odczytywać i weryfikować te diagramy pod kątem
właściwego uwzględnienia potrzebnych mu funkcji
i usług. Dodatkowo można wspólnie przygotować słownik z objaśnieniami pojęć, które mogą być inaczej rozumiane przez projektantów i zleceniodawcę.
Na przykład, jeśli przedmiotem projektu jest układ
sterowania żurawia do przeładunku towarów, to zleceniodawca może wymagać, aby:
19
Pomiary Automatyka Robotyka 2/2005
minimalizować czas przenoszenia ładunku, przy zachowaniu wymaganej precyzji jego umieszczenia
w miejscu docelowym
ruchy żurawia nie powodowały oscylacji ładunku,
a istniejące oscylacje były skutecznie tłumione podczas ruchu żurawia
zmiany parametrów żurawia (jego konfiguracji i długości liny) oraz ładunku (masy, kształtu i wymiarów),
a także warunków atmosferycznych (wiatr) nie pogarszały skuteczności tłumienia oscylacji.
Wymagania te przedstawia się w postaci scenariuszy
i diagramu przypadków użycia (rys. 2) oraz w razie potrzeby w postaci dodatkowych komentarzy i opisu tekstowego. Scenariusz opisuje sekwencję zdarzeń, w których zewnętrzni aktorzy współdziałają z obiektami
należącymi do systemu. Zdefiniowanie aktorów (człowiek względnie zewnętrzny system albo obiekt) jest niezwykle istotne, gdyż pozwala na precyzyjnie określenie
granicy pomiędzy projektowanym systemem a jego otoczeniem. Poniżej podano przykład scenariusza opisującego pracę żurawia portowego. Dodatkowe scenariusze mogą opisywać inne warianty pracy żurawia oraz
działania w stanach awaryjnych.
„Operator żurawia, po uzyskaniu potwierdzenia prawidłowego umocowania ładunku, włącza silnik wciągarki i unosi ładunek na wysokość ok. 4 m, po czym
przenosi go w kierunku miejsca rozładowania. Ładunek jest opuszczany precyzyjnie w miejscu wskazanym
przez obsługę naziemną ładunku — z zachowaniem
dużej ostrożności i po wytłumieniu jego oscylacji.”
Projektowanie koncepcyjne
z wykorzystaniem diagramów UML
Celem tej fazy projektowania jest:
opracowanie stabilnej struktury wewnętrznej (architektury) projektowanego systemu
wykrycie i usunięcie zagrożeń powodowanych przez
błędy w specyfikacji wymagań oraz ewentualne błędy w modelach tworzonych w tej i w poprzedniej fazie projektowania.
Projektowanie koncepcyjne w istotnym stopniu wpływa na jakość projektowanego produktu poprzez wczesne eliminowanie zagrożeń oraz przez wielokrotną (po
każdym cyklu iteracji) weryfikację zgodności ulepszanej wersji projektu z wymaganiami. Projektowanie jest
wspomagane przez odpowiednie narzędzia CASE (computer aided system engineering) np. [14, 15, 17].
Określenie struktury budowanego
systemu
Analiza diagramu przypadków użycia i scenariuszy pozwala na zidentyfikowanie obiektów, czyli elementów systemu (lub podsystemu), które są odpowiedzialne za realizację określonych usług i funkcji. Możliwe jest też
określenie, które obiekty ze sobą współpracują. Podobne obiekty grupuje się w klasy, które definiują typ obiektu i jego właściwości, w tym atrybuty (nazwy i typy parametrów, których wartości określają stan obiektu) oraz
operacje, czyli funkcje i usługi realizowane przez każdy
obiekt danej klasy. Przykładowo enkoder wału wciągarki jest obiektem klasy Czujniki (rys. 3).
Wstępną propozycję struktury projektowanego systemu lub jego części można przedstawić na diagramie
klas (rys. 3). Ikony klas i obiektów mają postać prostokątów. W środkowej części ikony można podać atrybuty, a w dolnej operacje. Współpracujące klasy lub obiekty są połączone poprzez różne relacje, pokazane jako
linie na diagramie.
Rys. 2. Diagram przypadków użycia pokazuje współpracę
zewnętrznych aktorów z projektowanym systemem.
Aktorami są ludzie (np. operator żurawia), ale też ładunek i czynniki zakłócające pracę systemu
Diagram przypadków użycia może być modyfikowany na ekranie
komputera, a brak jego zgodności
z opisem tekstowym lub rzeczywistymi wymaganiami przyszłego użytkownika może być łatwo wykryty.
Na rys. 2 pokazano, że zmiana parametrów żurawia (np. wydłużenie
liny, opuszczanie bomu) oraz wiatr
wpływają na przemieszczanie ładunku. Zwraca się uwagę na strzałki, które pokazują kierunek inicjowania interakcji pomiędzy elementami tego
diagramu.
20
Rys. 3. Diagram klas pokazuje strukturę wewnętrzną projektowanego systemu.
Pokazano parametry i operacje dla wybranych klas
Pomiary Automatyka Robotyka 2/2005
Weryfikacja scenariusza i diagramu klas
Rys. 4. Diagram sekwencyjny pokazuje realizację wybranego scenariusza przez
obiekty z diagramu klas, z wykorzystaniem atrybutów i operacji tych klas
Diagram sekwencyjny (rys. 4) pokazuje, jak obiekty z diagramu klas realizują kolejne funkcje opisane przez wybrany scenariusz. Podobne możliwości ma diagram
współpracy (kolaboracji) [10]. Brak precyzji scenariusza lub błędy diagramu klas uniemożliwią przygotowanie diagramu sekwencyjnego. Oznacza to wykrycie błędów, które są zagrożeniem dla realizacji projektu. Po ich
poprawieniu należy powrócić do przygotowywania diagramów. Pozwoli to zweryfikować poprawność kolejnej wersji budowanego systemu.
Weryfikacja odpowiedzialności podsystemów
i ich elementów
Na diagramie stanów (rys. 5) sprawdza się, czy można prawidłowo zrealizować wszystkie sytuacje, które mogą wystąpić w pełnym cyklu życia produktu lub jego podsystemu. Służy to zweryfikowaniu właściwości behawioralnych całego systemu lub jego elementów składowych
(podsystem lub jego część opisana przez: przypadek użycia, klasę lub obiekt). Stany, w których dany element może się znajdować są przedstawione przez prostokątne
ikony z zaokrąglonymi brzegami.
Dopuszczalne przejścia pomiędzy stanami są oznaczone liniami ze strzałką pokazującą kierunek przejścia.
Wnioski końcowe
W pracy przedstawiono metodykę RUP i pakiety wspomagające projektowanie graficzne, do modelowania systemów na wysokim poziomie abstrakcji, z użyciem języka UML.
Głównym celem projektowania wstępnego jest opracowanie struktury projektowanego produktu (lub systemu) oraz wykrycie i eliminacja zagrożeń, mogących
utrudnić lub uniemożliwić zrealizowanie projektu. Wczesne wykrycie zagrożeń (przed rozpoczęciem szczegółowego projektowania podsystemów) obniża koszty ich
usunięcia, zmniejsza straty czasu i ułatwia zapewnienie
wymaganej jakości produktu końcowego. Pozwala to
zrealizować nadrzędny cel projektanta: zadowolenie zleceniodawcy [10, 18].
Bibliografia
1.
2.
3.
4.
Rys. 5. Diagram stanów pokazuje wszystkie dopuszczalne
stany dla projektowanego systemu lub wybranego podsystemu oraz warunki przejścia i realizowane operacje.
Pokazany tutaj sterownik poślizgowy [4, 8] można stosować w obiektach nieliniowych i niestacjonarnych
Obok każdego przejścia podaje się
warunek realizacji tego przejścia
lub nazwę zdarzenia inicjującego
to przejście. Idea tych diagramów
jest oparta na maszynie stanów Harela [3].
Pomimo, że diagramy stanu są elementem języka UML wspieranego
przez liczne narzędzia CASE [14, 17],
to znacznie większe możliwości ma
pakiet Stateflow ze środowiska MATLAB/Simulink [4]. Prócz animacji stanów umożliwia on automatyczne generowanie oprogramowania czasu
rzeczywistego dla modeli Simulinka
zawierających diagramy stanu. Należy jednak dodatkowo mieć oprogramowanie RTW i StateflowCoder.
Jeśli pewne czynności można wykonywać równolegle w tym samym
czasie, to można to pokazać i zweryfikować na diagramie aktywności
opisanym w [6, 10].
5.
Bruegge B, Dutoit A, Object-Oriented Software Engineering: Conquering Complex and Changing Systems, Prentice-Hall, 1999.
Jacobson I., Booch G, and Rumbaugh G. The Unified Software Development Process Addison-Wesley,
1999.
Harel D., Statecharts: A visual formalism for complex syst, Sci of Comp. Programming, 1987, No 8,
pp. 231–274.
Mrozek B, Mrozek Z., MATLAB i Simulink, poradnik
użytkownika, Wydawnictwo Helion, 2004.
Mrozek Z.: Wykorzystanie UML i Modeliki w szybkim
projektowaniu mechatronicznym, [w: ] Projektowanie Mechatroniczne, Zagadnienia wybrane, praca
21
Pomiary Automatyka Robotyka 2/2005
6.
7.
8.
9.
10.
zbiorowa pod red. T. Uhla, Zespół Mechatroniki
Komitetu Budowy Maszyn PAN, Wydawnictwo Katedry Robotyki i Dynamiki Maszyn, AGH Kraków,
2002, s. 16–35.
Mrozek Z.: Importance of early design phase in mechatronic design, Proc. 10-th IEEE International Conference on Methods and Models in Automation and
Robotics MMAR, pp. 1131–1136, Międzyzdroje, Poland, 2004.
Mrozek Z.: Computer aided design of mechatronic
systems, International Journal of Applied Mathematics and Computer Science, vol 13 No 2, 2003,
pp. 255–267.
Mrozek Z., Tarasiewicz S.: Attempting sliding mode
controller to mobile robot arc welding process,
pp. 369–373, ed R. Tadeusiewicz, A. Ligęza, M. Szymkat, III Krajowa Konf. Metody i Systemy Komputerowe, Kraków 19–21 listopada 2001.
Mrozek Z.: UML as integration tool for design of the
mechatronic system, Second Workshop on Robot
Motion and Control, pp. 189–195, Oct 18–20, Bukowy Dworek, 2001.
Mrozek Z.: Komputerowo wspomagane projektowanie systemów mechatronicznych, Zeszyty Nauko-
11.
12.
13.
14.
15.
16.
17.
18.
we Politechniki Krakowskiej, seria Inżynieria Elektryczna i Komputerowa, nr 1, 2002.
Mrozek Z.: Modelowanie fizyczne, PAR 4/2004
s. 18–23.
OMG Unified Modeling Language Homepage http:
//www.omg.org/uml
Probasco L.: The Ten Essentials off RUP, the essence off an effective development process, TP177 9/00,
Rational Software Corporation, 2000.
Rational Rose, Rational Rose RT Rational Software
Corporation, http://www.rational.com/products/
rose/
Rational Unified Process, Best Practices for Software Development Teams, Rational Software White
Paper, TP026B, Rev 11/01.
Rational Unified Process, http://www.rational.
com/products/rup/
Real-time Studio, ARTiSAN Software Tools, Inc.
http://www.artisansw.com/
Uhl T. (red.), Bojko T., Mrozek Z., Petko M., Szwabowski W., Korendo Z., Bogacz M.: Wybrane problemy projektowania mechatronicznego, Wydawnictwo Katedry Robotyki i Dynamiki Maszyn, AGH
Kraków, 1999.
Nowe władze Polskiego Stowarzyszenia
Pomiarów, Automatyki i Robotyki
POLSPAR
15 grudnia 2004 roku odbyło się Walne Zgromadzenie Delegatów Polskiego Stowarzyszenia Pomiarów, Automatyki i Robotyki.
Prezes POLSPAR prof. Tadeusz Puchałka złożył
sprawozdanie z działalności Zarządu w minionej
kadencji, a szczegółowe sprawozdania z działalności poszczególnych Komitetów przedstawili: prof.
Andrzej Masłowski (Komitet Robotyki) prof. Janusz
Mindykowski (Komitet Pomiarów) oraz prof. Tadeusz Puchałka (Komitet Automatyki). Sprawozdanie
finansowe złożył skarbnik dr Jan Barczyk. W tej części zebrania prof. Jerzy Kurek przedstawił sprawozdanie Przedstawiciela POLSPAR w Radzie Federacji NOT. Sprawozdanie Komisji Rewizyjnej przedstawił prof. Tadeusz Missala — Komisja zgłosiła wniosek o udzielenie absolutorium ustępującemu Zarządowi.
W dyskusji nad sprawozdaniami podkreślono konieczność współpracy POLSPAR z odpowiednimi
Komitetami PAN oraz współpracy z przemysłem,
zwłaszcza konieczność pozyskiwania członków
wspierających.
Delegaci Walnego Zgromadzenia POLSPAR wybrali na następną kadencję Prezesa Stowarzyszenia
22
Prezes Stowarzyszenia POLSPAR
– dr hab. inż. Wiesław Winiecki
z Politechniki Warszawskiej
dr. hab. inż. Wiesława Winieckiego z Politechniki
Warszawskiej oraz Zarząd w składzie: Jan Barczyk
(skarbnik), Małgorzata Kaliczyńska, Józef Korbicz,
Jan Maciej Kościelny, Zdzisław Kowalczuk, Dorota
Kozanecka, Jerzy Kurek, Andrzej Masłowski, Krzysztof Mianowski, Janusz Mindykowski, Zbigniew Pilat,
Tadeusz Ustaborowicz, Jarosław Warczyński, Romuald Zielonko.
Do Komisji Rewizyjnej wybrano 5 osób: Tadeusza
Missalę, Andrzeja. Kasińskiego, Mariusza Olszewskiego, Jerzego Honczarenkę, Bolesława Tynca. Przewodniczącym Komisji Rewizyjnej został ponownie
prof. Tadeusz Missala.
Delegaci przyjęli Uchwałę Walnego Zgromadzenia POLSPAR określającą kierunki działalności
Stowarzyszenia w latach 2005–2007.
dr inż. Jan Barczyk