pjanusz@intertele.pl Inynieria Systemów Informacyjnych 2004 Paweł Janusz
1. Wstp Technika oprogramowania, któr stosowano w pocztkach informatyki bardzo róniła si od tej, któr uytkownicy posługuj si obecnie. Pocztkowo programici tworzcy programy nie musieli tworzy wielkich i skomplikowanych planów. Powstajce w latach 70. oprogramowanie znaczco róniło si od tego, jakie tworzone jest obecnie. Przede wszystkim ze wzgldu na jego przeznaczenie. Z czasem korporacje programistyczne zaczły zauwaa, e rozwijanie i poprawa oprogramowania moe by trudna, gdy nie ma si pod rk dobrze zrobionego planu aplikacji. Co wicej system był ciszy w rozwoju, bo wikszo załoe była w głowie programistów. Od połowy lat 70. organizacje zaczły zdawa sobie spraw ja wan rol pełni oprogramowanie dla biznesu. I prawdopodobnie pod jego wpływem brana postanowiła nieco zmieni sposób projektowania a w dalszej czci i tworzenia oprogramowania. Do pocztku lat 90 powstały róne metody. Najbardziej znane to : Metoda Grady ego Boocha Metoda Jamesa Rumbaugha Metoda Ivara Jacobsona Kada z tych metod charakteryzowała si innym podejciem do oprogramowania. Włanie dlatego entuzjaci jednej metody nie mogli zrozumie entuzjastów innej metody. Okazywało si, e rónice s tak due, e chcc skorzysta z innej ni obecnie stosowana metody, nowej trzeba by było uczy si od pocztku. Spowodowane było to rónym podejciem kadej z metod. W okresie od połowy lat 90. do roku 1997 to okres tzw. Łczenia si metod. Twórcy trzech wspomnianych ju połczyli swoje wysiłki w stworzeniu nowego standardu, który byłby na tyle uniwersalny, aby zawierał moliwie najwicej moliwoci projektowania. Rumbaugh i Jacobson dołczyli do Boocha w Rational Software Corporation. I stworzyli UML 1.0 W drugiej połowie 1997 roku powstała wersja UML 1.1. W tym te okresie organizacja OMG zaadoptowała UML i podjła si dalszego rozwoju standardu. Obecnie mamy do czynienia z najnowsza wersj UML 2.0. UML to Ujednolicony Jzyk Modelowania, jest ogólnie i szeroko stosowany przy tworzeniu rónej złoonoci systemów informacyjnych. Jest to jzyk zorientowany obiektowo, jednak tworzenie i pisanie aplikacji nie odbywa si w normalny sposób, przez pisanie kodu. Tylko tworzc odpowiednie diagramy (diagramy UML) tworzymy cał aplikacj. Siła tego rozwizania polega na tym, i cały przygotowywany system jest bardzo prosto przedstawiony i po krótkim wprowadzeniu mona go łatwo zrozumie. Opracowanie to nie ma na celu przedstawienie zaawansowanych metod tworzenia diagramów UML. Jego zadaniem jest ukazanie podstawowych informacji oraz moliwoci Ujednoliconego Jzyka Modelowania. Poza tym objto tego opracowania jest zbyt mała aby taki opis mógł zosta zawarty. W opracowaniu cz uwagi została zwrócona na pozytywne aspekty UML. Poza tym w ostatniej czci opracowania znalazło si krótkie omówienie narzdzi do tworzenia diagramów UML.
2. Charakterystyka wstpna UML Ide powstania UML, było ujednolicenie notacji i reprezentacji systemów informatycznych. W pocztkach informatyki systemy nie zawsze tworzone były w sposób uporzdkowany. Czasami system tworzony dla wybranego klienta był przedstawiony bardzo zawile i klient nie zawsze a właciwie to do rzadko mógł zrozumie działanie systemu. Przez co system zaprojektowany w ten sposób, oddany do realizacji przez analityków, mógł w efekcie nie działa poprawnie, poniewa model mógł zosta le zrozumiany przez programistów i nie odpowiada oczekiwaniom klienta. Taka sytuacja powodowała due problemy przy tworzeniu systemów, poniewa produkt stworzony niepoprawnie musiał, ju po stworzeniu, zosta poprawiony, a czasami nawet zmieniony całkowicie. Była to jedna z wielu przesłanek do stworzenia jednego, ujednoliconego i zrozumiałego modelu tworzenia systemów informatycznych. Wczeniejsze modele były zbyt ograniczenie. by mogły w pełni przedstawi wszystkie zalenoci całego systemu. Wane jest te to, e stworzony model UML, nie był modelem opisowym, ale graficznym. Dziki temu wszelkie moliwoci systemu mog by przedstawione w prosty i zrozumiały sposób. Oprócz tego łatwiej unikn nieprzewidzianych sytuacji. System jest równie łatwy do zaprezentowania klientowi, poniewa nie jest on stworzony pod specyficzny jzyk programowania czy rozwizanie. Pozwalam to równie na proste rozwiniecie systemu, gdy klient bdzie chciał rozwin dany projekt. Zalet UML a jest równie to, i mona nim zamodelowa nie tylko procesy programowe, ale równie nieprogramowe (np. biznesowe). Mona go uy do dowolnego procesu lub metody rozwizania. Jest to do mocne narzdzie, poniewa nie jest ono uzalenione od konkretnego producenta, poza tym jest on dostpny dla kadego. Obiekty UML reprezentowane s przez diagramy. Moemy podzieli je na : Diagramy klas Diagramy obiektów Diagramy przypadków uycia Diagramy stanów Diagramy przebiegu Diagramy czynnoci Diagramy kooperacji Diagramy komponentów Diagramy wdroenia Poniewa jzyk UML opisuje głownie model obiektowy, dlatego tez diagramy zostały podzielone w ten sposób, aby w pełni mu odpowiadały. W dalszej czci tego rozdziału zostanie przedstawiony skrótowy opis poszczególnych diagramów.
2.1. Diagram klas W modelu informatycznym odpowiada to klasie z której nastpnie tworzony bdzie obiekt. Podobnie jak jest to w modelu obiektowym, tak i w UML klasa oprócz atrybutów posiada metody, które operuj na tych danych. Składa si on z 4 czci Klasy, asocjacji, atrybutu klasy i operacji. Poszczególne klasy mog by połczone ze sob liniami. Klasa leca poniej oznacza klas pochodn. Łatwo zauway, e takie intuicyjne rozmieszczenie poszczególnych diagramów wizualnie do jasno pokazuje jakie relacje dziedziczenia zachodz pomidzy poszczególnymi klasami. Ma to ogromne znaczenie w przypadku, gdy do tworzonego projektu zostanie przydzielony nowy programista. Patrzc na diagram UML od razu wie z jakich metod w jakiej klasie moe działa. 2.2. Diagram obiektu Jest to egzemplarz klasy zawierajcy konkretne wartoci atrybutów. Posiada on własn nazw (przed dwukropkiem) i nazw klasy której jest obiektem (po dwukropku) 2.3. Diagram przypadku uycia Ten rodzaj diagramu opisuje zachowanie systemu z punktu widzenia uytkownika. Jest to bardzo wane podejcie, poniewa system tak naprawd tworzony jest dla uytkownika, dlatego powinien on by równie opisany z jego punktu widzenia.
Jak wida na tym diagramie, w tym systemie, którego diagram dotyczy, uytkownik programu w odpowiedni sposób działa na baz danych. Niemniej graficzny opis moe by o wiele bardziej złoony, poniewa moe np. ukazywa w jaki sposób uytkownik musi zadziała, co musi zrobi, aby uzyska podany wynik. 2.4. Diagram stanów Ten rodzaj diagramu opisuje w jakim stanie moe znale si dany obiekt. Wane jest to, aby opisywał wszystkie moliwe stany dla danego obiektu. Diagram oprócz pokazania stanów ukazuje w jaki sposób mona do okrelonego stanu doj. Asocjacje opisuj połczenia pomidzy klasami. 2.5. Diagram przebiegu Ukazuje on interakcje zachodzce pomidzy klasami i obiektami. Przewiduje on w pewien sposób to co moe dzia si z obiektami i jak poszczególne metody mog zadziała i jaki z tego powstanie efekt.
2.6. Diagram czynnoci Jest to diagram przedstawiajcy konkretny przypadek uycia. Pokazuje on przede wszystkim jakie czynnoci wykonywane s po sobie. 2.7. Diagram kooperacji Ten rodzaj diagramu pokazuje w jaki sposób odpowiednie elementy systemu współpracuj ze sob. Efektem jest poprawnie działajcy system. 2.8. Diagram komponentów Obrazuje uporzdkowanie komponentów. Odnosi si do statycznych aspektów perspektywy implementacyjnej. Wie si z diagramem klas (zwykle kademu komponentowi s przyporzdkowane pewne klasy, interfejsy i kooperacje). Np. Diagram komponentów strony www. Na diagramach komponentów uwzgldnia si elementy fizyczne (programy, biblioteki, tabele) instalowane na wzłach. Diagramy komponentów słu do obrazowania statycznych aspektów perspektywy implementacyjnej
2.9. Diagram wdroenia Diagram wdroenia pokazuje fizyczna architektur systemu komputerowego. Moe obrazowa komputery i inne przyrzdy oraz połczenia miedzy nimi i oprogramowanie na nich zainstalowane. Kady komputer jest reprezentowany przez prostopadłocian, a połczenia miedzy komputerami s widoczne w postaci linii łczcych te prostopadłociany. 2.10 Inne elementy UML Do innych obiektów stosownych w notacji UML mona zaliczy : Notatki, czyli komentarz do innego elementu. Połczona jest przerywan lini Stereotypy, s znaczeniem, ujmuje si je w << i >> Właciwoci, reprezentuj właciwoci elementu, zapisywane s w { i }
3. Zastosowanie W poprzedniej czci opracowania przedstawione zostały cel, jaki przywiecał twórcom jzyka UML. Na pocztku nauki złoono UML a moe wydawa si skomplikowana i trudna, jednak z czasem mona zauway, e w danym momencie nie korzysta si ze wszystkich diagramów. Tym niemniej w perspektywie tworzenia całego projektu wikszo z nich jest niezbdna. Jednak nawet projektanci tworzc specyfikacj zaznaczyli, i nie trzeba wykorzysta wszystkich moliwych diagramów. Mimo to warto zagłbi si i tworzc projekt skorzysta ze wszystkich moliwoci jakie daje UML. Projekt aplikacji tworzonej przy pomocy UML daje du moliwo póniejszego przewidzenia problemów, jakie mog wynikn podczas tworzenia, a nastpnie uytkowania aplikacji. Projekt gotowy jako diagram daje si póniej w łatwy sposób rozwin. Łatwo zauway, e UML stworzony został przede wszystkim dla projektantów aplikacji. Wydaje si, i tworzenie diagramów dla niewielkiej projektów utrudnia i wydłua tylko proces tworzenia. W rzeczywistoci okazuje si, i tworzenie modelu opisowego przy pomocy UML a moe bardzo ułatwi póniejsze pisanie aplikacji. Czasami tworzc jaki projekt nie zakłada si jego póniejszego rozwoju. Jednak z czasem okazuje si, e jest to niezbdne, bo np. klient zayczył sobie dodanie kilu moliwoci w projekcie. Dopóki aplikacja jest prosta i niewielka nie stwarza to duego problemu. Ale gdy jest to cały projekt pisany przez grup kilku programistów moe by ju nieco trudniej. W przypadku gdy stworzony jest diagram wystarczy tylko w odpowiednim miejscu dołoy zmiany jakie zamówił klient i odpowiednio pozmienia reszt diagramów. Przez to od razu bdzie wiadome, co dzieje si w danej chwili z aplikacj. Kolejn zalet, ale nie samego UML a lecz narzdzi dedykowanych do tworzenia diagramów w tym standardzie, jest automatyczne generowanie kodu. Nie trzeba tłumaczy jak bardzo wygodna to funkcja. W komercyjnych produktach generowany kod wynikowy moe by w rónych jzykach programowania np. Java, C++, CORBA IDL, czy nawet PHP. Oczywicie zaley to od oprogramowania jakie otrzymał lub zakupił zespół tworzcy dane rozwizanie. Posiadajc model opisany diagramami, oraz szkieletowy kod wynikowy tworzenie aplikacji to ju tak naprawd tylko stworzenie interfejsu uytkownika, oraz oprogramowanie funkcji. Dlatego ju w tym momencie łatwo zauway, e tworzenie diagramów UML jest przydatne, a czasami moe nawet bardzo ułatwi tworzenie całego projektu aplikacji. UML nie jest - w załoeniu swoich twórców - wysoce formalnym jzykiem do przedstawiania czy udowadniania nowych teorii. Ma to by przede wszystkim uniwersalny jzyk modelowania ogólnego zastosowania, przeznaczony do wykorzystania tam, gdzie tworzy si systemy oprogramowania. W dobie Internetu i globalizacji zunifikowany sposób przedstawiania informacji o systemach jest waniejszy ni kiedykolwiek. Tworzone obecnie systemy mog współpracowa z systemami opracowanymi na drugim kocu wiata. Tworzone s czsto przez zespoły programistów, którzy nigdy si nie widzieli, co stanowi dodatkow trudno; ich wzajemne zrozumienie jest czynnikiem kluczowym dla sukcesu takich projektów. UML pozwala na okrelenie ram komunikacji midzy programistami i zespołami programistów.
4. Zalety UML Niewtpliwie kade nowe narzdzia inynierii oprogramowania ma na celu ułatwienie pracy osobom tworzcym oprogramowanie. W tym momencie nie ma znaczenia kto korzysta z tego rozwizania. Czy jest to pojedynczy programista, który tworzy aplikacj na swoje potrzeby, czy cały zespół zatrudniony w globalnej firmie zajmujcej si tworzeniem oprogramowania np. biznesowego. Wane jest przede wszystkim to co mona otrzyma przez wczeniejsze stworzenie projektu wykorzystujc UML. Niewtpliwie podstawow zalet stosowania UML do tworzenia oprogramowania jest moliwo przewidzenia przez producenta oprogramowania w fazie modelowania aplikacji wszelkich moliwych interakcji ze strony uytkownika, oraz przedstawienie samemu uytkownikowi całej gamy narzdzi, jakimi bdzie dysponował po stworzeniu danego rozwizania. Nie trzeba tłumaczy, i klient, który zobaczy przed stworzeniem projektu pewne jego moliwoci moe o d razu wpłyn na kocowy wygld aplikacji. Poza tym łatwiej wprowadzi zmiany w fazie tworzenia projektu, ni po jego zakoczeniu. Kolejn zalet jest skalowalno projektu. Łatwo wyobrazi sobie sytuacj, gdy gotowy i uytkowany przez uytkownika projekt w którym momencie musi zosta zmieniony. Trzeba np. doda dodatkowe moliwoci. Zakładajc e przy projekcie pracowało kilku programistów i co najmniej jeden z nich ju nie jest pracownikiem firmy odpowiedzialnej za stworzenie projektu, w standardowym podejciu inny programista musiałby przeglda tony kodu i spdzi nad tym duo czasu, aby zrozumie pewne idee, które zrozumiałe były dla twórcy a niekoniecznie dla kadego programisty. Gdy jednak mamy stworzony diagram UML owy od razu mona znale powizania i odszuka zastosowanie czy sposób interakcji uytkownika w programie. Wtedy jakakolwiek zmiana jest nie tylko łatwa, ale idea całego projektu jest prosta w interpretacji i zrozumieniu. Tworzenie aplikacji zorientowanych obiektowo zwłaszcza takich, które w sposób zaawansowany wykorzystuj mechanizmy dziedziczenia bardzo łatwo mona zaprezentowa włanie w postaci notacji UML. To kolejna zaleta, o której nie mona zapomnie. Kolejny raz okazuje si, e stworzenie duego projektu składajcego si z duej iloci klas i zastosowanie w nich mechanizmów, które otrzymuje si stosujc podejcie obiektowe w UML staje si bardziej intuicyjne. Na diagramie od razu mona zauway, która funkcja dziedziczy z której oraz co zostało dodane w klasie potomnej. Przy standardowym odejciu trzeba było czasami przeglda kilkanacie plików, aby doj w kocu do klasy podstawowej. Posiadajc diagram UML jest to bardzo proste i szybkie wystarczy tylko cofa si i patrze jakie klasy spotykamy powyej klasy potomnej. Tworzc projekt w grupie programistów nie trudno o pewne niezrozumienie. Dlatego tak wan rzecz jest wiedza do czego dana cz projektu ma słuy i co realizowa. W kocu programici nie pisz całej aplikacji naraz, tylko poszczególne jej czci czy komponenty. Dlatego musz wiedzie, do czego bd one słuy i w jaki sposób mog by one udostpnione uytkownikowi lub innej czci programu. I tu po raz kolejny pomocny jest diagram UML, który w sposób intuicyjny, bez wikszego wgłbiania si w cał struktur systemu a tylko w to co najwaniejsze, czyli efekt kocowy (w tym wypadku działania jakiego komponentu, czy np. metody). Due znaczenie ma równie uniwersalno. Tej nie brakuje w UML. Wystarczy wyobrazi sobie du firm, w której powstaje aplikacja do obsługi banku internetowego. Cz
oprogramowania wykonuje si na serwerze w programie wielowtkowym napisanym w C++, natomiast wynik tego działania klient obserwuje w przegldarce internetowej. Róne działy firmy pracuj nad efektem całociowym, jednak nie mona wymaga od projektantów klienta do przegldarki WWW aby znali si na programowaniu C++, bo jest to im zupełnie niepotrzebne. Ani programistom piszcym aplikacj serwerow, aby zastanawiali si nad mechanizmami stron WWW. I tutaj po raz kolejny z pomoc przychodzi UML. Wystarczy stworzy odpowiedni diagram (w tym wypadku np. komponentów) i webmasterzy informuj co jest im potrzebne, natomiast programici tworz dostp do odpowiednich metod, które zostan póniej zdalnie uruchomione przez klienta. W tym wypadku jakby intuicyjnie nasuwa si kolejna zaleta, to niezaleno realizowanego projektu od platformy. Posiadajc dobrze działajc aplikacj i diagramy UML na podstawie których została ona stworzona, nie jest duym problemem przenie j na inn platform czy jzyk programowania. Oczywicie przedstawione tu zalety to nie wszystkie. Wiele z zalet UML a zale od projektu jaki realizowany jest w danej firmie. Niemnie te przedstawione powyej nasuwaj si jakby w sposób naturalny i s łatwe w zrozumieniu.
5. Tworzenie diagramów UML Zaczynajc tworzenie diagramów naley zastanowi si przede wszystkim co tworzona aplikacja ma na celu, w jaki sposób bdzie ona działała oraz jakie mechanizmy programowania mog by pomocne przy jej realizacji. Jak ju wczeniej było wspomniane, przy tworzeniu projektu nie trzeba wykorzystywa wszystkich dostpnych diagramów UML. Jeeli zaley tylko na stworzeniu graficznej reprezentacji obiektów i klas, to nie trzeba tworzy innych diagramów tylko te. Naley jednak pamita, i im bardziej zaawansowane i rónorakie diagramy stosowane s do opisu projektu, tym lepiej jest on opisany i tym łatwiej bdzie go zrozumie. Nie naley jednak na sił dodawa jaki diagram, który trak naprawd nie je potrzebny. Jeeli tworzona jest aplikacja na potrzeby wewntrzne firmy (np. działu programistów), to nie ma potrzeby tworzy diagramu przypadku uycia. Przy tworzeniu diagramów nie trzeba od razu tworzy ostatecznej wersji projektu. Ogromn sił tego typu projektowania jest rozszerzalno projektu. Raz stworzone podstawowe diagramy mona dowolnie poprawia modyfikowa i rozszerza. Warto wspomnie w tym miejscu o dwóch technikach tworzenia aplikacji : Metoda kaskadowa Metoda iteracji Odnosz si one do całego cyklu tworzenia aplikacji : od gromadzenia wymogów, po wdroenie gotowego systemu. Obie s przydatne, jeeli jednak w załoeniu tworzy si projekt mały to bardziej efektywn bdzie pierwsza, jeeli natomiast tworzy si duy projekt, to metoda kaskadowa moe okaza si nieskuteczna. Metoda kaskadowa polega ona na liniowym wykonywaniu kadego z czci projektu. Zanim przejdzie si do nastpnej fazy projektu, poprzednia faza musi by w całoci zakoczona. Metoda iteracji polega na nieliniowym działaniu, projekt realizowany jest sekwencyjnie, przez co np. testerzy nie musza czeka na zakoczenie pisania całego projektu, a tylko jego czci. Łatwiej wtedy znale błd i poprawienie go nie stwarza problemów. UML wspiera obydwie te techniki, jednak o wiele łatwiej jest przekaza do realizacji dana interesujc w danym momencie klienta cz projektu ni zastanawia si nad wszystkimi jego aspektami. Naley jednak pamita, e mimo wszystko zarys tworzonego projektu musi by znany, poniewa nie mona tworzy czci rozwizania nie zastanawiajc si nad udostpnieniu go w dalszej czci projektu.
6. Krótka charakterystyka narzdzi do tworzenia diagramów UML Cały opis jzyka UML byłby niepełny, gdyby w tym opracowaniu nie znalazł si cho krótki opis narzdzi do tworzenia diagramów UML. Przez czas w jakim UML dojrzewał powstało wiele ciekawych i oryginalnych produktów. Tworzc to opracowanie zostało wykorzystane jedno z nich. To narzdzie było zastosowane do stworzenia wszelkich diagramów UML owych w tym opracowaniu. Charakteryzuj si ono bardzo duymi moliwociami, poza tym jest ono bardzo intuicyjne. Co wane wersja podstawowa czyli CE (Community Edition) jest bezpłatna. Ma ona oczywicie o wiele mniejsze moliwoci generowania kodów wynikowych ni wersje płatne, ale dla na pocztek przygody z UML to narzdzi zdecydowanie wystarcza. Obecnie wersja CE generuje on-line (czyli w trakcie tworzenia diagramów) kod wynikowy w jzyku JAVA. Jak wida na zrzucie ekranu program ma bardzo przyjazny dla uytkownika interfejs. Diagramy tworzone s w 90% na zasadzie drag&drop. Strona producenta : http://www.gentleware.com
To kolejne narzdzie do tworzenia diagramów UML Równie i tym razem narzdzie posiada wersj tzw. CE, kttóra udostpniona jest nieodpłatnie. Wszelkie inne wersje s płatne. Strona producenta : http://www.visual-paradigm.com To narzdzie tworzone jest na zasadzie OpenSource. Nie ma ono moe tak efektownego GUI jak poprzednicy, jednak jest ono udostpnianie jak na razie za darmo. Strona projektu : http://argouml.tigris.org/ Strona producenta : http://www.smartdraw.com/
7. Podsumowanie Przedstawione w tym opracowaniu informacje miały na celu przyblienie podstawowych informacji o UML. Jak da si zauway tego typu rozwizanie jest bardzo pomocne i przydatne, jeeli jednak czytelnik ma ch wgłbienia si w tajniki i wszystkie bardzo szerokie moliwoci, to musi sign po stosown literatur. Jej lista poniej. Naley pamita, e standard UML opracowany jest zmyl o ludziach tworzcych systemy i programistach, dlatego warto pozna cho podstawy tego modelu. 8. Literatura OMG Unified Modeling Language Specification (http://www.uml.org) UML Wprowadzenie - Sinan Si Alhir (Helion 2004) UML Dla kadego Joseph Schmuller (Helion 2004) UML leksykon kieszonkowy Dan Pilone (Helion 2004) Jzyk UML Kazimierz Subieta (Instytut Podstaw Informatyki PAN, Warszawa Polsko- Japoska Wysza Szkoła Technik Komputerowych, Warszawa, 1999)
1. Wstp...2 2. Charakterystyka wstpna UML...3 2.1. Diagram klas...4 2.2. Diagram obiektu...4 2.3. Diagram przypadku uycia...4 2.4. Diagram stanów...5 2.5. Diagram przebiegu...5 2.6. Diagram czynnoci...6 2.7. Diagram kooperacji...6 2.8. Diagram komponentów...6 2.9. Diagram wdroenia...7 2.10 Inne elementy UML...7 3. Zastosowanie...8 4. Zalety UML...9 5. Tworzenie diagramów UML...11 6. Krótka charakterystyka narzdzi do tworzenia diagramów UML...12 7. Podsumowanie...14 8. Literatura...14