teoria cw1, Studia i nauka, Sprawozdania i notatki, Inżynieria oprogramowania, Teoria i instrukcje
[ Pobierz całość w formacie PDF ]
//-->I.ZASADY OBIEKTOWEGO PODEJŚCIA DO PROGRAMOWANIANiezależnie od języka implementacji, istnieją ogólne zasady obiektowego podejścia dotworzenia oprogramowania, nazywane modelem obiektowym. Składa się on z poniższychpojęć:●obiekt– każdy byt (pojęcie lub rzecz), mający znaczenie w dziedzinie zastosowania●klasa– uogólnienie zbioru obiektów, mających takie same atrybuty, operacje i znaczenie.Jeśli pewne klasy mają wspólną część, to powinna ona być ich wspólną klasą bazową (lubinaczej nadklasą).●komunikat(ang. message) – specyfikacja wymiany informacji między obiektami,zawierająca zlecenie wykonania określonej operacji lub wymiany danych.●abstrakcja proceduralna i abstrakcja danych- polega na ukrywaniu nieistotnych cechobiektu w trakcie operacji z nim związanych, dzięki temu że obiekt może być wyposażony wwiedzę o swych operacjach. Dzięki temu ułatwia się operacje i unika błędów, a także skracasię notację - można lepiej panować nad złożonymi systemami lub algorytmami.●hermetyzacja (ang. encapsulation)- polega na selektywnym dostępie do szczegółówobiektu (atrybutów i operacji) i dzięki temu zapewnieniu niezależności (braku niepotrzebnychsprzężeń). Prywatne atrybuty i operacje są niedostępne dla otoczenia, stanowiąc elementywewnętrznego mechanizmu działania obiektu. Publiczne atrybuty i operacje są dostępne dlaotoczenia, umożliwiając odwoływanie się do obiektu za pomocą komunikatów. Chronioneatrybuty i operacje są dostępne w ciągu podklas danej klasy. Cechy obiektowego podejścia doprogramowania●dziedziczenie (ang. inheritance) polega na przejmowaniu cech pewnych obiektów przezinne, z równoczesnym dodawaniem nowych cech tworzenie tzw. specjalizacji. Oznacza toprzyporządkowanie atrybutów i operacji do klas zgodnie z hierarchiczną zależnością, jakiejpodlegają klasy. Dzięki temu można budować systemy złożone, lecz elastyczne wzastosowaniu.●polimorfizm (ang. polymorphism)– polega na nadaniu takiej samej nazwy różnymoperacjom w klasach należących do jednej hierarchii (od nadklasy przez wszystkie podklasy).Pozwala m.in. na wywołanie tzw. wirtualnej metody (procedury lub funkcji), która może miećróżne znaczenie w zależności od kontekstu wywołania.W oparciu o wymienione zasady modelu obiektowego, powstaje język bardziejzbliżony do opisywanego problemu (w odróżnieniu od zbliżonego do maszyny).Dzięki tym założeniom program obiektowo zorganizowany może się składać prawiewyłącznie z deklaracji zmiennych obiektowych (instancji); w trakcie tych deklaracjiwykonywane są wszystkie operacje inicjalizacji obiektów (definiowania ich stanupoczątkowego), tak by mogły one zacząć funkcjonować w otoczeniu innych obiektów. Dalszefunkcjonowanie każdego obiektu polega na odbiorze komunikatów wysyłanych przez inneobiekty i odpowiednim ich przetwarzaniu, w ramach którego możliwe jest również wysyłaniewłasnych komunikatów, czyli oddziaływanie na otoczenie.Taki model daje większe możliwości, co jest związane głównie z decentralizacjąfunkcjonalności (każda klasa odpowiada za swoją część operacji złożonego systemu) i nie jestpotrzebny żaden nadrzędny mechanizm, który musiałby być odpowiednio bardziej złożony.II.MDA.PodejścienazwaneModelDrivenArchitecture zostało opracowane przez ObjectManagement Group (OMG) i udostępnione w2001 r., w celu standaryzacji procesu rozwijaniasystemówinformatycznych.Podejścietozapewnia, poprzez zdefiniowane w jego ramachstandardy, otwartość i niezależność od producentanarzędzi wspomagających – producenci tychnarzędzi stosują się do specyfikacji MDA,zapewniając tym samym ich współpracę.MDA jest oparte o model niezależny od platformy (platform-independent model, PIM)aplikacji, określający jej strukturę i funkcjonalność (model biznesowy). Kompletna aplikacjaMDA składa się z końcowego modelu PIM, jednego lub więcej modeli dedykowanych doplatformy (platform-specific model, PSM) i kompletnych implementacji, po jednej dlaobsługiwanychplatform.Terminplatformaoznaczatuwarstwęoprogramowaniasystemowego lub użytkowego, która stanowi środowisko w jakim uruchamia się rozwijanysystem informatyczny. Przykładami platform są: J2EE, Web Services, XML/SOAP, EJB,C#/.Net, CORBA, itd.Proces inżynierii oprogramowania prowadzony w zgodzie z MDA koncentruje siępoczątkowo na funkcjonalności aplikacji lub systemu, bez wnikania w niuanse technologiczneplatform docelowych. W ten sposób MDA pozwala zupełnie oddzielićszczegółyimplementacji od funkcjonalności. Dzięki temu nie jest potrzebne powtarzanie procesudefiniowania funkcjonalności systemu za każdym razem, gdy jest on przenoszony na nowąlub ewoluującą platformę.Poszczególne architektury są zwykle związane z używanymi technologiami. Zgodnie zMDA funkcjonalność jest modelowana tylko raz przez PIM, przy zastosowaniu języka UMLlub innego standardu OMG. Przejście od modelu PIM przez model PSM do docelowychplatform jest obsługiwane przez narzędzia zgodne ze specyfikacją QVT stworzoną przezOMG (Query/View/Transformation), np. M2M zawarte w Eclipse Modeling Framework.Zastosowanie tych narzędzi znacznie upraszcza obsługę zmieniających się platform i ichtechnologii, prowadząc w granicznym przypadku do automatyzacji tych kroków.Strukturę procesu zgodnego z MDA przedstawia schemat, pochodzący ze stronyinternetowej OMG. Jest to model warstwowy, w którego centrum są zawarte główneskładowe podejścia:1. metamodel MOF (Meta-Object Facility), zawierający specyfikację składni dlawszystkich modeli obsługiwanych w ramach MDA. Dzięki temu, że wszystkie modele stosujątą składnię, mogą być automatycznie przetwarzane, od modelu PIM przez PSM do koduaplikacji na konkretnej platformie. Aby to umożliwić, MDA wymaga, by modele byływyrażone w języku o składni zgodnej z MOF. Dzięki temu można zapisywać modele wrepozytorium zgodnym z MOF, wyszukiwać je i przetwarzać (wykonywać transformacje) zapomocą narzędzi zgodnych z MOF, a także przetwarzać do postaci definiowanej przez XMI,np. w celu udostępniania przez sieć. To wymaganie nie ogranicza typu modeli – językizgodne z MOF obecnie pozwalają tworzyć modele struktury aplikacji, zachowania i danych2. język UML, będący graficznym językiem modelowania, zgodnym z MOF.3. wspólny metamodel hurtowni danych CWM (Common Warehouse Model), któryopisuje sposób wymiany danych dotyczących modeli między hurtowniami danych, systemamizarządzania wiedzą i przy zastosowaniu technologii internetowych.W drugiej warstwie znajdują się obsługiwane platformy, wymieniono tu: Java, .NET,CORBA, Web Services, XMI/XML. XMI (XML Metadata Interchange) definiuje formatwymiany danych dla modeli wyrażonych w języku UML i innych językach zgodnych z MOF.Format ten jest oparty na języku XML i w efekcie definiuje odwzorowanie między językiemUML i XML.W trzeciej, najbardziej zewnętrznej warstwie znajdują się usługi rozszerzające(pervasive services), wymieniono tu: katalogowe (directory), transakcyjne (transactions),obsługi zdarzeń (events) i bezpieczeństwa (security).Na zewnątrz modelu są wymienione przykładowe dziedziny zastosowań rozwijanychsystemów (Finance, Manufacturing, Space, …)Wtypowym procesie realizowanym zgodnie z MDA,wyróżnia się następująceetapy:1. Budowa modelu przypadków użycia jest rezultatem identyfikacji i dokumentowaniawymagań. W tym celu tworzy się diagram przypadków użycia, który jest odzwierciedleniemwymagań funkcjonalnych i zawiera aktorów systemu i skojarzone z nimi przypadki użycia.Ponadto zawiera on tekstowe opisy przypadków użycia i ich scenariusze. Do wybranychprzypadków użycia można dołączyć diagramy czynności schematycznie pokazujące przebiegreprezentowanej przez przypadek użycia funkcji systemu;2. Budowa modelu analitycznego opisującego elementy składowe systemu i ichwspółdziałanie. Model analityczny powinien pokazywać realizacje wszystkich przypadkówużycia w postaci diagramów klas obejmujących klasy potrzebne do zrealizowaniamodelowanego działania, diagramów interakcji pokazujących podstawowy i alternatywneprzebiegi przypadku użycia. Następnie z klas występujących na tych diagramach tworzy siędiagram klas całego systemu;3. Budowa modelu projektowego będącego podstawą do wygenerowania szkieletukodu aplikacji. Model projektowy jest kompletnym modelem klas powstałym z rozszerzeniadiagramu z modelu analitycznego o wszystkie atrybuty i metody klas.4. Implementacja rozpoczynająca się od wygenerowania szkieletu aplikacji.Utworzony projekt staje się repozytorium kodu aplikacji. Od tej pory każda zmiana w modelupowoduje zmianę w kodzie aplikacji. Kolejnym krokiem jest uzupełnienie plików z kodemźródłowym odpowiednimi treściami, które pozwolą na funkcjonowanie aplikacji zgodnie zwymaganiami wyrażonymi w scenariuszach;5. Uruchomienie wykonywane po zakończeniu etapu kodowania. Ma ono na celudoprowadzenie do podstawowej, poprawnej pracy. Wykonuje się je drogą debugowania;6. Testowanie mające na celu ujawnienie wszelkich niesprawności działania aplikacji iniezgodności z wymaganiami. Na podstawie wyników testowania może być koniecznewprowadzenie korekt w implementacji lub nawet w etapach wcześniejszych (modelach);wtedy powtarza się cały cykl od najwcześniejszej korekty.
[ Pobierz całość w formacie PDF ]