MDA MDA Metamodel UML XMI (XML Metadata Interchange) – zało

MDA MDA Metamodel UML XMI (XML Metadata Interchange) – zało

MDA
MDA
Model driven architecture
Wybrane Zagadnienia Systemów Rozproszonych
MDA jest najważ
najważniejszą
niejszą inicjatywa grupy OMG (rozwijają
(rozwijającej
standardy UML i CORBA).
Intencją
Intencją jest podniesienie poziomu abstrakcji w procesie
budowy systemó
systemów, poprzez oddzielenie logiki biznesowej od
elementó
elementów projektowych zależ
zależnych od konkretnej infrastruktury
implementacyjnej (tj. ję
językó
zyków programowania czy
oprogramowania poś
pośredniczą
redniczącego).
Centralną
Centralną rolę
rolę odgrywa w tej technologii modelowanie w UML.
Same postulaty (modelowanie, izolowanie zagadnień
zagadnień
realizacyjnych) nie wykraczają
wykraczają koncepcyjnie poza uznane
zasady inż
inżynierii oprogramowania.
Jakoś
Jakościową
ciową zmianę
zmianę mogą
mogą wprowadzić
wprowadzić zasady modelowania
oraz odpowiednie ich wsparcie narzę
narzędziowe.
2
Metamodel UML
XMI (XML Metadata
Interchange) – założenia
ModelElement
name : Name
1..*
ElementOwnership
visibility : Visibility Kind
isSp ecification : Boolean
ownedElement
Pierwotnie (wersje 1.1 UML i MOF) udostę
udostępniał
pniały na
constrainedElement {ordered}
*
constraint
0..1
namesp ace
*
Feature
Namespace
isRoot : Boolean
isLeaf : Boolean
isAbstract : Boolean
ownerScop e : Scop eKind
visibility : Visibility Kind
*
GeneralizableElement
Parameter
Constraint
defaultValue : Exp ression
kind : ParameterDirectionKind
body : BooleanExp ression
feature {ordered}
*
p arameter {ordered}
*
0..1
Classifier
owner
1
typ e
potrzeby wymiany metadanych jedynie dostę
dostęp
poprzez standardowe interfejsy CORBA IDL
(nieefektywne dla obszerniejszych modeli).
Pierwszoplanowy cel: moż
możliwość
liwość zapisu modeli UML
w XML (celem ich wymiany pomię
pomiędzy narzę
narzędziami).
Sposó
Sposób zdefiniowania XMI (oparcie go na modelu
MOF), zapewnia jednak potencjał
potencjał znacznie szerszego
zakresu zastosowań
zastosowań: każ
każdy metamodel opisany w
MOF moż
może być
być (wraz ze swymi wystą
wystąpieniami)
reprezentowany w XMI.
1typ e
StructuralFeature
multip licity : M ultip licity
*
3
BehavioralFeature
1
4
XMI – zawartość standardu
XMIokreś
– zawartość
Standard
określa:
Reprezentacja obiektów w XML
Zał
Założenia projektowe dotyczą
dotyczące tworzonych dla metadanych
schemató
schematów XML Schema
Reguł
Reguły generowania schemató
schematów dla wł
własnych opisanych w
terminach MOF metamodeli *Meta Object Facility)
Facility)
Sposó
Sposób zapisu w XML metadanych zgodnych z tymi
metamodelami (zgodność
(zgodność w znacznym zakresie
kontrolowana przez ww. schematy).
Konkretne schematy dokumentó
dokumentów dla modeli (czyli – dla
metadanych) UML
Należ
Należy podkreś
podkreślić
lić, że w obecnej postaci sł
służy
zapisowi modelu a nie diagramó
diagramów (gdyż
(gdyż nie
determinuje postaci wizualnej wykraczają
wykraczającej poza
formalną
formalną treść
treść modelu).
Metadane w postaci XMI –
przykład
Reprezentacja
obiektówelement
w XML
Zapis
obiektó
ów XML
obiektów odbywa się
się w postaci elementó
5
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE XMI SYSTEM 'UML_1.4_XMI_1.1.dtd'>
<XMI xmi.version='1.2' xmlns:UML='omg.org/UML/1.4'>
<XMI.header>
<XMI.metamodel xmi.name='UML' xmi.version='1.4'/>
</XMI.header>
<XMI.content>
<UML:Model xmi.id='S.1' name=‘Zatrudnienia' visibility='public'
Zatrudnienie
isSpecification='false' isRoot='false'
isLeaf='false' isAbstract='false'>
pracownik
pracodawca
<UML:Namespace.ownedElement>
<UML:Class
Osoba xmi.id='S.2' name=‘Osoba' visibility='public' isSpecification='false'
Firma
namespace='S.1' *isRoot='true' isLeaf='true' isAbstract='false'
isActive='false'/>
*
<!-- tutaj opis klasy Firma -->
<UML:Association xmi.id='G.1' name=‘Zatrudnienie' visibility='public'
isSpecification='false' isRoot='false' isLeaf='false' isAbstract='false'>
<UML:Association.connection>
<!-- tutaj opisy końców asocjacji -->
</UML:Association.connection>
</UML:Association>
</UML:Namespace.ownedElement>
</UML:Model>
</XMI.content>
7
</XMI>
Sporz
ądzony w oparciu o przykład ze specyfikacji OMG UML 1.5 (http://www.omg.org)
i ich atrybutó
atrybutów.
Moż
Można tworzyć
tworzyć powią
powiązania pomię
pomiędzy elementami
reprezentują
reprezentującymi obiekty zaró
zarówno lokalnymi
(znajdują
(znajdującymi się
się w tym samym dokumencie) jak i
nielokalnymi.
Jest to moż
możliwe dzię
dzięki zapewnieniu toż
tożsamoś
samości
obiektu (ID lub UUID).
Obiekty oraz ich definicje mogą
mogą być
być przedmiotem
wersjonowania.
wersjonowania.
Zgodność
Zgodność z metamodelem moż
możliwa (w pewnym
zakresie) do wykontrolowania za pomocą
pomocą walidacji
XML.
6
(MDA) – definicja i cele
Główny cel: Ochrona inwestycji dokonywanych przy
tworzeniu systemów informatycznych przed zmianami
platformy technologicznej.
Jak ten cel osiągnąć: Przez uniezależnienie procesu
tworzenia aplikacji od platform technologicznych.
PIM = Platform Independent Model wg OMG:
Reprezentacja funkcjonalności biznesowej i zachowania
aplikacji niezakłócona szczegółami technologicznymi.
PSM = Platform Specific Model: Model
odzwierciedlający model PIM dla konkretnej platformy.
Odwzorowania: Np. obiekt biznesowy -> SQL Create table ...
EJB Entity Bean
Remote interface
PIM
PSM
kod
uruchomienie
8
Trzy główne zasady MDA Ż
ródło: An MDA Manifesto,
MDA Journal, maj 2004
1.
2.
3.
Bezpoś
Bezpośrednia reprezentacja problemu.
Tworzenie oprogramowania ma się
się
koncentrować
koncentrować nie wokó
wokół konkretnej
technologii ale wokó
wokół problemu, któ
który mamy
do rozwią
rozwiązania.
Automatyzacja. Należ
Należy uż
użyć
automatycznych narzę
narzędzi do
zmechanizowania tych aspektó
aspektów tworzenia
oprogramowania, któ
które nie mają
mają wiele
wspó
wspólnego z ludzką
ludzką kreatywnoś
kreatywnością
cią.
Otwarte standardy. Ponowne uż
użycie,
budowa wł
właściwej infrastruktury rynku.
Wykorzystanie open source.
source.
Dwa podejścia do MDA (2/2)
2: „Translationist approach”
PIM
Język akcji
„translation”
PSM
kod
uruchomienie
Dwa podejścia do MDA (1/2)
1: „Elaborationist approach”
Aplikacja jest definiowana w 3
etapach. Wszystkie wymagają
udziału człowieka (ale ...).
Reverse engineering
czasem jest konieczny.
Język akcji nie jest używany,
ponieważ logika aplikacji
jest specyfikowana
na poziomie kodu w językach
programowania
(zależnych od platformy !)
PIM
OCL
PSM
kod
3GL
9
uruchomienie
„elaboration”
10
Podejście 2: Uwaga
Bridgepoint
Kennedy Carter
Telelogic i inni
Tylko etap PIM wymaga
udziału człowieka.
Reszta jest
automatyczna.
Reverse engineering
nie jest potrzebny.
Język akcji
jest potrzebny
aby określić logikę
aplikacji na poziomie
PIM w sposób niezależny od platformy11
Compuware
Interactive Objects
Softeam i inni
PIM
Język akcji
Podejście 2 obejmuje
również interpretery
„interpretation”
uruchomienie
12
Korzyści wynikające z podejścia 2
Podejście 2: Podniesienie poziomu
abstrakcji
Źródło: S. Mellor
Modele
Języki 3GL, 4GL
Asembler
Kod maszynowy
13
Oba podejścia do MDA już funkcjonują w niektó
niektórych dziedzinach zastosowań
i oba są obiecujące.
ce. Jednak podejście 2 oferuje następujące korzyści:
ci:
Kró
Krótsze cykle wytwarzania oprogramowania:
oprogramowania: Sam PIM może
zostać wykonany i testowany.
B. Dostępność: Osoby nie programujące mogą uczestniczyć w
cał
całym
cyklu tworzenia aplikacji. (istnieje jednak niebezpieczeństwo, że kod
w języku akcji stanie się tak trudny, jak kod w języku programowania).
C. Jednolite podejście:
cie: Cał
Cały proces wytwó
wytwórczy odbywa się
w ramach UML.
UML. Nie ma potrzeby używania UML ró
równocześnie
z językami, któ
których semantyka był
była tworzona niezależnie od UML.
D. Peł
Pełna niezależność od platformy:
platformy: Zmiana platformy
nie wymaga zakodowania logiki aplikacji
w języku nowej platformy.
E. Nowe koncepcje mogą zostać wprowadzone na wyższym
poziomie
14
abstrakcji i niezależnie od platformy: Np. aspekty.
A.
Microsoft odrzuca nie tylko MDA
ale i znaczną część celów UML
OMG mocno wspiera podejście 2
• „Models are testable and simulatable” - Richard Soley, CEO of OMG
• „The aim [of MDA] is to build computationally complete PIMs”
– Oliver Sims, OMG architecture board
http://www.omg.org/mda/presentations.htm
Pierwsza strona OMG o MDA: http://www.omg.org/mda/
Jest jedyną
jedyną wielką
wielką organizacją
organizacją, któ
która nie uczestniczy w OMG
Lansuje dziedzinowe ję
ę
zyki
modelowania
zamiast UML
j
Mówi, że UML jest za trudny i nie do koń
końca pasuje do jego
narzę
narzędzi
Krytykują: np. nie można
bezpo
średnio używać klasy
UML ...
UML jako klasy C#
„... As a sketch”
sketch” – popierają
„... As a blueprint”
MDA)
blueprint” (podjeście 1 doNie
interesują się: „Bo mało kto się tym
„... As a programming language”
language” zajmuje” (???).
(podejście 2 do MDA)
Źródło: MDA Journal, styczeń 2004
15
Być
Być moż
może Microsoft stworzy jakieś
jakieś własne wersje UML i MDA
?
16
Użyteczne „linki” (1/2) Udane wdrożenia MDA
Podejś
Podejście 1
Interactive Objects:
Objects:
http://www.arcstyler.com
http://www.arcstyler.com//customers/
customers/customer_list.jspSofteam
- w tym Deutsche Bank
Softeam:
http://www.omg.org//mda/
mda/webcast/
webcast/webcast_files/
webcast_files/SofteamSofteam-MDAMDASofteam: http://www.omg.org
experience.pdf - telekomunikacja, transport
Borland:
http://www.borland.nl//together/
together/cases/
cases/ - bankowość, sł
służba zdrowia
Borland: http://www.borland.nl
Telelogic:
http://www.telelogic.com//solutions/
solutions/industries/
industries/index.cfm - telekomunikacja,
Telelogic: http://www.telelogic.com
Podejś
Podejście 2 (!)
finanse w ograniczonym stopniu
Użyteczne „linki” (2/2)
Kennedy Carter: http://www.kc.com
http://www.kc.com//case_study/
case_study/ - Siemens - liczniki
Metamaxim:
http://www.metamaxim.com//pages/caseStudy1.htm
pages/caseStudy1.htm
Metamaxim: http://www.metamaxim.com
Konkurs Unii Europejskiej –
Konsorcjum Modelware:
Modelware: http://www.modelware
http://www.modelware--ist.org/
ist.org/
MDA w OMG: http://www.omg.org
http://www.omg.org//mda/
mda/
OMG wspiera podejście 2: http://www.omg.org/mda/presentations.htm
http://www.omg.org/mda/presentations.htm
MDA a roundf/us
us//model_driven.pdf
round-trip engineering:
engineering: http://www.softeam.com/pd
http://www.softeam.com/pdf/
Języki akcji, semantyka akcji UML: http://www.kabira.com
/as/
http://www.kabira.com/as/
Executable UML
Diagrams for the future ?
http://opensource.devx.com
page/1
/1
http://opensource.devx.com//rchive.devx.com/
rchive.devx.com/Article/10717/0/
Article/10717/0/page
„Biblia”
Biblia” (książkę mogę pożyczyć): http://www.executableumlbook.com
http://www.executableumlbook.com//
SDL: http://www.sdl
http://www.sdl--forum.org/SDL/
forum.org/SDL/
Dwa podejścia do MDA. MDA – wizja z dziurą ?
http://www.metamaxim.com/download/documents/MDAv1.p
MDA Journal:
Journal:
http://www.bptrends.com
/search.cfm?keyword=MDA+journal&gogo=1&go.x=68&go.y=4
http://www.bptrends.com/search.cfm?keyword=MDA+journal&gogo=1&go.x=68&go.y=4
Action semantics consortium:
http://www.kc.com//as_site/
as_site/home.html
consortium: http://www.kc.com
OMG comitted products:
http://www.omg.org//mda/
mda/committedcommittedproducts: http://www.omg.org
products.htm
MDA Manifesto:
Manifesto: maj 2004
„MDA”
MDA” wg Microsoft: styczeń 2004 + krytyka od OMG luty 2004
+ kontra kwiecień 2004 + rekontra od OMG wrzesień 2004 + Microsoft zamilkł
zamilkł
Agile MDA – S. Mellor:
Mellor: June 2004
!
17
18
Przykład użycia MDA
DAEF
A. Dras „Model Driven Architecture Applied:
Exchange and Archiving of Data in Model Based
Environments”
Environments”
Ameos
Aplikacja DAEF (Data Archiving and Exchange
Framework ) wykorzystuje proces MDA do
przetransformowania wejś
wejściowego modelu UML w
wielomoduł
wielomodułowy kod, skł
składają
adający się
się z:
Pliku XML Schema (XSD) opisującego strukturę pewnego pliku
XML, któ
który tworzony jest ręcznie przez użytkownika
C++ API (Application
(Application Programming Interface),
Interface), sł
służące do
parsowania powyższego pliku XML do postaci drzewa DOM a
następnie do odczytywania i edycji sparsowanych danych przez
użytkownika
Aplikacji EJB umożliwiającej import tego pliku XML do bazy
danych oraz eksport bazy danych do pliku XML, oraz odczyt i
edycję danych w bazie
19
firmy Aonix:
moż
możliwość
liwość transformowania modeli UML w
inne modele UML oraz w kod
transformacjami tymi moż
można w peł
pełni sterować
sterować
są one programowalne za pomocą
pomocą skryptó
skryptów
w specjalnym ję
języku wewnę
wewnętrznym o nazwie
TDL (Template
(Template Definition Language)
Language)
umoż
umożliwia dostę
dostęp do wszystkich konstrukcji w
modelach i tworzenie na ich podstawie
nowych konstrukcji bą
bądź też
też dowolnego kodu
20
Przykład modelu źródłowego(SOM)
DAEF
Zastosowanie procesu MDA polegał
polegało:
na wykorzystaniu modelu UML jako modelu PIM.
nastę
następnie za pomocą
pomocą skryptó
skryptów w ję
języku TDL
zaprogramowano transformacje tegoż
tegoż modelu do trzech
modeli PSM, po jednym dla każ
każdej domeny XSD, C++
API oraz EJB
struktura modeli PSM został
została najpierw okreś
określone za
pomocą
pomocą odpowiednich profili UML
z David Hearnden „Software Evolution with the ModelModel-Driven Architecture”
Architecture”
type
Type
name : string
Datatype
Class
inherits
isAbstract : boolean
Association
name : string
Attribute
name : string
21
22
Przykładowa transformacja
(in English)
Przykład modelu docelowego
(Java)
type
JType
name : string
inherits
JDatatype
JInterface
JTypedElt
JClass
isAbstract : boolean
name : string
modifier : ModKind
implements
JFeature
JParameter
visibility : VisKind
JField
initialiser : Value
For each SOM class, create a Java interface of the same name,
plus an inheriting implementation class.
For each SOM attribute, create a Java private field in the
corresponding class of the corresponding type with appropriate
getter/setter methods.
For each SOM association, create corresponding array pairs in
the implementation Java classes, and create add/remove
methods in the interfaces.
For each SOM class, create a Java factory class for creating
instances
Create a system factory that links to all created factories
JMethod
initialiser : Value
body : string
23
24
Przykład zmiany modelu
Przykład transformacji
Student
Course
enrols
id : string
code : string
Student
id : string
Student
Course
Course [] getCourses();
Student [] getStudents();
String getId();
String getCode();
Void addCourse(Course c);
void addStudent(Student s);
Void removeCourse(Course c);
void removeStudent(Student s);
StudentImpl
Course [] getCourses() {…}
Student
id : string
StudentFactory
Student makeStudent();
CourseFactory
Course makeCourse();
Undergrad
Postgrad
CourseImpl
Student [] getStudents() {…}
SysFactory
25
Propagacja
Postgrad
Student
Undergrad
id : string
enrols
Course
code : string
Student
Course [] getCourses();
Postgrad
Undergrad
PostgradImpl
UndergradImpl
String getId();
Void addCourse(Course c);
Void removeCourse(Course c);
StudentImpl
Course [] getCourses() {…}
StudentFactory
Student makeStudent();
SysFactory
PostgradFactory
UndergradFactory
Postgrad makePostgrad();
Undergrad makeUndergrad();
27
26