mgr in. Jarosław Kuchta

POLITECHNIK GD SK WYDZIŁ ELEKTRONIKI TELEKOMUNIKCJI I INFORMTYKI Katedra rchitektury Systemów Komputerowych Rozprawa doktorska Integracyjna metoda konstrukcji 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

Prac wykonano w ramach projektu badawczego MNiSW N51902232/2949

Spis tre ci Rozdział 1. Trendy integracyjne w in ynierii oprogramowania... 5 1.1. Geneza i integracja metod analizy i projektowania...6 1.2. Integrowanie rodowisk implementacji...12 1.3. Problemy pełnej integracji...13 1.4. Propozycja metody integracyjnej...15 1.5. Tezy rozprawy...17 1.6. Struktura rozprawy...18 Rozdział 2. Koncepcja integracyjnej metody konstruowania aplikacji (IMC)... 19 2.1. Koncepcja j zyka modelowania i implementacji IML...20 2.1.1. Geneza j zyka...20 2.1.2. Cechy charakterystyczne j zyka IML...24 2.2. Wybrane elementy procesu wytwarzania...28 2.2.1. Przebieg procesu wytwarzania...28 2.2.2. Podstawowe mechanizmy usprawniaj ce proces wytwarzania...29 2.3. Metody zapewnienia jako ci...37 2.3.1. Koncepcja systemu oceny jako ci projektu...38 2.3.2. Zapewnienie spójno ci projektu...38 2.3.3. Szybkie przej cie od wymaga do implementacji...39 Rozdział 3. Podstawy j zyka IML... 41 3.1. Warstwa danych IML...42 3.1.1. Metaj zyk IML...42 3.1.2. Podstawowe klasy projektowe...45 3.1.3. Zasady zapisu danych projektowych...47 3.2. Wybrane elementy warstwy semantyki IML...48 3.2.1. Semantyka modelu klas...50 3.2.2. Semantyka modelu wymaga...55 3.2.3. Semantyka modelu przypadków u ycia...57 3.2.4. Semantyka modelu akcji...57 3.2.5. Semantyka modelu aktywno ci...59 3.2.6. Semantyka modelu implementacji...60 3.3. Warstwa prezentacji IML...62 3.3.1. rodowisko graficzne...63 3.3.2. Symbole graficzne...67 3.3.3. Relacje mi dzy elementami graficznymi...76 3.3.4. Elementy tekstowe j zyka...77 3.3.5. Wybrane zasady składni i konstrukcje j zykowe...84 3.3.6. Rodzaje diagramów...107 Rozdział 4. Kompilacja diagramów aktywno ci... 109 4.1. Odwzorowanie diagramu w model aktywno ci...110 4.1.1. Zasady tworzenia grafu odwzorowania...110 4.1.2. Zasady wst pnego przygotowania grafu odwzorowania...113 4.1.3. Zasady analizy semantycznej grafu odwzorowania...130 4.2. Transformacja modelu aktywno ci w model implementacji w j zyku IML...163 4.2.1. Zasady podziału modelu aktywno ci na procedury...164 4.2.2. Wybrane zasady syntezy instrukcji...169 4.2.3. Wybrane zasady ustalenia kolejno ci instrukcji...174 4.3. Translacja modelu implementacji na konkretny kod wykonywalny...174 4.3.1. Zasady translacji typów danych...175 3

4.3.2. Zasady odwzorowania komponentów abstrakcyjnych w konkretne...177 4.3.3. Zasady translacji instrukcji IML na instrukcje j zyka implementacji...178 Rozdział 5. Studium przypadku...181 5.1. Wybrane elementy projektu systemu rozproszonego...181 5.1.1. Opis dziedziny problemu...181 5.1.2. Specyfikacja wymaga...183 5.1.3. naliza przypadków u ycia...183 5.1.4. Projekt architektury systemu...187 5.1.5. Projektowanie logiki na poziomie operacji...189 5.2. Generowanie kodu...191 5.2.1. Odwzorowanie diagramu aktywno ci w model aktywno ci...191 5.2.2. Transformacja modelu aktywno ci w model implementacyjny...206 5.2.3. Translacja kodu wykonywalnego z IML do Javy...214 5.3. Wykrywanie bł dów i wprowadzanie modyfikacji...223 Rozdział 6. Ocena jako ci projektu...225 6.1. Metoda oceny jako ci projektu...225 6.1.1. Model jako ci projektu...226 6.1.2. Sposoby pomiaru jako ci...229 6.1.3. Program oceny jako ci...232 6.2. Definicje metryk i miar...233 6.2.1. Metryki i miary kompletno ci...233 6.2.2. Metryki i miary poprawno ci...234 6.2.3. Metryki i miary spójno ci...235 6.2.4. Metryki i miary zrozumiało ci...237 6.2.5. Metryki i miary modyfikowalno ci...238 6.2.6. Metryki i miary weryfikowalno ci...239 6.3. Ocena jako ci przykładowego projektu...240 6.3.1. Tworzenie i ocena specyfikacji wymaga...240 6.3.2. Wnioski z oceny...250 Rozdział 7. Podsumowanie...252 7.1. Spełnienie wymaga strategicznych...252 7.1.1. Wymagania co do efektywno ci...253 7.1.2. Wymagania co do jako ci...255 7.2. Metoda IMC na tle innych metod...257 7.3. Warunki stosowalno ci...260 7.4. Wnioski i perspektywy rozwoju...263 Bibliografia...265 Indeksy...268 4

Rozdział 1. Trendy integracyjne w in ynierii oprogramowania W dziedzinie in ynierii oprogramowania mo na zauwa y wyra ne d enie do integracji ró nych metod i narz dzi wytwarzania oprogramowania. Dominuj ce s 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 s 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 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 s 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 rodowisk wyst puj jednak powa ne problemy. Nale y tu wymieni niezgodno aparatów poj ciowych stosowanych w 1. Trendy integracyjne w inŝynierii oprogramowania 5

modelowaniu i w implementacji, niejednoznaczno odwzorowania jednych poj na drugie, niezgodno notacji [45]. Te problemy powoduj, e dotychczas stosowane metody s 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 projektowych a 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 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 s poddawane ocenie przez system kontroli jako ci obliczaj cy szereg miar statystycznych. Powy sze aktywno ci mog by podejmowane wielokrotnie, a do zapewnienia odpowiedniej jako ci wynikowej aplikacji. 1.1. 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

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 Testowanie jednostkowe Testowanie integracyjne Testowanie systemowe Testowanie akceptacyjne Rys. 2. Fazy i aspekty procesu wytwarzania oprogramowania 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 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]. 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 Flow 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

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 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 t 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 architektur 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

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 z czasu wzrostu i czasu dojrzewania. Czas wzrostu jest czasem potrzebnym na wytworzenie pierwszej wersji oprogramowania. W czasie dojrzewania wytwarzane s 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 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 s zło eniem diagramów klas z OMT, metody Boocha i wielu innych metod obiektowych. Diagramy stanów s (z pewnymi modyfikacjami) oparte o prac Harela. Diagramy aktywno ci s 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

metody przedobiektowe metody obiektowe 1.generacji metody obiektowe 2.generacji unifikacja metod obiektowych 1966 1973 1975 1976 1978 1987 1990 1991 1992 1994 1997 2001 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 2006 gile Unified Process Rys. 3.Geneza i rozwój obiektowych metod analizy i projektowania UML od 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]. 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

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 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 s zmiany wymaga nawet w pó nym stadium projektu. Projekt musi by dopasowywany do zmieniaj cych si wymaga i warunków na korzy 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 s oparte o odpowiednio zmotywowanych deweloperów, którym trzeba zapewni rodowisko pracy i zaufa, e wykonaj swoj 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

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 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 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 s zintegrowane rodowiska programowania wizualnego: Delphi, Borland C ++ Builder, Java Builder, Visual Studio [15][36][54][50]. Podejmowane s 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 2007 + modelowanie obiektowo-relacyjne Delphi 7.0 + projektowanie struktury danych (diagramy E-R) Delphi 2.0 + projektowanie interfejsu uŝytkownika Turbo Pascal 7.0 + edycja zasobów Turbo Pascal 5.0 + 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

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 klas z nagłówkami procedur. Diagramy funkcjonalne i dynamiczne nie s 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

marginesie nale y zaznaczy, e nieefektywno 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 s 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 si na siebie, cz ciowo s 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 wi e si niejednoznaczność 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 by 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

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 interpretacji diagramów analitycznych przez człowieka (programist ) jest potencjalnym ródłem bł dów. Wszystko to powoduje, e wczesne fazy wytwarzania oprogramowania s 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 stanowi solidn podstaw 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. 1.4. Propozycja metody integracyjnej Przedstawiona w tej pracy integracyjna metoda konstrukcji aplikacji IMC jest autorsk propozycj rozwi zania powy szych problemów [41][42][43]. Zakłada ona, e wszystkie informacje projektowe s zapisywane w jednym, zintegrowanym projekcie informatycznym. Informacje s 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 s 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

wprowadzi zmiany. Niektóre takie zmiany b d od razu widoczne na poziomie implementacji, inne b d 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. Cz 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 notacj graficzn wzmocniono cisł 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 jest swobodne. S 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 danych projektowych (rys. 8b). Dost p do informacji z tej bazy jest wielowarstwowy, tzn. informacje wprowadzone w fazie analizy s dost pne równie w fazie projektowania i implementacji. Na wy szych warstwach dokonuje si uszczegółowienia rozwi za wprowadzonych na warstwach ni szych a do poziomu wystarczaj cego do wygenerowania kodu. a) naliza b) naliza Projektowanie Implementacja Projektowanie Zintegrowany projekt informatyczny Implementacja c) Implementacja Projektowanie warstwy informacyjne poziom 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

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 semantyk dynamiczn [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 stosowania diagramów. W IMC zakłada si, e projektant b dzie mógł wprowadzi do modelu implementacyjnego takie rozwi zania, jakie s 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. 1.5. 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 mog by 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

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 diagramów aktywno ci. Pozostałe elementy procesu wytwarzania w metodzie IMC s 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

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 w modelu takie korekty i uzupełnienia, które s niezb dne do poprawnej implementacji. Wewn trz procesu wytwarzania s zawarte mechanizmy zapewniaj ce integralno projektu. Poszczególne modele mog by formalnie ocenione w systemie 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 s 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

2.1. Koncepcja j zyka modelowania i implementacji IML 2.1.1. 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, e stanowi 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 od 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

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) Edit Document b) a + c 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 Diagramy przepływu danych (DFD) 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 przeznaczenia danych. W zły przepływu danych s poł czone wektorami przepływu danych w formie wektora ci głego zako czonego strzałk prost. Wektory mog mie trzy etykiety: ródłow, główn i docelow. Etykieta wektora przepływu danych jest 2.Koncepcja metody IMC 21

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 Diagramy interakcji UML 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. 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

Diagramy Nassi-Shneidermana (N-S) 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 symbolik stosowan 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. 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

1 1 2.1.2. Cechy charakterystyczne j zyka IML W j zyku IML zastosowano kilka charakterystycznych rozwi za, takich jak: dualizm tekstowo-graficzny, podobie stwo reprezentacji graficznej i tekstowej, minimalizacja zbioru symboli graficznych, elastyczno składni tekstowej, oddzielenie poj cia nazwy od identyfikatora, stosowanie tekstu wieloj zycznego, wyró nianie słów kluczowych, wykorzystanie stereotypów do precyzowania semantyki. Dualizm tekstowo-graficzny Reprezentacja graficzna projektu nadaje si do projektowania na wysokim poziomie abstrakcji. Diagramy ułatwiaj prac koncepcyjn, umo liwiaj lepsze zrozumienie powi za mi dzy elementami projektu. Z drugiej strony reprezentacja tekstowa projektu bardziej nadaje si do wyra enia du ej liczby szczegółów implementacyjnych. W przypadku prostych algorytmów szybciej pisze si tekst programu ni rysuje diagram przepływu. Dlatego w metodzie IMC przyj to w warstwie prezentacji j zyka IML zasad dualizmu tekstowo-graficznego. Zasada ta oznacza, e kaŝdy element semantyczny moŝe mieć reprezentację tekstową albo graficzną, a wybór reprezentacji zaleŝy od projektanta (rys. 17). W poł czeniu z reguł podobie stwa reprezentacji graficznej i tekstowej (p. poni ej) zapewnia to mo liwo automatycznej (lub półautomatycznej) zmiany reprezentacji. for i for j C i,j to.row.count to B.Col.Count.Col.Count i,k k 1 B k,j Podobieństwo reprezentacji graficznej i tekstowej for i 1 to.row.count do { for j 1 to B.Col.Count do { C[i, j] sum { from k 1 to.col.count { [i,k] B[k,j] } } } } Rys. 17. Reprezentacja graficzna i odpowiadająca jej reprezentacja tekstowa dla algorytmu mnoŝenia macierzy są Z zasady dualizmu tekstowo-graficznego wynika reguła podobieństwa reprezentacji graficznej i reprezentacji tekstowej. Ta nieformalna reguła stanowi, e reprezentacja graficzna i reprezentacja tekstowa elementu do siebie wizualnie podobne. Dlatego np. za operator przypisania w IML przyj to strzałk. Symbol strzałki jest podobny do wektora przepływu danych, a oba symbole reprezentuj te same operacje. W celu jeszcze lepszego dopasowania składni tekstowej i graficznej zdefiniowano trzy symbole przypisania: w lewo, w prawo oraz symbol wymiany. Dwa pierwsze mog by ł czone w symbol operacji zło onej (np. addto ) z symbolami operacji binarnych (takimi jak + ) poprzez umieszczenie symbolu operacji binarnej w indeksie górnym bezpo rednio przy ko cu docelowym strzałki. Rozpoznaje si te symbol zło ony, w którym symbol operacji binarnej jest umieszczony w indeksie górnym pomi dzy strzałk a poziom kresk j przedłu aj c (rys. 18). 24