Anda di halaman 1dari 40

Bab4

Metode PMG-pro
Bab ini menyampaikan usulan PMG-pro (abstrak, model, menghasilkan dan
menyediakan) metode. Pasal 4.1 menyajikan gambaran mengenai PMG-Pro. Berikut bagian
langkah-langkah yang hadir dan bagian PMG-Pro: langkah presentasi dan abstraksi dalam
Bagian 4.2, Layanan Perpustakaan dan kerangka repositori di bagian 4.3, pemodelan
langkah Bagian 4.4 dan generasi kode langkah di bagian 4.5. Pada akhir setiap bagian,
ringkasan pendek disajikan.
4.1 gambaran mengenai PMG-pro
Untuk pengembangan aplikasi berbasis layanan, kami mengusulkan sebuah metode
baru yang disebut PMG-pro (Present, Model, menghasilkan, dan memberikan). Arsitektur
PMGpro ditampilkan dalam gambar 4.1. Arsitektur PMG-pro yang terdiri dari tiga bagian
utama: presenter/abstractor yang digunakan pada langkah presentasi, editor pemodelan yang
digunakan pada langkah pemodelan, dan kode generator/penyedia yang digunakan pada
langkah menghasilkan/menyediakan. Ada juga sebuah perpustakaan yang digunakan untuk
menyimpan dihasilkan sumber kode dan layanan model pada langkah presentasi. Masingmasing model Layanan (abstrak) yang disimpan di Perpustakaan berikatan dengan kode
sumber (beton).
Seperti yang ditunjukkan dalam nama, metode PMG-pro memiliki empat langkah:
menyajikan, pemodelan, menghasilkan dan menyediakan. Langkah pertama digunakan untuk
menyajikan layanan-layanan existing premade grafis yang sesuai dengan bahasa tertentu
pemodelan. Layanan-layanan existing adalah run-waktu layanan yang dapat mengakses
mempekerjakan Deskripsi mereka.
Selain presentasi grafis, langkah pertama ini menghasilkan juga kode yang perkakas
dan yang bertindak sebagai proxy kelas antara gabungan layanan dan Jasa beton di penyedia
layanan. Proses rekayasa ulang semacam ini dimungkinkan karena layanan sering

dideskripsikan menggunakan Deskripsi terbuka dan standar teknologi, misalnya UPnP,


DPWS, WSDL, dll. Selain itu, beberapa Frame-

Gambar 4.1: Arsitektur PMG-pro. Terdiri dari presentasi dan abstraksi langkah, langkah
pemodelan, dan kode generasi dan menyediakan langkah.
work/API untuk teknologi ini juga sudah tersedia, seperti UPnP Cyberlink untuk Java [52]
untuk UPnP, Ws4d [115] untuk DPWS dan sumbu (WSDL2Java) [36] untuk layanan Web.
Setelah kita disajikan semua layanan pra-dibuat yang ada dan menyimpannya dalam sebuah
Layanan Perpustakaan, langkah pemodelan aplikasi berbasis layanan baru dapat dimulai.
Aplikasi baru akan ditetapkan sebagai interaksi dengan abstrak layanan. Tergantung pada
bahasa pemodelan, simbol-simbol yang berbeda dan notasi dapat digunakan untuk
menyajikan interaksi. Kita dapat menggunakan misalnya diagram aktivitas atau diagram
urutan untuk menentukan interaksi. Jelas, interaksi dari satu layanan Abstrak lain berarti
invokasi layanan.
Langkah terakhir digunakan untuk secara otomatis menghasilkan kode yang sesuai
untuk bahasa pemrograman tertentu. Tentu saja bahasa harus sama dengan yang digunakan
pada langkah presentasi. Kode harus dihasilkan secara otomatis. Compiler asli yang dapat

digunakan untuk mengkompilasi kode. Pada bagian selanjutnya, kami akan hadir tiga
langkah metode PMG-pro. Kita akan mulai dengan langkah presentasi, pemodelan dan kode
generasi langkah pada akhir.
4.2 Layanan presentasi dan langkah abstraksi
Dalam bagian ini kami menyajikan langkah pertama PMG-Pro yang digunakan untuk
menyajikan layanan premade menjadi representasi grafis layanan. Untuk ini kita
membutuhkan layanan presenter dan layanan abstractor. Arsitektur Layanan presenter dan
abstractor ditampilkan dalam gambar 4.2.

gambar 4.2: Layanan presenter dan abstractor PMG-Pro. mempresentasikan dan layanan
abstrak sehingga layanan integrator dapat membentuk mereka dalam lingkungan berbasis
model.
4.2.1 Gambaran
Untuk pengembangan aplikasi berbasis layanan, mendefinisikan model aplikasi
servicebased (yang merupakan layanan komposit) adalah hanya mungkin jika model
termasuk layanan (yaitu ada) di tempat. Bagian pertama dari PMG-pro adalah layanan
Abstractor Presenter. Abstractor/presenter digunakan untuk menghasilkan kode dan

representasi grafis dari layanan. Menyajikan layanan nyata sebagai presentasi grafis.
Langkah ini mungkin semacam langkah abstraksi dan/atau presentasi. Perbedaan antara
keduanya adalah bahwa presentasi adalah hanya sebuah proses yang mengubah satu model
untuk model lain tanpa mengurangi informasi. Sebaliknya, abstraksi akan mengurangi
beberapa informasi tentang target model. Abstraksi akan selalu menyertakan proses
presentasi.
Untuk pengembangan aplikasi berbasis layanan, mendefinisikan model aplikasi
servicebased (yang merupakan layanan komposit) adalah hanya mungkin jika model
termasuk layanan (yaitu ada) di tempat. Bagian pertama dari PMG-pro adalah layanan
Abstractor Presenter. Abstractor/presenter digunakan untuk menghasilkan kode dan
representasi grafis dari layanan. Menyajikan layanan nyata sebagai presentasi grafis.
Langkah ini mungkin semacam langkah abstraksi dan/atau presentasi. Perbedaan antara
keduanya adalah bahwa presentasi adalah hanya sebuah proses yang mengubah satu model
untuk model lain tanpa mengurangi informasi. Sebaliknya, abstraksi akan mengurangi
beberapa informasi tentang target model. Abstraksi akan selalu menyertakan proses
presentasi.
Langkah presentasi dan abstraksi Layanan terdiri dari parser XML, Kode Generator
dan pembuat grafis. Mereka digunakan untuk menangani Deskripsi.

Gambar 4.3: Model yang sederhana Deskripsi Layanan di PMG-pro. Model ini diadaptasi
dari model konseptual Layanan disajikan dalam [103] dan [47]. Semua sifat layanan yang
dijelaskan dalam Deskripsi Layanan.
Layanan XML, XMI dan kode. Berdasarkan target pemodelan bahasa, presentasi
grafis Layanan dapat berbeda. Sebagai contoh, jika kita menggunakan UML sebagai bahasa

pemodelan kemudian Layanan dapat dipresentasikan sebagai kelas. Kelas ini disajikan dalam
XMI sebagai standar pertukaran antara UML alat. Proses transformasi dari Deskripsi
Layanan XML ke XMI adalah proses presentasi dan bukan proses abstraksi karena
mengandung informasi yang sama. Selain itu, proses tidak mengurangi informasi.
4.2.2 Deskripsi Layanan
Layanan dapat konkret dan abstrak. Run-waktu layanan adalah layanan beton
informasi tentang layanan run-time yang diberikan dalam Deskripsi Layanan (Sk). Dengan
demikian, gambaran Layanan adalah layanan abstrak karena itu menggambarkan layanan.
Layanan yang sebenarnya berada di penyedia layanan.
Fakta bahwa konsep Layanan-orientasi sistem dapat didefinisikan, dilaksanakan, dan
dijelaskan dalam beberapa cara telah memperkenalkan berbagai jenis pelaksanaan konsep.
Sebagai contoh, ada layanan Web, Layanan OSGi, Layanan UPnP, DPWS Jasa, Jasa Jini,
dan implementasi yang lain. Jelas, cara yang berbeda dapat digunakan untuk
menggambarkan fungsi layanan. PMG-pro menggunakan Deskripsi Layanan berbasis XML,
yang merupakan layanan yang dijelaskan menggunakan XML. Kami menganggap bahwa
Deskripsi Layanan berbasis XML adalah yang terbaik karena ini adalah platform independen.
Gambar 4.3 menunjukkan model konseptual dari deskripsi layanan yang digunakan dalam
tesis ini.
Dari gambar 4.3 dapat dilihat bahwa layanan yang memiliki satu atau lebih layanan
Deskripsi. Kami mengusulkan kategori Deskripsi keterangan dan kemampuan. Deskripsi
kategori memungkinkan Layanan kategorisasi dalam proses abstraksi. Deskripsi kemampuan
memberikan informasi kepada pengguna layanan tentang kemampuan layanan. Hal ini dapat
kemampuan layanan pada penyedia layanan atau persyaratan minimum kemampuan pada sisi
klien untuk menjalankan layanan.
4.2.3 Presenter Layanan
Proses pengembangan aplikasi berbasis layanan membutuhkan Deskripsi Layanan
yang ada (Layanan model). Namun, hal ini tidak perlu memiliki model layanan lengkap yang
menggambarkan struktur dan perilaku layanan yang ada. Sebagai contoh, dalam Web

Layanan teknologi, Deskripsi operasi adalah bagian penting dari WSDL untuk menulis
layanan Web. Operasi yang menggambarkan tindakan (fungsi) yang didukung oleh layanan.
Perilaku aktual layanan yang tinggal di penyedia layanan (tindakan) yang tidak dikenal yang
diperlukan. Untuk alasan ini, PMG-pro hanya menampilkan struktur dan tidak ada bagian
perilaku. Struktur terhubung ke nyata pelaksanaan layanan (kode). Kode itu sendiri adalah
hanya proxy untuk pelaksanaan layanan sebenarnya yang tinggal di penyedia layanan.
Deskripsi statis mereka adalah informasi yang cukup untuk dapat menulis mereka. Dengan
demikian, Layanan dapat dilihat sebagai suatu objek yang abstrak perilaku rincian, tetapi
menjelaskan gambaran sifat objek.
Layanan presentasi langkah dilakukan berdasarkan pada konsep teks-untuk-model
transformasi. Sebagai contoh, dalam kasus mengubah Deskripsi Layanan UPnP ke UML
kelas, presentasi melibatkan transformasi XML (teks) ke UML kelas yang disimpan dalam
XMI. Pertimbangan utama adalah bahwa layanan dapat disajikan menggunakan setiap
notasi/simbol grafis sesuai dengan bahasa tertentu pemodelan. Dari gambaran Layanan (sk),
abstractor/presenter menghasilkan grafis Layanan model (Msk) sesuai dipilih pemodelan
bahasa dan sumber kode (Csk) sesuai dengan bahasa pemrograman yang dipilih. Tergantung
pada bahasa yang dipilih pemodelan, representasi grafis yang berbeda (yaitu, notasi) dapat
digunakan untuk mewakili layanan yang ada. Sebagai contoh, UML kelas, komponen
CORBA, peserta dalam SoaML, atau SCA komponen di antara mereka. Pada tingkat sistem,
misalnya SysML [81], UML profil untuk sistem pemodelan, sebuah blok bangunan dapat
digunakan untuk mewakili layanan yang ada.
Harus dicatat bahwa layanan representasi grafis harus berhubungan dengan layanan
ideal yang dalam hal ini dilakukan melalui kode untuk mengimplementasi invokasi layanan.
Oleh karena itu, sangat penting untuk menjaga hubungan (binding) antara

Gambar 4.4: Hubungan antara Deskripsi Layanan, model (representasi grafis) dan kode
sumber. Layanan beton itu sendiri juga tersedia pada saat run-time. Layanan
pengguna tidak tahu bagaimana layanan yang telah dilaksanakan.
representasi grafis (yaitu layanan model) dan kode sumber (yaitu implementasi untuk
invokasi layanan). 4.4 angka menunjukkan hubungan antara Deskripsi Layanan, model, dan
kode sumber. Layanan beton itu sendiri (implementasi) tidak terlihat dari sudut pandang
pengguna jasa.
Dari gambar 4.4 dapat dilihat bahwa ada 1:1.. * hubungan antara representasi grafis
dan kode sumber yang berarti bahwa representasi grafis dari layanan yang mungkin memiliki
beberapa varian dari kode sumber untuk mengimplementasikan invokasi layanan. Mereka
mungkin dapat dilaksanakan menggunakan bahasa pemrograman yang berbeda pada
platform yang berbeda.
4.2.4 Contoh
Dalam lingkungan berbasis model, untuk proses pembangunan aplikasi layanan
berbasis yang menggunakan layanan yang ada, sekali lagi, hal ini tidak perlu memiliki model
layanan lengkap yang menjelaskan struktur dan perilaku dari layanan. Untuk alasan ini,
PMG-pro hanya menampilkan struktur dan tidak ada bagian perilaku. Tapi mereka dapat
diakses melalui pelabuhan. Struktur terhubung ke nyata pelaksanaan layanan (kode). Kode

itu sendiri adalah hanya proxy untuk pelaksanaan layanan sebenarnya yang tinggal di
penyedia layanan.
Notasi yang berbeda sesuai dengan yang ada pemodelan bahasa dapat digunakan
untuk saat ini model layanan. Dalam bagian ini kami menyajikan empat contoh menunjukkan
penggunaan bahasa berbeda pemodelan untuk menggambarkan (untuk model) Layanan
UPnP. Untuk contoh-contoh ini, Layanan UPnP cahaya yang digunakan. Lihat Lampiran B
untuk XML Layanan penjelasan tentang Intel UPnP cahaya layanan.
Contoh pertama adalah menyajikan layanan UPnP cahaya yang menggunakan blok
bangunan ARCTIS [53] [57]. Ini adalah transformasi XML-UPnP ke blok bangunan XMIARCTIS.

Gambar 4.5: Model sederhana bangunan blok untuk mewakili perangkat UPnP (dan
layanan). Perangkat UPnP memiliki input (UPnP tindakannya) dan
menghasilkan acara (UPnP negara variabel). Meta model perangkat UPnP
disajikan dalam gambar 3.5

Sebelum kami hadir proses transformasi, model konseptual dari blok bangunan UPnP
dibangun, lihat gambar 4.5. UPnP ini konseptual blok bangunan yang dibuat berdasarkan
pada model konseptual UPnP disajikan dalam gambar 3.5. Seperti ditunjukkan pada gambar,
sebuah blok bangunan umum perangkat UPnP (dan layanan) memiliki input dan output.
Tindakan UPnP dapat digunakan sebagai masukan dari blok bangunan. Untuk output dari

blok bangunan, kita dapat menggunakan UPnP negara variabel. UPnP, pemberitahuan negara
mengubah variabel (jenis evented) akan dikirim kepada orang lain perangkat UPnP yang
berlangganan layanan. Dengan ini, kami menggunakan output sebagai peristiwa. Jenis lain
dari output dibangun dengan menggunakan UPnP tindakan yang memiliki nilai kembali. Tipe
output menghasilkan output ketika tindakan UPnP dipanggil.
Menggunakan ARCTIS, model konseptual UPnP blok bangunan yang disajikan
dalam angka 4,5 dapat dilaksanakan. ARCTIS adalah editor pemodelan yang didasarkan
pada UML. Lebih dari ARCTIS yang mendukung model-berdasarkan teknik teknik untuk
reaktif sistem [66]. Pengembang perangkat lunak dapat menggunakan ARCTIS untuk
menentukan, menganalisis, dan memverifikasi sistem perangkat lunak yang menggunakan
model [57]. ARCTIS juga memiliki model memeriksa pendukung otomatis model kebenaran.
Bukan UML kelas ARCTIS menggunakan blok bangunan sebagai entitas dasar. Blok
bangunan ARCTIS dianggap sebagai semacam enkapsulasi kegiatan yang dapat diakses
melalui pelabuhan. Dalam kasus ini, satu blok bangunan dapat digunakan untuk mewakili
salah satu layanan. Sebuah aplikasi berbasis layanan di ARCTIS ini kemudian dapat
ditetapkan sebagai sebuah blok bangunan diagram. Sebuah aplikasi berbasis layanan dapat,
sekali lagi, dikemas dan disajikan sebagai sebuah blok bangunan yang baru. Jelas, blok
bangunan yang baru ini dapat digunakan untuk membangun sebuah diagram blok bangunan
baru sebagai spesifikasi baru dari sistem perangkat lunak. Dengan ini, perkembangan
inkremental layanan berbasis aplikasi besar dapat dicapai. Tentang ARCTIS, pembaca yang
tertarik harus merujuk [65, 53, 57].

Gambar 4.6: Model konseptual dari ARCTIS bangunan blok - elemen dasar dari model dalam
ARCTIS [53, 57, 65].

Untuk dapat menyajikan layanan ringan UPnP menggunakan blok bangunan


ARCTIS, kita perlu mengubah Deskripsi Layanan XML-UPnP ke XMI data (format XML
yang digunakan dalam ARCTIS). XML adalah singkatan dari eXensible Markup Language.
Dengan demikian, XML adalah bahasa. Dengan mempertimbangkan ini, XML UPnP
Layanan Deskripsi isa model sejak Deskripsi adalah instance dari bahasa. Demikian pula,
ARCTIS bangunan blok adalah juga model seperti itu adalah instance dari ARCTIS yang
didasarkan pada UML 2.0 [53, 57, 65]. Dengan fakta ini, teori model transformasi disajikan
dalam bagian 3.2.4 dapat diterapkan.
Untuk mengotomatisasi proses transformasi, konsep model untuk model transformasi
dapat diterapkan. Untuk ini, memerlukan model konseptual sumber dan target pemodelan
bahasa. Model konseptual ini digunakan untuk membangun aturan transformasi. Gambar 3.5
menunjukkan model konseptual perangkat UPnP dan layanannya, sementara gambar 4.6
menunjukkan model konseptual blok bangunan ARCTIS dalam sebuah diagram UML kelas.
Menggunakan model konseptual UPnP (gambar 3.5), model konseptual ARCTIS
(gambar 4.6) dan model konseptual UPnP bangunan blok (angka 4,5), transformasi aturan
untuk mengubah Deskripsi Layanan UPnP ke sebuah blok bangunan UPnP-ARCTIS dapat
dibangun yang disajikan dalam tabel 4.1.

Tabel 4.1: Transformasi aturan antara UPnP - blok bangunan ARCTIS


perangkat UPnP

Bangunan blok ARCTIS

nama Perangkat

nama blok bangunan

Aksi

Aktivitas Input dan aktivitas output

indakan argumen

Jenis aktivitas input

Variabel keadaan

Aktivitas output

Jenis variabel kondisi

Jenis aktivitas output

aktivitas Output untuk tindakan yang memiliki nilai kembali


Deskripsi Layanan UPnP yang menggunakan aturan transformasi dibangun dapat
berubah menjadi blok bangunan ARCTIS secara otomatis. 4.7 angka menunjukkan
representasi dari layanan UPnP dalam sebuah blok bangunan ARCTIS sebagai hasil dari
proses transformasi. Harus dicatat bahwa proses hanya untuk visual mewakili ada layanan.
Hal ini dapat menggunakan representasi grafis atau tekstual. Perilaku internal Layanan tidak
terlihat.
Serupa dengan proses transformasi UPnP-ARCTIS di atas, Layanan UPnP cahaya di
atas dapat disajikan menggunakan komponen SCA, UML diagram kelas, peserta SoaML
yang ditampilkan dalam gambar 4.8, sosok 4.9 dan 4.10 gambar, masing-masing. Dapat
dilihat bahwa proses presentasi hanya dilakukan untuk visualisasi dari layanan yang ada.
Layanan tidak statis, tetapi Deskripsi statis. UML kelas, misalnya, dapat mewakili statis
entitas dengan perilaku yang dinamis. Ini ditangani secara statis selama komposisi pada saat
runtime dan desain.

Gambar 4.7: Blok bangunan ARCTIS digunakan untuk mewakili visual layanan UPnP Light
Dalam contoh ini kita juga mempertimbangkan bahwa semua model Layanan
terhubung ke kode sumber yang sama untuk invokasi layanan. Daftar 5.3 menunjukkan kode
sumber Java untuk invokasi Layanan UPnP cahaya. Di PMG-pro sumber yang dihasilkan
secara otomatis selama langkah abstraksi presentasi. Kode sumber lengkap disajikan dalam
Lampiran D.

Gambar 4.8: SCA komponen yang digunakan untuk mewakili Layanan ringan UPnP.

Gambar 4.9: UML kelas digunakan untuk mewakili Layanan UPnP cahaya.

Gambar 4.10: Peserta SoaML yang digunakan untuk mewakili Layanan UPnP Light.
4.2.5 Abstractor Layanan
Model layanan yang dapat muncul dalam abstraksi berbeda tingkat. Misalnya,
pengguna dapat menggunakan ikon untuk model layanan, sementara seorang pengembang
dapat menggunakan kelas model layanan. PMG-pro, abstractor Layanan digunakan untuk
abstrak layanan tingkat berbeda abstraksi.
4.2.5.1 Model Layanan Umum
Layanan-layanan existing run-waktu mungkin telah dilaksanakan menggunakan
standar yang berbeda dan teknologi. Akibatnya, mereka menggunakan berbagai cara untuk
menggambarkan layanan, bahkan layanan dengan fungsionalitas yang sama. Di PMG-pro,
dari Deskripsi Layanan sepasang kode dan representasi grafis dari layanan yang dihasilkan.
Untuk layanan yang sama, akan ada model layanan yang umum. Contoh model layanan yang
umum, yang merupakan platform independen model, diilustrasikan pada gambar 4.11.
Dalam gambar 4.11, tiga lampu layanan yang menyediakan fungsionalitas yang sama
ditampilkan. Layanan UPnP lampu dan cahaya UPnP menggunakan UPnP skema untuk
menggambarkan

Gambar 4.11 r: Platform layanan independen model dan kode. Dalam contoh ini, sebuah
lampu adalah sama dengan model berbeda implementasi layanan: Layanan
UPnP Lamp, DPWS Lamp dan UPnP cahaya.
Layanan sementara lampu DPWS menggunakan DPWS untuk menggambarkan service.
Semua layanan lampu menyediakan fungsionalitas untuk beralih ON-OFF lampu meskipun
mereka menggunakan nama operasi yang berbeda. Dari model layanan yang berbeda ini
Layanan lampu yang memiliki fungsi ON dan OFF dapat didefinisikan.
Semua model Layanan terhubung ke kode, dan begitu kode untuk lampu Layanan
model. Jelas, kode dapat bervariasi dalam hal bahasa pemrograman. Dalam konteks Jawa,
kita dapat menggunakan antarmuka atau kelas abstrak untuk menyatakan kode. Daftar 4.1
menunjukkan contoh kode untuk model Layanan Umum Layanan lampu, ketika kelas abstrak
digunakan untuk menyatakan kode lampu. Dapat dilihat bahwa kelas abstractLamp adalah
kelas abstrak dengan dua metode yang abstrak. Kemudian, dalam kode generasi langkah

PMG-Pro ketika kelas d digunakan dalam model, implementasi kelas kelas akan dihasilkan
secara otomatis berdasarkan template.

Harus dicatat bahwa generalisasi adalah salah satu cara di atas. Proses generalisasi
ini lebih seperti sebuah proses klasifikasi, mana model layanan serupa akan memiliki satu
kelas yang umum. Subclass tidak dapat dimodifikasi. Namun, untuk menunjukkan kasus
kami hadir contoh kelas UPnP lampu diubah yang akan ditampilkan dalam daftar 4.2.
Informasi tentang super dan subclass disimpan di Perpustakaan layanan.

4.2.6 ringkasan
Dalam PMG-pro, langkah presentasi digunakan untuk menyajikan layanan menjadi
representasi grafis dan kode pelaksanaan layanan invokasi. Kami menganggap bahwa XML
adalah bahasa sehingga XML UPnP Deskripsi Layanan adalah model karena contoh XML.
Mengubah model ke model lain misalnya UML kelas dapat mempekerjakan konsep model
untuk model transformasi (M2M).
Dengan mengembangkan abstractor/presenter berbeda notasi yang berbeda sesuai
dengan pemodelan bahasa dapat dipilih. Selain representasi grafis layanan, langkah
presentasi menghasilkan kode sumber yang sesuai dengan bahasa pemrograman yang dipilih.
Untuk ini, konsep model-untuk-text (M2T) transformasi digunakan. Representasi grafis jasa
digunakan oleh pengembang layanan untuk model layanan berbasis aplikasi baru sementara
kode yang digunakan untuk menghasilkan kode dalam langkah generasi kode.

4.3 Layanan Perpustakaan dan layanan kerangka (APIs) repository


Layanan Perpustakaan dan layanan kerangka (APIs) repositori adalah struktur pusat
PMG. Tiga bagian-bagian lain PMG-Pro (abstractor layanan, model editor dan kode
generator) terhubung bagian ini.
Repositori Layanan kerangka (APIs) berisi Layanan kerangka kerja dan API yang
digunakan oleh layanan abstractor sebagai dasar untuk transformasi Layanan penjelasan ke
notasi yang sesuai untuk pemodelan bahasa (misalnya, UML kelas) dan menghasilkan
implementasi kelas. Contoh yang ada kerangka Layanan adalah [52] [36] forWeb layanan
dan UPnP. Kerangka lain untuk embedded System juga dapat dimasukkan dalam Layanan
repositori dan perpustakaan.
Layanan Perpustakaan berisi model layanan dan kode yang terhubung. Layanan
Perpustakaan digunakan oleh integrator layanan. Dengan menggunakan sebuah editor model,
integrator layanan menggunakan model Layanan grafis yang disimpan di Perpustakaan
layanan untuk menentukan layanan berbasis aplikasi, sementara kode generator

menggunakan Layanan Perpustakaan untuk kode generasi dari model berbasis layanan
aplikasi. Kami akan menyajikan metode generasi kode kemudian di langkah generasi kode.
Layanan Perpustakaan juga digunakan oleh layanan abstractor untuk menyimpan
Layanan representasi grafis dan kode dalam cara hirarkis. Hal ini dibangun berdasarkan pada
ontologi. Satu asumsi penting yang kita gunakan untuk membangun hirarki Layanan adalah
bahwa, Deskripsi Layanan harus berisi cukup informasi untuk kategorisasi layanan.
Gambar 4,12 menunjukkan contoh Layanan Taksonomi di domain rumah pintar,
mana berbeda implementasi MediaRenderer Layanan (misalnya UPnP dan DPWS)
dikategorikan di bawah layanan MediaRenderer, layanan hiburan, dan layanan rumah Smart,
masing-masing. Semua layanan MediaRenderer pada tingkat 0 hirarki memiliki representasi
grafis (dengan stereotip <<PSM>>). Layanan MediaRenderer di tingkat 1 hirarki
didefinisikan sebagai model yang umum untuk mewakili semua layanan renderer media.
Perlu dicatat bahwa kode yang akan digunakan oleh kode generator dan model yang akan
digunakan oleh pemodel untuk menentukan aplikasi berbasis layanan baru.
Pada tingkat 1 dan di atas, ada hubungan yang sama antara model dan kode. Kode
sumber mengikat ke model layanan pada tingkat 1 dan di atas tidak nyata kode. Pada tingkat
yang sangat tinggi dari hirarki, model Layanan terhubung ke abstrak informasi tentang
kemungkinan target platform (kode sumber) yang tersedia dan digunakan pada kode
generator. Berdasarkan platform target dipilih, kode generator akan menghasilkan kode
sumber yang disesuaikan.
Di smart rumah domain, Ontologi telah digunakan untuk menyusun layanan seperti
digunakan dalam [111, 87]. Dalam [87] penggunaan ontologi memungkinkan Deskripsi
efektif heterogen layanan dan sumber daya yang tinggal di rumah pintar. Ini termasuk

Gambar 4,12: Contoh taksonomi model layanan. Masing-masing model terhubung ke kode
sumber.
proposal untuk layanan berbasis ontologi otomatis penemuan dan komposisi dinamis
layanan.
Waktu ide layanan taksonomi disajikan dalam gambar 4,12 ontologi cerdas layanan
rumah dibuat. Dasar taksonomi pohon menampilkan umum ontologi Formal dalam gambar
4.13. Ontologi ini dapat digunakan untuk mengotomatisasi pembangunan Layanan hirarki di
PMG-pro. Dalam kasus ini, PMG-pro mengasumsikan bahwa semua perangkat di rumah
pintar menyediakan layanan tertanam.

Gambar 4.13: Ontologi formal umum rumah pintar perangkat yang digunakan dalam
PMGpro.
PMG-pro angka 4.13, perangkat rumah pintar dikelompokkan ke dalam tiga kelas;
perangkat hiburan, otomatisasi dan pengawasan. Termasuk dalam perangkat hiburan yang
televisi, mp3 player, media server dan perangkat media renderers. Perangkat ini menyediakan
fungsi yang dapat ditemukan dan digunakan.

4.4 langkah pemodelan


PMG-pro adalah metode independen bahasa. Mungkin untuk menggunakan bahasa
yang ada model yang berbeda dan berbeda pemodelan editor. Syarat adalah bahwa presenter
harus menghasilkan notasi (yaitu, abstrak Layanan model) yang sesuai dengan pilihan
pemodelan bahasa. Menggunakan model dihasilkan layanan, Layanan integrator dapat model
aplikasi berbasis layanan baru.
Ada tidak ada kontribusi langsung PMG-Pro di langkah pemodelan. Kontribusi hanya
adalah kemungkinan menggunakan bahasa yang berbeda model ke model servicebased
aplikasi. Namun, dalam bagian ini kami akan menjelaskan bagaimana layanan berbasis
aplikasi dapat dimodelkan di PMG-pro. Kami fokus hanya pada aktivitas dan sequence
diagram. Tetapi jelas, tergantung pada pilihan pemodelan bahasa.

4.4.1 tinjauan
Dalam pengembangan perangkat lunak, model digunakan untuk menggambarkan
struktur dan perilaku sistem perangkat lunak. Struktur menentukan apa contoh-contoh model
yang; mengidentifikasi komponen bermakna membangun model dan berkaitan mereka satu
sama lain. Model perilaku menekankan perilaku dinamis sistem, yang dalam UML misalnya,
pada dasarnya dapat dinyatakan dalam tiga jenis perilaku model; interaksi diagram, diagram
aktivitas, dan negara mesin diagram.
4.4.2 kolaborasi kegiatan Diagram
Meskipun teknik berbasis model, diagram negara-mesin dianggap sebagai model
yang paling eksekusi [35], kami masih tertarik menggunakan UML diagram aktivitas dan
kolaborasi diagram. Alasannya adalah bahwa, dari kegiatan diagram yang kita dapat
menghasilkan mesin negara diagram [66]. UML diagram aktivitas yang digunakan terutama
untuk model sistem aliran data objek yang pola umum dalam layanan

Gambar 4.14: Model aplikasi berbasis layanan ditentukan menggunakan diagram aktivitas.

Gambar menunjukkan sebuah aplikasi berbasis layanan yang menggunakan tiga


layanan yang sudah ada. Setiap layanan memiliki kegiatan internal. Swimlane mewakili
sebuah layanan berbasis aplikasi model. Diagram aktivitas ini juga baik untuk model perilaku
sistem yang tidak sangat bergantung pada peristiwa eksternal. Sebuah sistem yang sebagian
besar memiliki langkah-langkah yang dijalankan untuk penyelesaian, daripada diganggu oleh
peristiwa dan memerlukan objek data aliran antara langkah-langkah.
Dengan demikian, model layanan berbasis aplikasi di PMG-pro dapat disajikan
sebagai kegiatan kolaborasi yang mana hubungan antara model layanan yang ditetapkan
menggunakan aktivitas node. Lihat gambar 4.14 untuk contoh. Gambar menunjukkan sebuah
aplikasi berbasis layanan yang menggunakan tiga layanan yang sudah ada. Setiap layanan
memiliki kegiatan internal. Dari pandangan layanan berbasis aplikasi, kegiatan dipandang
sebagai sebuah layanan sederhana.
4.4.3 Sequence Diagrams
Ada beberapa cara untuk model interaksi (koneksi) antara layanan (yaitu, Layanan
komposisi) dalam sebuah diagram aplikasi berbasis layanan. Komposisi Layanan sederhana,
diagram urutan yang lebih sederhana daripada diagram aktivitas. Dengan komposisi
sederhana berarti komposisi yang tidak memiliki dataflow dan tanpa aktivitas apapun antara
model-model layanan.
Dengan mengembangkan layanan abstractor/presenter yang mampu menghasilkan
UML kelas dari Deskripsi Layanan, kami dapat menggunakan objek kelas untuk menentukan
layanan berbasis aplikasi baru dalam bentuk diagram urutan. 4.15 angka menunjukkan
contoh sebuah aplikasi berbasis layanan yang ditentukan dalam diagram urutan.

Gambar 4.15: Model aplikasi berbasis layanan ditentukan menggunakan diagram urutan.
Angka ini tiga berbeda UPnP layanan yang digunakan untuk membangun
sebuah aplikasi berbasis layanan. Aplikasi akan memutar musik ketika
Layanan UPnPLight yang dipanggil, dan akan berhenti pada nilai tertentu
cuaca parameter
4.4.4 model tingkat tinggi
Menggunakan layanan hirarki (Lihat gambar 4,12), hal itu mungkin untuk pemodel
untuk model baru berbasis layanan aplikasi pada setiap tingkat hirarki. Semakin tinggi tingkat
hirarki lain platform-independent model akan. Dengan tingkat tinggi model, berarti model
layanan berbasis aplikasi yang dibangun menggunakan model platform-independent layanan
di tingkat 1 dan di atas layanan hirarki (Lihat gambar 4,12).
Mode tingkat tinggi l mungkin menggunakan presentasi yang dekat dengan pengguna
akhir, untuk contoh gambar yang menggambarkan layanan yang nyata. Dalam hirarki
Layanan (Lihat gambar 4,12), untuk pengguna akhir, Layanan dapat disajikan di tingkat
tertinggi Layanan hirarki. Meskipun topik ini dari konteks PMG-pro, penjelasan singkat
tentang bagaimana ide dapat dilakukan diberikan. Dalam proyek ISIS [110], es, alat
komposisi pengguna akhir yang memungkinkan pengguna untuk menulis layanan yang
berbeda

saat

menjalankan

dikembangkan.

Kami

menganggap

bahwa

dengan

mengembangkan layanan khusus presenter dan abstractor, Layanan presentasi (Layanan


model) untuk pengguna akhir dan kode untuk menerapkan model layanan yang dapat

dihasilkan. Model layanan yang kemudian dapat digunakan oleh pengguna akhir untuk model
komposisi.
4.4.5 ketepatan model
Salah satu isu utama saat menggunakan diagram aktivitas dan diagram urutan
berkaitan semantik. Berkaitan dengan kegiatan UML diagram, beberapa karya telah untuk
mengatasi masalah ini [29, 12, 107]. Beberapa usulan telah juga diusulkan, misalnya [59, 18,
26].
Namun, PMG-pro adalah bahasa yang independen. Menggunakan ada pemodelan
bahasa untuk model sebuah aplikasi berbasis layanan. Dengan ini, semantik model dan model
kebenaran mengikuti pilihan pemodelan bahasa. Sebagai contoh, ketika kita menggunakan
ARCTIS model sebuah aplikasi berbasis layanan kemudian model kebenaran akan diperiksa
menggunakan yang built-in model checker. Dengan demikian, jika kita menggunakan alat
UML model layanan berbasis aplikasi maka semantik dan model memeriksa mekanisme
mengikuti checker built-in model nya jika mereka memiliki. Ini mengarah ke sebuah
kesimpulan bahwa semantik diagram aktivitas dan urutan ini tidak masalah besar di PMGpro, sementara semantik bagian struktur mudah.
4.4.6 ringkasan
Pemodelan aplikasi berbasis layanan di PMG-pro dibatasi untuk model layanan yang
disimpan di Perpustakaan layanan. Model layanan yang disimpan adalah representasi dari
layanan run-time yang ada. Berbagai pemodelan bahasa dapat digunakan untuk aplikasi
berbasis layanan model. Run-time hadir PMG-pro layanan menggunakan notasi yang sesuai
dengan pilihan pemodelan bahasa.
Sejak PMG-pro menggunakan ada pemodelan bahasa, kebenaran model tergantung
dengan built-in model checker. PMG-pro mengasumsikan bahwa semua pemodelan bahasa
memiliki checker (built-in) model sendiri.
4.5 kode generasi dan tahap penyediaan

Untuk menjalankan model layanan berbasis aplikasi yang telah dihasilkan di langkah
pemodelan, PMG-pro menerapkan kode generasi bukan model interpretasi. Kami
menerapkan model untuk pendekatan transformasi teks. Manfaat dari pendekatan ini adalah
bahwa kita memiliki pemeriksa tambahan untuk ketepatan model karena pendekatan yang
menggunakan bahasa pemrograman yang ada.
Alat pemodelan banyak, terutama domain-spesifik pemodelan alat, datang dengan
generator kode mereka sendiri. Dalam kasus ini, PMG-pro dapat menggunakan generator
kode tersebut. Namun, untuk bukti-of-konsep dimana sebuah aplikasi berbasis layanan akan
disediakan sebagai layanan baru, generator kode tertentu yang harus dikembangkan. Dalam
bagian ini kami menyajikan sebuah konsep PMG-Pro menghasilkan kode dari model berbasis
layanan aplikasi.

Gambar 4.16: Generator kode. Template yang digunakan untuk menghasilkan kode sumber.
4.5.1 Tinjauan
Gambar 4.16 menunjukkan arsitektur kode generator. Seperti dapat dilihat pada
gambar, input untuk kode generasi PMG-Pro adalah model layanan berbasis aplikasi yang
dapat diagram aktivitas atau diagram urutan. XMI parser membaca model layanan berbasis
aplikasi yang disajikan dalam XMI file. Output dari parser diberikan kepada generator.
4.5.2 kode generasi

Model memiliki dua bagian. struktur dan perilaku. Di PMG-pro struktur dasar
dijelaskan menggunakan kelas statis dan blok bangunan sementara perilaku diekspresikan
menggunakan UML aktivitas node dan tindakan dalam urutan diagram.
Kode langsung ditafsirkan dari unsur-unsur aktivitas. Sebagai contoh, sambungan
garis dari satu pelabuhan di sebuah blok bangunan ke pelabuhan di blok bangunan lain berarti
layanan doa. Kode untuk sambungan ini hanya disalin dari kelas proxy yang berisi kode
untuk invokasi yang sebenarnya.
4.5.2.1 kode dari aktivitas diagram
Model layanan berbasis aplikasi dapat didefinisikan dengan menggunakan diagram
aktivitas. Dengan demikian, kode harus dihasilkan dari diagram aktivitas ini. Dalam bagian
ini kami menyajikan ide dasar dari bagaimana PMG-pro menghasilkan kode dari aktivitas
diagram. 4.17 gambar dan daftar 4.3 menunjukkan contoh node penggabungan dan kode kode
yang dihasilkan.
Sebuah node penggabungan adalah sebuah node kontrol yang menyatukan beberapa
alternatif. Tidak digunakan untuk mensinkronisasi mengalir bersamaan tetapi tidak mau
menerima salah satu alternatif yang mengalir. Ini memiliki beberapa tepi masuk dan keluar
tepi yang tunggal. Pelaksanaan diagram aktivitas dapat digambarkan seperti yang
ditunjukkan dalam daftar kode 4.3. Dalam [95] terdaftar contoh lain dari kode generasi untuk
node aktivitas lain. Konsep serupa juga dapat ditemukan di [10] dan [30].

Gambar 4.17: Sebuah penggabungan node. Gambar menunjukkan aktivitas dan tiga aliran
input data. Aktivitas akan dijalankan semua data mengalir tiba

Berkaitan dengan generasi kode ARCTIS, PMG-pro kode generator berlaku hanya
proses transformasi sederhana. It membaca dan mengubah aktivitas node (dengan kontrol
dan objek mengalir) langsung ke kode. Jadi, ini bekerja hanya pada diagram aktivitas
sederhana karena formalism. Alasannya adalah bahwa kode generator di PMG-pro ini
dikembangkan hanya untuk bukti-of-konsep. Namun, karena metode independen bahasa dan
alat-alat, PMG-pro dapat menggunakan setiap built-in kode generator. Sebaliknya, ARCTIS
mengkonversi diagram aktivitas kolaborasi menjadi mesin negara yang bisa dijalankan.
Untuk ini, cTLA digunakan untuk alasan [55]. Kode ini kemudian, dihasilkan dari mesin
dihasilkan negara. Ia bekerja pada diagram aktivitas yang lebih kompleks.
4.5.2.2 kode dari sequence diagram
Beberapa sistem memiliki perilaku dinamis sederhana yang dapat dinyatakan dalam
urutan tertentu pesan antara sejumlah kecil, tetap dari objek atau komponen. Dalam urutan
kasus seperti diagram benar-benar dapat menentukan sistem perilaku. Kode dapat dihasilkan
dari kasus-kasus sederhana ini. Daftar 4.4 menunjukkan contoh kode yang dihasilkan dari
diagram urutan yang ditunjukkan dalam gambar 4.15.

Namun, dalam banyak kasus, perilaku lebih kompleks, misalnya ketika kumpulan
berkomunikasi objek besar atau sangat bervariasi, ketika ada banyak poin cabang (misalnya
pengecualian), ketika ada iterasi yang kompleks, atau sinkronisasi isu-isu seperti sumber
daya pertengkaran. Dalam kasus tersebut, urutan diagram benar-benar tidak dapat
menggambarkan sistem perilaku, tetapi mereka dapat menentukan kasus penggunaan khas
untuk sistem, detail-detail kecil dalam perilaku, dan disederhanakan Ikhtisar perilaku. Hidup
urutan grafik (LSCs) adalah salah satu contoh solusi untuk masalah ini.
4.5.2.3 metode generasi kode untuk menangani kemampuan perangkat
Dalam konteks MDA, platform sasaran berbeda memerlukan kode disesuaikan yang
berbeda. Dalam konteks embedded System, persyaratan konfigurasi dan kemampuan
perangkat sering digunakan bukan platform. Kemampuan perangkat dan konfigurasi
memperkenalkan masalah untuk menghasilkan kode bahkan dalam kemampuan perangkat
yang sama. Sebagai contoh, dapat terjadi pengembangan aplikasi mobile. Dalam kasus ini,
itu bisa terjadi bahwa kode sumber bekerja untuk satu ponsel tertentu tidak akan bekerja pada
salah satu dari jenis yang sama. Sebagai contoh, ini dapat disebabkan oleh perbedaan dalam

konfigurasi pengguna (misalnya ukuran memori) atau / dan kemampuan perangkat


(misalnya, resolusi kamera).

Layanan di lingkungan aplikasi berbasis layanan dianggap yang disediakan oleh


pihak ketiga; oleh karena itu mereka dengan mudah dapat datang dan pergi. Itu akan sangat
mungkin bahwa termasuk layanan tidak tersedia ketika sebuah aplikasi berbasis layanan
diimplementasikan, disebarkan, dan menjalankan. Untuk menghasilkan kode untuk
perangkat dengan kemampuan perangkat tertentu, dua solusi yang diusulkan. Solusi pertama
adalah menghasilkan kode untuk mungkin gabungan pelayanan di ontologi. Misalnya, kelas
lampu abstrak yang ditunjukkan dalam gambar 4.11 dapat diimplementasikan secara berbeda
selama proses generasi kode. Solusi ini juga akan mendukung run-waktu adaptasi dalam hal

layanan yang akan dihapus atau layanan baru muncul. Daftar 4.5 menunjukkan contoh
mungkin kode yang dihasilkan untuk mengimplementasikan lampu, menggunakan solusi
pertama.
Kelas lampu di atas adalah implementasi kelas kelas abstrak disajikan dalam daftar
4.1. Membentang kelas abstractLamp untuk menerapkan metode yang abstrak. Kelas
pelaksanaan ini yang dihasilkan secara otomatis berdasarkan template.
Solusi kedua adalah untuk menghasilkan kode hanya untuk layanan (tertentu) hadir.
Solusi ini memerlukan informasi tentang perangkat tersedia pada saat runtime. Ini berarti
kode tidak dihasilkan sebelum platform yang digunakan, yang pada dasarnya berarti
berdasarkan permintaan kode generasi. Misalnya, jika Layanan lampu yang tersedia hanya
UPnPLamp, kemudian kode generator hanya akan menghasilkan (menggunakan)
UPnPLamp.java. Kode generator tidak akan menghasilkan kode (menggunakan) untuk
layanan lampu lain (yaitu, UPnP cahaya dan lampu DPWS).
4.5.3 ringkasan
Model menggambarkan struktur dan perilaku sebuah aplikasi berbasis layanan. Di
PGM-pro, kode dari struktur yang dihasilkan oleh objek Instansiasi sementara kode dari
perilaku yang dihasilkan oleh interpretasi dari interaksi antara instance objek. Kami
beradaptasi DSL lingkungan dimana kita berasumsi Layanan sebagai sebuah konsep yang
diimplementasikan. Untuk alasan ini, kami tidak menentukan bahasa yang harus digunakan
untuk model layanan berbasis aplikasi.

Bab 5
Proof-of-Concept
Bagian PMG-Pro telah penyaji iklan menggunakan bahasa pemrograman Java. Bab
ini menyajikan prototipe dan studi kasus menunjukkan bukti-of-konsep. Bagian 5.1 adalah
ikhtisar prototipe. Bagian 5.2, 5.3 dan 5.4 hadir prototipe presenter Layanan ARCTIS,

Layanan Perpustakaan dan kode generator. Untuk bukti-of-konsep, tiga studi kasus disajikan
dalam Bagian 5.5.
5.1 Tinjauan
Kami memiliki bagian-bagian penyaji iklan PMG-Pro untuk menunjukkan ide
presentasi visual layanan menggunakan representasi grafis. Rencana kami adalah untuk
memperluas layanan abstractor / presenter untuk dapat menghasilkan berbeda notasi
mendukung editor dan bahasa berbeda pemodelan. Untuk ini, kami mengembangkan
antarmuka pengguna umum seperti ditunjukkan pada gambar 5.1 menunjukkan ringkasan.
Harus dicatat bahwa tidak semua link pada gambar dilaksanakan.

Gambar 5.1 menunjukkan ringkasan: Screenshot dari antarmuka pengguna PMG-Pro.


5.2 Layanan Presenter
Fokus dari pembangunan prototipe adalah untuk menunjukkan bahwa PMG-pro
bekerja. Untuk ini, kita fokus hanya pada presentasi otomatis run-waktu layanan dan bagianbagian kode generasi. Untuk layanan, kami telah mengimplementasikan dua layanan
presenter. Presenter layanan pertama mampu menghadirkan layanan run-time sebagai blok
bangunan ARCTIS. Kedua layanan presenter dikembangkan untuk hadir runtime Layanan
sebagai UML kelas di Rational Rose [85].

Menggunakan ARCTIS, perilaku sebuah aplikasi berbasis layanan adalah model


menggunakan kolaborasi aktivitas diagram saat menggunakan UML (Rational Rose),
perilaku yang meniru menggunakan diagram urutan. Oleh karena itu, prototipe PMG-pro
mendukung untuk dua teknik pemodelan; diagram aktivitas kolaborasi dan diagram urutan.
Jelas, semantik bahasa berikut pilihan pemodelan bahasa.
Dua prototipe presenter layanan yang disebutkan di atas sama. Dalam tesis ini kami
menyajikan hanya prototipe presenter layanan yang menerapkan transformasi UPnP layanan
ke blok bangunan ARCTIS. Untuk transformasi ini, kami digunakan XMI (XML untuk
pertukaran meta-data). Prototipe pertama mampu mengubah Deskripsi Layanan UPnP
(XML) ke blok bangunan ARCTIS (XMI 2.1), sementara prototipe kedua mampu mengubah
Deskripsi Layanan WSDL (XML) menjadi UML kelas.
Penggunaan UML kelas (yang statis) untuk hadir Layanan (oleh alam dinamis)
mungkin karena presentasi di PMG-pro adalah hanya visual menyajikan (dan abstraksi)
Layanan run-time. Hal ini tidak layanan yang sebenarnya. Layanan yang sebenarnya dan
perilaku yang berada di penyedia layanan. Di PMG-pro, model Layanan adalah abstrak
presentasi layanan yang ada pada tingkat tinggi. Fungsi akses ke layanan yang sebenarnya
dilakukan oleh kode terhubung.
5.2.1 Deskripsi Layanan UPnP
UPnP menggunakan XML sebagai bahasa skema untuk menentukan perangkat dan
layanan deskripsi, kontrol pesan, dan eventing. Perangkat berbasis UPnP dapat menerapkan
nol atau lebih layanan. Namun, setiap perangkat UPnP harus host gambaran perangkat XML
yang berisi informasi spesifik tentang perangkat, informasi tentang layanan perangkat, dan
bahkan informasi tentang perangkat yang bersarang.
Deskripsi Layanan itu sendiri adalah dokumen XML yang berisi daftar tindakan dan
variabel negara yang berlaku untuk layanan tertentu yang ditawarkan oleh perangkat UPnP.
Gambar 5.2 mengilustrasikan gambaran Layanan daya (SetTarget) perangkat UPnP cahaya
dalam XML. Lihat Lampiran B untuk rincian lebih lanjut.

Gambar 5.2: Contoh gambaran Layanan UPnP. Tindakan yang tercantum dalam Deskripsi
Layanan. Lihat Lampiran B untuk lebih detail.
5.2.2 Template blok bangunan ARCTIS
Untuk menghasilkan blok bangunan ARCTIS kami menggunakan template blok
bangunan (XMI file). Kami membangun template berdasarkan sebuah blok bangunan
ARCTIS sederhana yang ditunjukkan dalam gambar 5.3. Gambar menunjukkan aktivitas
internal sebuah blok bangunan ARCTIS yang sederhana untuk layanan UPnP dalam diagram
aktivitas. Berkenaan dengan layanan UPnP, parameter penting dari sebuah blok bangunan
operasi (aksi), menerima sinyal (EVENT) dan variabel. Karena itu kita hanya
mempertimbangkan parameter ini pada pembangunan template blok bangunan ARCTIS.
5.2.3 transformasi
Secara umum, transformasi didefinisikan oleh aturan pemetaan menggunakan bahasa
transformasi. Setiap aturan pemetaan menjelaskan apa satu, atau beberapa elemen dalam

model sumber harus dijadikan model target. Ketika semua pemetaan aturan diterapkan,
pemetaan menggambarkan transformasi lengkap dari model sumber ke target model.

Gambar 5.3: Diagram aktivitas internal dari sebuah blok bangunan ARCTIS yang sederhana
untuk layanan UPnP. Blok bangunan memiliki satu tindakan (operasi) dan salah
satu acara keluar. Blok bangunan ini digunakan untuk pembangunan template
untuk sebuah blok bangunan UPnP ARCTIS.

Gambar 5.4: Representasi XML dari blok bangunan ARCTIS untuk pembangunan template
untuk sebuah blok bangunan UPnP ARCTIS.
Blok bangunan ARCTIS adalah model seperti yang Instansiasi Alat pemodelan
ARCTIS. Demikian pula, mengingat bahwa XML pemodelan bahasa kemudian gambaran
Layanan UPnP dapat dianggap sebagai model karena Deskripsi UPnP adalah instance dari
bahasa XML. Kedua model ini dalam XML.
Untuk mengubah Deskripsi Layanan XML UPnP ke blok bangunan XMI, presenter
layanan menggunakan XML Parser. XML parser akan mengurai sifat Layanan UPnP (nama
perangkat, properti perangkat, tindakan, program, argumen, argumen jenis dan arah
tindakan). Berdasarkan sifat-sifat ini dan XMI template, blok bangunan ARCTIS dibangun.
Proses dilakukan dalam tiga langkah utama sebagai berikut:
1. Baca description.xml
2. Baca sifat UPnP

3. peta sifat ke template dari blok bangunan ACRTIS.


Algoritma presenter Layanan ditampilkan dalam daftar 5.1. Transformasi UPnP
Layanan penjelasan ke blok bangunan ARCTIS adalah jenis teks-tomodel transformasi.
Untuk ini, aturan transformasi yang disajikan dalam tabel 4.1 digunakan. Aturan-aturan
sangat sederhana. Misalnya, untuk menampilkan nama blok bangunan, kami menggunakan
nama perangkat UPnP. 5.5 angka menunjukkan snapshot dari layanan UPnP Light dalam
ARCTIS blok bangunan yang disajikan dalam gambar 4.7. Snapshot menunjukkan beberapa
properti UPnP telah dipetakan ke XMI ARCTIS bangunan blok. Versi lengkap dari XMI
dapat ditemukan di Apendiks C.

Selain blok bangunan ARCTIS, presenter layanan juga menghasilkan Jawa kelas.
Implementasi kelas pada dasarnya digunakan sebagai proxy untuk layanan invokasi. Untuk
menghasilkan kelas implementasi ini, sebuah template digunakan. Kami menggunakan
Cyberlink untuk Java untuk layanan UPnP [52], untuk membangun template ini. Kelas
implementasi ini terhubung ke blok bangunan ARCTIS.

Gambar 5.5: Representasi XML Layanan UPnP cahaya dalam ARCTIS blok bangunan yang
disajikan dalam gambar 4.7. XML yang berisi informasi tentang nama-nama operasi, xmi:id,
argumen, jenis argumen, petunjuk, dll.

Anda mungkin juga menyukai