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
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].
nama Perangkat
Aksi
indakan argumen
Variabel keadaan
Aktivitas output
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.
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.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 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
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
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.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
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.