Perbandingan kedua pendekatan

Baik OOHDM dan WebML menyediakan abstraksi pemodelan

generik, yang dapat dipetakan ke model implementasi apa
pun. Skema hypertext WebML memadukan dua aspek yang terpisah
{komposisi dan model navigasi. Yang pertama sangat mirip dengan
tampilan yang dirancang di OOHDM karena menentukan komposisi
node navigasi atom atau komposit. Yang terakhir ini menyerupai
skema konteks navigasi OOHDM karena ia mendefinisikan
bagaimana item navigasi dapat diakses melalui struktur navigasi.

WebML memang merupakan model platform-independen, yang

bagaimanapun juga menggunakan cara standar untuk
mendeskripsikan item navigasi, interkoneksinya dan parameter yang
lewat, eksposisinya dalam antarmuka pengguna, sehingga
sekumpulan aturan dapat didefinisikan secara
otomatis. menerjemahkan model yang tidak bergantung platform ke
dalam menjalankan kode.

Jalur Navigasi untuk Majalah Online

Gambar 5.9 memberikan contoh spesi kasi lintasan navigasi untuk

contoh mag-azine online kami. Diagram tersebut mengilustrasikan
jalur alternatif di mana pengguna dapat mencapai node navigasi
cerita , di mana dia dapat mengakses data dari cerita yang dipilih dan
menavigasi melalui kumpulan cerita dalam konteks yang ditentukan
oleh jalur navigasi yang diikuti sebelumnya. Seperti juga ditentukan
dalam skema konteks navigasi OOHDM yang diilustrasikan pada
Gambar 5.6, navigasi dimulai dari menu utama , yang dalam hal ini
dimodelkan sebagai keadaan sederhana yang dapat diakses dari
pseudostate awal. Setiap indeks dihitung melalui tindakan entri di
negara bagian yang sesuai.

Pengguna dapat memilih item indeks, dan pilihan ini merupakan

transisi ke status Story yang menetapkan nilai parameter
groupby, sehingga menentukan konteks khusus untuk penelusuran
story dalam status Story. Tindakan AuthorObj.get Stories .getFirst
lalu mengambil kumpulan cerita penulis, dan mengembalikan
pengenal cerita pertama, yang akan menjadi titik awal untuk
menjelajahi koleksi dalam status Story. Metode getFirst mengambil
cerita pertama dalam koleksi berbasis tipe, yang akan menjadi titik
awal navigasi dalam status Story. Dari menu utama, transisi
lain, yang diberi warna merah oleh acara , memungkinkan pengguna
mengakses beberapa cerita yang disorot.

Ini mengangkut parameter yang disorot, yang mewakili pilihan

pengguna untuk menelusuri koleksi cerita yang disorot. Mirip dengan
transisi lain yang dijelaskan di atas, transisi juga menetapkan nilai
parameter groupby . Setelah status Story tercapai melalui salah satu
jalur navigasi di atas, pengguna dapat kembali ke Menu Utama , atau
dapat menggulir koleksi cerita . Parameter arah dalam transisi
Navigasi menunjukkan arah pengguliran yang dipilih oleh pengguna.

Metode Story.scroll mengambil cerita yang akan

ditampilkan . Batasan tentang bagaimana pengguna dapat beralih di
antara konteks cerita yang berbeda, seperti yang telah dibahas untuk
contoh OOHDM, juga dipertahankan. Ingatlah bahwa dalam skema
konteks OOHDM batasan ini diwakili oleh garis putus-putus yang
membatasi konteks di mana pengguna diizinkan untuk beralih. Ini
memungkinkan pengguna yang menjelajahi koleksi berbasis penulis
untuk beralih ke koleksi berbasis tipe.

Seperti yang dilambangkan dengan dua elips kecil yang

terhubung, Story adalah status gabungan. Gambar 5.10
menggambarkan diagram yang menspesifikasikan detailnya yang
terbuka. Status terdiri dari dua substrat navigasi bersamaan, masing-
masing mewakili tampilan pada entitas konten. Tindakan entri
mengambil dan menampilkan objek Story yang melewati transisi
yang dilalui.

Jika detail dari substrat master diketahui, sinkronisasi dengan region

lain yang disajikan secara bersamaan dapat dilanjutkan.
Perhatikan bahwa dua jenis sinkronisasi digunakan, pemisahan
tradisional menjadi komputasi serentak, ditampilkan sebagai persegi
panjang hitam berlapis, dan kronisasi sinkronisasi antar kawasan
yang dipisahkan oleh garis putus-putus.
Antarmuka dan pengumpulan data

Sejauh ini kami telah mengilustrasikan desain jalur navigasi, tanpa

membahas di mana dan bagaimana pengumpulan data dan metode
yang digunakan dalam tindakan harus didefinisikan. Dari perspektif
ini, desain jalur navigasi dapat didekati dengan dua cara.
Salah satu kemungkinannya adalah memulai dengan tampilan tingkat
tinggi pada status navigasi, sebagai penyempurnaan model tugas dari
fase analisis persyaratan. Perbaikan bertahap dapat diterapkan untuk
menguraikan keadaan tingkat yang lebih tinggi menjadi
substrat. Namun, desain rinci dari jalur navigasi juga berkaitan
dengan spesifikasi operasi rendering, untuk mengidentifikasi metode
yang akan dipanggil dan objek yang akan dipakai ketika keadaan
tertentu dimasukkan, dibiarkan, atau dimanipulasi secara
internal. Oleh karena itu, bagian integral dari desain jalur navigasi
adalah penerapan model konseptual yang didefinisikan selama
analisis kebutuhan dengan koleksi, antarmuka, dan metode yang
mengungkapkan rincian lebih lanjut tentang logika bisnis aplikasi .
Pendekatan lain adalah untuk membangun model jejak navigasi di
atas tampilan navigasi, sebagai aktivitas terakhir dalam desain
navigasi, serupa dengan apa yang dilakukan dalam skema konteks
navig Interaksi Layanan Web

Seperti yang telah diperkenalkan di Bab 2, banyak penekanan telah

dikhususkan untuk masalah teknologi, arsitektur, dan
implementasi. Namun, jika kami secara khusus mempertimbangkan
situasi di mana interaksi dengan layanan Web didorong oleh
pengguna, yaitu, pengguna memberikan masukan yang diperlukan
dan mengambil keputusan yang diperlukan untuk memandu
pelaksanaan keseluruhan proses yang didukung oleh layanan
Web, maka kami dapat dengan mudah menyadari bahwa interaksi
layanan Web hanya menyediakan aspek desain navigasi yang
berbeda. "Untuk mendeskripsikan elemen utama interaksi layanan
Web untuk dipertimbangkan pada tingkat konseptual, kami akan
mengilustrasikan abstraksi pemodelan yang diperkenalkan oleh
WebML, yang telah diperluas dengan beberapa \ unit layanan Web "
yang mengimplementasikan operasi WSDL layanan Web SOAP /
WSDL.
Layanan Web

Misalkan untuk memperluas aplikasi Web majalah online dengan

kemungkinan untuk mengambil cerita yang ditulis oleh seorang
penulis dari layanan Web jarak jauh . Menurut skema, pengguna
dapat menavigasi ke halaman Kisah Pencarian, di mana unit entri
memungkinkannya untuk memasukkan kata kunci pencarian untuk
cerita dari penulis yang dipilih. Unit SearchStories memodelkan
operasi respons permintaan WSDL untuk interaksi dengan layanan
Web jarak jauh.asi OOHDM.
Pengenal yang dihasilkan oleh unit data AuthorDetails dan kata kunci
pencarian yang dimasukkan oleh pengguna melalui unit entri
EnterData), pesan permintaan dibuat dan dikirim ke operasi
SearchStories yang diekspos oleh layanan Web. Pesan tanggapan
yang dihasilkan oleh layanan Web dan dikirim kembali ke aplikasi
Web berisi daftar cerita yang memenuhi kriteria pencarian.

Desain Presentasi Abstrak

Desain presentasi abstrak menggambarkan komposisi elemen untuk

tampilan informasi dan pemanggilan fungsi dalam antarmuka
pengguna Web.

Gambar 5.15 mengilustrasikan antarmuka pengguna halaman entri

Amazon.com. Kotak persegi panjang bulat mengelilingi elemen
antarmuka pengguna komposit, yang terdiri dari widget konkret yang
berbeda, seperti item menu, tautan, grafik para-teks, tombol, dan
gambar. Gambar 5.16 menggambarkan model presentasi untuk
halaman yang sama, yang merepresentasikan struktur, dalam istilah
widget abstrak, dari empat elemen antarmuka pengguna yang disorot
pada Gambar 5.15. Elemen Menu Departemen berisi beberapa
penggerak sederhana yang sesuai dengan link untuk menavigasi ke
menu departemen.
Struktur Menu Utama dan elemen Cari & Beli tidak ditampilkan
dalam gambar. Menu Atas akan terdiri dari aktivator sederhana, satu
untuk setiap tautan yang tertanam di bilah navigasi. Di atas elemen
ini terdapat tautan ke penyedia layanan Amazon lokal. Kami
memodelkannya melalui elemen antarmuka komposit Amazon
Lokal. Semua elemen lainnya adalah iklan untuk sorotan yang
berbeda. Seperti yang ditunjukkan untuk elemen Sorotan1, struktur
bagian dalam setiap sorotan dibuat dari Judul peserta pameran
sederhana, ditambah elemen gabungan Gambar dan
Deskripsi, keduanya terbuat dari peserta pameran sederhana dan a
aktivator sederhana, mewakili jangkar untuk tautan ke deskripsi yang
lebih detail.
(mirip dengan konteks Sorotan yang digambarkan dalam contoh
OOHDM pada Gambar 5.7), ke komposisi unit konten yang
menentukan navigasi sorotan (mirip dengan unit hiperteks WebML
pada Gambar 5.8), atau hanya ke kelas konten, untuk mewakili
presentasi itu elemen sebenarnya sesuai dengan multiplisitas item
konten. Jumlah sorotan per node navigasi, dan kondisi yang
menentukan konten mana yang harus dibuat saat merender halaman
Web karena itu diwarisi dari desain navigasi.
Seperti yang dapat dicatat dari contoh sebelumnya, desain widget
abstrak menyediakan sarana untuk menentukan jenis widget mana
yang dapat mewakili konten dan fungsi yang diidentifikasi selama
desain navigasi, dan bagaimana mereka dikelompokkan ke dalam
halaman Web. Teknik ini mengambil abstrak dari navigasi dan logika
komposisi konten dan lebih berfokus pada komposisi murni elemen
presentasi dalam halaman. Dengan demikian, ini dapat berguna jika
widget abstrak dipetakan ke elemen desain navigasi. Secara khusus,
meskipun dapat menjadi redundan bila digunakan dalam kombinasi
dengan teknik yang telah memungkinkan spesi kasi komposisi
halaman (misalnya, desain hypertext WebML), ini bisa sangat
berguna bila digabungkan dengan teknik yang tidak membahas
pengelompokan konten. elemen dan fungsi dalam halaman Web
akhir (misalnya, desain tampilan navigasi OOHDM). Dalam hal ini,
widget abstrak digunakan sebagai fasad atau dekorator tampilan
navigasi, memperkayanya dengan karakteristik presentasi.

Ruang interaksi

Pada Bagian 4.4.2, kami telah mendefinisikan dan menunjukkan

bagaimana mendapatkan ruang interaksi abstrak dari model tugas,
dan bagaimana menghubungkannya ke kelas domain aplikasi. Pada
tahap desain, spesi kasi ruang interaksi selanjutnya dapat dipersempit
dan diperluas melalui elemen berikut [NOP + 06]:
Elemen masukan: tentukan elemen presentasi yang
memungkinkan pengguna memasukkan beberapa masukan.
 Elemen keluaran: menentukan elemen presentasi yang membuat
beberapa keluaran dari suatu sistem.
Tindakan: tentukan elemen presentasi yang memungkinkan
pengguna untuk berinteraksi dengan aplikasi dan untuk
menjalankan tindakan tertentu.
Hubungan navigasi: tentukan navigasi antar ruang interaksi.
Input, output, dan tindakan dapat diturunkan dari model tugas
yang didefinisikan selama rekayasa persyaratan. Tindakan mewakili
tugas; elemen input merepresentasikan parameter input yang diproses
oleh tindakan; elemen output merepresentasikan data yang
ditampilkan dan digunakan oleh pengguna untuk menghasilkan input.
Tindakan biasanya direpresentasikan pada abstraksi tingkat tinggi,
dalam bentuk label yang dapat dipahami pengguna, tanpa referensi
apa pun ke metode objek aplikasi yang terkait dengannya. Oleh
karena itu, perbaikan tambahan diperlukan untuk membuat model
presentasi lebih dekat dengan implementasi. Untuk tujuan ini, ruang
interaks Tampilan Data Abstrak

Abstrak Tampilan Data adalah ekstensi dari model perangkat lunak

berorientasi objek, diperkenalkan untuk menentukan objek
antarmuka pengguna dan hubungannya dengan objek
aplikasi. Hubungan generalisasi / spesialisasi juga dapat digunakan
untuk komposisi ADV, sehingga mendorong penggunaan kembali
beberapa objek antarmuka berulang, seperti bilah navigasi
global. Hubungan ini tidak hanya memodelkan bahwa ADV
menyediakan antarmuka pengguna untuk pemiliknya, tetapi juga
bahwa ADV dapat memicu beberapa metodenya. ADV telah diadopsi
untuk spesifikasi antarmuka pengguna Web dalam konteks
metodologi OOHDM .

Notasi yang diadopsi menggunakan kotak untuk mewakili ADV atau

pemilik ADV, garis putus-putus untuk mewakili permintaan
layanan, dan garis padat untuk mewakili ketentuan layanan. Yang
menarik dalam contoh ini adalah definisi hubungan antara ADV
Highlight dan objek pemiliknya, Product, untuk merepresentasikan
pemanggilan metode pemilik untuk mengambil data yang akan
ditampilkan oleh elemen antarmuka. Selain menentukan aspek
struktural, seperti pada contoh di atas, ADV juga membahas aspek
perilaku, untuk memodelkan bagaimana antarmuka pengguna
mengubah keadaan mereka sebagai reaksi terhadap tindakan
pengguna. Contohnya adalah ketika pengguna mengklik lampu sorot
di halaman entri Amazon untuk mendapatkan deskripsi produk yang
lebih detail.

Bagan negara dapat digunakan untuk memodelkan transisi

keadaan. Demi kesederhanaan, kami menggunakan anotasi tekstual
untuk menentukan efek mengklik sorotan . HideHighlight). Sebagai
efek samping, metode ProductDetails dipanggil untuk mengelola
perubahan tampilan antarmuka pengguna.
Tampilan baru untuk tampilan deskripsi rinci dimodelkan melalui
ADV tambahan, , mewakili antarmuka tempat informasi lebih lanjut
tentang produk, seperti Harga dan Status, ditampilkan.

Desain Presentasi Beton

Desain presentasi beton berkaitan dengan komposisi elemen

antarmuka konkret dalam halaman Web. Metode UWE mengusulkan
model presentasi berbasis UML , di mana beberapa stereotip kelas
digunakan untuk memodelkan elemen presentasi, seperti fragmen
teks, gambar, audio, video, jangkar, tombol, dan formulir, yang juga
dapat disarangkan ke model struktur hierarki halaman Web. esain
Presentasi Beton

Desain presentasi beton berkaitan dengan komposisi elemen

antarmuka konkret dalam halaman Web. Elemen komposit, yang
disebut objek presentasi, digunakan untuk memodelkan komposisi
sembarang apa pun dari objek sebelumnya. Perilaku setiap objek
antarmuka pengguna juga dapat dijelaskan oleh mesin negara.
Perhatikan bahwa pemetaan serupa dari desain presentasi abstrak ke
beton disarankan dalam konteks metode OOHDM . Elemen
presentasi beton, mirip dengan yang diusulkan oleh model
UWE, didefinisikan dalam ontologi.

Desain Arsitektur

Desain arsitektur bertujuan untuk menangkap keputusan penting

tentang organisasi sistem perangkat lunak, untuk menyoroti
subsistem penyusun, komponen dan interaksi. Dalam aplikasi
Web, ini berarti menangani beberapa pilihan tentang logika bisnis
aplikasi, untuk menetapkan model referensi untuk kegiatan
implementasi. Pendekatan yang umum digunakan adalah dengan
mendefinisikan dekomposisi perangkat lunak aplikasi, untuk
mewakili distribusi komponen pada tingkatan aplikasi yang
berbeda , dan hubungan yang didefinisikan di antara mereka .
Pada bagian ini, kami akan memberikan gambaran umum tentang
masalah utama yang berhubungan dengan desain arsitektur, dengan
meninjau dua metode terkenal.

Ekstensi Aplikasi Web Conallen untuk UML

Pada tahun 2000 Jim Conallen mengusulkan sebuah teknik untuk

desain arsitektur, yang menggunakan UML dengan tambahan
semantik dan batasan untuk memodelkan elemen arsitektur spesifik
Web . Menurut metode ini, desain arsitektur dimulai dengan definisi
diagram komponen, yang merepresentasikan komponen
aplikasi, antarmuka, hubungannya, dan kelas dari model domain
yang mewujudkannya. Selain mengidentifikasi kelas dan
kolaborasi, aktivitas desain juga mencakup partisi komponen menjadi
objek yang berada di tingkatan aplikasi yang berbeda. Distribusi
objek
1565 Desain Aplikasi Web di atas klien dan sisi server adalah fokus
utama, tetapi lapisan aplikasi lain, jika ada, dapat dipertimbangkan
juga.
Salah satu hal baru yang utama dari metode ini adalah spesifikasi
halaman Web sebagai elemen arsitektur. Menjadi bagian dari aplikasi
front-end, halaman Web adalah elemen fundamental dalam desain
navigasi dan presentasi. Bagaimanapun juga, halaman Web mewakili
penghubung antara browser dan semua subsistem lain dari aplikasi
Web; Oleh karena itu, mereka menawarkan kesempatan untuk
menangkap elemen arsitektur utama dan kolaborasi mereka. Dari
perspektif pemodelan, halaman Web dapat dianggap sebagai objek
dan, dengan demikian, dapat ditentukan, misalnya, melalui kelas
UML. Namun, notasi UML tradisional tidak akan menangkap
beberapa fitur yang khusus untuk aplikasi Web.

engilustrasikan contoh pemodelan berdasarkan ekstensi

Conallen, yang mewakili elemen arsitektural yang ikut campur dalam
eksekusi komponen Home.jsp, halaman JSP yang menerbitkan berita
yang disaring sesuai dengan preferensi pengguna . Selain memiliki
konten dinamis yang disematkan dalam HTML, kelas ini juga
menetapkan penggunaan skrip sisi klien, seperti yang terlihat dari
operasi dan variabel yang ditentukan. Seperti yang ditunjukkan pada
Gambar 5.21, setiap halaman server dan halaman klien direalisasikan
oleh komponen yang mewakili pemetaan ke URL.

WebSA menampilkan tiga model arsitektur

Model konfigurasi merinci komponen dan konektor yang menyusun

aplikasi. Model integrasi menggabungkan tampilan arsitektural, yang
ditentukan oleh dua model sebelumnya, dengan tampilan fungsional
yang mengekspresikan data, hypertext, dan desain
Presentasi. Pertama, model konseptual dipetakan ke model
platform independen, yang disebut model integrasi, yang
menggabungkan elemen fungsional dan arsitektural dengan
mendefinisikan pemetaan di antara keduanya. Model integrasi
kemudian dapat menerima transformasi dalam model implementasi
apa pun, memenuhi persyaratan platform eksekusi yang mungkin.

Model konfigurasi WebSA mendefinisikan arsitektur aplikasi Web

dengan menggunakan elemen yang mewakili komponen dan
konektor perangkat lunak yang berbeda.
Model Konfigurasi

Contoh komponen Web adalah halaman server sebagai wadah umum

untuk beberapa fungsionalitas sisi server. Contoh WebPart adalah
bagian dari halaman server yang melayani tujuan komputasi
menu. Sambungan dibuat melalui WebPorts, yang merupakan titik
interaksi antara WebComponent, atau WebPart, dan
lingkungannya. Contoh entitas WebPattern adalah pola Model-View-
Controller yang terkenal.

Gambar 5.23 menggambarkan contoh model konfigurasi untuk

arsitektur yang mirip dengan yang digambarkan pada Gambar
5.20. Komponen Halaman Klien dan Halaman Server digambarkan
sebagai templat umum. Browser Web menerima permintaan
pengguna dan menampilkan Halaman Klien yang sesuai. Komponen
MVC bereaksi terhadap pesan tersebut melalui Screen Data
WebPort, yang bertugas mengambil.
dapat, misalnya, dikombinasikan dengan jalur navigasi (lihat bagian 5.7.2 sebagai contoh), di
mana tindakan status dan transisi secara tepat terikat ke metode objek.
Contoh model konfigurasi WebSA, untuk arsitektur yang mirip dengan yang diilustrasikan pada
Gambar 5.20 dan 5.21 data dari Halaman Server. Komponen MVC, selanjutnya, meminta
antarmuka dari Model yang mengumpulkan data yang diperlukan untuk antarmuka
pengguna. Pola dan komponen selanjutnya dapat dihubungkan ke model konfigurasi. Model
konfigurasi merepresentasikan desain abstrak untuk mesin run-time generik yang mampu
menginterpretasikan model fungsional aplikasi Web.

Mesin WebRatio menggabungkan tampilan fungsional yang dijelaskan melalui model desain
WebML menjadi model eksekusi yang dapat diinterpretasikan oleh mesin WebRatio.

Sejauh ini kita telah melihat desain aplikasi Web tradisional dengan thin client dan
sebagian besar logika aplikasi

Sekarang mari kita lihat kelas lebih lanjut dari aplikasi yang lebih interaktif dan lebih
responsif, yang umumnya dikenal sebagai Rich Internet Applications . Baru-baru ini, dengan
diperkenalkannya AJAX, sebagian besar aplikasi Web 2.0, terutama aplikasi sosial terkenal
seperti Facebook atau Google Desktop, beralih ke fungsi interaktif, serupa dengan yang
disediakan oleh aplikasi desktop. Mekanisme untuk meminimalkan transfer data klien-server
dengan memindahkan manajemen interaksi dan lapisan presentasi dari server ke klien. Tabel 5.1
merangkum konsep-konsep primitif baru yang diperkenalkan pada tingkat yang berbeda.

WebML memperkenalkan perbedaan antara objek sisi klien dan sisi server, baik dalam model
data maupun dalam model hypertext. Mari kita ingat contoh yang diilustrasikan pada Gambar
5.8 dan mari kita memodifikasi Halaman Utama dengan memperkenalkan beberapa objek sisi
klien. Seperti yang ditunjukkan oleh label CS, Halaman Beranda sekarang menjadi halaman sisi
klien. " Lebih khusus lagi, kondisi pemilih \ Teks berisi SearchKey "dijalankan di sisi
server, mengikuti semantik WebML konvensional yang sudah dijelaskan di Bagian 5.4. "
Kondisi \ Date = PrefDate" dievaluasi di sisi klien, untuk lebih lanjut menyaring instance cerita
yang diambil melalui pemilih sisi server.

Navigasi tautan dari unit Tanggal Pilihan Entri malah menyebabkan evaluasi sisi klien dari
kondisi pemilih di daftar cerita yang sebelumnya dihitung di sisi server. 10Untuk mencegah
konflik dengan pembahasan aplikasi pengenal konteks di Bagian 6.2.3, di sini kita menggunakan
label \ CS " daripada label \ C "yang digunakan oleh penulis di .

Ekstensi ADRIA

ADRIA mengusulkan perluasan desain analisis berorientasi objek dengan model tugas dan ruang
interaksi untuk memodelkan fitur RIA seperti komputasi sisi klien dan sinkronisasi antara objek
sisi klien dan server. Mari kita ingat contoh dari Gambar 5.10, yang menjelaskan bagaimana
detail cerita majalah online dihitung selangkah demi selangkah dengan menyinkronkan dua
wilayah presentasi secara bersamaan. Angka tersebut belum menentukan apakah objek yang
dipanggil harus dihitung di klien atau di sisi server. Pembaca yang tertarik untuk mengetahui
lebih banyak detail tentang ekstensi ADRIA untuk RIA merujuk ke untuk lebih jelasnya.

11Penjelasan rinci tentang transformasi model dilaporkan di bagian 7.2.3 dan proses bisnis, dan
skenario interaksi untuk kelompok pengguna yang berbeda. Model ini mematuhi metamodel
WebRE yang sesuai dengan Departemen Keuangan , dan sesuai dengan CIM dalam paradigma
MDA. UWE menerapkan pemisahan masalah yang sama yang telah banyak dibahas dalam buku
ini, yang menjelaskan model yang berbeda untuk fungsionalitas, konten, navigasi, dan masalah
presentasi. Untuk pemodelan arsitektur, UWE mengandalkan WebSA , yang dijelaskan sebagai
metamodel UML yang sesuai dengan MOF.

Setelah model ini dibuat, UWE mengusulkan langkah perantara untuk menggabungkan mereka
dalam apa yang disebut model gambaran besar, yang biasanya dicapai dengan menerapkan
transformasi model. Semua model yang disebutkan di atas sesuai dengan PIM dalam paradigma
MDA. Satu pendekatan terdiri dari penambahan detail arsitektural sedini mungkin, melengkapi
model fungsional pada tingkat PIM. Model arsitektural dapat diintegrasikan dengan model
gambaran besar, memperoleh model yang terintegrasi, juga terletak pada level PIM.

Semua model UWE dijelaskan dalam metamodel UWE, yang didefinisikan menggunakan MOF
sebagai perpanjangan dari metamodel UML. Pada bagian 7.2.3, kami membahas secara rinci
tentang transformasi model.

Model Hypermedia Berlapis

Lapisan dalam model tersebut sesuai dengan dimensi pemodelan yang berbeda, yaitu
penyimpanan, struktur, dan presentasi. Model Referensi Dexter adalah salah satu contoh yang
paling terkenal, mungkin model yang paling berpengaruh. Ini mengusulkan arsitektur referensi
yang menyediakan kosakata umum untuk perbandingan sistem hypertext yang berbeda dan
model. Seperti yang ditunjukkan pada Gambar 5.

" Ini mewakili jaringan hypertext node-link sebagai \ database "yang terdiri dari hierarki
komponen yang saling berhubungan dengan link. Model tersebut hanya mencakup mekanisme
presentasi dasar, yang menangkap esensi interaksi. Lapisan ini tidak dielaborasi dalam model
Dexter, dan dibiarkan terbuka untuk semua tipe data dan struktur yang mungkin dapat
dimasukkan dalam node hypertext.
Ringkasan

Dalam bab ini kami telah memberikan gambaran umum tentang teknik desain utama dan
masalah yang ditangani oleh desain aplikasi Web. Teknik desain mencerminkan kebutuhan yang
berasal dari lingkungan World Wide Web dan teknologi yang mendasarinya. Dengan desain alur
kerja, kita telah membahas diagram aktivitas sebagai salah satu abstraksi yang menangkap alur
kerja untuk aplikasi Web. Selain model alur kerja, kami juga telah menyebutkan konsep alur
kerja yang dapat diintegrasikan ke dalam pemodelan navigasi.

Dalam desain data, kami sebagian besar berfokus pada penyempurnaan model domain aplikasi
menjadi model data relasional, tetapi kami menekankan bahwa ini bukan satu-satunya model
manajemen data yang sesuai di Web. Sudut pandang desain khusus domain web telah
didiskusikan terutama menggunakan contoh skema hypertext WebML, yang mengintegrasikan
komposisi navigasi dan konteks ke dalam satu model. Kami telah menghubungkan desain jalur
navigasi ke antarmuka dan kumpulan data sebagai struktur akses utama yang digunakan untuk
menghubungkan abstraksi jalur navigasi ke konten. Desain presentasi abstrak dibahas pada
tampilan data abstrak seperti yang digunakan oleh OOHDM, widget abstrak yang biasa
digunakan dalam desain antar muka pengguna, dan ruang interaksi yang digunakan untuk
menangkap objek interaksi pada tingkat antarmuka pengguna.

Desain presentasi beton memerlukan desain presentasi abstrak ke model yang lebih dekat dengan
antarmuka pengguna yang biasanya ditampilkan oleh browser Web standar. Kami telah
membahas ekstensi UML untuk aplikasi Web yang mendukung komponen sisi server dan sisi
klien, seperti skrip, halaman, dan kelas. Kami juga mengilustrasikan teknik desain WebSA, yang
merupakan teknik berbasis model, berdasarkan gagasan integrasi dan transformasi tampilan
desain tradisional dalam rekayasa aplikasi Web dengan konfigurasi komponen dan tampilan
integrasi di mana pola arsitektur yang berbeda seperti Model-View- Pengontrol dapat langsung
digunakan. Aplikasi Internet yang Kaya menyajikan persyaratan tambahan untuk metode
rekayasa Web.

Kami membahas perluasan metode yang ada untuk melayani secara spesifik untuk RIA. Pada
bagian terakhir dari bab ini kita telah membahas perspektif historis tentang desain aplikasi Web
yang berakar pada komunitas desain hypermedia. Kami merujuk pembaca ke Metode Desain
Hypermedia Berorientasi Subjek , yang menggabungkan node struktur akses tampilan
berorientasi objek sebagai abstraksi tambahan. Model Teralis untuk spesifikasi semantik
penelusuran dengan Jaring Petri dan Jaring Petri berwarna bisa menjadi model lain yang
digunakan untuk desain jalur navigasi.

Web Composition Markup Language adalah model desain arsitektur berbasis XML lainnya yang
memanfaatkan abstraksi komponen untuk aplikasi Web.