PowerPoint Presentation

Document Sample
PowerPoint Presentation Powered By Docstoc
					                 Standardy w zakresie systemów rozproszonych
                                i baz danych




                                              Wykład 7:
                                              Model Driven Architecture
                                              (MDA)
                                                      Piotr Habela
                                                      Kazimierz Subieta


                                                      Polsko-Japońska Wyższa Szkoła
                                                      Technik Komputerowych, Warszawa




P.Habela, K.Subieta. SSR, Wykład 7, Folia 1                                             kwiecień 2009
                                              Plan prezentacji



   •     Modelowanie – rola w dzisiejszych metodykach
   •     Motywacja Model Driven Architecture (MDA)
   •     Podstawowe pojęcia i koncepcja MDA
   •     Istniejące specyfikacje OMG
   •     MDA: podsumowanie i otwarte kwestie
   •     MDA a nasze prace


P.Habela, K.Subieta. SSR, Wykład 7, Folia 2                      kwiecień 2009
                        Modelowanie – ogólne spostrzeżenia
• Obowiązkowe z punktu widzenia jakości a nawet
  wykonalności większej skali projektów
• Pomyślna standaryzacja UML wzmacnia jego pozycję jako
  środka komunikacji pomiędzy uczestnikami projektu
        – dynamizuje rozwój narzędzi
• Narzędzia CASE nie są efektywnym środkiem
  programowania wyższego poziomu - wbrew początkowym
  nadziejom
• Narzędzia CASE są traktowane często jako źródło narzutów
  metodologicznych i dokumentacyjnych
        – stąd postrzegane negatywnie np. w metodach XP

P.Habela, K.Subieta. SSR, Wykład 7, Folia 3                  kwiecień 2009
                                              Geneza MDA
• Kolejna inicjatywa konsorcjum OMG (CORBA, UML…),
  oparta na ramie pojęciowej UML
• MDA jest stworzone w duchu standardu CORBA:
        – jako rozwiązanie uniwersalne w stosunku do platform i technologii
        – jako nawiązanie architektoniczne obejmujące całość cyklu
          wytwarzania oprogramowania
• Bardziej szerokie i realistyczne spojrzenie na rozwój
  technologii:
        –    Nieuniknione jest współistnienie wielu języków programowania,
        –    Nieuniknione są różnorodne technologie middleware
        –    Technologie ewoluują i są zastępowane przez inne
        –    Cykl życiowy systemu/projektu może być długi
P.Habela, K.Subieta. SSR, Wykład 7, Folia 4                           kwiecień 2009
                                              MDA – motywacja
• Zapewnienie modelowaniu centralnego miejsca:
        – nie ideologicznie, a praktycznie
        – jako działanie ukierunkowane wprost na wytworzenie produktu
• Zakłada podniesienie produktywności w następujących
  aspektach wytwarzania oprogramowania:
        – Implementacja, testowanie
        – Integrowanie, pielęgnacja
• Modele są abstrakcyjne w sensie technologii:
        – ochrona inwestycji poczynionych podczas analizy w obliczu zmian
          technologicznych i wymogów współdziałania
• Realizacja tradycyjnej misji OMG:
        – przenośność, współdziałanie, ponowne użycie.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 5                        kwiecień 2009
                                              3 główne zasady MDA


       1. Bezpośrednia reprezentacja problemu. Tworzenie
          oprogramowania ma się koncentrować nie wokół
          konkretnej technologii ale wokół problemu, który
          mamy do rozwiązania.
       2. Automatyzacja. Należy użyć automatycznych
          narzędzi do zmechanizowania tych aspektów tworzenia
          oprogramowania, które nie mają wiele wspólnego z
          ludzką kreatywnością.
       3. Otwarte standardy: Ponowne użycie, budowa
          właściwej infrastruktury rynku, wykorzystanie open
          source.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 6                         kwiecień 2009
                                    Założenia koncepcyjne MDA
• Oddzielenie specyfikacji funkcjonowania systemu od
  szczegółów specyficznych dla danej platformy.
• Podejścia ad-hoc w narzędziach CASE opartych na UML
  usiłowały zawrzeć w jednym kroku przejście od modelu do
  kodu. Jest to problematyczne:
        – Albo fiksujemy „jedynie słuszne” odwzorowania abstrakcji
          modelu na konstrukcje językowe wybranej platformy
        – Albo zaśmiecamy model znaczną liczbą specyficznych dla
          platformy adnotacji
• MDA zakłada:
        – Wyodrębnienie modelu abstrakcyjnego - wyniku analizy
        – Modelu określającego sposób implementacji dla określonej
          platformy
• Wsparcie odwzorowania pomiędzy tymi modelami jako
  zasadnicze źródło poprawy produktywności.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 7                          kwiecień 2009
              Poziomy abstrakcji wyodrębnione w MDA
• Określane pojęciem viewpoint:
        – zastosowanie zasady abstrakcji celem uzyskania optymalnego dla
          prowadzonych działań obrazu systemu.
• Wyróżniono 4 poziomy:
        – Computation Independent Model (CIM)
                 • inaczej: domain model; vocabulary
                 • model biznesowy,
                 • nie precyzujący zakresu odpowiedzialności oprogramowania;
        – Platform Independent Model (PIM)
                 • abstrakcyjna specyfikacja systemu
        – Platform Specific Model (PSM)
                 • model odwzorowany na konkretne rozwiązania wybranej platformy;
        – Implementation Model
                 • proste przełożenie decyzji z modelu platformowego.
• Pojęcia „PI” i „PS” są względne – zależne od tego, co
  uznamy za platformę.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 8                                         kwiecień 2009
                                     Transformacja PIM -> PSM

                                                              1.   Specyfikacja platform
                                                              2.   Specyfikacja systemu
                                                              3.   Wybór platformy
                                                              4.   Transformacja specyfikacji
                                                                   do realizacji na platformie




                                   Źródło: MDA Guide V1.0.1
P.Habela, K.Subieta. SSR, Wykład 7, Folia 9                                              kwiecień 2009
                                               Czego wymaga PIM?
• Zakłada się niewielką liczbę (kilka) profili dla wyrażania
  modeli PIM przeznaczonych dla rodzajów zastosowań
        – systemy informacyjne, systemy czasu rzeczywistego, itd.
• Poza zdefiniowaniem pojęć pożądana może okazać się
  stosowna dla ich użycia notacja graficzna
        – w tej roli UML
• Niezależność od platformy: złożenie pojęć PIM w spójną
  abstrakcyjną ramę - „maszynę wirtualną”
        – Takie rozwiązanie pozwala precyzyjnie określić decyzje
          projektowe przy przejściu na model PSM
        – Stan i akcje maszyny wirtualnej mogą być w jednoznaczny sposób
          odwzorowane na stan i akcje konkretnego PSM
        – Odwzorowanie może być automatyczne
• Definicja takiej abstrakcyjnej ramy jest niewątpliwie
  jednym z najważniejszych kandydatów do standaryzacji.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 10                        kwiecień 2009
                                               Pervasive Services
• Objaśnienie koncepcji MDA nawiązuje do przedłużenia
  ewolucji języków programowania, zmierzających ku coraz
  wyższemu poziomowi abstrakcji.
        – Poziom PIM – najwyższy poziom w programowaniu
• Pervasive Services zaproponowane jako zręby takiej
  maszyny wirtualnej:
        – Niezależne od platformy definicje usług, takich jak np. trwałość,
          transakcyjność, komunikaty, security, etc.
        – W znacznej części planowane jako rozwinięcie / uogólnienie
          zestawu Common Object Services standardu CORBA.
        – Pewne doświadczeniu przy abstrakcyjnym opisie możliwości
          oferowanych przez technologie uzyskano przy tworzeniu CWM.

P.Habela, K.Subieta. SSR, Wykład 7, Folia 11                           kwiecień 2009
                                               PSM a model platformy
• Nową jakość ma zagwarantować daleko posunięte wsparcie dla
  odwzorowania PIM => PSM.
        – Dążenie do zdefiniowanie na poziomie „meta” możliwie dużej liczby
          zagadnień związanych z tym odwzorowaniem.
        – Będzie to odwzorowanie abstrakcyjnych usług używanych w PIM na
          konkretne technologie modelu platformowego.
• Model platformy przedstawiany ma być również za pomocą
  UML i OCL i przechowywany w repozytoriach MOF.
• Niezbędne profile UML dla poszczególnych platform
        – specyficzne dla technologii pojęcia w postaci stereotypów oraz
          związanych z nimi ograniczeń i tagged values
• Obecnie przykłady koncentrują się na technologiach języka Java
        – dzięki powstaniu profili UML w ramach Java Community Process
        – m.in. JSR026: UML/EJB Mapping Specification;
        – Microsoft nie uczestniczy w tym przedsięwzięciu.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 12                               kwiecień 2009
          Realizacja odwzorowania (transformacji) (1)
• Zrealizowane na poziomie metamodeli:
        – opisują, jak mają być odwzorowywane pomiędzy sobą instancje
          (wystąpienia) tych modeli;
        – elementy (konstrukty) modeli PIM i PSM a także odwzorowania
          pomiędzy nimi są modelowane za pomocą MOF.
• Krokiem w stronę wytworzenia PSM jest naniesienie
  specyficznych dla wybranej technologii oznaczeń (marks) [typy,
  stereotypy, role…] na model PIM.
• Oznaczenia te mogą np. określać wybór jednego z kilku szablonów
  dla transformacji danego elementu modelu.
        – Mogą też dostarczać parametrów dla takich szablonów.
• Dopuszcza się różne rodzaje oznaczeń mających różne cele, co
  może nam nasuwać skojarzenia z aspektami czy rolami obiektów.
• Oczywiście, stosowany zestaw oznaczeń też musi zostać
  odpowiednio zamodelowany.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 13                            kwiecień 2009
          Realizacja odwzorowania (transformacji) (2)
Marked PIM + transformation
                   => PSM + record of transformation
Jak wyrażać transformacje (mappings)?
        – Język naturalny nieprecyzyjny i nieczytelny maszynowo;
        – „technology to be adopted”...
• Przejście od PIM do PSM może obejmować więcej niż
  jeden krok transformacji.
• Model type mapping vs. model instance mapping:
        – Określa, czy modele PIM oraz PSM są wystąpieniami czy
          specjalizacjami typów zdefiniowanych dla PI oraz PS i opisanych
          w transformacji.
        – W obu przypadkach na poziomie typów PI oraz PS mogą być
          zdefiniowane (i odwzorowywane między sobą) całe wzorce
          (patterns).
P.Habela, K.Subieta. SSR, Wykład 7, Folia 14                        kwiecień 2009
                              Rodzaje transformacji wg OMG
1. Ręczna:
          • Od tradycyjnych podejść różni się oddzieleniem PIM od PSM oraz
            udokumentowaniem transformacji pomiędzy nimi.
2. Transformacja PIM zdefiniowanego z użyciem profilu.
          • Oznaczenia zdefiniowane w profilu PS odnoszące się do pojęć
            profilu PI;
          • UML 2 pozwoli na definiowanie operacji w profilach – mogą one
            posłużyć do zdefiniowania reguł transformacji.
3. Transformacja używająca oznaczeń i wzorców
4. Transformacja automatyczna:
          • Specyficzne sytuacje, gdy sam PIM wystarcza do wytworzenia
            PSM (sam wybór platformy i PIM determinują go)

P.Habela, K.Subieta. SSR, Wykład 7, Folia 15                        kwiecień 2009
        1-sze podejście do MDA: „Elaborationist approach”
                                                             Compuware, Interactive Objects, Softeam i inni


        PIM                                          • Aplikacja jest definiowana w 3 etapach.
                                                     • Wszystkie wymagają udziału człowieka
  OCL
                                                     • Reverse engineering czasem jest
                                                       konieczny.
        PSM                                          • Język akcji nie jest potrzebny, ponieważ
                                                       logika aplikacji jest specyfikowana na
                                                       poziomie kodu w językach zależnych od
                                                       platformy

          kod
  3GL
       uruchomienie                            elaboration


P.Habela, K.Subieta. SSR, Wykład 7, Folia 16                                                       kwiecień 2009
         2-gie podejście do MDA: „Translationist approach”
                                                  Bridgepoint, Kennedy Carter, Telelogic i inni

                                                           • Tylko etap PIM wymaga

              Język akcji
                                      PIM                    udziału człowieka. Reszta
                                                             jest automatyczna.
                                                           • Reverse engineering nie jest
                                                             potrzebny.
  „translation”
                                     PSM                   • Język akcji jest potrzebny
                                                             aby określić logikę aplikacji
                                                             na poziomie PIM w sposób
                                                             niezależny od platformy
                                        kod
                                   uruchomienie
P.Habela, K.Subieta. SSR, Wykład 7, Folia 17                                             kwiecień 2009
                                               Korzyści z podejścia 2
  • Krótsze cykle wytwarzania oprogramowania
          – Sam PIM może zostać wykonany i testowany
  • Dostępność
          – Osoby nie programujące mogą uczestniczyć w cyklu tworzenia aplikacji
          – Ale istnieje niebezpieczeństwo, że język akcji stanie się tak samo
            trudny, jak język programowania
          – Ponadto, język akcji nie zajmuje się interfejsem użytkownika
  • Jednolite podejście
          – Cały proces wytwórczy odbywa się w ramach UML
          – Nie ma potrzeby używania UML równocześnie z językami, których
            semantyka była tworzona niezależnie od UML
  • Pełna niezależność od platformy
          – Zmiana platformy nie wymaga powtórnego zakodowania logiki
            aplikacji
  • Programowanie na wyższym poziomie abstrakcji
          – niezależnie od platformy, np. aspekty
P.Habela, K.Subieta. SSR, Wykład 7, Folia 18                             kwiecień 2009
  Transformacje MDA – pożądane własności                                      (1)
1. Możliwość „dostrojenia” transformacji, poprzez:
        •         Pytanie projektanta o decyzje przy wykonywaniu transformacji;
        •         Umożliwienie projektantowi uszczegółowienia kryteriów
                  transformacji;
        •         Wprowadzenie parametrów do definicji transformacji.
                  Mając na względzie klarowność obu modeli, należy rozważyć
                  możliwość przechowywania niektórych parametrów jako
                  własności raczej samej transformacji niż któregokolwiek z
                  modeli.
2. Możliwość śledzenia źródeł (identyfikacja źródła danego
   konstruktu modelu docelowego).
        •         Związane z możliwościami inżynierii odwrotnej.
        •         Szczególnie istotne jest jednak zachowanie spójności w
                  warunkach modyfikacji modelu docelowego.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 19                               kwiecień 2009
  Transformacje MDA – pożądane własności                                     (2)
3. Tzw. „spójność inkrementacyjna”:
        •         Ponowne wygenerowanie modelu docelowego po modyfikacji
                  modelu źródłowego nie powinno prowadzić do utraty pracy
                  wykonanej w modelu docelowym (np. sprecyzowanie sposobu
                  wyświetlania czy uzupełnienie ciał metod);
        •         Bardziej jaskrawym przykładem jest zmiana modelu w
                  warunkach istnienia wypełnionej danymi bazy. W takiej sytuacji
                  bardziej przydatne byłyby definicje niezbędnych zmian
                  schematu, nie zaś wygenerowany kod definicji nowych tabel.
4.          Dwukierunkowość transformacji:
        •         Nie zawsze wykonalne.
        •         Wymaga analogicznych środków wyrazu w obu modelach, zaś
                  głównym motywem rozwijania MDA jest wyższy poziom
                  abstrakcji modelu PIM.
        •         Model PSM wprowadza więcej szczegółów implementacyjnych
P.Habela, K.Subieta. SSR, Wykład 7, Folia 20                              kwiecień 2009
                               Transformacja jako metaobiekt
• Transformacja jest wykonywanym na modelach procesem.
        – Powinna być jednakże reprezentowana również jako obiekt
          przechowujący informacje o odwzorowaniu, które logicznie doń
          przynależą.
• Związek pomiędzy modelami wyznaczony przez
  transformację powinien być trwały.
        – Można przyjąć, że powstanie jeden obiekt opisujący (instancję)
          transformacji na każde zastosowanie reguły transformacji
          pomiędzy modelami.
• Transformacje zaś powinny mieć możliwość ich
  parametryzowania.
        – W instancji transformacji znajdą się wówczas wartości przyjętych
          parametrów.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 21                         kwiecień 2009
                   MDA - istotne specyfikacje OMG            (1)
• UML (Unified Modeling Language)
        – rozszerzalny obiektowy język modelowania z wizualną notacją
        – wsparty specjalizowanymi profilami może służyć tworzeniu
          modeli CIM, PIM, PSM.
• MOF (Meta Object Facility)
        – pojęciowo zgodny z UML
        – może być traktowany jako podzbiór
        – służy definiowaniu innych metamodeli oraz konstrukcji
          ustandaryzowanych repozytoriów metadanych, pozwalających
          przechowywać ich wystąpienia.
• XMI (XML Metadata Interchange)
        – oparty na MOF standard XML-owego zapisu modeli (UML lub
          innych zdefiniowanych w terminach MOF).

P.Habela, K.Subieta. SSR, Wykład 7, Folia 22                       kwiecień 2009
                   MDA - istotne specyfikacje OMG              (2)
• CWM (Common Warehouse Metamodel)
        – definiuje abstrakcyjne własności z obszaru hurtowni danych.
• Software Process Engineering Metamodel
        – pozwala definiować w jednolitej postaci metodyki wytwarzania
          oprogramowania.
• Pervasive Services:
        – abstrakcyjne usługi używane w definicjach modeli PIM (zdarzenia,
          usługi katalogowe, security, transakcje…).
        – Rozwijane obecnie poprzez inżynierię odwrotną popularniejszych
          usług CORBA.
• EDOC (Enterprise Distributed Object Computing), EAI
  (Enterprise Application Integration)
        – profile UML stosowane do tworzenia PIM.

P.Habela, K.Subieta. SSR, Wykład 7, Folia 23                            kwiecień 2009
                                               UML 2.0
• Uporządkowanie i ujednolicenie wewnętrznej organizacji
  pojęć:
        – Ujednolicenie metamodelu z rozwiązaniami MOF.
        – Końce asocjacji traktowane jednolicie z atrybutami – toteż m.in.
          można modelować statyczne asocjacje (bodajże występuje tam
          jawnie pojęcie static, w miejce pierwotnie stosowanego owner’s
          scope).
        – Podobnie poprawiona sprawa parametrów metod – mogą teraz one
          określać liczności podobnie jak atrybuty i asocjacje.
        – Aktywności (diagramy aktywności) nie są już specjalizacjami
          (szczególnym rodzajem) stanów z diagramów stanów.
        – OCL będzie również opisany metamodelem.


P.Habela, K.Subieta. SSR, Wykład 7, Folia 24                        kwiecień 2009
                                 UML 2.0 – własności użytkowe
• Liczność domyślna w UML = *
• Kolejna nowość – o ile dana rola nie jest oznaczona jako
  isUnique=true, to dopuszczalne są powtórzenia!
• Ciekawe właściwości asocjacji (a właściwie ich ról) –
  dotyczą wszystkich „Property”:
        – subsets nazwaInnejRoli, union -> isDerivedUnion : Boolean
        – rozróżniono „non-navigable” i „unspecified navigability”;
• Collaboration diagram => communication diagram?
• Poza diagramami sekwencji diagramy interakcji obejmują
  ponadto interaction overview diagrams
        – obrazują przepływ sterowania w oparciu o diagram aktywności;
        – każdy węzeł może być diagramem interakcji.
P.Habela, K.Subieta. SSR, Wykład 7, Folia 25                          kwiecień 2009
                                               UML 2.0 a MOF 2.0




    • UML zdefiniowany w MOF.
    • Wspólny pakiet Core – stanowi zarówno:
       fundament dla poszczególnych metamodeli;
       zestaw pojęć służących definiowaniu metamodeli (meta-
        metamodel).
P.Habela, K.Subieta. SSR, Wykład 7, Folia 26                       kwiecień 2009
                                               Meta-modelowanie
• Niezbędny jest mechanizm definiowania
        – inny niż gramatyka BNF, która jest odpowiednia dla notacji tekstowej.
• Ważnym zadaniem jest zdefiniowanie języka transformacji,
  służącego do odwzorowywania wystąpień metamodeli. Wymaga on:
        – Wskazania modeli źródłowego i docelowego;
        – Deklaracji wykorzystywanych przez transformację elementów modeli
          źródłowego i docelowego;
        – Deklaracji warunków wstępnych i końcowych przekształcenia;
        – Deklaracji przekształceń: mogą przybrać postać prostego skojarzenia
          elementu źródłowego z docelowym plus ograniczeń nałożonych na
          model docelowy;
        – Zarówno dla formułowania warunków jak i dla odwzorowań przydają się
          operatory makroskopowe
                 • autorzy [MDA Explained] przyjęli jako robocze rozwiązanie OCL;
        – możliwość definiowania transformacji przez wskazanie innych (np. w
          postaci sekwencji);

P.Habela, K.Subieta. SSR, Wykład 7, Folia 27                                        kwiecień 2009
                                     UML – mocne i słabe strony
• UML jako narzędzie budowy PIM:
        – silna strona = model klas;
        – słaba strona = behavior (środki zróżnicowane, ekspresyjne, ale słabiej
          sformalizowanie).
• Executable UML = UML + AS (Action Semantics): maszyny stanów i
  procedury pisane w AS dla każdego ze stanów. Problemy:
        – dla wielu dziedzin model maszyn stanów może okazać się niewygodny
          (stosowany głównie dla embedded);
        – AS jest niskopoziomowe (poziom abstrakcji jak w PSM -> mały zysk z
          przeniesienia definicji do PIM; „UML-owy asembler”);
        – notacja AS nie jest ustandaryzowana.
• OCL:
        – Może wspierać definicję dynamiki systemu i podnosić precyzję modelu;
        – Nie pozwala na wygenerowanie pełnych ciał metod.
• Niezbędne jest ustandaryzowanie języka transformacji
        – Rozpisano RFP na język QVT (Query, View, Transformation).

P.Habela, K.Subieta. SSR, Wykład 7, Folia 28                                kwiecień 2009
                                               Microsoft...?
       •     Microsoft odrzuca nie tylko MDA, ale i znaczną część celów UML
       •     Jest jedyną wielką organizacją, która nie uczestniczy w OMG
       •     Lansuje dziedzinowe języki modelowania zamiast UML
       •     Dla Microsoftu UML jest za trudny i nie do końca pasuje do jego
             narzędzi
       •     UML „as a sketch” – popiera
       •     UML „as a blueprint” (podejście 1 do MDA) – krytykuje, np. nie
             można bezpośrednio używać klasy UML jako klasy C#
       •     UML „as a programming language” (podejście 2 do MDA) - nie
             jest zainteresowany, rozwija własne języki
       •     Być może Microsoft tworzy jakieś własne wersje UML i MDA ?



P.Habela, K.Subieta. SSR, Wykład 7, Folia 29                          kwiecień 2009
                                               Podsumowanie
• Języki modelowania – w miarę precyzyjna definicja dzięki
  MOF.
• Z kolei brak ustandaryzowanej postaci definiowania
  transformacji czyni realizacje założeń MDA zależnymi od
  poszczególnych dostawców.
• Otwarte kwestie:
        – Czy można wprowadzić dostatecznie precyzyjny język dla
          definiowania zachowania systemu, który zarazem będzie oferował
          istotnie wyższy poziom abstrakcji niż postać docelowa w kodzie
          programu?
        – Co z programowaniem aspektowym i jego ewentualnym
          wsparciem?
        – Odwzorowania z modelu klas na warstwy danych oraz aplikacyjną
          są stosunkowo jednoznaczne, natomiast wygenerowanie z nich
          warstwy prezentacji może być wątpliwe…

P.Habela, K.Subieta. SSR, Wykład 7, Folia 30                      kwiecień 2009
                                               MDA a nasze prace

• MOF dostarcza dość intuicyjnych środków definiowania
  metamodeli.
• Tworzone u nas definicje metamodelu dla ODRA można
  uznać za zgodne z meta-metamodelem MOF.
• Propozycja specyfikacji QVT (Query View
  Transformation), jak również przydatność w definiowaniu
  odwzorowań istniejącego już OCL, zgodnie przemawiają za
  użytecznością obiektowego języka zapytań jako środka do
  manipulacji metadanymi.
• Wobec tego, realizując narzędzie z obszaru technologii
  CASE możnaby rozpatrywać ODRA jako repozytorium
  modeli/metamodeli używanych w MDA.

P.Habela, K.Subieta. SSR, Wykład 7, Folia 31                       kwiecień 2009

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:46
posted:12/4/2011
language:Polish
pages:31