Apakah Contoh Khas Fungsi?

Sebuah fungsi WebApp dapat menjadi sesuatu yang sederhana seperti menerapkan menu pull-
down atau serumit melakukan perhitungan canggih diperlukan untuk mendukung alur kerja
bisnis. Untuk menggambarkan spektrum kompleksitas fungsional, pertimbangkan beberapa
contoh:
Contoh 1: Client-side dukungan interaksi. Webapps sering menggabungkan fungsi client-side
ditujukan untuk memberikan dukungan untuk navigasi pengguna dan akses informasi (lihat
Gambar 11.1a). Contoh yang paling umum ini adalah menu drop-down, rollovers, dan
preloading gambar.
Contoh 2: Client-side manajemen informasi. Webapps kadang-kadang menerapkan kompleks
sisi klien manipulasi informasi (lihat Gambar 11.1b). Contohnya termasuk antarmuka berbasis
browser untuk aplikasi fungsional yang mendasari, dan aplikasi yang melibatkan manipulasi
informasi yang kompleks, termasuk preloading data dan aplikasi Ajax.
Contoh 3: Server-side konten penanganan. Webapps dapat menggabungkan fungsi server-side
untuk mengelola konten dinamis dan cepat berubah (lihat Gambar 11.1C). Contoh di sini akan
menjadi forum diskusi, wiki, dan situs menyajikan konten dari acara live (misalnya, situs berita,
situs olahraga). Contoh 4: manajemen Server-side set data yang besar. Webapps dapat
menggunakan fungsi server-side untuk mengelola besar set data yang kompleks (lihat Gambar
11.1d). Contohnya termasuk katalog produk, repositori dokumen, perpustakaan, dan daftar
personil.
Contoh 5: Proses dan / atau dukungan ow workfl. Webapps sering menerapkan proses
komputasi atau transformasional tertentu yang mendukung entri prosedural data, manajemen
transaksi, atau mengalir bisnis workfl (lihat Gambar 11.1e). Contohnya termasuk belanja
online, proses pendaftaran, dan survei online.

Dapat Fungsi dikategorikan?

Contoh-contoh yang baru saja kita bahas menggambarkan keragaman fungsi WebApp, tetapi
contoh saja tidak memberikan bimbingan sien suffi untuk merancang fungsi ini. Sebagai
langkah pertama dalam diskusi kita desain fungsional, kami akan membangun kategori fungsi,
memahami atribut masing-masing kategori, dan kemudian mempertimbangkan bagaimana
masing-masing ditujukan sebagai bagian dari proses desain. fungsi webapp
 GAMBAR 11.1
dapat ed klasifi menjadi enam kategori utama yang diringkas dalam Tabel 11.1 (bersama
dengan contoh singkat untuk masing-masing dari SafeHomeAssured.com).
Perlu dicatat bahwa kategori Fungsi User-Tingkat tidak berarti fungsi client-side (yaitu,
dilaksanakan dekat dengan pengguna). Demikian pula, kategori Fungsi Aplikasi-Level tidak
berarti fungsi server-side. Di mana dan bagaimana fungsi diimplementasikan pada dasarnya
adalah masalah yang diatasi ketika arsitektur fungsional dirancang. Kedua kelompok yang luas
berhubungan dengan maksud dari fungsi-dan karenanya, ketika (bukan bagaimana atau di
mana) Anda harus mempertimbangkan itu.
Misalnya, dengan SafeHomeAssured.com, format informasi produk untuk presentasi kepada
pengguna akan dianggap sebagai kategori 1B (Informasi Dukungan Pengguna) tapi mungkin
juga terjadi dalam sistem manajemen konten (CMS) di server. Sebaliknya, penebangan
tindakan pengguna dalam berinteraksi dengan aplikasi (termasuk tidak hanya tautan yang
dipilih, tetapi juga di mana mouse digerakkan) dianggap kategori 2A (Application Interaksi
Support) tapi mungkin dilacak oleh client-side scripting.
Hal ini juga berguna untuk dicatat bahwa kategori ini, sementara luas ortogonal, tidak benar-
benar independen. Memang, dalam banyak kasus akan ada cara yang berbeda untuk melihat
fungsi yang sama. Untuk menggambarkan hal ini, mempertimbangkan fungsi
SafeHomeAssured.com yang menyediakan update data langsung dari sensor keamanan aktif.
Kita bisa menerapkan pembaruan hidup melalui beberapa fungsi user-level yang secara berkala
menyebabkan klien untuk meminta pembaruan yang kemudian dihasilkan secara dinamis (atas
permintaan) dari repositori data yang mendasari

Apakah Ini Selalu Kemungkinan untuk Bedakan Antara Informasi dan Fungsi?
Seringkali, batas antara informasi dan domain fungsional kabur. Pertimbangkan arsitektur
WebApp informasi yang sudah termasuk remah roti (Bab 10) dalam desain dalam rangka
memberikan dukungan bagi pengguna untuk mempertahankan orientasi mereka dalam ruang
informasi. Desainer fungsional mungkin memutuskan untuk menerapkan karakteristik tertentu
dari arsitektur informasi dengan menambahkan beberapa kode ke server Web yang secara
otomatis menghasilkan dan menambahkan remah roti untuk setiap halaman yang disampaikan.
Dalam hal ini desain fungsional sedang didorong oleh kebutuhan tertentu dalam desain
informasi.
TABLE KATEGORI FUNGSI 11.1 webapp
Kelompok 1: User-Level (eksternal) Fungsi. Kategori ini meliputi fungsi yang secara langsung
mempengaruhi pengalaman pengguna dari WebApp dan biasanya langsung dipahami oleh
mereka.
Kategori 1A: User Interaksi Dukungan. Kategori ini fungsi meliputi apa saja yang
mempengaruhi cara di mana pengguna mungkin langsung berinteraksi dengan WebApp dan
mencakup berikut: dinamis mengadaptasi mekanisme akses (misalnya, menyoroti link ketika
mouse diposisikan di atasnya), memfasilitasi akses ke mekanisme navigasi (misalnya, menu
drop-down), adaptasi (online atau off-line, pribadi atau global) dari struktur navigasi dan
pilihan yang tersedia, dan menyediakan pilihan navigasi global (misalnya, menu utama situs)
dan dukungan lokasi (misalnya, remah roti) .
SafeHomeAssured.com contoh: Seperti yang ditunjukkan pada Gambar 9.4, pengguna
menerapkan satu set alat untuk menggambar tata letak ruang fl lantai. Kenaikan khusus ini akan
memerlukan dukungan gambar yang sangat canggih, seperti kemampuan untuk drag dan drop
item dari toolbox menggambar.
Kategori 1B: Informasi Dukungan Pengguna. Kategori ini mencakup setiap fungsi yang
mempengaruhi sifat informasi dan / atau bagaimana itu disajikan kepada pengguna dan
meliputi: konten dan presentasi adaptasi, memperbarui konten hidup atau dinamis, pengguna
modifi kasi konten, dan memberikan informasi kontekstual global ( misalnya, fungsi untuk
secara otomatis menyertakan situs banner atau menegakkan style sheet tertentu).
SafeHomeAssured.com contoh: Presentasi kepada pengguna data sensor hidup untuk
pemantauan keamanan (lihat Gambar 9.8).
Kategori 1C: User Task Support. Hal ini termasuk fungsi yang mendukung, membimbing, atau
mengontrol pengguna dalam mencapai tugas-tugas c spesifik. Contoh yang paling umum
adalah mencari dan manajemen alur kerja (misalnya, penanganan jalan workfl ow diikuti oleh
pengguna, termasuk berbagai pilihan dan pengecualian), tetapi juga meliputi berikut: generasi
trails dan remah roti, pemeriksaan dinamis dan umpan balik pada pengguna informasi -
provided, mekanisme login, dan kontrol akses.
SafeHomeAssured.com contoh: Produk manajemen pesanan.
Kelompok 2: Aplikasi-Level (internal) Fungsi. Kategori-kategori ini berhubungan dengan
fungsi yang diperlukan untuk mendukung WebApp, tetapi yang hanya akan terlihat oleh
pengguna sebagai efek orde kedua.
Kategori 2A: Aplikasi Interaksi Dukungan. Kategori ini meliputi fungsi tersebut
yang diperlukan untuk mengelola dan memelihara mekanisme interaksi tetapi tidak untuk
langsung mengendalikan elemen tertentu dengan mana pengguna berinteraksi. Ini akan
mencakup, misalnya, pelacakan dan pencatatan interaksi dengan pengguna tertentu (sehingga
evaluasi dan adaptasi berikutnya dapat terjadi).
Aspek-aspek lain meliputi: pencarian generasi indeks dan pemeliharaan, penggunaan logging
dan analisis, dan pemantauan untuk link yang rusak dan potensi kesalahan interaksi lainnya.
SafeHomeAssured.com contoh: Profi ling pengguna berdasarkan sejarah produk mereka.
Kategori 2B: Dukungan Informasi Aplikasi. Ini meliputi aplikasi-tingkat
pengelolaan informasi. Ini meliputi: pengembangan dan pemeliharaan sistem manajemen
konten (CMS), pemeliharaan database, dan pemantauan untuk konten kedaluwarsa atau gaya
perbedaan.
SafeHomeAssured.com contoh: Latar Belakang pemantauan sensor keamanan pelanggan pada
saat mereka belum login.
Kategori 2C: Aplikasi Task Support. Ini mencakup dukungan webapp internal yang untuk
tugas-tugas pengguna secara keseluruhan. Ini termasuk aspek-aspek seperti gateway ke
aplikasi lain (seperti sistem pembayaran dalam e-commerce webapp); otentikasi pengguna; dan
batch, off-line, atau waktu-kritis pengolahan tugas (seperti pengolahan pesanan dikirimkan
atau pemantauan dari kemajuan lelang online).
Contoh SafeHomeAssured.com: Batch processing pesanan pelanggan

Desain fungsional dalam Proses Desain

desain fungsional bukanlah tugas diskrit yang dilakukan pada satu titik dalam proses desain.
Sebaliknya, itu terjalin erat dengan kegiatan desain lainnya. Kategorisasi fungsional yang
disajikan dalam bagian sebelumnya, The Nature of WebApp Fungsi, memberi kita cara
berfokus pada aspek yang berbeda dari fungsi yang diinginkan dan melihat di mana mereka
dibahas dalam proses desain.
Mengambil pandangan yang luas dari desain webapp, ada perpecahan utama antara fungsi
userlevel dan fungsionalitas aplikasi-tingkat. fungsi user-level adalah ekspresi dari kemampuan
webapp yang mendukung pengguna dalam mencapai tujuan mereka.
fungsionalitas aplikasi-tingkat mewakili desain-tingkat yang lebih rendah dari fungsi internal
yang mungkin tidak langsung terlihat oleh pengguna (kecuali dalam hal efek orde kedua).
Mengingat definisi defi ini, adalah wajar untuk menyatakan bahwa fungsi user-level lebih erat
digabungkan dengan persyaratan webapp inti dan analisis konsekuen. fungsionalitas aplikasi-
level lebih dalam tertanam dalam struktur webapp dan akan sering muncul dari desain progresif
fungsi user-level.
Mengacu pada Gambar 11.2, lapisan luar mewakili kation spesifik progresif dari webapp.
Lapisan dalam berhubungan dengan desain. Aspek desain yang adalah ekspresi paling dekat
dari persyaratan adalah desain interaksi, tugas yang menangkap cara di mana pengguna
berinteraksi dengan aplikasi. Interaksi (antarmuka) desain memiliki informasi dan elemen
fungsional, dan sering endapan spesifik c desain informasi dan tugas-tugas desain fungsional.
Kedua desain informasi dan desain fungsional dapat berkembang secara paralel dan sering
terjadi iteratif.
Aspek fungsional user-level menanggapi interaksi dirancang dan menentukan bagaimana ini
akan tercapai. Desain fungsional aplikasi-tingkat memberikan dukungan internal untuk
mencapai fungsi pengguna. Oleh karena itu, tingkat aplikasi desain fungsional biasanya akan
mengikuti, dan menanggapi, desain fungsional yang user-level.

Apa Apakah Elemen Desain Proses Fungsional?

Unsur-unsur dari proses desain fungsional ditunjukkan pada Gambar 11.3. Mengacu pada
gambar, desain fungsional dimulai dengan desain fungsi pengguna, yang berasal dari definisi
tujuan pengguna (didokumentasikan sebagai pernyataan bahasa sederhana

GAMBAR 11.2
dan / atau kasus penggunaan selama kegiatan komunikasi). fungsi pengguna diwakili baik
sebagai model interaksi (urutan UML dan / atau diagram negara) dan model fungsional
(aktivitas UML diagram).
Desain fungsi pengguna dikembangkan secara paralel dengan arsitektur informasi untuk
memastikan bahwa mereka konsisten. Pada intinya Anda mulai dengan mempertimbangkan
kedua model analisis (Bab 7) dan arsitektur awal informasi (Bab 10) dan kemudian memeriksa
bagaimana fungsi mempengaruhi berikut:
Interaksi pengguna dengan aplikasi
Informasi yang disajikan
Tugas-tugas pengguna yang dilakukan
Desain fungsi pengguna akan dikombinasikan dengan desain informasi untuk menciptakan
arsitektur fungsional. Sebuah arsitektur fungsional adalah representasi dari domain fungsional
dari WebApp dan menggambarkan komponen fungsional utama dalam webapp dan bagaimana
komponen ini berinteraksi satu sama lain. Mengingat peran sentral, kita akan membahas
arsitektur fungsional secara rinci nanti dalam bab ini di bagian Arsitektur Fungsional.

GAMBAR 11.3

Berapa Banyak Desain Fungsional Apakah Cukup?

Seperti semua tugas desain lainnya, formalitas dan luasnya desain fungsional akan tergantung
pada sifat dari webapp. Sebuah webapp besar dengan fungsi kompleks yang sangat ditenun
menjadi proses bisnis organisasi biasanya akan memerlukan set lengkap tugas pemodelan
desain fungsional yang ditunjukkan pada Gambar 11.3. 3 Sebaliknya, WebApp kecil yang
hanya suplemen operasi bisnis organisasi akan
membutuhkan desain jauh lebih sedikit formal. Dalam kasus seperti itu, desain fungsional
mungkin terbatas untuk urutan diagram untuk fungsi pengguna dan diagram komponen untuk
arsitektur fungsional. Hal ini terutama berlaku ketika WebApp adalah antarmuka bisnis kunci
untuk pelanggan potensial dan aktual.
GAMBAR 11.3
Untuk SafeHomeAssured.com, kenaikan yang berbeda akan membutuhkan tingkat yang cukup
berbeda dari desain fungsional. Yang pertama WebApp kenaikan (yang berkaitan dengan
perusahaan dan produk-produknya) akan memiliki sedikit kerumitan-mungkin fungsional yang
terbatas pada beberapa manajemen konten untuk produk database-dan karenanya desain
fungsional akan minimal. Untuk kenaikan 6 (terkait dengan kontrol dan monitoring sensor),
fungsi tersebut akan jauh lebih kompleks, dan karenanya desain akan jauh lebih rinci.

Bagaimana Akan Perdana Desain Fungsional dilakukan untuk SafeHomeAssured.com?

SafeHomeAssured.com memiliki campuran yang menarik informasi-fokus dan fungsional
terfokus komponen. Dalam kegiatan komunikasi awal (Bab 4), kami mengidentifikasi satu set
awal tujuan informasi dan aplikatif untuk SafeHomeAssured.com direproduksi sebagian sini:
Untuk menyediakan pengguna dengan meminta spesifikasi produk.
Untuk menyediakan alat-alat yang akan memungkinkan pengguna untuk mewakili tata letak
ruang (yaitu, rumah,
pejabat ce / ruang ritel) yang harus dilindungi.
Untuk membuat rekomendasi yang disesuaikan tentang keamanan dan pemantauan produk
yang dapat
digunakan dalam ruang pengguna.
Untuk memungkinkan pengguna untuk mendapatkan penawaran untuk biaya produk.
Untuk memungkinkan pengguna untuk menempatkan pesanan untuk hardware keamanan.
Untuk memungkinkan pengguna untuk mengontrol peralatan pemantauan (misalnya, kamera,
mikrofon) dalam ruang mereka.
Untuk memungkinkan pengguna untuk sign up untuk layanan pemantauan.
Untuk memungkinkan pemantauan pelanggan untuk query database pemantauan tentang
aktivitas akun mereka.
Tujuan ini kemudian refi ned ke dalam daftar berikut fungsi yang harus dilakukan:
Memberikan kutip produk
Proses rangka sistem keamanan
data pengguna Proses
 Buat pengguna profi le
Tata letak ruang pengguna Menggambar
Kenalkan sistem keamanan untuk tata letak
Agar pemantauan Proses
Dapatkan dan info akun display
Dapatkan dan menampilkan pemantauan Info
fungsi layanan pelanggan (akan Defi ned kemudian)
fungsi dukungan Tech (untuk Defi ned kemudian)
Pada akhirnya fungsi-fungsi ini dijabarkan ke dalam satu set kasus penggunaan yang
menangkap informasi pengguna kunci dan interaksi fungsional.
Seperti yang kita catat sebelumnya, yang pertama SafeHomeAssured.com kenaikan didominasi
informasi terfokus (Bab 4), namun kenaikan berikutnya mulai memperkenalkan fungsionalitas
yang semakin kompleks. Mari kita pertimbangkan kenaikan 2, yang mencakup skenario
penggunaan berikut atau kasus penggunaan.
Kartu No. kartu Nama
2 Men-download spesifikasi produk.
3 Dapatkan info yang disesuaikan dengan kategori pengguna saya.
4 Mencari spesifik, sebuahsensor c.
Selama pemodelan analisis, tim WebE dikembangkan konten dan interaksi model sederhana
untuk peningkatan ini, tapi memutuskan bahwa fungsi sangat sederhana bahwa model
fungsional yang terpisah tidak benar-benar diperlukan (terutama karena banyak fungsi dalam
hal ini akan cukup jelas dari diagram urutan model interaksi).
diskusi kita di bagian ini menggambarkan bahwa beberapa aspek dari desain fungsional akan
langsung jatuh tempo, setidaknya sebagian, dengan struktur yang melekat dan teknologi yang
dipaksakan oleh arsitektur Web yang lebih luas. Aspek-aspek lain, bagaimanapun, perlu
pertimbangan lebih dalam dan membutuhkan pengembangan arsitektur fungsional secara
keseluruhan.

Arsitektur fungsional
Sebuah arsitektur fungsional adalah representasi dari domain fungsional dari webapp.
Representasi arsitektur menjawab dua pertanyaan kunci:
Bagaimana kita partisi fungsi menjadi komponen-komponen yang telah jelas peran dan
interface?
Di mana masing-masing komponen fungsional ada, dan apa yang berinteraksi dengan?
Dengan kata lain, arsitektur fungsional terurai webapp menjadi komponen fungsional
konstituen.
 GAMBAR 11.4

Apa yang Fungsional Arsitektur Look Like?

Ada banyak cara pemodelan dan mendokumentasikan arsitektur fungsional 4;
Namun, karena sebagian besar webapps sangat modular, model dasar yang baik adalah
UML komponen diagram [OMG04]. Diagram ini menunjukkan bagaimana webapp yang akan
diatur dalam satu set komponen sistem utama dan mewakili koneksi
antara komponen-komponen ini. Gambar 11.5 menyajikan arsitektur fungsional awal untuk
peningkatan 2 dari
SafeHomeAssured.com. Perhatikan bahwa lokasi komponen fungsional menggambarkan di
mana komponen-komponen fungsional dijalankan, bukan di mana mereka disimpan (atau
bahkan yang dihasilkan, jika fungsi tersebut dibuat secara dinamis). Dalam arsitektur ini
keputusan telah dibuat untuk secara dinamis menghasilkan halaman informasi produk
(termasuk halaman kategori menengah). Hal ini terjadi karena kandungan yang sebenarnya
tergantung pada kelas pengguna. Dalam arsitektur khusus ini, generasi akses produk, kategori,
dan halaman informasi produk (yang akan telah dirancang sebagai bagian dari arsitektur
informasi) dibuat secara dinamis oleh komponen halaman kompilasi dinamis. Hal ini pada
gilirannya akan menggunakan baik generasi hasil pencarian atau komponen produk generasi
halaman untuk membuat konten halaman, dan komponen produk generasi menu untuk
membuat menu terkait dan alat bantu navigasi lainnya (seperti remah roti). Sebuah komponen
back-end, pencarian pengindeks, akan bertanggung jawab untuk generasi indeks pencarian.
Perhatikan bahwa model arsitektur ini juga telah diperluas untuk menunjukkan hubungan
dengan architecture.6 informasi Misalnya, komponen halaman kompilasi dinamis bertanggung
jawab untuk menciptakan halaman akses produk dan semua subpages bawah ini dalam hirarki
informasi. Ketika IA dimodifikasi, kita dapat melihat apa komponen fungsional yang mungkin
akan terpengaruh, dan sebaliknya.

Bagaimana Kita Mengembangkan Arsitektur Fungsional?

Tempat yang jelas untuk memulai desain fungsional adalah untuk mempertimbangkan baik
model analisis webapp (bersama dengan spesifikasi yang menyertainya) dan arsitektur
informasi awal. Kita telah mencatat bahwa adalah mungkin untuk mengidentifikasi fungsi yang
ada di masing-masing kategori yang tercantum dalam Tabel 11.1. Setiap skenario atau bagian
dari skenario (seperti konten produk Customize tergantung pada tipe user) dapat diuraikan ke
dalam kategori skenario generik komponen berikut:

GAMBAR 11.5
Pemilihan Informasi (yaitu, fungsi yang terkait dengan identifikasi dan / atau pemilihan
informasi yang akan disajikan kepada pengguna)
kompilasi Informasi (yaitu, fungsi terkait dengan penggabungan informasi bersama-sama ke
komposit yang akan dipresentasikan kepada pengguna)
Pengolahan informasi (yaitu, analisis atau perhitungan data)
Interaksi System (yaitu, fungsi terkait dengan interaksi dengan sistem lain eksternal ke
webapp)
Kami kemudian mempertimbangkan apakah spesifik c komponen skenario harus dipanggil
secara dinamis pada permintaan pengguna, secara dinamis pada inisiasi acara, atau secara
manual. Akhirnya, kami melakukan clustering, penggabungan, dan nement refi komponen
arsitektur. Sebagai contoh, perhatikan diskusi sidebar terkait dengan pengembangan arsitektur
fungsional untuk SafeHomeAssured.com.

Apa Tentang Fungsi untuk Penanganan Exception?

Karena faktor utama dalam desain fungsional sering penanganan pengecualian, penting untuk
merancang fungsi yang memungkinkan sistem untuk mengatasi kondisi yang tidak biasa. Bagi
sebagian besar kenaikan dalam SafeHomeAssured.com, ini bukan masalah besar, tapi
penanganan eksepsi harus tetap diperhatikan. Misalnya, prodFunctional Arsitektur Modeling
Informasi yang dinilai dalam komponen halaman kompilasi dinamis. Komponen ini
menghasilkan SafeHome halaman akses produk dan juga menghasilkan halaman kategori
menengah yang membentuk jalur navigasi untuk produk (sebagaimana didefinisikan dalam
arsitektur informasi). Hal ini memungkinkan halaman-halaman menengah yang akan
dihasilkan dengan cara yang memastikan bahwa mereka berisi link hanya untuk produk-produk
yang tersedia untuk pengguna saat ini. Pertimbangkan hal berikut dua fragmen HTML untuk
kamera keamanan halaman kategori yang sama:
Halaman web: Security Camera Kategori (untuk tamu)

Dapat Pola Arsitektur Digunakan Selama Desain Fungsional?

Pola dibahas secara rinci dalam Bab 13. Namun, satu tertentu pola-model-view-controller-
untuk webapp arsitektur fungsional sangat umum bahwa itu adalah layak membahas secara
singkat di sini.
Jacyntho dan rekan-rekannya [Jac02] menyarankan arsitektur desain tiga-lapisan yang
decouples antarmuka aplikasi dari navigasi dan dari perilaku aplikasi.
Mereka berpendapat bahwa menjaga antarmuka, aplikasi, dan navigasi implementasi
menyederhanakan terpisah dan meningkatkan penggunaan kembali. Model-view-controller
(MVC) arsitektur [Kra88] adalah salah satu dari sejumlah model infrastruktur WebApp
menyarankan bahwa decouples antarmuka pengguna dari fungsi webapp dan konten informasi.
Model bagian dari arsitektur MVC (kadang-kadang disebut sebagai objek Model) berisi
semua aplikasi-spesifik konten dan pengolahan logika, termasuk semua benda konten, akses
ke data eksternal dan sumber-sumber informasi, dan semua fungsi pemrosesan yang aplikasi
spesifik c . Dengan kata lain, ini pada dasarnya adalah konten, serta metadata apapun, struktur
navigasi, pengguna ProFI les, dan sebagainya.
The View bagian dari arsitektur MVC berisi semua fungsi antarmuka-spesifik dan
memungkinkan penyajian konten dan pengolahan logika, termasuk semua benda konten, akses
ke data eksternal dan sumber-sumber informasi, dan semua fungsi proses yang diperlukan oleh
pengguna akhir.
Controller bagian dari arsitektur MVC mengelola akses dan manipulasi Model dan View. Hal
ini juga mengkoordinasikan aliran data antara mereka. Dalam webapp, controller memonitor
interaksi pengguna dan, berdasarkan ini, mengambil data dari Model dan menggunakan ini
untuk memperbarui atau membangun View. Sebuah representasi skematis dari arsitektur MVC
ditunjukkan pada Gambar 11.6.
Mengacu pada angka tersebut, pengguna permintaan atau data ditangani oleh Controller.
Controller juga memilih View objek yang berlaku berdasarkan permintaan pengguna. Setelah
jenis permintaan ditentukan, permintaan perilaku ditransmisikan ke Model, yang
mengimplementasikan fungsi atau mengambil konten yang diperlukan untuk mengakomodasi
permintaan. Objek Model dapat mengakses data yang tersimpan dalam database perusahaan,
sebagai bagian dari menyimpan data lokal atau sebagai kumpulan file independen. Data yang
dikembangkan oleh Model harus diformat dan diselenggarakan oleh sesuai View obyek dan
kemudian ditransmisikan dari server aplikasi kembali ke browser berbasis client untuk
ditampilkan pada mesin pelanggan.

GAMBAR 11.6
kesamaan yang kuat untuk model MVC, meskipun View dan Pengendalian aspek saling terkait.
Dalam banyak kasus, arsitektur fungsional WebApp didefinisikan dalam konteks lingkungan
pengembangan di mana aplikasi ini akan dilaksanakan (misalnya, ASP.net, JWAA, atau J2EE).
Jika Anda memiliki bunga lebih lanjut, lihat [Fow03] untuk diskusi lingkungan pengembangan
dan peran mereka dalam desain arsitektur aplikasi Web.

Desain Fungsional rinci

Karena proses WebE adalah inkremental dan konstruksi WebApp biasanya membuat
penggunaan berat dari pembangunan berbasis komponen, hasil desain fungsional rinci dalam
beberapa model formal atau dokumentasi rinci. Ketika pemodelan diperlukan, itu meminjam
banyak dari pendekatan desain fungsional konvensional seperti UML [OMG04] [Pil05]. UML
menyediakan sejumlah representasi desain yang berguna untuk desainer fungsional (misalnya,
sequence diagram, diagram negara), tetapi tidak menyediakan integrasi yang baik dengan
desain informasi rinci. Namun, kedua WAE dan WebML (pendekatan desain informasi dibahas
dalam Bab 10) dapat diperpanjang ke domain fungsional.

Bagaimana Bisa WAE Modeling Digunakan untuk Desain Rinci?

WAE menetapkan satu set ekstensi untuk UML yang memfasilitasi pemodelan webapp desain
tingkat rendah [Con99]. Dalam Bab 10, kita diilustrasikan penggunaan WAE dengan contoh
bagi SafeHomeAssured.com ditunjukkan pada Gambar 10.11. WAE sangat cocok untuk
memodelkan interaksi client-server yang khas dari webapps.
Gambar 11.7 menunjukkan ikon utama yang digunakan untuk mewakili objek dalam model
WAE. Dengan menggabungkan ikon ini, menjadi mungkin untuk mewakili interaksi kompleks
antara objek data, benda fungsional, dan presentasi benda-serta untuk menunjukkan di mana
interaksi antara benda-benda ini terjadi. Pandangan analisis digambarkan dalam Bab 10.
pandangan logis menggambarkan unsur-unsur konseptual dalam WebApp, sedangkan tampilan
fisik menunjukkan bagaimana ini memetakan ke komponen pelaksanaannya.
Mengacu kembali ke Gambar 10.11, Anda dapat melihat bahwa itu menangkap kedua struktur
informasi dan pengolahan fungsional, tetapi tidak menunjukkan desain khusus dari komponen
logis yang memungkinkan pencampuran ini informasi dan fungsi. Gambar 11.8 menunjukkan
desain logis yang berasal dari sosok 10.11 dan menyoroti cara di mana fungsi mengarah ke
informasi, dan sebaliknya.

GAMBAR 11.7

Mengapa Apakah WebML tepat untuk Workfl ow Modeling?

Jika Anda mengembangkan aplikasi ow berorientasi workfl, kami sarankan adaptasi WebML
untuk dukungan workfl lebih efektif ow [Bra03] [Bra06]. Banyak webapps digunakan untuk
menyediakan antarmuka front-end dengan proses organisasi yang memiliki urutan yang
ditetapkan langkah-langkah. Contohnya adalah berlimpah, tetapi beberapa yang sederhana
meliputi proses pembayaran dalam aplikasi e-commerce (misalnya, pilih item, mengkonfirmasi
pesanan, memberikan rincian pembayaran, rm pembayaran kerahasiaan), acara atau perjalanan
ticketing
 GAMBAR 11.8
(Misalnya, pilih acara atau perjalanan rute, pilih tanggal dan waktu, pilih tempat duduk,
konfirmasi pembayaran), lelang online, pengajuan aplikasi, dan sebagainya-daftar panjang.
WebML telah diadaptasi [Bra06] untuk model aplikasi workfl ow-oriented. alur kerja bisnis
dimodelkan, dan kemudian proses ini dipetakan ke model desain WebML yang telah diperluas
untuk mendukung pemodelan yang lebih efektif dari proses. Pendekatan pemodelan
merupakan kasus yang berbeda atau skenario (misalnya, contoh tertentu dari aplikasi pinjaman)
yang akan dihadapi sebagai proses diterapkan. Setiap kasus akan melalui berbagai kegiatan
atau langkah-langkah proses yang mungkin terjadi pada waktu yang berbeda atau oleh orang
yang berbeda. langkah-langkah proses ini dapat dimodelkan menggunakan WebML. Sebagai
contoh, proses pengelolaan aplikasi pinjaman tertentu akan mencakup langkah-langkah
berikut: (1) sebuah pengajuan awal aplikasi dengan pelanggan, (2) validasi oleh manajer kredit,
(3) penyelesaian pemeriksaan kredit oleh karyawan bank . dan (4) persetujuan akhir (atau
penolakan) oleh yang berwenang pemberi persetujuan pinjaman Model A WebML, seperti
yang ditunjukkan pada Gambar 11.9, dapat memberikan manfaat yang cukup besar ketika
model mengalir workfl cukup kompleks. Hal ini memungkinkan para desainer untuk
mengungkap kesalahan, kelalaian, atau inkonsistensi sebelum menyelesaikan arsitektur
fungsional untuk webapp tersebut. Seperti telah kita bahas, pendekatan pemodelan WebML
berlebihan untuk fungsi sederhana seperti yang khas selisih 2 dari SafeHomeAssured.com (di
mana fungsi tersebut hampir seluruhnya dipicu oleh peristiwa pengguna browsing dan ada
sedikit proses atau sejarah antara peristiwa atau interaksi antara pengguna). Namun, di mana
WebApp memiliki fungsi yang didistribusikan dalam waktu atau antara beberapa pengguna,
10 modeling WebML dianjurkan. seperti yang ditunjukkan pada Gambar 11.9, dapat
memberikan manfaat yang cukup besar ketika model mengalir workfl cukup kompleks. Hal ini
memungkinkan para desainer untuk mengungkap kesalahan, kelalaian, atau inkonsistensi
sebelum menyelesaikan arsitektur fungsional untuk webapp tersebut. Seperti telah kita bahas,
pendekatan pemodelan WebML berlebihan untuk fungsi sederhana seperti yang khas selisih 2
dari SafeHomeAssured.com (di mana fungsi tersebut hampir seluruhnya dipicu oleh peristiwa
pengguna browsing dan ada sedikit proses atau sejarah antara peristiwa atau interaksi antara
pengguna). Namun, di mana WebApp memiliki fungsi yang didistribusikan dalam waktu atau
antara beberapa pengguna, 10 modeling WebML dianjurkan. seperti yang ditunjukkan pada
Gambar 11.9, dapat memberikan manfaat yang cukup besar ketika model mengalir workfl
cukup kompleks. Hal ini memungkinkan para desainer untuk mengungkap kesalahan,
kelalaian, atau inkonsistensi sebelum menyelesaikan arsitektur fungsional untuk webapp
tersebut. Seperti telah kita bahas, pendekatan pemodelan WebML berlebihan untuk fungsi
sederhana seperti yang khas selisih 2 dari SafeHomeAssured.com (di mana fungsi tersebut
hampir seluruhnya dipicu oleh peristiwa pengguna browsing dan ada sedikit proses atau
sejarah antara peristiwa atau interaksi antara pengguna). Namun, di mana WebApp memiliki
fungsi yang didistribusikan dalam waktu atau antara beberapa pengguna, 10 modeling WebML
dianjurkan. atau inkonsistensi sebelum menyelesaikan arsitektur fungsional untuk webapp
tersebut. Seperti telah kita bahas, pendekatan pemodelan WebML berlebihan untuk fungsi
sederhana seperti yang khas selisih 2 dari SafeHomeAssured.com (di mana fungsi tersebut
hampir seluruhnya dipicu oleh peristiwa pengguna browsing dan ada sedikit proses atau
sejarah antara peristiwa atau interaksi antara pengguna). Namun, di mana WebApp memiliki
fungsi yang didistribusikan dalam waktu atau antara beberapa pengguna, 10 modeling WebML
dianjurkan. atau inkonsistensi sebelum menyelesaikan arsitektur fungsional untuk webapp
tersebut. Seperti telah kita bahas, pendekatan pemodelan WebML berlebihan untuk fungsi
sederhana seperti yang khas selisih 2 dari SafeHomeAssured.com (di mana fungsi tersebut
hampir seluruhnya dipicu oleh peristiwa pengguna browsing dan ada sedikit proses atau
sejarah antara peristiwa atau interaksi antara pengguna). Namun, di mana WebApp memiliki
fungsi yang didistribusikan dalam waktu atau antara beberapa pengguna, 10 modeling WebML
dianjurkan. com (di mana fungsi tersebut hampir seluruhnya dipicu oleh peristiwa pengguna
browsing dan ada sedikit proses atau sejarah antara peristiwa atau interaksi antara pengguna).
Namun, di mana WebApp memiliki fungsi yang didistribusikan dalam waktu atau antara
beberapa pengguna, 10 modeling WebML dianjurkan. com (di mana fungsi tersebut hampir
seluruhnya dipicu oleh peristiwa pengguna browsing dan ada sedikit proses atau sejarah
antara peristiwa atau interaksi antara pengguna). Namun, di mana WebApp memiliki fungsi
yang didistribusikan dalam waktu atau antara beberapa pengguna, 10 modeling WebML
dianjurkan.
 GAMBAR 11.9
Untuk SafeHomeAssured.com, setiap kenaikan webapp yang melibatkan interaksi
asynchronous antara pengguna dan webapp akan menjadi kandidat untuk pemodelan
menggunakan WebML. Misalnya, kenaikan 4 dari SafeHomeAssured.com termasuk skenario
Dapatkan rekomendasi untuk tata letak sensor untuk ruang saya. Jika pengguna memasukkan
layout dan webapp segera menghasilkan rekomendasi, alur kerja terkait tidak diperlukan dan
komponen fungsional sederhana dapat dirancang. Sebaliknya, jika rekomendasi tata letak harus
secara manual dibuat oleh seorang karyawan SafeHomeAssured.com (atau bahkan memeriksa
sebelum rilis kepada pelanggan), maka workfl yang tepat ow harus dimasukkan untuk
mengelola permintaan untuk rekomendasi.
Bahkan jika rekomendasi dapat dihasilkan secara otomatis, tetapi upaya pengolahan diperlukan
berarti tidak bisa dilakukan dengan cepat (dan bukan permintaan perlu ditempatkan dalam
antrian sebelum rekomendasi yang dihasilkan secara otomatis), alur kerja perlu dirancang
untuk kembali hasilnya ke pelanggan setelah telah dihasilkan.
Negara Modeling Sebagai webapps tumbuh lebih kompleks, ada kemungkinan bahwa Anda
akan harus mengakomodasi berinteraksi proses, terutama dengan beberapa pengguna secara
simultan (atau beberapa pengguna setidaknya yang interaksi dengan server Web yang
disisipkan). Masalah tidak bisa signifi dalam desain webapps adalah memastikan bahwa
keadaan informasi yang mendasari benar dipertahankan bila kita memiliki proses berinteraksi
kompleks.
Dalam contoh sebelumnya, kita membahas sebuah aplikasi pemesanan hotel secara online.
Mengingat bahwa proses berinteraksi adalah norma di webapp ini, potensi overbooking dari
hotel (atau menunjukkan bahwa ruang yang tersedia dan kemudian harus menunjukkan bahwa
itu bukan) merupakan masalah desain tidak bisa signifi. desain yang efektif untuk situasi seperti
ini dapat dikelola melalui penggunaan pemodelan negara.

GAMBAR 11.10
tindakan dari satu atau lebih pengguna, terutama ketika respon untuk satu pengguna akan
terpengaruh oleh apa yang pengguna lain do.Figure 11,10 menggambarkan diagram negara
untuk interaksi pelanggan baru untuk
SafeHomeAssured.com. Dalam diagram ini enam negara eksternal dapat diamati (diwakili oleh
persegi panjang bulat) diidentifikasi. State diagram menunjukkan peristiwa yang diperlukan
untuk memindahkan pelanggan dari satu negara ke negara lain, informasi yang ditampilkan
sebagai negara yang dimasukkan, pengolahan yang terjadi dalam negara, dan kondisi keluar
yang memungkinkan transisi terjadi.
Perilaku SafeHomeAssured.com seperti yang diamati oleh pengguna sebagian besar tergantung
dari apa yang pengguna lain lakukan, dengan pengecualian dari pelanggan dan
SafeHomeAssured.com karyawan yang berinteraksi selama pemantauan rumah.
Mempertimbangkan situasi di mana seorang pelanggan telah mendaftar untuk layanan
pemantauan. The SafeHomeAssured.com software monitoring dapat secara otomatis
memonitor kamera (melalui algoritma Pengolahan Citra) dan sensor lain di rumah pelanggan
dan mengidentifikasi situasi anomali seperti:
1. Sistem keamanan bersenjata, dan sensor pintu masuk mengindikasikan pelanggaran
keamanan kurang dari x detik. Hal ini mungkin terjadi ketika pemilik rumah memasuki rumah
tanpa terlebih dahulu melucuti sistem keamanan. Peringatan terdengar harus mengingatkan
pemilik rumah untuk melucuti sistem dalam interval waktu tertentu.
2. Sistem keamanan bersenjata, dan sensor menunjukkan pelanggaran keamanan yang mungkin
lebih besar dari x detik pada sebuah pintu masuk atau lebih besar dari y detik pada setiap sensor
lainnya. Ini mengindikasikan adanya pelanggaran keamanan yang benar.
3. Sebuah sensor dalam sistem keamanan menunjukkan kemungkinan kebakaran atau keadaan
darurat lainnya.