Anda di halaman 1dari 25

5.2.

1 UPnP Service Description


UPnP menggunakan XML sebagai bahasa skema untuk menentukan
perangkat dan layanan deskripsi, kontrol pesan, dan eventing. Perangkat berbasis
UPnP dapat menerapkan layanan nol atau lebih. Namun, setiap perangkat UPnP harus
meng-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 Negara variabel yang berlaku untuk layanan tertentu yang ditawarkan
oleh perangkat UPnP.

Gambar 5.2: Contoh gambaran Layanan UPnP. Tindakan yang tercantum dalam Deskripsi
Layanan. Lihat Lampiran B untuk lebih detail

5.2.2 An ARCTIS Building Block Template


Untuk menghasilkan blok bangunan ARCTIS kita menggunakan template
blok bangunan (XMI file).
5.2.3 Transformation

Secara umum, transformasi yang ditetapkan oleh aturan pemetaan


menggunakan transformasi bahasa. Setiap aturan pemetaan menjelaskan apa satu,
atau beberapa elemen dalam sumber model harus dapat berubah menjadi dalam target
model. Ketika semua aturan pemetaan yang diterapkan, pemetaan menggambarkan
transformasi lengkap dari model sumber untuk 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 event keluar. Blok bangunan ini digunakan
untuk pembangunan template untuk sebuah blok bangunan UPnP ARCTIS

Blok bangunan ARCTIS adalah model seperti yang Instansiasi ARCTIS Alat
pemodelan. Demikian pula, mengingat bahwa XML bahasa pemodelan kemudian
Deskripsi Layanan UPnP dapat dianggap sebagai model sejak Deskripsi UPnP adalah
instance dari bahasa XML. Berdasarkan sifat-sifat template XMI, dan 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.
Selain blok bangunan ARCTIS, Layanan presenter menghasilkan Kelas Java.
Implementasi kelas pada dasarnya digunakan sebagai proxy untuk Layanan invokasi.
Untuk menghasilkan kelas implementasi ini, sebuah template digunakan. Kami
menggunakan CyberLink untuk Layanan Java UPnP, untuk membangun template ini.
Ini implementasi kelas terhubung ke blok bangunan ARCTIS.

5.3 The Service Library


Layanan Perpustakaan dilaksanakan dalam tabel sederhana yang berisi
informasi tentang hubungan antara model dan kode nyata. Pada saat kami
melaksanakan Layanan Perpustakaan secara manual dan menyimpan sebagai .txt file.
Tabel berisi empat kolom: representasi grafis layanan, tingkat dalam hirarki
layanan, nama file kode terhubung dan subclass. Tabel 5.1 menunjukkan tabel.
Tabel 5.1: Database sederhana untuk menerapkan Layanan Perpustakaan
untuk tujuan bukti dari konsep.

5.4 Code Generator


Meskipun ada beberapa alat pemodelan menyediakan built-in Kode
Generator, untuk keperluan bukti konsep, PMG-pro juga menyediakan kode generator
sederhana. Ini dilakukan karena built-in Kode Generator, misalnya generator kode
ARCTIS, tidak cocok untuk, membuat bukti konsep. ARCTIS tidak melaksanakan
langkah menyediakan PMG-Pro. Untuk memberikan sebuah aplikasi berbasis layanan
sebagai layanan baru, kode tambahan diperlukan.
Model layanan berbasis aplikasi memiliki dua bagian. struktur dan perilaku.
Kode dari bagian perilaku yang dihasilkan menggunakan konsep Instansiasi. Satu
Instansiasi dibuat untuk setiap model layanan yang digunakan. Dalam kasus generasi
ARCTIS Kode java, dari setiap blok bangunan, satu objek instantiated[55]. Karena
blok bangunan dalam skenario ini adalah platform independen, objek untuk instansi
tergantung pada pilihan platform.
Sumber:

[55] Frank Alexander Kraemer, Peter Herrmann, and Rolv Brk. Aligning UML 2.0
State Machines and Temporal Logic for the Efficient Execution of Services. In
R. Meersmann and Z. Tari, editors, Proceedings of the 8th International
Symposium on Distributed Objects and Applications (DOA), 2006, Montpellier,
France, volume 4276 of Lecture Notes in Computer Science, pages 16131632.
SpringerVerlag Heidelberg, 2006.
Bagian perilaku yang dihasilkan dari interaksi antara layanan model. Informasi untuk
menghasilkan kode perilaku bagian ini diambil dari kegiatan node. Untuk ini kami
beradaptasi metode generasi yang disajikan dalam[10]. Berkaitan dengan metode
mereka, ARCTIS bangunan blok dapat dianggap sebagai entitas yang mengeksekusi
tindakan eksternal.
Sumber:
[10] A.K. Bhattacharjee and R.K. Shyamasundar. Validated code generation for
activity diagrams. In Proceedings of Distributed Computing and Internet.
5.5 Studi Kasus
Untuk tujuan bukti dari konsep, kami menggunakan lingkungan rumah pintar.
Rumah pintar yang contoh sederhana lingkungan yang mengandung perangkat yang
berbeda (dengan tertanam services) yang dapat secara bebas dikendalikan oleh orang
lain, dalam arti layanan invokasi.
Lingkungan rumah cerdas juga digunakan dalam [109] dan [22]. 5.6 gambar
menggambarkan rumah pintar yang digunakan dalam tesis ini. Gateway perumahan
mengendalikan dan mengelola rumah perangkat dengan layanan tertanam. Dalam
jenis tempat tinggal, mungkin untuk mempertahankan kontrol pintu dan jendela
jendela, katup, keamanan dan sistem surveilans, dll. Ini juga mencakup kontrol
perangkat multi media yang merupakan bagian dari sistem hiburan rumah.
Sumber:
[109] Chao-Lin Wu, Chun-Feng Liao, and Li-Chen Fu. Service-oriented smarthome
architecture based on OSGi and mobile-agent technology. IEEE Transactions on
Systems, Man, and Cybernetics, Part C: Applications and Reviews, 37(2):193
205, 2007.
[22] Lorcan Coyle, Steve Neely, Graeme Stevenson, Mark Sullivan, Simon Dobson,
and Paddy Nixon. Sensor fusion-based middleware for smart homes. International
Journal of Assistive Robotics and Mechatronics, 8(2):5360, 2007.
Tiga studi kasus serupa yang disajikan dalam bagian ini. Untuk setiap studi
kasus, skenario komposisi yang telah dikembangkan. Tujuan dari studi kasus

menunjukkan bagaimana metode PMG-pro dapat diterapkan untuk domain yang


berbeda dan menunjukkan bahwa berbagai pemodelan bahasa dapat digunakan. Tiga
studi kasus yaitu:
1. Model berbasis pendekatan untuk pengembangan layanan rumah cerdas

Gambar 5.6:
Rumah pintar - dipilih lingkungan untuk bukti dari konsep. Semua perangkat
menyediakan jasa yang dapat dipanggil.
Kami memiliki tiga studi kasus berdasarkan lingkungan ini.
Studi kasus masing-masing memiliki skenario layanan berbasis aplikasi.

2. pengembangan aplikasi berbasis peristiwa yang menggunakan layanan yang


ada.
3. sebuah metode berbasis model untuk pengembangan layanan berbasis aplikasi
dalam lingkungan heterogen.
Dalam studi kasus ini, kita menggunakan terutama UPnP Layanan sebagai
model unit perangkat lunak. Alasannya adalah bahwa UPnP menggunakan XML
untuk menggambarkan layanan dan, ini tampaknya menjadi umum untuk
menggunakan XML untuk menjelaskan layanan (misalnya web services). Selain itu,
UPnP telah secara luas digunakan dan dilaksanakan di beberapa perangkat rumah.
5.5.1 Studi Kasus 1: Model berbasis pendekatan untuk pengembangan Smart home
Service.
Kasus ini studi hadiah ide kami menerapkan MDD untuk komposisi layanan
yang sudah ada, yang kita bertujuan menunjukkan cara baru layanan rumah pintar

akan dipromosikan. Studi kasus serupa diterbitkan dalam Prosiding Ambient bantu
kesehatan dan manajemen kesehatan di jantung kota, ICOST 2009 [94].
Sumber:
[94] Selo Sulistyo and Andreas Prinz. Model-Driven development approach for
providing smart home services. In Ambient Assistive Health and Wellness
Management in the Heart of the City, volume 5597/2009 of LNCS, pages 274
277. Springer Berlin / Heidelberg, Tours, France, 2009.
5.5.1.1 Tujuan Studi Kasus
Tujuan dari studi kasus ini adalah untuk menunjukkan penggunaan MDD
pendekatan untuk mengembangkan layanan rumah smart dengan menulis layanan
yang berbeda yang telah dilaksanakan menggunakan teknologi yang berbeda. Untuk
tujuan ini, kami menggunakan Rational Rose sebagai alat. Oleh karena itu, ada
layanan adalah disarikan ke dalam UML kelas. Kemudian, sebuah diagram urutan
digunakan untuk model aplikasi berbasis layanan baru.
5.5.1.2 Pendahuluan
Rumah pintar adalah tentang penerapan teknik otomatisasi untuk kenyamanan
dan keamanan rumah milik pribadi warga. Di rumah pintar, gateway perumahan
(RGw) menghubungkan rumah dengan perangkat embedded yang berbeda (dan
layanan) ke Internet. Kami mempertimbangkan semua layanan tersebut menjadi
layanan dasar di mana kita dapat mempromosikan layanan canggih baru dengan
menggunakan layanan kerjasama layanan dasar tersebut. Layanan baru yang mungkin
termasuk beberapa perangkat, kedua layanan internal dalam jaringan rumah dan
layanan eksternal di luar jaringan rumah.

5.5.1.3 Skenario Kasus Penggunaan


Dalam skenario ini, kita berasumsi bahwa ada empat berbagai layanan yang
berjalan secara mandiri di rumah pintar. Diantaranya adalah UPnP AlarmModule
yang vides layanan data, UPnP ponsel Deteksi Layanan yang menyediakan layanan
deteksi mobileabsence, UPnP berbasis televisi yang menyediakan layanan tampilan
dan layanan SMS Web. Kami akan mengembangkan aplikasi baru yang
memungkinkan pemilik rumah pintar untuk mendapatkan status / kesehatan yang
berhubungan dengan peralatan rumah (diwakili oleh sensor di sistem alarm) mana
saja ia berada. Alarm pesan akan ditampilkan ke baik UPnP berbasis televisi ketika

pemilik di rumah atau di ponsel mereka ketika pemilik rumah tidak di rumah.
Layanan baru ini dilaksanakan sebagai layanan OSGi.

Gambar 5.7: Representasi abstrak UPnP menampilkan layanan di UML kelas

5.5.1.4 Proses Pembangunan


Langkah pertama adalah layanan abstraksi dalam hal UML kelas. Ada
beberapa kerangka gambaran layanan, misalnya, WSDL (Web Deskripsi Layanan
bahasa), UPnP, dan OSGi. Berdasarkan Deskripsi Layanan, kami hadir Layanan
sebagai UML kelas dan menghasilkan kode untuk menerapkan invokasi layanan.
Proses transformasi gambaran Layanan UPnP ke UML kelas dilakukan
dengan menerapkan konsep model transformasi. Untuk transformasi ini, aturan
transformasi yang disajikan dalam tabel 5.2.
Tabel 5.2: Transformasi aturan antara UPnP - UML kelas

Menggunakan tabel diatas dan template UML kelas (dalam XMI),


displayOnTV aksi berubah menjadi displayOnTV operasi. Argumen tindakan x, y dan
pesan, berubah menjadi argumen operasi. Tabel 5.3 menunjukkan hasil transformasi.
Gambar 5.7 menunjukkan hasil dari transformasi saat XMI UPnP berbasis televisi
Deskripsi dibuka di Rational Rose. Proses abstraksi serupa dilakukan untuk layanan
lainnya.
Tabel 5.3: Transformasi gambaran Layanan UPnP ke UML kelas

Setelah semua layanan yang sudah ada yang kita masukkan ke dalam layanan
baru telah disarikan ke dalam UML kelas, dapat kita model layanan baru, kedua
aspek struktural dan perilaku. Dengan demikian, kami memiliki 4 UML kelas
mewakili empat layanan yang ada. Gambar 5.8 di bawah ini menunjukkan diagram
urutan layanan baru. Layanan baru, alarmService, adalah sebuah kolaborasi empat
layanan yang berbeda (tampilan layanan, Layanan SMS, layanan telepon Deteksi dan
alarm service).
Perilaku alarmsystem:OSGiService digambarkan dalam sebuah diagram
urutan sederhana. Tujuan utama dari sebuah diagram urutan adalah untuk menentukan
urutan peristiwa yang menghasilkan beberapa hasil yang diinginkan. Fokus adalah
kurang pada pesan sendiri dan lebih pada urutan di mana pesan terjadi; Namun
demikian, kebanyakan diagram urutan akan berkomunikasi apa pesan yang dikirim
antara objek sistem serta urutan di mana mereka terjadi. Panah garis putus-putus
menunjukkan bahwa pesan adalah jenis event, yang dalam kasus ini, UPnP peristiwa.
Sebuah panah padat digunakan untuk menggambarkan bahwa objek panggilan
operasi pada objek lain.
Dari angka, dapat dilihat bahwa ketika sebuah sensor diaktifkan, alarmsystem:
OSGiService akan mencari lokasi sensor dan mendeteksi keberadaan ponsel. Aplikasi
akan kemudian sendSMS dan tampilan pesan ke tampilan layanan di televisi UPnP.
Penggunaan putus-putus panah untuk menggambarkan peristiwa dapat membantu
pelaksanaan model, tapi itu akan menjadi sangat kompleks menggunakan diagram
urutan untuk menggambarkan sistem berdasarkan aktivitas yang kompleks. Contoh
lain kesulitan menggunakan diagram urutan adalah keputusan menggambarkan.

Gambar 5.8: UML diagram urutan sistem alarm dalam skenario.

Misalnya, untuk menggambarkan sebuah kasus ketika ponsel adalah di rumah


pesan akan dikirim ke televisi berbasis UPnP. Sebaliknya, menggunakan layanan
sendSMS untuk mencapai ponsel.
Untuk mengeksekusi model, transformasi model kode dilakukan. Untuk ini,
generator kode sumber berbasis template dibangun menggunakan Java. Karena
gabungan Layanan akan disediakan sebagai layanan OSGi, template dikembangkan
berdasarkan kerangka OSGi, yang dalam kasus ini, kita menggunakan kerangka
Knopflerfish OSGi.
5.5.1.5 Ringkasan Studi Kasus
Dalam kasus ini studi, kami telah menunjukkan pendekatan MDD untuk
mengembangkan layanan smarthome dengan mengarang empat layanan yang
berbeda, di perangkat komputasi yang berbeda; Layanan UPnP, OSGi Jasa dan

layanan Web. Layanan baru adalah layanan OSGi yang dimaksudkan untuk berjalan
di OSGi-powered gateway perumahan. Masalah dengan penggunaan UML diagram
urutan adalah dengan pembatasan untuk mengekspresikan berdasarkan aktivitas
sistem kompleks.

5.5.2 Studi Kasus 2: pengembangan Event aplikasi berbasis menggunakan layanan


yang ada.
Kami telah membuat studi kasus pengembangan aplikasi event-based dari layanan
ditentukan menggunakan spesifikasi UPnP. Dalam kasus ini, sebuah aplikasi berbasis
layanan ini dikembangkan. Gabungan fungsionalitas dari aplikasi berbasis layanan
baru tidak disediakan sebagai layanan. Ini adalah hanya aplikasi normal yang
menjalankan dan menunjukkan di satu komputer. Studi kasus diterbitkan dalam
Proceeding of 2nd International Conference on Computer Technology and
Development (ICCTD 2010) [92]
Sumber:
[92] Selo Sulistyo. Model-based approaches for the development of event-based
systems using embedded services. In Proceeding of 2nd International Conference
on Computer Technology and Development (ICCTD), pages 591 596, 2010.
5.5.2.1 Tujuan Studi Kasus
Layanan interaksi dalam aplikasi berbasis layanan mungkin menggunakan
berbasis peristiwa atau permintaan/Balasan berbasis interaksi atau keduanya. Kami
tertarik untuk interaksi berdasarkan aktivitas. Selain itu, kami tertarik pada
penggunaan berbasis model pendekatan untuk pengembangan aplikasi event-based.
Tujuan dari studi kasus ini adalah untuk menunjukkan bahwa alat lain dapat
digunakan untuk mengembangkan aplikasi berbasis layanan. Daripada Rational Rose,
kita menggunakan ARCTIS sebagai alat pemodelan.
5.5.2.2 Pendahuluan
Dalam studi kasus ini kami menggunakan UPnP Layanan sebagai contoh
gambaran layanan berbasis XML. Kami menganggap bahwa UPnP perangkat di
rumah cerdas memberikan layanan dapat digunakan oleh perangkat lain (titik
kontrol). Jadi, titik kontrol adalah pengguna jasa. Dari sudut pandang pengguna
layanan, perangkat UPnP dapat dipresentasikan sebagai objek. Mereka memiliki
atribut (yaitu variable negara) dan menyediakan fungsionalitas/Layanan/operasi

(yaitu tindakannya) kepada pengguna jasa. Dari sudut pandang pengembang


perangkat lunak mereka dapat dipresentasikan sebagai objek yang dapat disusun
dengan benda-benda lainnya. Dalam PMGpro, presentasi dari perangkat UPnP
sebagai objek dilakukan selama langkah presentasi.
Sebagai pengguna layanan normal, titik kontrol dapat menggunakan satu atau
lebih layanan UPnP. Dalam perspektif berorientasi objek, hubungan antara instance
titik kontrol (objek) dan contoh-contoh perangkat UPnP (objects) dapat dimodelkan
berbeda, misalnya menggunakan diagram objek. Ini adalah bagaimana kita
mempertimbangkan bahwa UPnP kompatibel dengan lingkungan berorientasi objek.
Bagian ini memberikan latar belakang untuk UPnP teknologi, khususnya,
gagasan tentang sistem event-based di rumah pintar berbasis UPnP.
1. Universal Plug and Play (UPnP)

Gambar
Peristiwa

5.9:
cahaya UPnP layanan pada Intel SDK untuk UPnP-perangkat
Mata-mata.

Aspek penting dari jaringan rumah pintar adalah konfigurasi diri di


perangkat mana yang otonom diperbolehkan untuk bergabung dan
meninggalkan jaringan rumah dan pada saat yang sama, Jaringan secara
otomatis belajar tentang perubahan apapun. UPnP adalah salah satu contoh

enabler untuk mencapai tujuan ini. UPnP memungkinkan fleksibel


konektivitas ke jaringan ad hoc dan tidak dikelola.
UPnP Service
Layanan UPnP Ini merupakan persyaratan bahwa setiap
perangkat berbasis UPnP harus host gambaran perangkat XML
yang berisi daftar properti tertentu tentang perangkat dan
layanan yang terkait dengan perangkat. Sebagai contoh, yang
berisi informasi tentang FriendlyName perangkat, ID
perangkat, dll. Deskripsi perangkat dokumen juga mencakup
Uniform Resource Locator (URL) untuk Deskripsi Layanan.
Deskripsi Layanan adalah dokumen XML yang berisi daftar
tindakan dan negara yang berlaku untuk layanan tertentu yang
ditawarkan oleh perangkat. Lihat Lampiran B untuk contoh
lengkap UPnP layanan dan perangkat Deskripsi disajikan
menggunakan dokumen XML.
UPnP Events
Satu hal yang menarik dengan UPnP adalah bahwa layanan
UPnP memiliki keadaan variabel yang dapat digunakan untuk
membangun sistem berdasarkan aktivitas. Ketika variabel
negara telah berubah nilai, ini akan mengirimkan nilai berubah
ke semua perangkat UPnP lain untuk memberitahu bahwa nilai
telah berubah. Gambar 5.9 di bawah ini menunjukkan peristiwa
Deskripsi dalam cahaya perangkat UPnP.
Perangkat UPnP mungkin bertindak sebagai titik kontrol atau
perangkat. UPnP perangkat yang bertindak sebagai titik kontrol dapat
mendaftarkan untuk event untuk menerima pemberitahuan jika perubahan
variabel negara untuk keterangan layanan tertentu. Publikasi perubahan
Serikat oleh layanan disebut eventing. Dalam konteks ini, variabel evented
adalah variabel-variabel yang mengirimkan pemberitahuan ke titik kontrol
mengenai perubahan seperti status.
Titik kontrol dapat berlangganan ke sejumlah evented variabel. Ketika
berlangganan peristiwa khusus, perangkat mengajukan keadaan lengkap
semua variabel ke titik kontrol. Setelah mengirim set lengkap informasi
tentang semua variabel ke titik kontrol, perangkat terus mengirim update
ke titik kontrol jika ada perubahan dalam variabel tertentu terjadi.
2. (UPnP-Based) Event-based Systems

Deskripsi Layanan UPnP yang berisi gambaran keadaan variabel (di


objectoriented istilah adalah atribut). Variabel negara ini bisa menjadi
jenis evented, yang berarti bahwa perubahan nilai variabel ini akan
dikonfirmasi untuk semua titik kontrol (pemakai jasa) yang berlangganan.
Dengan variabel evented negara ini, titik kontrol (pemakai jasa) dapat
mengeksekusi diperlukan operasi yang tergantung pada peristiwa itu. Ini
adalah bagaimana kita mempertimbangkan bahwa UPnP Layanan dapat
digunakan untuk membangun sebuah sistem yang reaktif. Itu adalah
sebuah sistem yang bergantung pada event untuk melaksanakan operasi
fungsi-fungsi.
Layanan komposit adalah sebuah aplikasi berbasis layanan yang
menyusun layanan dan menyediakan fungsi baru kepada orang lain
sebagai layanan baru. Dalam kasus kami, kami mempertimbangkan semua
layanan UPnP menjadi layanan dasar yang kita dapat menulis sebagai
aplikasi berbasis layanan baru. Satu contoh sederhana aplikasi terdiri di
rumah smart adalah sebuah aplikasi cuaca untuk musik yang akan
memainkan lagu tertentu atau musik untuk kondisi cuaca yang spesifik.
Dalam contoh ini, perangkat UPnP yang mengukur parameter cuaca akan
memberikan data diukur renderer media UPnP untuk memainkan lagu
tertentu.
Sistem berdasarkan aktivitas sederhana terdiri dari serangkaian
produsen dan konsumen yang adalah klien dari layanan pemberitahuan
event. Semua klien tersambung ke layanan yang sama dan mengakses
fungsi untuk berlangganan atau menerbitkan pemberitahuan. Seperti
disebutkan sebelumnya, UPnP memiliki semua mekanisme untuk
mempublikasikan, berlangganan dan berhenti berlangganan yang
memungkinkan untuk membangun sistem event-based.
3. Memperluas cakupan UPnP menggunakan event pengiriman Gateway
Untuk mendistribusikan peristiwa UPnP, event pengiriman gateway
diperlukan. Kami telah menerapkan UPnP event pengiriman Gateway (uEDG) menggunakan Java.

Gambar 5.10:
Skenario
memperluas jaringan UPnP.

Gambar 5.10 menunjukkan hubungan dua rumah cerdas menggunakan


event pengiriman Gateway. U-EDG berisi penyedia layanan OlehWeb,
OlehWeb layanan klien dan UPnP EventListener. Penyedia layanan Web
yang menyediakan layanan yang dapat digunakan oleh klien untuk mengupload event UPnP dan UPnP paket (SSDP paket). Untuk definisi UPnP
peristiwa dan UPnP SSDP paket pembaca harus merujuk [46].
Sumber:
[46] Michael Jeronimo and Jack Weast. UPnP Design by Example: A
Software Developers Guide to Universal Plug and Play. Intel Press,
May 2003.
Pada sisi klien, klien layanan Web dapat menggunakan layanan yang
disediakan untuk meng-upload yang menerima paket dan pemberitahuan
dari rumah cerdas satu sama lain. UPnP EventListener yang pada sisi klien
mendengarkan event UPnP dan UPnP paket. Ketika suatu peristiwa atau
paket UPnP di rumah pintar telah diterima layanan Web klien akan
mengirim mereka ke rumah pintar lain yang menggunakan layanan Web
yang disediakan. Harus mampu menangkap peristiwa UPnP, klien harus
juga menerapkan UPnP titik kontrol [46].
Sumber:
[46] Michael Jeronimo and Jack Weast. UPnP Design by Example: A
Software Developers Guide to Universal Plug and Play. Intel Press,
May 2003.

Setiap event UPnP memiliki ID perangkat (uuidd), urutan nomor event


(seqd), nama variabel negara (bernama) dan nilai (dihargai). Dengan event
del sangat Gateway, UPnP peristiwa dapat didistribusikan dari satu cerdas
rumah ke rumah lain pintar. Dengan mekanisme ini didistribusikan,
jumlah perangkat yang dapat disusun juga meningkat.
5.5.2.3 Skenario Kasus Penggunaan
Kita berasumsi bahwa ada berbagai layanan yang berjalan secara mandiri di
rumah pintar. Diantaranya adalah UPnP WeatherModule layanan, Layanan ringan
UPnP, Layanan dari sebuah renderer media UPnP dan layanan dari UPnP media
server. Kami ingin mengembangkan aplikasi event-based yang akan memainkan mp3
musik/lagu pada nomor trek yang dipilih ketika suhu ruangan lebih besar dari 20
derajat dan cahaya (lampu) diaktifkan. Di sini, status lampu digunakan untuk
menunjukkan bahwa pemilik rumah smart di rumah.
Untuk memberikan penjelasan tentang fungsi layanan, kami hadir deskripsi
singkat dari masing-masing layanan sebagai berikut.
1. Layanan WeatherModule UPnP
Layanan ini memiliki empat output; udara suhu, kelembaban, radiasi
matahari, dan kecepatan angin. Setiap titik kontrol yang berlangganan ke
layanan ini akan mendapatkan pemberitahuan ketika nilai output berubah.
Modul ini adalah produser event.
2. Layanan ringan UPnP
Layanan ringan UPnP memiliki lima input (tindakan) dan dua output.
Tindakan ini misalnya; Bila dan GetLevel. Meskipun undang-undang
sebagai konsumen event, cahaya UPnP ini juga dapat bertindak sebagai
produser event. Variabel negara Statusand LoadLevelStatus adalah suatu
peristiwa. Untuk detail Deskripsi Layanan cahaya UPnP pembaca harus
melihat [46].
Sumber:
[46] Michael Jeronimo and Jack Weast. UPnP Design by Example: A
Software Developers Guide to Universal Plug and Play. Intel Press,
May 2003.
3. UPnP Media Server dan Media Renderer
Media manapun di media player harus dapat diputar pada media renderers.
Dalam kasus ini studi kita berasumsi bahwa media renderer sudah daftar
media, jadi titik kontrol perlu hanya mengirim perintah (kontrol) untuk
bermain, berhenti, sebelumnya, dan selanjutnya. Untuk contoh rinci

bagaimana UPnP media server dan dia m sebuah renderer digunakan


pembaca harus merujuk [34, 33].
Sumber:
[33] UPnP Forum. Mediarenderer : Device template version 1.01, 2010.
Available at http://upnp.org/specs/av/UPnP-av-MediaRenderer-v3Device.pdf. Last accessed at 20/09/2011.
[34] UPnP Forum. Mediaserver: Device template version 1.01, 2010.
Available at http://upnp.org/specs/av/UPnP-av-MediaServer-v3Device.pdf. Last accessed at 20/09/2011.
Media server dan sebuah renderer mungkin bertindak sebagai event
konsumen dan produser, tetapi dalam studi kasus ini kita menggunakannya
sebagai konsumen event. Kita berasumsi bahwa m dia renderer memiliki
sudah daftar lagu, sehingga titik kontrol dapat mengirim perintah kendali
untuk bermain, berhenti, selanjutnya, dll.
5.5.2.4 Pendekatan Pengembangan
Untuk mengembangkan aplikasi event-based menggunakan UPnP layanan, hal
ini diperlukan untuk memiliki model Layanan UPnP.
1. Service Presentation/Abstractions
Presentasi yang berbeda dapat digunakan untuk layanan UPnP hadir
sebagai objek. Untuk mewakili sebuah layanan oleh model kita perlu
pemodelan bahasa. Daripada menggunakan UML kelas, kami
menggunakan blok bangunan ARCTIS. Sebuah blok bangunan adalah
semacam enkapsulasi kegiatan yang memiliki eksternal input output.
Tabel 5.4: Transformasi gambaran Layanan UPnP ke blok bangunan ARCTIS

Layanan abstraksi adalah teks-untuk-model transformasi. Dengan


menggunakan layanan penjelasan, yang ada dan menjalankan layanan
dalam jaringan dapat berubah (disarikan) menggunakan presentasi grafis.
Selain representasi grafis, Jawa kelas yang dihasilkan. Kelas ini digunakan
sebagai proxy untuk membuat invokasi ke layanan yang tinggal di
penyedia layanan.
Sebenarnya proses transformasi model dilakukan dengan menerapkan
transformasi teks-untuk-teks. Itulah XML-UPnP Layanan descrption ke
dalam blok bangunan XMI-ARCTIS. Kami telah didefinisikan template
untuk blok bangunan XMI-ARCTIS seperti yang disajikan lama di
gambar 5.3. Menggunakan template ini dan dengan menerapkan aturan
transformasi yang disajikan dalam tabel 4.1, Deskripsi Layanan XMLUPnP dapat berubah menjadi blok bangunan XMI-ARCTIS. XMI
kemudian dapat dibuka dalam Alat pemodelan ARCTIS. Tabel 5.4
menunjukkan proses transformasi UPnP parameter ke parameter bangunan
blok ARCTIS. File XMI lengkap dan representasi di ARCTIS UPnPLight
ditampilkan dalam Apendiks C.
2.

Event-based berbasis aplikasi


Setelah semua layanan yang ada di atas disajikan dalam blok bangunan

Gambar 5.11: Model yang baik disajikan dalam diagram blok bangunan ARCTIS. Tiga
blok bangunan yang digunakan untuk menggambarkan aplikasi gabungan.

Pada penyajian pelayanan (abstractor), pemodelan pelayana baru


berbasis aplikasi bisa dilakukan. Dengan blok bangunan, sistem
didefinisikan dalam hal komposisi blok bangunan, di mana blok
bangunan sendiri merangkum kegiatan. Dengan demikian, model aplikasi
event-based berbasis UPnP ditentukan dengan mendefinisikan koneksi
dari blok bangunan UPnP. Model ini mendefinisikan struktur dan perilaku
dari aplikasi event-based.
Gambar 5.11 menunjukkan model konseptual aplikasi berbasis layanan
yang disajikan di diagram blok bangunan. Gambar ini menunjukkan
bahwa aplikasi layanan berbasis memiliki satu atau lebih blok bangunan
yang terhubung menggunakan konektor. Hubungan itu antara blok
bangunan merupakan interaksi layanan. Mereka didefinisikan
menggunakan aktivitas node dalam sebuah diagram aktivitas UML.
Seperti ditunjukkan dalam Gambar 5.11, model ARCTIS dari aplikasi
event-based baru didefinisikan. Jika kita melihat blok bangunan C2:
UPnP Cahaya, variabel keadaan Status Lampu akan digunakan untuk
mengirim perintah bermain untuk C0 yang: UPnP MediaRenderer jika
suhu udara lebih besar dari 20 derajat.
3. Code Generation
Untuk menerapkan aplikasi event-based dapat dihasilkan keluar dari
koneksi dari blok bangunan otomatis. Sambungan mungkin berarti
pemanggilan dari satu perangkat ke layanan lain yang disematkan dalam
perangkat. Untuk tujuan ini, kode generator dapat menggunakan cara
yang mudah untuk generasi kode dengan menafsirkan secara langsung
diagram aktivitas. Karena kita memiliki semua kode yang diperlukan
untuk setiap blok bangunan, kode yang dihasilkan bertindak sebagai 'kode
lem' yang mengkoordinasikan layanan yang termasuk (perangkat).
ARCTIS memiliki generator kode untuk J2SE yang memungkinkan
generasi kode otomatis dari model ARCGIS [55]. Dalam prototipe kami,
satu kelas Java akan dihasilkan untuk satu ARCTIS blok bangunan
diagram. Kode Java untuk model ARCTIS dihasilkan didasarkan pada
kelas model ARCTIS, template, dan proxy. kelas bertindak sebagai 'lem
kode' yang mengimplementasikan komposisi layanan.
5.5.2.5 Ringkasan Studi Kasus

Dalam studi kasus kami telah menunjukkan bagaimana model - berbasis


pendekatan digunakan untuk pengembangan sistem tersebut. Kami abstrak dan
menyajikan layanan ke reusable blok bangunan ARCTIS yang dapat kita
gunakan untuk membangun dan menentukan aplikasi event-based baru. Sebuah
blok bangunan adalah representasi grafis dari kelas implementasi yang dapat
digunakan kembali dan dukungan untuk pembangunan inkremental.
Dengan pendekatan pengembangan
berbasis model, spesifikasi
interaksi layanan dapat dilakukan pada tingkat abstraksi yang tinggi. Meskipun
dalam hal penggunaan ini kita hanya menggunakan UPnP dan layanan Web,
kami percaya bahwa pendekatan ini juga berlaku untuk layanan abstrak lainnya
yang berbasis XML. Tentu saja, dalam hal ini, objek di Internet of Things harus
menyediakan layanan yang disematkan dijelaskan dalam XML.

5.5.3 Studi Kasus 3: Sebuah model - metode berbasis untuk pengembangan layanan aplikasi berbasis di lingkungan layanan beraneka ragam
Dalam studi kasus ini, kami mengembangkan aplikasi berbasis layanan
menggunakan teknologi layanan yang berbeda. Selain itu, aplikasi berbasis layanan
kemudian disediakan sebagai layanan UPnP. Studi kasus ini adalah yang paling
lengkap siklus penciptaan layanan dari metode PMGpro. Dalam studi kasus ini,
fungsi gabungan disediakan sebagai layanan UPnP. Dengan demikian, layanan ini
dijelaskan menggunakan XML, yang lebih fleksibel daripada layanan OSGi dalam
hal interoperabilitas. Studi kasus ini dipublikasikan dalam Prosiding IEEE
International Conference on Software Engineering and Service
Ilmu ICSESS 2010 [97]. Sebuah kertas penuh studi kasus ini juga diterbitkan di
forum SDL.
5.5.3.1 Tujuan dari Studi Kasus
Tujuan dari studi kasus menunjukkan bagaimana PMG-pro dapat digunakan
untuk model aplikasi berbasis layanan di lingkungan layanan beraneka ragam
5.5.3.2 Pendahuluan
Fakta bahwa konsep sistem pelayanan-orientasi dapat didefinisikan,
diimplementasikan, dan dijelaskan dalam beberapa cara telah
memperkenalkan berbagai jenis pelaksanaan konsep. Untuk alasan ini dan
lainnya, motivasi kerja ini adalah untuk menyediakan sebuah metode untuk

membangun aplikasi berbasis layanan menggunakan layanan yang


dikembangkan menggunakan teknologi yang berbeda (lingkungan layanan
beraneka ragam).
5.5.3.3 Skenario Use Case
Menimbang bahwa semua perangkat di Internet melaksanakan fungsi mereka
sebagai layanan disematkan yang dapat dipanggil, aplikasi komposit baru
dapat dipromosikan. Dalam skenario ini, kita menggunakan perangkat berikut:
1. Modul cuaca yang memberikan layanan pengumpulan data yang
berbeda (yaitu, suhu udara, radiasi matahari, kecepatan angin, dan
sensor kelembaban).
2. Lampu yang menyediakan on - off dan layanan dimmer
3. Media Renderers yang memberikan bermain di layanan multimedia.
4. Perangkat virtual yang menyediakan layanan pengiriman email.
Dalam lingkungan rumah pintar, berbeda dapat dibuka dan standar bahasa
dan teknologi yang sering digunakan untuk menggambarkan layanan.
Misalnya, Universal Plug and Play (UPnP) adalah salah satu standar yang
populer untuk menggambarkan layanan disematkan dari perangkat hiburan
rumah (misalnya, media penyaji). Contoh lain adalah Web Services
Description Language (WSDL) dan Perangkat Profil untuk Web Services
(DPWS). Berdasarkan layanan ini disematkan berbeda, aplikasi baru dapat
dipromosikan. Dalam skenario ini, aplikasi baru dipromosikan. Aplikasi ini
memiliki fungsi baru sebagai berikut:

aplikasi ini dapat mengirim pemberitahuan (email) ketika suhu


udara dari Modul Weather lebih besar dari 50 C,
itu akan memainkan musik / lagu pada renderer media saat lampu
dihidupkan dan radiasi matahari di bawah dari 10, dan
menyediakan dua layanan UPnP baru. Layanan pertama adalah
untuk memungkinkan pengguna untuk mengkonfigurasi lagu
dimana pengguna ingin bermain untuk kondisi cuaca tertentu,
sementara layanan kedua adalah untuk mendapatkan info
konfigurasi.

5.5.3.4 Pengembangan Proses


1. Presentasi
Langkah presentasi adalah jenis tulisan - untuk - transformasi Model.
Kami telah mengembangkan layanan abstractor / presenter yang mampu

mengubah UPnP deskripsi layanan ke blok bangunan ARCTIS dan kode


sumber terikat nya (class Java). ARCTIS adalah editor pemodelan yang
menggunakan sebuah blok bangunan sebagai entitas dasar.
Sebuah perangkat UPnP memiliki dua jenis deskripsi; perangkat dan
deskripsi layanan. Sebuah perangkat UPnP dapat memiliki beberapa layanan
yang dalam deskripsi layanan UPnP disebut Tindakan. Untuk
mengotomatisasi langkah ini kita menggunakan aturan transformasi. Tabel 4.1
di Bagian UPnP ARCTIS menunjukkan aturan transformasi untuk mengubah
sifat yang berbeda dalam deskripsi layanan UPnP ke properti di sebuah blok
bangunan ARCTIS. Untuk membangun aturan transformasi, baik ARCTIS
dan UPnP meta-model yang diperlukan. Namun, aturan yang sangat
sederhana. Misalnya, untuk menyajikan nama blok bangunan, kami
menggunakan nama perangkat UPnP. Jelas, deskripsi layanan berbasis XML
lainnya (misalnya, WSDL, DPWS) akan menggunakan proses yang sama.
Selain representasi grafis, kode sumber (kelas Java untuk pemanggilan
layanan) juga dihasilkan untuk setiap deskripsi layanan UPnP. Jelas, bahasa
pemrograman lainnya juga dapat digunakan. Setelah semua deskripsi layanan
diubah menjadi model layanan grafis langkah pemodelan dapat dimulai.
2. Permodelan
Menggunakan taksonomi layanan itu akan mungkin untuk model ke model
aplikasi berbasis layanan baru menggunakan model layanan pada setiap
tingkat hirarki. Semakin tinggi tingkat hirarki yang lebih platform-independen
model akan. Dengan model tingkat tinggi, kita berarti model aplikasi berbasis
layanan yang dibangun menggunakan model layanan platform-independen di
tingkat 1 dan di atas dari hirarki dalam taksonomi layanan. Dari model-tingkat
tinggi dari aplikasi layanan berbasis kode sumber yang berbeda dapat
dihasilkan. jelas,

Gambar 5.12: Model ARCS dari aplikasi baru. Layanan ini termasuk model merinci
struktur aplikasi, sedangkan interaksi antara model layanan menentukan perilaku.

itu akan dibatasi oleh jumlah kode sumber mengikat ke model layanan yang
disimpan di perpustakaan layanan.
Menggunakan ARCTIS, aplikasi berbasis layanan dapat ditetapkan sebagai
diagram blok bangunan. Perilaku aplikasi berbasis layanan baru didefinisikan
oleh interaksi antara blok bangunan, yang dalam hal ini didefinisikan
menggunakan node aktivitas didefinisikan dalam UML 2.0. Dengan demikian,
semantik mengikuti semantik UML 2.0 diagram aktivitas. Gambar 5.12
menunjukkan model ARCGIS dari aplikasi layanan berbasis didefinisikan
dalam skenario. Ada empat blok bangunan yang mewakili layanan yang ada
yang berbeda disebutkan dalam skenario. Dalam model ini, model layanan
yang diambil dari tingkat 1 dari hirarki layanan. Ini berarti bahwa mereka
mungkin memiliki beberapa implementasi yang berbeda.
Dalam ARCTIS, aplikasi berbasis layanan dapat, lagi, dikemas dan disajikan
sebagai sebuah blok bangunan baru. Hal ini memungkinkan kita untuk model
layanan yang disediakan baru didefinisikan dalam skenario. Sebagaimana
didefinisikan dalam skenario aplikasi berbasis layanan baru akan
menyediakan dua layanan baru (misalnya, pengaturan layanan dan

mendapatkan-Layanan Konfigurasi). Dalam ARCTIS, ini dapat ditentukan


dengan mendefinisikan parameter baru (misalnya, port). Jelas, ini blok
bangunan baru dapat digunakan untuk membangun sebuah diagram blok
bangunan baru sebagai spesifikasi baru dari sistem perangkat lunak. Ini adalah
cara bagaimana perkembangan inkremental dari aplikasi besar dapat
dilakukan dalam ARCTIS.

3. Generasi kode dan pengadaaan


Untuk menggambarkan generasi kode di PMG-pro, kita menggunakan bahasa
pemrograman Java. Untuk menghasilkan kode dari struktur blok diagram dan
blok bangunan yang digunakan. Dari diagram blok bangunan aplikasi utama
(kelas) yang dihasilkan. Nama kelas didefinisikan menggunakan nama
diagram blok bangunan.
Dari masing-masing blok bangunan, satu objek yang dipakai. Sejak blok
bangunan dalam skenario ini adalah platform independen, yang benda yang
dipakai yang tergantung pada pilihan platform yang. Listing 5.4 menunjukkan
contoh kode ketika platform UPnP dipilih untuk generasi kode untuk
menghasilkan langkah. Hanya kelas yang mengimplementasikan layanan
UPnP yang dipakai.

Kode dari bagian kelakuan diambil dari node aktivitas. Untuk ini kita
mengadaptasi metode generasi disajikan dalam [10]. Berkenaan dengan
metode mereka, sebuah blok bangunan ARCTIC dapat dianggap sebagai suatu
entitas yang mengeksekusi tindakan eksternal. Misalnya, untuk node
keputusan (dengan masukan suhu udara) menghasilkan kode yang
ditunjukkan pada Listing 5.5.

Untuk contoh skenario, dua layanan baru yang disediakan sebagai layanan
UPnP. Untuk ini, kode UPnP harus ditambahkan. Kami telah menerapkan
kode generator untuk menghasilkan kode untuk skenario aplikasi. Gambar
5.13, adalah screenshot dari layanan UPnP berjalan. Kami menggunakan
perangkat lunak Spy disediakan oleh Intel Alat untuk teknologi UPnP [46].
Hal ini dapat dilihat bahwa aplikasi baru (layanan komposit) menyediakan
dua layanan UPnP yang merupakan GetConfiguration()dan
SettingService().
5.5.3.5 Ringkasan Studi Kasus
Aplikasi perangkat lunak cenderung lebih layanan berbasis. Menjadi layanan
berbasis, dua hal yang diperlukan: cara untuk membuat layanan yang
sederhana dan mekanisme untuk menggambarkan interaksi dari layanan
tersebut sederhana. Selain itu, dengan pendekatan pengembangan modeldriven kita perlu menghadirkan layanan dan interaksi mereka grafis.

Gambar 5.13: Layanan komposit baru pada saat run-time. Aplikasi layanan berbasis baru
disediakan sebagai layanan UPnP baru.

Beberapa implementasi yang berbeda dari konsep layanan orientasi ada. PMG-pro
menyajikan layanan sebagai sebuah blok bangunan dapat digunakan kembali
independen yang pelaksanaan konsep. Sebuah blok bangunan mengacu pada kelas
implementasi yang bertindak sebagai proxy untuk layanan beton yang
sebenarnya. Interaksi antara blok bangunan yang didefinisikan menggunakan
diagram aktivitas. Sebuah blok bangunan mungkin juga mencakup blok bangunan
lainnya. Dengan pendekatan ini, kecil, diverifikasi, dan divalidasi dikemas
diagram aktivitas (blok bangunan) dapat digunakan untuk membangun secara
bertahap diagram blok bangunan besar menghadirkan aplikasi perangkat lunak
yang kompleks.