UML i Executable UML



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

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta

Podstawy programowania III WYKŁAD 4

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela

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

WPROWADZENIE DO UML-a

Wprowadzenie do UML, przykład użycia kolizja

Diagramy UML, przykład problemu kolizji

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

PRZEWODNIK PO PRZEDMIOCIE

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

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

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

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego

Metodologie projektowania rozproszonych baz danych w języku UML 2.0

UML w Visual Studio. Michał Ciećwierz

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

Podstawy modelowania programów Kod przedmiotu

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania

Narzędzia CASE dla.net. Łukasz Popiel

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

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

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

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

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)

Rok akademicki: 2014/2015 Kod: IEL s Punkty ECTS: 5. Poziom studiów: Studia I stopnia Forma i tryb studiów: -

Podstawy inżynierii oprogramowania

Wytwarzanie oprogramowania

Wykład 1 Inżynieria Oprogramowania

Wykorzystanie standardów serii ISO oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

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

Diagramy czynności Na podstawie UML 2.0 Tutorial

Unified Modeling Language

Inżynieria oprogramowania. Jan Magott

SVN. 10 października Instalacja. Wchodzimy na stronę i pobieramy aplikację. Rysunek 1: Instalacja - krok 1

Technologie informacyjne - wykład 12 -

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz

PRZEWODNIK PO PRZEDMIOCIE

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

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08

Modele bezpieczeństwa logicznego i ich implementacje w systemach informatycznych / Aneta Poniszewska-Marańda. Warszawa, 2013.

Projekt systemu informatycznego

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej

KIERUNKOWE EFEKTY KSZTAŁCENIA

MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI

Opis metodyki i procesu produkcji oprogramowania

Procesowa specyfikacja systemów IT

INŻYNIERIA OPROGRAMOWANIA. laboratorium

WOJSKOWA AKADEMIA TECHNICZNA

REFERAT PRACY DYPLOMOWEJ

Tworzenie aplikacji bazodanowych

STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe

REFERAT O PRACY DYPLOMOWEJ

PRZEWODNIK PO PRZEDMIOCIE

INŻYNIERIA OPROGRAMOWANIA

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

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

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

MiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

Podczas dziedziczenia obiekt klasy pochodnej może być wskazywany przez wskaźnik typu klasy bazowej.

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Zasady organizacji projektów informatycznych

Egzamin / zaliczenie na ocenę*

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI

Informatyczne fundamenty

INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Wykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Inżynieria oprogramowania

Procesy biznesowe w praktyce. Przykłady użycia z wykorzystaniem jbpm 4.4

Projektowanie baz danych za pomocą narzędzi CASE

Wykład I. Wprowadzenie do baz danych

Modelowanie obiektowe - Ćw. 3.

WYMAGANIA EDUKACYJNE

Piotr Bubacz Cloud Computing

PRZEWODNIK PO PRZEDMIOCIE

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Projektowanie systemów informatycznych. wykład 6

Wykład 6 Metodyki wytwarzania oprogramowania internetowego. Wykładowca: dr inż. Mariusz Trzaska

Dokument Detaliczny Projektu

2/4. informatyka" studia I stopnia. Nazwa kierunku studiów i kod. Informatyka WM-I-N-1 programu wg USOS. Tytuł zawodowy uzyskiwany przez

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

Uniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013

Michał Adamczyk. Język UML

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

Programowanie obiektowe

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor

SCENARIUSZ LEKCJI. Streszczenie. Czas realizacji. Podstawa programowa

Modelowanie i analiza systemów informatycznych

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Podstawy programowania

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

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

Wzorce projektowe i refaktoryzacja

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia)

Technologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania

Transkrypt:

1. Wstęp Alicja KILIŃSKA-WIŚNIEWSKA Politechnika Koszalińska, Wydział Elektroniki i Informatyki E-mail: alicja.kilinska.wisniewska@gmail.com UML i Executable UML Na samym początku należałoby krótko scharakteryzować potrzebę stosowania modelowania przy użyciu języków typu UML podczas tworzenia rozproszonych systemów. Obecnie rozwijający się rynek korporacji wymusza na deweloperach oraz użytkownikach końcowych korzystanie z różnych systemów klienckich do projektowana i zarządzania bazami danych. Każda korporacja posiada własny zaimplementowany system oparty zwykle na innym systemie niż inne korporacje. Nie jest to czymś złym dopóki nie zaistnieje potrzeba komunikacji i przesyłania danych pomiędzy tymi systemami. Podobna sytuacja może zaistnieć podczas gdy jedne konsorcjum wykupuje drugie konsorcjum i przejmuje jego cały system informatyczny wraz z wdrożonym systemem. Uzyskamy wtedy sytuację w której główne centrum firmy będzie musiało korzystać z dwóch odrębnych systemów baz danych, np. Microsoft SQL Server i Oracle Database. W takim przypadku mamy do czynienia z heterogenicznymi rozproszonymi bazami danych. Obecnie nie odnaleziono rozwiązania jak w prosty i nie ingerencyjny sposób łączyć ze sobą dwa lub więcej rozproszone heterogeniczne systemy bazodanowe, aczkolwiek pewne problemy, które mogą wystąpić w przyszłości można już wykluczyć na etapie samego projektowania systemu dla jednego konsorcjum przy założeniu, że kiedyś może zaistnieć potrzeba połączenia tego systemu z innym. Stwarza to duże pole manewru i doskonałe możliwości do rozwoju języków modelowania i do badania ich zastosowań podczas modelowania rozproszonych systemów bazodanowych. Artykuł został poświęcony budowie i zastosowaniu języka xuml oraz językowi UML w wersji 2.0, gdyż prace nad starszymi wersjami nie są już wspierane przez konsorcjum OMG. 2. UML wprowadzenie Język UML powstał w listopadzie 1997 roku w połączeniu prac trzech naukowców Jamesa Rumbaugha, Grady go Boocha oraz Ivara Jacobsona. Każdy z nich już wcześniej próbował opracować język graficzny który pozwalałby w prosty i intuicyjny sposób przedstawić programiście wymagania projektowanego systemu, jednak dopiero po połączeniu ich sił powstał język UML, który do dzisiaj jest standardem i obecnie jest już w wersji 2.0. Został on oficjalnie uznany poprzez konsorcjum OMG, które podjęło się prowadzenia jego dalszego rozwoju. 3. Motywacja UML Język UML został przyjęty entuzjastycznie przez grono projektantów i programistów, gdyż przedstawia on potrzeby i wymagania w sposób nie związany z żadnym środowi-

56 Alicja Kilińska-Wiśniewska skiem programistycznym. Projekty są tworzone w sposób graficzny, co pozwala je później przenieść sprawnie na każdą platformę językową. Przede wszystkim jednak istotną kwestią stało się samo modelowanie przed przystąpieniem do pracy, gdyż programiści już na starcie pracy byli w stanie wykluczyć większość błędów które mogłyby w późniejszym czasie znacznie spowolnić prace nad projektem. Każda część przedstawionego problemu w sensie projektowanego systemu lub aplikacji może zostać rozpatrzona pojedynczo, a następnie złożona w większą całość, projektant lub programista ma możliwość dopracowywania pojedynczych elementów systemu nad którym pracuje, aby finalnie móc je połączyć w jeden kompletny system. 4. UML charakterystyka Projektanci korzystający z języka UML mają w zasięgu szereg modeli, które mogą być zastosowane, aby przedstawić budowę systemu pod kątem obiektu jak i zamodelować zachowanie systemu w ramach czasowych. I tak diagramy dla ich lepszego zrozumienia pod kątem wykorzystania można podzielić na dwie kategorie: diagramy struktury, niezależne od czasu, diagramy dynamiki, istniejące w ramach czasowych. Poniższy schemat prezentuje podział diagramów języka UML pod kątem wykorzystania w ramach czasowych. Rys. 1. Podział diagramów w języku UML 2.0 Fig. 1. Division diagrams in UML 2.0 Najczęściej stosowanymi diagramami są diagram klas oraz diagram przypadków użycia. Diagram klas jest graficznym przedstawieniem statycznych i deklaratywnych elementów dziedziny przedmiotowej oraz związków pomiędzy nimi, natomiast diagram przypadków użycia jest graficznym przedstawieniem przypadków użycia, aktorów oraz związków między nimi występujących w danej dziedzinie przedmiotowej.

5. xuml wprowadzenie UML i Executable UML 57 Język executable UML w skrócie nazywany xuml wywodzi się z języka UML w jego wersji 1.x. Został stworzony na potrzeby grupy programistów i projektantów MMC (The Modular MissionComputer), która zajmowała się pracami nad samolotami F-16 (miała pozwolić na wykonanie wymogów tzw. misji 21-go wieku). Aktualizacje MMC w połowie zapewniają zwiększoną moc obliczeniową samolotu pod względem awioniki oraz systemów uzbrojenia. Oryginalnie zespół korzystał podczas pracy nad aktualizacjami z narzędzi CASEi ręcznym kodowaniem w ADA. Lecz o wiele wydajniejszy okazał się język xuml który wyłonił się podczas prac i dalsza część projektu była już kontynuowana przy pomocy narzędzia Kennedego Cartera iuml. Zespół zyskał możliwość korzystania z języka UML który umożliwiał sprawdzenie zachowania modeli przed wprowadzeniem ich ręcznego kodowania. 6. Motywacja xuml Przy pomocy języka xuml możliwe jest programowanie i debugowanie na wyższym poziomie abstrakcji niż wcześniej. Z utworzonych diagramów można bezpośrednio wygenerować kod elementu który jest tworzony. Tworzone modele są możliwe do przetestowania i mogą być kompilowane przy pomocy języka w którym docelowo mają zostać stworzone. Jedną z najważniejszych cech języka xuml jest fakt, że znacznie obniża on koszty rozwoju oprogramowania, między innymi dzięki temu iż jest on crossplatform czyli nie jest on związany ściśle z żadnym językiem programowania, platformą ani technologią. Eliminuje to pracochłonne zadanie opracowywania przejścia z PIM (Platform-Independent Model) do PSM (Platform-Specific Model). ExecutableUML umożliwia łatwą wymianę i ponowne stworzenie projektu za pomocą standardu UML. Jest swoistym uzupełnieniem wieloletniej luki pomiędzy specyfikacją przestrzeni problemu, a samą realizacją problemu za pomocą narzędzi programistycznych. Ponieważ działania są bezpośrednio określone w języku, proces generowania kodu jest o wiele bardziej wydajny i przewidywalny niż byłoby to w przypadku zwykłego generatora kodu. W przypadku tworzenia dziedziny problemu w systemach rozproszonych to rozwiązanie jest idealne, gdyż pozwala zaprojektować system, a następnie odtworzyć jego odwzorowanie z postaci graficznej w dowolnie wybranym języku programowania. Programista tworząc system jest świadomy faktu, iż jeżeli zaistnieje potrzeba to z gotowego wdrożonego już systemu z modelu można wygenerować ten sam system w innej technologii, jest to mniej pracochłonne niż tworzenie systemu od podstaw. W przypadku połączenia systemu heterogonicznego może to być doskonałym rozwiązaniem o wiele mniej pracochłonnym niż żmudne prace nad opracowaniem schematu działania tych systemów. 7. xuml charakterystyka ExecutableUML powstał z pierwszej wersji UML z którego zostały usunięte jego słabe semantyczne części, a dodane elementy definicji akcji semantycznych. UML w wersji 1.x nie jest językiem wykonywalnym ponieważ jest semantycznie niekompletny, dopie-

58 Alicja Kilińska-Wiśniewska ro wprowadzenie do niego akcji semantycznych na wyższym poziomie abstrakcji uczyniło go wykonywalnym (executable UML). Rys. 2. Graficzna reprezentacja definicji xuml Fig. 2. Graphical representation ofthe definitionxuml xuml jest ściśle zorientowaną obiektowo metodą rozwijania systemu, która oparta jest na zasadzie budowy precyzyjnych modeli testowo-analitycznych. Wykonywanie określonych testów na stworzonych modelach oraz określenie strategii semantycznej skutkuje wybraniem odpowiedniego modelu do stworzeniasystemu docelowego. Charakterystyczne dla xuml są kompletne modele analizy, które mogą być testowane za pomocą symulacji, dzięki którym można przeprowadzać kompletne testy systemu. Tworzone są w prostej notacji, które może być zrozumiana przez każdego. W xuml można odnaleźć diagramy języka UML: diagram przypadków użycia, diagram klas, diagram sekwencji, diagram stanów oraz diagram współpracy. Rysunek 3 przedstawia model komponentów xuml. Rys. 3. Model komponentów języka xuml. Fig. 3. Components model in xuml. Diagram przypadków użycia opisuje wymagania projektowanego systemu we wstępnej fazie jego projektowania. Składa się z aktorów, przypadków użycia i relacji zachodzących pomiędzy nimi. Jest częścią statyczną i został wprowadzony do xuml, ponieważ dokładnie realizuje schematy postępowania dla każdego przewidzianego scenariusza. Jest istotnym elementem podczas wyznaczania wymagań dla wykonywalnej części projektowanego systemu. Do opisu statycznej struktury systemu wykorzystywany jest diagram klas. Składa się on z obiektów, które opisane są przez swoje atrybuty, operacje i zależności zachodzących pomiędzy poszczególnymi obiektami. W przypadku xuml wykluczone zostają różnice pomiędzy związkami asocjacyjnymi, ponieważ model rozpatrywany jest na poziomie

UML i Executable UML 59 dynamicznym. Diagram aktywności jest stosowany do opisania poszczególnych akcji w modelu xuml. Diagram ten nie opisuje całości zachowań przewidzianych dla systemu, lecz tylko wybrane jego części. Diagramy te mogą dostarczyć projektantowi wielu użytecznych informacji takich jak przepływ pracy. Kolejnym elementem xuml jest diagram stanów przejściowych, który opisuje aspekty zachowania obiektów należących do tej samej klasy. Składają się z pseudostanów, stanów i przejść, które opisują cykl życia poszczególnych obiektów. Ponadto zawierają akcje, które mogą być w kilku stanach: wejście w pewien stan, wyjście z pewnego stanu, przejście pomiędzy poszczególnymi stanami oraz kontynuację akcji w pewnym stałym stanie. Rys. 4. Wykonywalny i możliwy do przetłumaczenia model rozwoju UML. Fig. 4. Translatable and executableumlmodeldevelopment Projektowanie systemu w xuml odbywa się w trzech etapach: modelowanie systemu, zamodelowanie domeny, weryfikacja i uruchomienie modelu. W pierwszym etapie należy przede wszystkim zdefiniować dziedzinę problemu i określić ją przy pomocy diagramu przypadków użycia. Aczkolwiek projektant ma zawsze możliwość powrotu do tego etapu i wprowadzenie niezbędnych poprawek. W drugim etapie projektowana jest domena, na którą składają się klasy określające tą domenę. Dla każdej klasy projektowany jest następnie diagram stanów. Projektowanie samego modelu domeny odbywa się w sposób iteracyjny, jest to podyktowane tym iż niektóre wymagania dla już wcześniej zaprojekowanych klas otrzymuje się po zaprojektowaniu klas następnych. W trzecim i zarazem ostatnim etapie następuje weryfikacja i wykonanie. Weryfikacja modelu odbywa się w podziale na dwa aspekty, statyczny oraz dynamiczny. Statyczna analizuje poprawność składni modelu, dynamiczna natomiast obiekty i relacje zawarte w nim. Jest to najważniejszy etap, który również jest powtarzany w sposób iteracyjny aby wykluczyć wszystkie błędy. Następnie diagramy xuml są przekształcane w kod źródłowy za pomocą translatora. 8. Wnioski Metodologia UML może być z powodzeniem zastosowana podczas projektowania heterogenicznych rozproszonych systemów bazodanowych. Projektant otrzymuje możliwość przetestowania stworzonego systemu bazodanowego, który może być później odwzorowywany w dowolnie wybranej technologii.

60 Alicja Kilińska-Wiśniewska Wprowadzenie projektowania w metodologii xuml daje projektantowi systemów jeszcze większe możliwości, gdyż uniezależnia go od przekazywania modelu do programisty. xuml daje możliwość przekształcenia zaprojektowanego modelu bezpośrednio do kodu źródłowego i do prowadzenia na nim testów, których wynikiem będzie w pełni sprawny system bazodanowy. xuml jest obiecującą metodologią, która doskonale odwzorowuje abstrakcyjność projektowanego systemu. Literatura 1. Kennedy C.: Supporting Model Driven Architecture with executable UML, 2002, Kennedy Carter Limited. 2. Kennedy C.: Configurable Code Generation in MDA using iccg, 2002, Kennedy Carter Limited. 3. Booch G., Rumbaugh J., Jacobson I.: The Unified Modeling Language User Guide, Addison Wesley, First Edition Oct 20, 1998. 4. Mellor S. J.: Executable UML A foundation for Model Driven Architecture, 2002 5. OMG. Action Semantics for the UML. OMG, 2000. 6. www.knowgravity.com/eng/value/cassandra.htm Streszczenie Artykuł ma na celu przedstawienie aspektów modelowania rozproszonego środowiska bazodanowego w ujęciu heterogenicznym przy zastosowaniu języka UML (Unified Modeling Language) i jego potomka xuml (Executable UML). W zależności od wybranego podejścia przedstawienie jego implementacji do modelu rozproszonego. W artykule zostanie przedstawione wprowadzenie do języka UML oraz xuml historia języków oraz ich specyfikacja. ExecutableUML jest podstawowym kryterium w modelowaniu MDA (Model DrivenArchitekture) Jest to nowe podejście do tworzenia specyfikacji i aplikacji na podstawie modelu niezależnie od platformy na której ten system ma funkcjonować. UML and Executable UML Summary Article is to present aspects of modeling a distributed database environment in terms of heterogeneous using UML (Unified Modeling Language)and its descendant xuml (Executable UML). Depending on the approach to present its implementation into a distributed model. The article will be provided an introduction to UML and xuml history of languages and their specifications. Executable UML is a key criterion in modeling MDA (Model Driven Architecture) is a new approach to creating specifications and applications based on the model regardless of the platform on which this system is to function.