mgr in. Jarosław Kuchta

Transkrypt

1 POLITECHNIK GDŃSK WYDZIŁ ELEKTRONIKI TELEKOMUNIKCJI I INFORMTYKI Katedra rchitektury Systemów Komputerowych Rozprawa doktorska Integracyjna metoda wytwarzania aplikacji obiektowych w rodowisku graficznym z uwzgl dnieniem wymaga jako ciowych mgr in. Jarosław Kuchta promotor: prof. dr hab. in. Henryk Krawczyk Gda sk, 2008

2 Pracę wykonano w ramach projektu badawczego MNiSW N /2949

3 Spis tre ci Rozdział 1. Trendy integracyjne w inŝynierii oprogramowania Geneza i integracja metod analizy i projektowania Integrowanie środowisk implementacji Problemy pełnej integracji Propozycja metody integracyjnej Tezy rozprawy Struktura rozprawy...18 Rozdział 2. Koncepcja integracyjnej metody konstruowania aplikacji (IMC) Koncepcja języka modelowania i implementacji IML Geneza języka Cechy charakterystyczne języka IML Wybrane elementy procesu wytwarzania Przebieg procesu wytwarzania Podstawowe mechanizmy usprawniające proces wytwarzania Metody zapewnienia jakości Koncepcja systemu oceny jakości projektu Zapewnienie spójności projektu Szybkie przejście od wymagań do implementacji Warstwa danych IML Metajęzyk IML Podstawowe klasy projektowe Zasady zapisu danych projektowych Wybrane elementy warstwy semantyki IML Semantyka modelu klas Semantyka modelu wymagań Semantyka modelu przypadków uŝycia Semantyka modelu akcji Semantyka modelu aktywności Semantyka modelu implementacji Warstwa prezentacji IML Środowisko graficzne Symbole graficzne Relacje między elementami graficznymi Elementy tekstowe języka Wybrane zasady składni i konstrukcje językowe Rodzaje diagramów Rozdział 4. Kompilacja diagramów aktywności Odwzorowanie diagramu w model aktywności Zasady tworzenia grafu odwzorowania Zasady wstępnego przygotowania grafu odwzorowania Zasady analizy semantycznej grafu odwzorowania Transformacja modelu aktywności w model implementacji w języku IML Zasady podziału modelu aktywności na procedury Wybrane zasady syntezy instrukcji Wybrane zasady ustalenia kolejności instrukcji Translacja modelu implementacji na konkretny kod wykonywalny Zasady translacji typów danych Zasady odwzorowania komponentów abstrakcyjnych w konkretne

4 Zasady translacji instrukcji IML na instrukcje języka implementacji Rozdział 5. Studium przypadku Wybrane elementy projektu systemu rozproszonego Opis dziedziny problemu Specyfikacja wymagań naliza przypadków uŝycia Projekt architektury systemu Projektowanie logiki na poziomie operacji Generowanie kodu Odwzorowanie diagramu aktywności w model aktywności Transformacja modelu aktywności w model implementacyjny Translacja kodu wykonywalnego z IML do Javy Wykrywanie błędów i wprowadzanie modyfikacji Rozdział 6. Ocena jakości projektu Metoda oceny jakości projektu Model jakości projektu Sposoby pomiaru jakości Program oceny jakości Definicje metryk i miar Metryki i miary kompletności Metryki i miary poprawności Metryki i miary spójności Metryki i miary zrozumiałości Metryki i miary modyfikowalności Metryki i miary weryfikowalności Ocena jakości przykładowego projektu Tworzenie i ocena specyfikacji wymagań Wnioski z oceny Rozdział 7. Podsumowanie Spełnienie wymagań strategicznych Wymagania co do efektywności Wymagania co do jakości Metoda IMC na tle innych metod Warunki stosowalności Wnioski i perspektywy rozwoju Bibliografia Indeksy

5 Rozdział 1. Trendy integracyjne w in ynierii oprogramowania W dziedzinie inŝynierii oprogramowania moŝna zauwaŝyć są są wyraźne dąŝenie do integracji róŝnych metod i narzędzi wytwarzania oprogramowania. Dominujące dwa trendy. Z jednej strony następuje łączenie rozmaitych metod analizy i projektowania oprogramowania, z drugiej strony następuje łączenie narzędzi i środowisk implementacji oraz podnoszenie ich na coraz wyŝszy poziom abstrakcji. Wynikiem pierwszego trendu jest zunifikowany język modelowania UML [13][14]. Produktami drugiego trendu zintegrowane środowiska programowania wizualnego, takie jak Delphi [17] czy Visual Studio [68]. Naturalnym podejściem jest połączenie obu trendów i stworzenie jednej, spójnej metody obejmującej cały proces wytwarzania oprogramowania (p. rys. 1). integracja metod analizy i projektowania UML metoda integracyjna IDE są integracja narzędzi implementacji Rys. 1. Trendy integracyjne w inŝynierii oprogramowania Prace nad zintegrowanym podejściem do procesu wytwarzania oprogramowania cały czas trwają. Podejmowane próby włączenia narzędzi modelowania do zintegrowanych środowisk implementacji, np. Rational XDE [7] do Visual Studio [64]. Na drodze do pełnej integracji tych występują środowisk jednak powaŝne problemy. NaleŜy tu wymienić niezgodność aparatów pojęciowych stosowanych w 1. Trendy integracyjne w inŝynierii oprogramowania 5

6 modelowaniu i w implementacji, niejednoznaczność odwzorowania jednych pojęć na drugie, niezgodność są notacji [45]. Te problemy powodują, Ŝe dotychczas stosowane metody dalekie od doskonałości. Integracyjna metoda konstrukcji aplikacji IMC (ang. Integrated Method of pplication Construction) jest autorską propozycją rozwiązania tych problemów. UmoŜliwia ona przeprowadzenie analizy, projektowania i implementacji w środowisku graficznym. Dzięki połączeniu modelu wymagań, projektu oprogramowania i modelu implementacji w jedno, spójne rozwiązanie, moŝna zwiększyć efektywność tworzenia oprogramowania, zmniejszyć ryzyko błędów, a dzięki zintegrowanemu systemowi oceny jakości dokumentacji poprawić jakość tworzonego oprogramowania. Siła metody IMC leŝy w wielowarstwowym dostępie do wspólnej dla wszystkich faz procesu wytwarzania oprogramowania bazy danych projektowych. Podstawą rozwiązania jest specyfikacja wymagań wprowadzana do bazy danych. Dzięki odpowiednim regułom odwzorowania specyfikacja ta umoŝliwia półautomatyczne wygenerowanie modelu analitycznego. W fazie projektowania na podstawie modelu analitycznego jest tworzony projekt aplikacji, często z podziałem na kilka warstw architektonicznych. W fazie implementacji dokonuje się uściślenia i udoskonalenia rozwiązań aŝ projektowych do uzyskania odpowiedniego modelu implementacyjnego, z którego następnie jest automatycznie generowany kod wykonywalny aplikacji. Całość pracy realizuje się w jednym, spójnym środowisku projektowym. Podczas implementacji stosuje się te same graficzne formy prezentacji, co w czasie analizy i projektowania. Wygenerowany kod (np. w Javie lub w języku maszynowym) nie jest juŝ modyfikowany. Wszelkie modyfikacje sposobu implementacji przeprowadza się na diagramach implementacyjnych. Unika się aŝ są tym samym transformacji wyników modelowania na kod implementacyjny i z powrotem, co jest potencjalnym źródłem błędów. Produkty kaŝdej z faz poddawane ocenie przez system kontroli jakości obliczający szereg miar statystycznych. PowyŜsze aktywności mogą być podejmowane wielokrotnie, do zapewnienia odpowiedniej jakości wynikowej aplikacji Geneza i integracja metod analizy i projektowania Współczesny proces wytwarzania oprogramowania jest procesem bardzo złoŝonym. Składa się z kilku faz, a kaŝda z tych faz obejmuje kilka róŝnych aspektów (p. rys. 2). Przez dłuŝszy czas metody i narzędzia wspomagające proces wytwarzania oprogramowania rozwijały się niezaleŝne dla róŝnych faz i aspektów tego procesu. Szczególnie przed wprowadzeniem technik obiektowych istniało wiele róŝnych metod analizy i projektowania skupiających się na poszczególnych, wybranych aspektach. 6

7 Proces wytwarzania oprogramowania Planowanie Opracowanie specyfikacji wymagań naliza ryzyka i analiza ekonomiczna Szacowanie pracochłonności i kosztów Opracowanie harmonogramu naliza wymagań naliza strukturalna naliza funkcjonalna naliza behawioralna naliza dynamiczna Projektowanie Projektowanie architektury systemu Projektowanie obiektowoproceduralne Projektowanie struktury danych Projektowanie interfejsu uŝytkownika Implementacja Implementacja obiektowoproceduralna Implementacja struktury danych Implementacja interfejsu uŝytkownika Opracowanie systemu pomocy Testowanie W projektowaniu proceduralnym najstarszą z metod była metoda z lat 60-tych oparta o diagramy przepływu sterowania wykresy operacyjne [8]. Ze względu na Testowanie jednostkowe Testowanie integracyjne Testowanie systemowe Testowanie akceptacyjne swoją uniwersalność metoda ta jest uŝywana do dzisiaj, chociaŝ raczej do celów ilustracyjnych i to do prostych algorytmów. Wykresy operacyjne mają pewną wadę nie bardzo nadają się do opisu sterowania strukturalnego. Dlatego w latach 70-tych duŝe nadzieje niosła metoda oparta o strukturalne diagramy sterowania Nassi- Shneidermana i Chapina [60][19]. Rys. 2. Fazy i aspekty procesu wytwarzania oprogramowania W aspekcie strukturalnym duŝe znaczenie miała analiza bazująca diagramach na diagramach związków encji ERD (ang. Entity-Relationship Diagrams) opracowanych w połowie lat 70 przez Chena [20]. W tym czasie pojęcie obiektu w informatyce nie było jeszcze znane, dlatego teŝ Chen wprowadził pojęcie encji dla oznaczenia rzeczy lub przedmiotu mającego znaczenie dla systemu. Metoda analizy związków encji w późniejszym czasie miała stać się podstawą dla rozwoju metod obiektowych. spekt funkcjonalny był domeną metody opartej o diagramy przepływu danych (DFD ang. Data Float Diagram). Metoda opracowana pod koniec lat 70 przez Yourdona i Constantine a [75] oraz przez DeMarco [25] umoŝliwiała strukturalny podział funkcjonalności systemu na procesy. spekt behawioralny często był opisywany przy pomocy diagramów przejść stanów. ChociaŜ samo pojęcie stanów i tabel przejść jest tak stare jak maszyna Turinga, pierwsze zastosowania do opisu złoŝonych systemów sięgają początku lat 80 [37]. Współcześnie stosuje się notację Harela [31]. Harel wprowadził pojęcia stanów złoŝonych, stanów równoległych oraz akcji i aktywności stanu. spekt dynamiczny często był utoŝsamiany z behawioralnym i stosowano w nim te same metody. Dla podkreślenia ujęcia czasowego diagram stanów mógł zostać 1. Trendy integracyjne w inŝynierii oprogramowania 7

8 przedstawiony w alternatywnej postaci zwanej diagramem sekwencji zdarzeń [4], porządkującej zdarzenia wzdłuŝ wspólnej osi czasu. Sporą popularnością w projektowaniu cieszyły się teŝ metody formalne oparte o języki formalne, np. PDL lub Z [16][30][35][69]. Nie były to metody graficzne i chociaŝ zapewniały moŝliwość ścisłej, formalnej specyfikacji systemu, to jednak czytelność tak wykonanych projektów pozostawiała wiele do Ŝyczenia. Wprowadzenie technik obiektowych zapoczątkowało proces integracji róŝnych metod analizy wokół modelu obiektowego. Początek lat 90 przyniósł Ŝywiołowy rozwój metod obiektowych. Jedną tę z pierwszych metod obiektowych opracowali Coad i Yourdon [21][22]. Ich wkładem do modelowania był diagram klas i obiektów w formie moŝliwej do zastosowania zarówno w analizie jak i projektowaniu. W analizie Coad i Yourdon skoncentrowali się na aspekcie statycznym. W zakresie projektowania zastosowali samą formę diagramu klas i obiektów do czterech aspektów projektowych. UmoŜliwiało to wprost przeniesienie diagramów analitycznych do projektowania i następnie ich uszczegółowienie. Inne podejście zostało zaprezentowane w metodzie Wirfs-Brocka [74]. W metodzie tej do opisu klas zastosowano karty CRC (ang. Class Responsibility-Collaboration cards). Do pokazania struktury klas zastosowano grafy hierarchii klas, natomiast do pokazania kontraktów między klasami, podsystemami i klientami-serwerami uŝyto diagramów kolaboracji. Bardzo duŝo w analizę obiektową włoŝył Booch. Jego metoda rozwijała się stopniowo od projektowania obiektowego, przez obiektowe projektowanie aplikacji, do obiektowej analizy i projektowania aplikacji [9][10][11][12]. W swojej metodzie Booch wykazał, Ŝe moŝna połączyć proces analizy i projektowania w jeden proces modelowania. Stwierdził, Ŝe analiza obiektowa tworzy model logiczny, w którym tworzy się architekturę klas i obiektów. Podczas projektowania powstaje model fizyczny, który obejmuje architekturę modułów i architekturę procesów. W ten sposób model logiczny i model fizyczny tworzą dwa poziomy modelowania. Na kaŝdym poziomie powstają dwa modele rozpatrywane w innym wymiarze: model statyczny i model dynamiczny. W sumie Booch wyróŝnił cztery modele: statyczny model logiczny, dynamiczny model logiczny, statyczny model fizyczny oraz dynamiczny model fizyczny. Udane połączenie analizy obiektowej, jaką znamy z prac Coada i Yourdona, z analizą opartą o diagramy przepływu danych i analizą przejść stanów stanowi metoda OMT (ang. Object Modeling Technique) opracowana przez Rumbaugha i innych [65]. Metoda OMT objęła trzy aspekty analizy: aspekt statyczny, aspekt dynamiczny i aspekt funkcjonalny oraz dwa poziomy projektowania: projektowanie systemowe i projektowanie obiektowe. W kaŝdym z trzech aspektów analizy tworzony został odpowiedni model: model obiektowy, model dynamiczny i model funkcjonalny. Model obiektowy opisywany jest przez diagramy klas i obiektów (bardzo zbliŝone do diagramów Coada i Yourdona). Model dynamiczny opisywany jest przez diagramy przejść stanów wg Harela [31] oraz diagramy sekwencyjne (zwane diagramami scenariuszy). Model funkcjonalny opisywany jest przez diagramy przepływu danych. Faza projektowania, chociaŝ jest równieŝ bardzo dokładnie opisana, nie ma tak precyzyjnej notacji graficznej, jak faza analizy. Całkowicie odmienne podejście do analizy reprezentuje Jacobson. Jest on twórcą metody OOSE (ang. Object-Oriented System Engineering) [38] znanej raczej jako 8

9 podejście przez przypadki uŝycia (ang. Use Case Driven pproach). W swojej metodzie proponuje rozpoczęcie analizy od określenia tzw. przypadków uŝycia. Pod pojęciem przypadku uŝycia Jacobson definiuje spójną jednostkę funkcjonalności systemu lub klasy manifestującą się wymianą sekwencji komunikatów pomiędzy systemem a zewnętrznymi, współdziałającymi z nim obiektami zwanymi aktorami. Podejście Jacobsona jest o tyle róŝne od innych metod, Ŝe do dziś trwają działania mające na celu lepsze dopasowanie przypadków uŝycia do innych aspektów modelu obiektowego. Pierwsze metody obiektowe powstawały w sposób Ŝywiołowy. Powstało co najmniej kilka równoprawnych metod niezgodnych pod względem aparatu pojęciowego i stosowanej notacji. Ponadto Ŝadna z tych metod nie obejmowała całego cyklu Ŝycia oprogramowania. Dlatego w połowie lat 90 zaczęły powstawać metody obiektowe drugiej generacji, jak Fusion i MOSES. Metoda Fusion [23] obejmuje trzy fazy: analizę, projektowanie i implementację. W fazie analizy i projektowania metoda Fusion opiera się na czterech poprzednich metodach: OMT, metodach formalnych, metodzie Wirfs-Brocka i metodzie Boocha. W zakresie implementacji metoda Fusion opisuje sposób realizacji interakcji międzyobiektowej oraz maszyny stanów w języku programowania obiektowego. Metoda MOSES [33] obejmuje cały cykl Ŝycia oprogramowania. Zakłada, Ŝe cykl ten składa się są z czasu wzrostu i czasu dojrzewania. Czas wzrostu jest czasem potrzebnym na wytworzenie pierwszej wersji oprogramowania. W czasie dojrzewania wytwarzane kolejne wersje. Czas wytwarzania kaŝdej wersji składa się z trzech stopni: planowania przedsięwzięcia, budowania i dostarczenia produktu. Spośród tych najwaŝniejsze jest budowanie. Składa się ono z pięciu faz: planowania, badania, specyfikacji, implementacji i przeglądu. KaŜda z tych pięciu faz bazuje na pewnym podzbiorze aktywności ze zbioru wspólnych aktywności. W metodzie MOSES wykorzystuje się poprzednie metody, zwłaszcza karty CRC Wirfs-Brocka i diagramy stanów Harela. Bardziej intensywne działania integracyjne podjęło konsorcjum kilkunastu firm softwerowych, m.in. Microsoft, Rational, IBM, Hewlett-Packard, Oracle. Działania te doprowadziły do powstania zunifikowanego języka modelowania UML (ang. Unified Modeling Language). Na genezę języka UML złoŝyło się wiele wcześniejszych metod (p. rys. 3). Głównymi twórcami UML są: Booch, Rumbaugh i Jacobson [14]. Stąd teŝ są są są UML łączy w sobie elementy występujące w ich własnych metodach. Od Jacobsona pochodzi diagram przypadków uŝycia. Diagramy klas i obiektów w UML złoŝeniem diagramów klas z OMT, metody Boocha i wielu innych metod obiektowych. Diagramy stanów (z pewnymi modyfikacjami) oparte o pracę Harela. Diagramy aktywności podobne do diagramów przepływu pracy (ang. work flow diagrams) uŝywanych w wielu metodach (równieŝ przedobiektowych). Nad włączeniem diagramów aktywności do UML pracował Odell [56]. Diagramy sekwencji moŝna było znaleźć w wielu metodach obiektowych (m.in. w OMT i u Boocha) oraz przedobiektowych pod róŝnymi nazwami. Z metod Boocha, metody Fusion oraz kilku innych źródeł zaadaptowano diagramy kolaboracji. Diagramy implementacji (diagramy komponentów i diagramy rozwinięcia) stanowią zmodyfikowane diagramy modułów i procesów Boocha. 1. Trendy integracyjne w inŝynierii oprogramowania 9

10 metody przedobiektowe metody obiektowe 1.generacji metody obiektowe 2.generacji unifikacja metod obiektowych Wykresy operacyjne Diagramy związków encji Metoda Coada i Yourdona Strukturalne diagramy sterowania Diagramy przepływu danych Metody Boocha Fusion OMT UML Diagramy przejść stanów MOSES Metody formalnej specyfikacji Diagramy stanów Harela Metoda Wirfs- Brocka Diagramy sekwencji zdarzeń Metoda Jacobsona Extreme Programming Model Driven rchitecture rozwój metod opartych o UML 2004 Profile UML UML 2.0 Rational Unified Process UML 1997 roku rozwija się dalej. W 2004 roku opublikowano kolejną bardziej znaczącą wersję tego języka UML 2.0. Równocześnie UML, jako język otwarty, stał się podstawą dla wielu odmian tego języka profili stosowanych w rozmaitych dziedzinach [92] gile Unified Process Rys. 3.Geneza i rozwój obiektowych metod analizy i projektowania W tej samej organizacji OMG (ang. Object Modeling Group), która stworzyła UML, powstała metoda MD (ang. Model Driven rchitecture) [59] zakładająca najpierw modelowanie funkcjonalności systemu w sposób niezaleŝny od platformy implementacji za pomocą języka specyficznego dla dziedziny zastosowania, a następnie tłumaczenie tego modelu za pomocą modelu definicji platformy do modeli specyficznych dla platformy stosujących języki ogólnego zastosowania (p. rys. 4). DSL GPL PIM PDM PSM Objaśnienia: PIM Platform Independent Model model niezaleŝny od platformy implementacji PSM Platform Specific Model model specyficzny dla platformy implementacji PDM Platform Definition Model model definicji platformy implementacji (np. CORB, DotNet, Web) DSL Domain Specific Language język specyficzny dla dziedziny zastosowania (np. CSound dla zastosowań audio, DOT Language dla wizualizacji grafów), GPL General Purpose Language język ogólnego zastosowania (np. Java, C#) Rys. 4. Schemat postępowania w metodzie MD Po zastosowaniu do modelu MD języka UML powstał model RUP (ang. Rational Unified Process) [40] metoda wytwarzania oprogramowania oparta o spiralny model wytwarzania (p. rys. 5) oraz szereg zasad i praktyk inŝynierskich, takich jak: iteracyjne wytwarzanie oprogramowania, 10

11 zarządzanie wymaganiami, stosowanie architektury bazującej na komponentach, modelowanie graficzne, stosowanie systemu zarządzanie jakością, zarządzanie zmianami. Faza przekazania (transition) Faza podjęcia (inception) Faza konstrukcji (construction) Faza opracowania (elaboration) Rys. 5. Model spiralny procesu wytwarzania w metodzie RUP Metoda RUP jest często krytykowana za jej formalizm w sensie złoŝoności realizowanych zadań [3]. lternatywą są jest UP (ang. gile Unified Process) [5], lekka wersja RUP reprezentująca podejście oparte o następujące zasady [76]: 1. NajwyŜszym priorytetem jest zadowolenie klienta, które moŝna zapewnić przez szybkie i ciągłe dostarczanie działającego oprogramowania. 2. Dopuszczalne zmiany wymagań nawet w późnym stadium projektu. Projekt musi być dopasowywany do zmieniających się wymagań i warunków na korzyść są klienta. 3. Działające oprogramowanie jest dostarczane często, co kilka tygodni lub co kilka miesięcy. Im częściej tym lepiej. 4. Potrzebna jest bliska, codzienna współpraca między przedstawicielami klienta i zespołem projektowym. 5. Projekty oparte o odpowiednio zmotywowanych deweloperów, którym trzeba zapewnić środowisko pracy i zaufać, wykonają swoją Ŝe pracę. 6. Najbardziej odpowiednią i efektywną metodą zbierania informacji przez zespół projektowy jest bezpośrednia rozmowa. 7. Działające oprogramowanie jest podstawową miarą postępu prac. 8. Proces opracowywania oprogramowania powinien być stale podtrzymywany przez sponsorów, deweloperów i uŝytkowników. 9. Potrzebne jest stałe zwracanie uwagi na techniczną doskonałość i dobre projektowanie 10. Upraszczanie ma znaczenie zasadnicze 11. Najlepsze wymagania, projekty i struktury pochodzą od samoorganizujących się zespołów. 12. W regularnych odstępach zespół projektowy zastanawia się nad tym, jak zwiększyć swoją efektywność, następnie odpowiednio zmienia i dopasowuje swoje sposoby postępowania. Zarówno metody formalne, jak i lekkie mają swoje zalety i swoje wady, które predestynują je do określonych obszarów zastosowań [6] (p. tab. 1) 1. Trendy integracyjne w inŝynierii oprogramowania 11

12 Tab. 1. Porównanie obszarów zastosowań metod formalnych i metod lekkich metody formalne (np. RUP) metody lekkie (np. UP) wysoka krytyczność projektu niska krytyczność projektu dobrze określone wymagania częsta zmiana wymagań mało doświadczeni deweloperzy doświadczeni deweloperzy duŝa liczba deweloperów mała liczba deweloperów uporządkowany system pracy kreatywny system pracy 1.2. Integrowanie rodowisk implementacji są Po pierwszych metodach implementacji opartych na kompilacji liniowej (z uŝyciem osobnych programów do edycji, kompilacji, konsolidacji i testowania) nastąpił intensywny rozwój zintegrowanych środowisk implementacji (IDE). Do środowisk tych włączano są stopniowo róŝne narzędzia przenosząc jednocześnie środek cięŝkości pracy programisty na wyŝszy poziom abstrakcji, zwłaszcza na aspekt projektowania interfejsu uŝytkownika. Reprezentatywnymi produktami trendu integracyjnego w implementacji zintegrowane środowiska programowania wizualnego: Delphi, Borland C ++ Builder, Java Builder, Visual Studio [15][36][54][50]. Podejmowane równieŝ działania zmierzające do włączenia metod modelowania do zintegrowanych środowisk implementacji. Przykładem tego moŝe być Rational XDE środowisko modelowania przeznaczone do integracji z Microsoft Visual.NET Studio oraz z IBM IDE [63][64]. RównieŜ Borland włącza narzędzia modelowania do swoich środowisk IDE (p. rys. 6). Delphi modelowanie obiektowo-relacyjne Delphi projektowanie struktury danych (diagramy E-R) Delphi projektowanie interfejsu uŝytkownika Turbo Pascal edycja zasobów Turbo Pascal technika obiektowa Turbo Pascal 3.0 Edytor Kompilator Linker Debugger Rys. 6. Włączanie narzędzi projektowania i modelowania do środowisk implementacji na przykładzie IDE firmy Borland 12

13 1.3. Problemy pełnej integracji Na drodze do pełnej integracji metod wytwarzania oprogramowania występuje jeszcze szereg problemów. RozwaŜmy dla przykładu sposób wytwarzania oprogramowania za pomocą Rational XDE. Jest to środowisko modelowania wykorzystujące język UML i przeznaczone do konsolidacji m. in. z Microsoft Visual.NET Studio. Praca w takim zintegrowanym środowisku przebiega według następującego schematu (p rys. 7): 1. Na podstawie wymagań uŝytkowych projektant tworzy model aplikacji w UML posługując się narzędziami XDE. 2. Z modelu generowany jest szkielet aplikacji kod źródłowy w C#. 3. Programista wpisuje kod metod obiektowych w języku C# w oznaczone odpowiednimi komentarzami miejsca w wygenerowanym kodzie aplikacji. 4. Następnie programista uruchamia aplikację typowymi narzędziami IDE z Microsoft Visual.NET Studio. 5. Jeśli model wymaga modyfikacji, to przeprowadza się synchronizację modelu z kodem (za pomocą odpowiedniego narzędzia) i powraca do p. 1. Wymagania uŝytkowe model XDE +.NET Studio XDE Modelowanie model Synchronizacja modelu Generowanie kodu Uzupełnienie kodu kod źródłowy.net Studio Implementacja kod źródłowy plikacja Rys. 7. Schemat funkcjonalny pracy ze zintegrowanym środowiskiem Rational XDE i Microsoft Visual.NET Studio Jak wynika z powyŝszego schematu, w tej metodzie pracy występuje pewien dualizm. Z jednej strony model aplikacji jest tworzony w języku modelowania UML. Z drugiej strony kod aplikacji powstaje w obiektowym języku programowania (C#). Proces generowania kodu z modelu jest procesem mocno nieefektywnym. utomatyczny generator kodu interpretuje jedynie statyczne elementy modelu produkując strukturę są klas z nagłówkami procedur. Diagramy funkcjonalne i dynamiczne nie w ogóle rozpoznawane, choć wchodzą w skład dokumentacji projektowej i muszą być później interpretowane przez człowieka. Programista musi uzupełnić wygenerowany kod wpisując własną interpretację. W przypadku konieczności dokonania zmian w modelu proces trzeba powtarzać, a wprowadzony uprzednio przez programistę kod moŝe juŝ nie być zgodny z nową wersją modelu. Takie podejście ma zasadnicze wady: Brak pełnej interpretacji modelu przez generator kodu zmusza programistę do samodzielnej interpretacji diagramów modelowych. Interpretacja przez człowieka jest na pewno wolniejsza od interpretacji komputerowej i wpływa na zmniejszenie efektywności całego procesu wytwarzania oprogramowania. (Na 1. Trendy integracyjne w inŝynierii oprogramowania 13

14 są marginesie naleŝy zaznaczyć, nieefektywność Ŝe generatora kodu zapewne nie wynika z nieumiejętności napisania efektywnego generatora kodu przez programistów, lecz z tego, Ŝe w modelu aplikacji brak jest wielu informacji z poziomu implementacji, które potrzebne do wygenerowania pełnego kodu.) Język modelowania UML jest zasadniczo róŝny od języka programowania C#. Zupełnie róŝna jest składnia obu języków. UML jest językiem graficznym, a C# językiem tekstowym. Nawet składnia tekstowa występująca w UML róŝni się od składni C# (np. w zakresie deklaracji atrybutów). RównieŜ warstwa semantyki jest w wielu miejscach niezgodna. To wszystko powoduje, Ŝe diagramy modelowe mogą być nieczytelne dla programistów na co dzień posługujących się językiem programowania [3]. Idealnym rozwiązaniem jest metoda, w której z modelu jest generowany pełny kod aplikacji. Takie rozwiązanie wymaga jednak modelowania na kilku poziomach szczegółowości: zarówno na poziomie analizy i projektowania, jak i implementacji. Występują tu jednak powaŝne trudności: NajpowaŜniejszą trudność tworzą róŝnice pojęciowe. Pomiędzy pracą analityka a pracą programisty występują róŝnice w stosowanym aparacie pojęciowym. nalityk stosuje pojęcia z dziedziny problemu, posługuje się pojęciami encji (bytu), klasy, aktora, interakcji, stanu, aktywności. Programista posługuje się pojęciami z dziedziny programowania: klasy, instancji, interfejsu, metody, procedury. Częściowo oba zbiory pojęć nakładają są na siebie, częściowo jednak róŝne. Nawet te pojęcia, którymi posługuje się zarówno analityk, jak i programista, róŝnią się w rozumieniu jednego i drugiego. Najlepszym przykładem jest tu klasa. Klasa w rozumieniu analityka jest uogólnieniem (abstrakcją) występujących w świecie rzeczywistym obiektów (dokumentów, osób, przedmiotów). Klasa w rozumieniu programisty jest szczególnym typem danych łączącym w sobie dane i kod oraz umoŝliwiającym dziedziczenie atrybutów i metod. Z róŝnicami pojęciowymi się niejednoznaczność wiąŝe odwzorowania elementów modelowych w implementacyjne. Ponownie jako przykład moŝna podać klasę np. reprezentującą klienta w aplikacji biznesowej. Klient moŝe w ogóle nie występować jako klasa implementacyjna. Dane klienta mogą przechowywane np. w tabeli bazy danych, a dostęp do danych moŝe być zapewniany przez formularz ekranowy. Tak więc nie kaŝda klasa analityczna będzie odpowiadała jednej klasie implementacyjnej. Trudną do pokonania barierą jest niezgodność notacji. Niezgodność ta występuje zarówno w samym modelowaniu, jak i pomiędzy modelowaniem a implementacją. Ten pierwszy rodzaj niezgodności polega na tym, Ŝe do wyraŝenia takich samych pojęć w róŝnych aspektach modelowania uŝywa się róŝnych symboli graficznych (vide UML). Wynika to z wciąŝ jeszcze małej dojrzałości graficznych metod modelowania. Drugi rodzaj niezgodności polega na tym, Ŝe analityk posługuje się metodami graficznymi, programista zaś zapisuje program w notacji tekstowej. Zapis tekstowy jest w odróŝnieniu od notacji graficznej sekwencyjny i wymaga zupełnie innego podejścia. Oddzielenie modelowania od implementacji ma bardzo powaŝne konsekwencje negatywne: WydłuŜa cykl wytwarzania oprogramowania. Niektóre prace muszą być wykonywane dwukrotnie raz podczas modelowania, drugi raz podczas implementacji. 14

15 Długi czas pomiędzy modelowaniem a uzyskaniem konkretnej implementacji powoduje, Ŝe trudno jest zweryfikować poprawność modeli analitycznych. Wymusza to odejście od klasycznego paradygmatu wytwarzania kaskadowego na rzecz metod iteracyjno-przyrostowych [29][70]. nalityk i programista posługują się róŝnymi językami. Konieczność są interpretacji diagramów analitycznych przez człowieka (programistę) jest potencjalnym źródłem błędów. Wszystko to powoduje, Ŝe wczesne fazy wytwarzania oprogramowania często uwaŝane za nadmiarowe. Programiści koncentrują się na jak najszybszym uzyskaniu konkretnych efektów (a więc na implementacji). Mają skłonność do traktowania projektu jako zbioru ogólnych wskazówek i pisania kodu w sporym oderwaniu od projektu. Tymczasem starannie wykonana analiza i projektowanie powinny solidną podstawę stanowić do implementacji. Jest to warunek konieczny do zapewnienia odpowiedniej jakości oprogramowania. PoniewaŜ jakość oprogramowania jest miarą stopnia spełnienia wymagań uŝytkowników, więc poznanie i zrozumienie tych wymagań w czasie analizy jest niezbędne do uzyskania dobrej jakości. Równie istotne jest utrzymanie spójności całego projektu z wymaganiami. Brak spójności metod znacząco utrudnia utrzymanie integralności projektu, a więc zapewnienie ciągłego powiązania pomiędzy wymaganiami, a implementowanymi funkcjami przez wszystkie fazy procesu wytwarzania Propozycja metody integracyjnej Przedstawiona w tej pracy integracyjna metoda konstrukcji aplikacji IMC jest autorską propozycją są są są rozwiązania powyŝszych problemów [41][42][43]. Zakłada ona, Ŝe wszystkie informacje projektowe zapisywane w jednym, zintegrowanym projekcie informatycznym. Informacje tam zapisywane na wielu warstwach informacyjnych, przy czym kaŝda warstwa jest przypisana do określonego poziomu szczegółowości (p. rys. 8). Na najniŝszym poziomie szczegółowości zapisywane wymagania wobec systemu, na wyŝszych rozwiązania właściwe dla poziomu analizy i dla poziomu projektowania, na najwyŝszym dla poziomu implementacji. Informacje zapisane na wyŝszym poziomie szczegółowości uzupełniają, a czasami modyfikują informacje zapisane na niŝszym poziomie szczegółowości. Po zapisaniu informacji na poziomie implementacji jest generowany pełny kod aplikacji. W ujęciu metody IMC implementacja nie polega na pisaniu kodu aplikacji w wybranym języku programowania, lecz na uszczegółowieniu wyniku projektowania. Projekt jest w implementacji uzupełniony o wszystkie szczegóły potrzebne do wygenerowania efektywnego kodu. Tak więc wynikiem implementacji nie jest bezpośrednio kod wykonywalny aplikacji, lecz model implementacji zapisany w taki sam sposób, jak model wymagań i projekt oprogramowania. Ze modelu implementacji jest dopiero generowany kod wykonywalny. MoŜe on być generowany bezpośrednio, jako kod binarny, lub pośrednio, jako kod źródłowy, z którego będzie dopiero kompilowany kod binarny. Nawet jednak w tym drugim przypadku wygenerowany kod źródłowy nie podlega modyfikacji. Jeśli potrzeba zmienić np. algorytm metody, to wszelkie zmiany wprowadza się do modelu implementacji i na nowo generuje kod wykonawczy. Jeśli zmiany wymaga rozwiązanie na poziomie projektowania lub nawet na poziomie analizy, to trzeba wybrać odpowiednią warstwę informacyjną i do niej 1. Trendy integracyjne w inŝynierii oprogramowania 15

16 wprowadzić będą będą Część zmiany. Niektóre takie zmiany od razu widoczne na poziomie implementacji, inne wymagały dopracowania do implementacyjnego poziomu szczegółowości. W metodzie IMC zarówno aparat pojęciowy, jak i notacja graficzna została stworzona w oparciu o język UML. notacji musiała jednak zostać zmieniona tak, aby zapewnić spójność z notacją stosowaną w implementacji. Dla potrzeb graficznego opisywania metod obiektowych stworzono nową notację opartą o diagramy przepływu danych, diagramy przepływu sterowania (wykresy operacyjne) oraz o strukturalne diagramy przepływu sterowania. Cała notacja została ujednolicona w celu zminimalizowania liczby stosowanych symboli. by umoŝliwić wyraŝenie wszystkich szczegółów potrzebnych do wygenerowania efektywnego kodu graficzną ścisłą notację wzmocniono notacją tekstową. W wyniku powstał nowy język IML (ang. Implementable Modeling Language), którego definicję oparto ze strony graficznej na UML, a składnię tekstową na współczesnych obiektowych językach programowania: Java, C#, C ++, Object Pascal (Delphi). W procesie wytwarzania przyjęto model znany z prac Coada i Yourdona [21][22] jako model piłki bejsbolowej (rys. 8a). W tym modelu przejście pomiędzy analizą, projektowaniem i implementacją Są jest swobodne. one traktowane jako wielokrotnie podejmowane, często w dowolnej kolejności, aktywności. W metodzie IMC dodano do tego modelu zintegrowany projekt informatyczny wspólną dla wszystkich faz procesu wytwarzania bazę są danych projektowych (rys. 8b). Dostęp do informacji z tej bazy jest wielowarstwowy, tzn. informacje wprowadzone w fazie analizy dostępne równieŝ w fazie projektowania i implementacji. Na wyŝszych warstwach dokonuje się uszczegółowienia rozwiązań aŝ wprowadzonych na warstwach niŝszych do poziomu wystarczającego do wygenerowania kodu. a) naliza b) naliza Projektowanie Implementacja Projektowanie Zintegrowany projekt informatyczny Implementacja c) Implementacja Projektowanie warstwy poziom informacyjne szczegółowości naliza Zintegrowany projekt informatyczny Wymagania Rys. 8. Model pracy w metodzie IMC: a) model piłki bejsbolowej Coada i Yourdona, b) zintegrowany projekt informatyczny w metodzie IMC, c) układ wielowarstwowy rozwinięty z modelu (b) z dodaną warstwą wymagań 16

17 Koncepcja metody IMC jest bardzo zbliŝona do RUP, występują jednak pomiędzy nimi istotne róŝnice: W IMC połoŝono znacznie większy nacisk na integrację modelowania z implementacją i szybkość przejścia od modelowania do implementacji. RUP jest oparty o język UML lub xuml wykonywalną wersję UML (ang. Executable UML), który jest po prostu UML wzbogaconym o dynamiczną semantykę [58]. W IMC wprowadzono nowy język modelowania i implementacji - IML, duŝo bardziej zorientowany na implementację. W IMC ujednolicono symbolikę i semantykę dla wszystkich typów diagramów UML, co z jednej strony zmniejsza liczbę symboli do zapamiętania, a z drugiej zwiększa elastyczność są stosowania diagramów. W IMC zakłada się, Ŝe projektant będzie mógł wprowadzić do modelu implementacyjnego takie rozwiązania, jakie moŝliwe w językach obiektowych ogólnego zastosowania, dzięki temu generowany kod będzie w pełni efektywny i nie będzie wymagał korekty przez programistę. Wymagania strategiczne co do metody integracyjnej Celem proponowanego rozwiązania jest zwiększenie efektywności wytwarzania wobec metod tradycyjnych przy zapewnieniu porównywalnej lub lepszej jakości produktów końcowych Tezy rozprawy W pracy niniejszej zostaną wykazane następujące tezy: 1. Metoda IMC wykorzystująca język modelowania i implementacji IML dostarcza spójne i modyfikowalne produkty procesu wytwarzania, które być mogą graficznie prezentowane i redagowane. 2. Produkt końcowy procesu wytwarzania metodą IMC moŝe być przekształcany do kodu wykonywalnego na danej platformie programowania za pomocą kompilatora wykorzystującego semantykę i składnię języka IML 3. Metoda IMC wraz z odpowiednim systemem oceny jakości IQUEST zapewnia kontrolę jakości produktów pośrednich jak i prowadzi do uzyskania załoŝonej jakości produktu końcowego. 1. Trendy integracyjne w inŝynierii oprogramowania 17

18 1.6. Struktura rozprawy Treść dalszych rozdziałów jest następująca: W rozdziale drugim przedstawiono koncepcję metody IMC i jej trzech filarów: języka IML, zintegrowanego procesu wytwarzania oraz wykorzystywanych metod zapewnienia jakości. Rozdział trzeci opisuje podstawy języka IML w trzech warstwach: danych, semantyki i prezentacji. Rozdział czwarty jest poświęcony jednemu z elementów procesu wytwarzania: kompilacji diagramów aktywności języka IML do kodu wykonywalnego Rozdział piąty to studium przypadku. Na przykładzie aplikacji biznesowej oprogramowania Wirtualnego Domu Towarowego pokazuje wybrane elementy procesu projektowania wraz z generowaniem kodu wykonywalnego w języku Java. W rozdziale szóstym przedstawiono metodę oceny jakościowej produktów procesu wytwarzania moŝliwą do zastosowania we wczesnych fazach procesu. Rozdział siódmy zawiera podsumowanie pracy, ocenę stosowalności metody IMC i wnioski związane z rozwojem metody. Potwierdzenie tezy pierwszej zostało podzielone pomiędzy rozdziały: drugi, trzeci i piąty. Tezę drugą wykazano w teoretycznie rozdziale czwartym, a w rozdziale piątym zilustrowano na praktycznym przykładzie. Dowód tezy trzeciej znajduje się w rozdziale szóstym. Ze względu na szeroki zakres dziedziny badań, w tej pracy pokazano tylko wybrane elementy proponowanej metody. W rozdziale trzecim semantykę i składnię języka IML zaprezentowano jedynie w zakresie niezbędnym do zrozumienia pozostałej części pracy. W rozdziale czwartym zamiast całego, złoŝonego procesu wytwarzania, przedstawiono jedynie jeden z jego elementów kompilację są diagramów aktywności. Pozostałe elementy procesu wytwarzania w metodzie IMC typowe dla metod opartych o podejście iteracyjno-inkrementacyjne z zastrzeŝeniem stosowania metod zapewnienia jakości (opisanych w rozdziale drugim i szóstym), a zwłaszcza metod zapewnienia spójności projektu. Dla zapewnienia zrozumiałości metody celowo nie pokazano szczegółowo algorytmów procesu kompilacji, lecz skoncentrowano się na zasadach kompilacji i jej przykładowych wynikach. W rozdziale piątym świadomie pominięto szereg działań projektanta od specyfikacji wymagań do diagramu aktywności, tak by moŝna było pokazać działanie procesu kompilacji na konkretnym przykładzie 18

19 Rozdział 2. Koncepcja integracyjnej metody konstruowania aplikacji (IMC) Koncepcja metody IMC jest oparta o trzy główne filary: język IML, zintegrowany proces wytwarzania oprogramowania oraz system oceny jakości (p. rys. 9). Język IML z jednej strony zapewnia projektantowi moŝliwość konstruowania aplikacji poprzez graficzny interfejs projektanta, a z drugiej strony określa sposób zapisu danych projektowych w bazie danych stanowiącej podstawę informatyczną systemu. Jest wykorzystywany w dokumentacji produkowanej w procesie wytwarzania oprogramowania we wszystkich fazach tego procesu. Proces wytwarzania oprogramowania składa się z wielu aktywności, przy czym w odróŝnieniu od klasycznych metod kaskadowych nie jest wymagane zakończenie jednej aktywności przed przejściem do następnej. Cząstkowe rozwiązania projektowe w kaŝdej fazie mogą być dzięki mechanizmom automatyzacji sprawdzone poprzez szybką implementację. To podejście jest moŝliwe dzięki zastosowaniu spójnej notacji IML dla modelowania i implementacji, przez co projektant moŝe graficznie wprowadzić są są w modelu takie korekty i uzupełnienia, które niezbędne do poprawnej implementacji. Wewnątrz procesu wytwarzania zawarte mechanizmy zapewniające integralność projektu. Poszczególne modele mogą być formalnie ocenione w systemie są jakości zapewniającym wczesne wykrywanie błędów i braków. Częściowa automatyzacja procesu umoŝliwia łatwe wygenerowanie działającego kodu aplikacji. Kolejne przyrostowe wersje aplikacji poddawane ocenie klienta. Ocena ta słuŝy do weryfikacji i korekty wymagań w następnej iteracji procesu. Graficzny interfejs projektanta Język IML Baza danych projektowych Wymagania Zintegrowany proces wytwarzania Rozpoznanie naliza Projekt Implementacja plikacja System oceny jakości Ocena przez klienta Rys. 9. Schemat koncepcyjny metody IMC 2.Koncepcja metody IMC 19

20 2.1. Koncepcja j zyka modelowania i implementacji IML Geneza języka Język modelowania i implementacji IML zapewnia środki do prezentacji projektu w sposób graficzny i w sposób tekstowy. Za podstawę definicji notacji graficznej przyjęto zunifikowany język modelowania UML. Przy opracowywaniu notacji tekstowej przyjęto wiodące rozwiązania współczesnych języków obiektowych, takich jak Delphi, C#, C ++, Java i Visual Basic. Dla zapewnienia spójności notacji graficznej i tekstowej konieczne stało się wprowadzenie pewnych modyfikacji w języku IML w stosunku do UML. Za podstawowy środek graficznej prezentacji funkcjonalności przyjęto znane z UML diagramy aktywności, do których wprowadzono elementy stosowane na wykresach operacyjnych oraz elementy przepływu danych wzorowane na diagramach DFD (stosowanych np. w metodzie OMT) i na diagramach interakcji UML. Notację przepływu danych znacznie wzbogacono dla wyraŝenia szczegółów implementacyjnych. Do diagramów aktywności wprowadzono elementy sterowania strukturalnego wzorowane na diagramach Nassi-Shneidermana [60]. Połączono diagramy aktywności z diagramami interakcji i diagramami przejść stanów tak, stanowią Ŝe one bezpośrednie rozszerzenie diagramów aktywności. Diagramy aktywności UML i wykresy operacyjne Diagramy aktywności UML przypominają stosowane od lat 1960 wykresy operacyjne (ang. flowchart) [8]. W języku IML wprowadzono do definicji diagramu aktywności pewne modyfikacje w zakresie symboliki, z których najwaŝniejsze to: zastosowanie sześciokąta jako symbolu warunku, zastosowanie prostokąta zaokrąglonego jako symbolu aktywności i prostokąta zwykłego jako symbolu akcji, zastosowanie wektora przerywanego jako wektora przepływu sterowania i wektora ciągłego jako wektora przepływu danych. Sześciokąt jako symbol warunku jest bardziej pojemnym symbolem od rombu w tym sensie, Ŝe moŝna w nim zmieścić więcej tekstu. Jest to waŝne przy praktycznym wykorzystaniu tego symbolu w implementacji. Przy zastosowaniu rombu do rozgałęzienia sterowania (jak w UML), przy kaŝdym wektorze odchodzącym od tego symbolu umieszcza się wyraŝenie warunku. Jest to wygodne przy modelowaniu, tymczasem przy implementacji oblicza się jedno wyraŝenie dla warunku i w zaleŝności wartości tego wyraŝenia podejmuje się a) b) decyzje co do dalszego [x 0] T x>0 postępowania (p. rys. 10). [x<0] F Drugą modyfikacją jest wprowadzenie do diagramu Rys. 10. Oznaczenie rozgałęzienia sterowania na diagramie aktywności: a) w języku UML, b) w języku IML 20

21 b aktywności IML oprócz symbolu aktywności (prostokąta zaokrąglonego jak w diagramach UML) równieŝ symbolu akcji (zwykłego prostokąta jak na wykresach operacyjnych). ktywność jest działaniem długotrwałym, podejmowanym często cyklicznie. kcja z kolei jest działaniem krótkotrwałym, niepodzielnym w skali czasowej diagramu (p. rys. 11). a) b) Edit a + c Document Rys. 11. RóŜnice w stosowaniu prostokąta zaokrąglonego i prostego: a) symbol aktywności, b) symbol akcji PoniewaŜ diagram interakcji stanowi proste rozszerzenie diagramów aktywności, więc na tym ostatnim mogą występować dwa rodzaje przepływu: przepływ danych i przepływ sterowania. Dlatego wprowadzono dwa róŝne symbole przepływu: wektor przerywany dla przepływu sterowania i wektor ciągły dla przepływu danych. Diagram aktywności z wektorami przepływu sterowania przedstawiono na rys. 12. Dla porównania podano teŝ prezentację tego samego algorytmu w notacji UML i w notacji wykresów operacyjnych. a) b) STRT c) Preparation Preparation Preparation T F ok T Condition F [Condition] [not ok] [ok] [not Condition] T ok T Condition F F Do Something Do Something Else Do Something Do Something Else Do Something Do Something Else Finalization Finalization Finalization STRT Rys. 12. Diagram aktywności z wektorami przepływu sterowania: a) w notacji IML, b) w notacji UML, c) w notacji stosowanej na wykresach operacyjnych W definicji języka UML zabrakło diagramów przepływu danych (ang. Data Flow Diagrams DFD) opisujących funkcjonalność poprzez przetwarzanie danych między procesami [65]. Zostały one zastąpione przez diagramy interakcji, które jednak nie zawierają symboli procesów. W IML wprowadzono elementy przepływu danych do diagramów aktywności w ten sposób, Ŝe: Węzłami przepływu mogą być obiekty i operacje. Symbolem obiektu jest ikonid (zespół złoŝony z ikony i pola tekstowego identyfikującego obiekt), symbolem operacji jest prostokąt zaokrąglony (jeśli operacja jest realizowana w formie aktywności) lub prostokąt zwykły (jeśli operacja jest realizowana w formie akcji). Operacje mogą nie tylko przetwarzać dane, ale równieŝ być źródłem i miejscem Diagramy przepływu danych (DFD) są przeznaczenia danych. Węzły przepływu danych połączone wektorami przepływu danych w formie wektora ciągłego zakończonego strzałką prostą. Wektory mogą mieć trzy etykiety: główną źródłową, i docelową. Etykieta wektora przepływu danych jest 2.Koncepcja metody IMC 21

22 1: 5: 2: 3: polem tekstowym, które opisuje właściwości lub operacje obiektów źródłowych i docelowych wektora będące źródłem lub przeznaczeniem danych, albo parametry operacji źródłowych i docelowych wektora. Diagram umoŝliwia pokazanie wymiany danych między dwoma obiektami i modyfikację danych przez parametr modyfikowalny operacji. SłuŜy do tego dwukierunkowy wektor przepływu danych. Zamiast ikonidu obiektu moŝe być stosowane pole tekstowe zawierające wyraŝenie. Diagram umoŝliwia wybór róŝnych źródeł danych i róŝnych miejsc przeznaczenia danych przez umieszczenie symbolu warunku na drodze przepływu danych. Przykład pokazano na rys. 13. Dla porównania podano teŝ prezentację tego samego diagramu w notacji DFD. a) Magazyn Magazyn B stan stan a Porównanie stanów (a, b) b Raport niezgodności b) Magazyn Magazyn B Porównanie stanów Raport niezgodności Rys. 13. Diagram przepływu danych: a) w notacji IML, b) odpowiadający mu diagram DFD W UML przepływ danych wyraŝa się w formie diagramów interakcji. Interakcja reprezentuje wymianę komunikatów między obiektami współpracującymi ze sobą w ramach kolaboracji. Kolaborację wyraŝa się na diagramie kolaboracji w formie sieci powiązań między obiektami. Przekazywane wzdłuŝ tych powiązań komunikaty tworzą interakcję. W IML diagram interakcji jest toŝsamy z diagramem aktywności, na którym stosuje się wektory przepływu danych. Przekazywanie komunikatów uogólniono do przesyłania danych. Drogę przesyłania danych między dwoma obiektami wyraŝa symbol magistrali danych (strzałka blokowa). Przykład diagramu interakcji w notacji IML i UML pokazano rys. 14. Diagramy interakcji UML a) Klient Zamówienie Potwierdzenie Dział sprzedaŝy 4: Faktura Zapytanie o stan Stan towaru Dział magazynowy b) :Klient 1: Zamówienie 5: Potwierdzenie Dział spedycji :Dział sprzedaŝy 2: Zapytanie o stan 3: Stan towaru :Dział magazynowy 4: Faktura :Dział spedycji Rys. 14. Diagram aktywności z magistralami danych: a) w notacji IML, b) odpowiadający mu diagram interakcji w notacji UML 22

23 Do języka IML zaadaptowano strukturalne diagramy sterowania Nassi- Shneidermana (N-S). Diagramy te stosowano w latach 1970 dla rozwiązania problemu strukturalizacji algorytmu, czyli dopasowania notacji graficznej do strukturalnych języków programowania. by zapewnić spójność notacji diagramów N-S z stosowaną symboliką w diagramach aktywności wprowadzono pojęcie graficznej struktury sterowania konstruowanej z podstawowych symboli: bloku wykonawczego (symbolu akcji), bloku powtarzania (symbolu aktywności), symbolu warunku oraz symbolu ramki grupującej. Graficzną strukturę sterowania tworzy się poprzez nakładanie na jednego symbolu na krawędź górną albo dolną drugiego symbolu. Graficzne struktury sterowania wchodzą jako węzły do diagramów aktywności. Przykład graficznej struktury sterowania pokazano na rys. 15. Diagramy Nassi-Shneidermana (N-S) a) T Do Something Preparation ok Condition F Do Something Else b) Preparation T ok Do Something Condition Finalization Do Something Else F Finalization Diagramy przejść stanów Rys. 15. lgorytm z rys. 12. w notacji strukturalnej: a) graficznej struktury sterowania IML, b) diagramu N-S Graficzne struktury sterowania mogą być uŝyte do prezentacji złoŝonych stanów na diagramie przejść stanów. Na diagramach UML symbolem stanu jest zaokrąglony prostokąt oznaczający równieŝ aktywność. W języku IML rozdzielono symbol stanu i symbol aktywności przyjmując elipsę za symbol stanu. Prostokąt zaokrąglony symbolizuje na diagramach przejść stanów aktywność, czyli operację wykonywaną tak długo, jak długo obiekt znajduje się w określonym stanie. Z kolei prostokąt zwykły symbolizuje na diagramie przejść stanów akcję wejściową lub wyjściową stanu albo akcję przejściową (wykonywaną w czasie przejścia stanów). PoniewaŜ przejście stanów moŝe być uwaŝane za specyficzny rodzaj przepływu sterowania, więc jako symbol przejścia stanów uŝywa się wektora przepływu sterowania. Symbol warunku moŝe być równieŝ uŝyty w połączeniu z wektorem przejścia stanów do oznaczenia warunku strzegącego przejścia. Przykład diagramu stanów IML pokazano na rys. 16. Dla porównania pokazano diagram przejść stanów w notacji UML. a) Initialize State 1 DoSomething Finalize Event1 Event2 Condition Execction State 2 b) State1 entry: Initialize exit: Finalize do: DoSomething [Condition] Event1 /Execction Event2 Rys. 16. Diagram stanów: a) w notacji IML, b) w notacji UML State 2 2.Koncepcja metody IMC 23