Pemodelan Aplikasi Web

Untuk membangun sebuah rumah anjing Anda hanya perlu dua tangan terampil, bahan yang dibutuhkan, dan beberapa alat cepat mulai palu kemudian menggergaji dan mencapai hasil yang menarik, tergantung pada kreativitas pribadi Anda . Tak seorang pun, namun (Booch et al. 1999), akan mulai membangun gedung pencakar langit dengan cahaya gemerlap yang sama  - hasilnya pasti akan berakibat fatal! Yang jelas untuk semua orang ketika datang untuk membangun gedung pencakar langit sering diabaikan ketika datang untuk membangun web yang kompleks aplikasi. Sebuah pendekatan yang sistematis dan spesifikasi dari aplikasi Web yang akan dibangun di bentuk model visual yang dianjurkan jika kita perlu mengembangkan aplikasi Web yang kompleks. Pada uraian ini berkaitan dengan pengembangan model berbasis aplikasi Web. bagian 3.2 memberikan wawasan tentang dasar-dasar pemodelan umum, diikuti oleh bagian 3.3 yang membahas Aplikasi Modeling the40 Web spesifik dalam aplikasi Web pemodelan.

Content Modeling

Informasi yang diberikan oleh aplikasi Web adalah salah satu faktor yang paling penting bagi keberhasilan aplikasi itu, tidak sedikit karena asal-usul dari Web sebagai sebuah informasi media (lihat juga Bab 11). Pemodelan konten dalam arti pemodelan data murni adalah biasanya cukup untuk aplikasi web statis. Kompleks aplikasi Web (sesuai dengan kategorisasi didefinisikan dalam Bab 1) tambahan membutuhkan pemodelan aspek perilaku.
Ini berarti bahwa pemodelan konten meliputi penciptaan model domain masalah, yang terdiri aspek statis dan dinamis, sebagaimana diketahui dari Rekayasa Perangkat Lunak tradisional. Selain itu karakteristik berikut aplikasi Web harus diperhitungkan:
• Dokumen-sentris karakter dan multimedia: Hal ini diperlukan untuk mengambil semua jenis yang berbeda format media ke account user ketika pemodelan konten, termasuk struktur yang Informasi ini didasarkan pada.
• Integrasi data yang ada dan software: Banyak aplikasi Web membangun yang ada Data repositori dan komponen perangkat lunak, yang tidak diciptakan untuk aplikasi Web awalnya. Pemodelan Konten harus memenuhi dua tujuan berpotensi bertentangan, yaitu, harus mencakup persyaratan isi dari aplikasi Web sejauh terbaik, dan itu harus mencakup struktur data yang ada dan komponen perangkat lunak.
Hypertext Modeling
Non-linearitas hypertext adalah salah satu sifat yang paling penting yang harus diperhitungkan ketika model aplikasi Web. Dengan demikian struktur hypertext harus dirancang dengan hati-hati. ini dapat dicapai dengan menggunakan struktur akses yang cocok, yaitu, navigasi pilihan, untuk menghindari risiko pengguna tersesat dan menempatkan mereka di bawah stres kognitif yang berlebihan

• konsep pemodelan struktur hipertext

Berbeda dengan tingkat konten, yang diagram ER atau diagram kelas yang digunakan, khusus notasi yang sering digunakan untuk model struktur hypertext. Pemodelan struktur Hypertext berdasarkan konsep hypertext, yaitu, pada node (juga disebut halaman atau dokumen) dan link antara node. Titik awal yang digunakan untuk menciptakan model struktur hypertext biasanya konten Model yang berisi kelas dan objek yang akan dibuat tersedia sebagai node dalam hypertext. sering model struktur hypertext ditetapkan sebagai pandangan pada model konten dan karena itu kadang-kadang juga disebut pandangan navigasi. Dengan demikian node ditentukan sebagai pandangan pada model konten memilih satu atau lebih obyek dari konten. Beberapa metode bahkan menentukan aturan transformasi untuk mendapatkan link atas dasar hubungan pada tingkat konten. Link tambahan dapat ditambahkan dengan eksplisit desain keputusan. Metode lain model hypertext struktur secara independen dari model konten. Misalnya OOHDM (Object-Oriented Hypermedia Metode Desain) (Schwabe et al. 2002) menawarkan pendekatan untuk skenario model, di mana model struktur hypertext dapat dibangun langsung dari persyaratan navigasi diidentifikasi oleh skenario ini.

• konsep pemodelan akses

Struktur hypertext model yang dibangun sejauh saja tidak cukup untuk menggambarkan bagaimana node dapat dicapai dengan navigasi. Untuk memungkinkan pengguna untuk menavigasi ke node pengguna perlu navigasi dan
Orientasi bantu. Ini dirumuskan dalam bentuk struktur akses menyempurnakan hypertext struktur model. Struktur akses berulang dijelaskan dalam (Jerman dan Cowan 2000, Lyardet et al. 1999, Rossi dkk. 1998, Akanda dan Jerman 2005) sebagai pola desain, juga disebut ”Pola desain hypermedia” atau “navigasi pola”. Penggunaan pola-pola navigasi membantu untuk meningkatkan kualitas dari model hypertext sangat.

• Kaitannya dengan Modeling Konten

Tergantung pada metode pemodelan yang mendasari, model hypertext lebih atau kurang kuat tergantung pada model konten. Ada ada baik ketergantungan pada tingkat jenis, misalnya, yang kelas dalam bentuk model konten yang node dalam model hypertext, dan pada tingkat contoh, yaitu, yang menetapkan objek dalam model konten mengisi bahwa node dalam model hypertext. tidak semua metode menggambarkan dependensi antara model konten dan model hypertext tepat. Namun demikian, beberapa metode menentukan turunan langsung dari hypertext dari konten dengan mendefinisikan node atas dasar pandangan (dalam arti “view database”) (Schwabe et al. 2002, Koch dan Kraus 2002).
Presentation Modeling
Mirip dengan Rekayasa Perangkat Lunak tradisional, pemodelan presentasi berkaitan dengan user interface dan dengan demikian dengan tampilan dan nuansa dari aplikasi Web. Berbeda dengan aplikasi tradisional, elemen pusat dari presentasi dalam aplikasi web adalah halaman sebagai unit visualisasi.

• konsep 

Elemen model dijelaskan pada tiga tingkatan hirarkis:
• Sebuah halaman presentasi menggambarkan halaman yang disajikan kepada pengguna sebagai unit visualisasi. Hal ini dapat terdiri dari unit presentasi yang berbeda.
• Sebuah unit presentasi berfungsi untuk elemen antarmuka pengguna kelompok terkait, mewakili logis fragmen halaman. Ini menyajikan sebuah node yang berasal dari model hypertext.
• Unsur presentasi adalah blok bangunan dasar dari model presentasi. presentasi elemen merupakan satu set node informasi dan dapat mencakup teks, gambar, audio, dll Kita dapat memvisualisasikan komposisi halaman presentasi atas dasar kelas UML bersarang representasi diagram yang dikenal sebagai “komposisi”, seperti pada contoh yang ditunjukkan pada Gambar 3-9. ini Misalnya menggunakan kelas stereotip? halaman? dan unit presentasi? untuk menggambarkan presentasi halaman dan unit presentasi. Perhatikan bahwa semua jenis elemen presentasi juga ditunjuk oleh sesuai UML stereotip. Gambar 3-9 menunjukkan halaman presentasi dua sistem kami meninjau. Kertas A diposisikan pada halaman yang disebut “PaperPage” dengan bidang yang sesuai serta link ke versi penuh kertas dan link untuk menampilkan penulis kertas. Selain itu, pengguna dapat menekan tombol untuk menambahkan review baru. Halaman “AuthorPage” memiliki unit presentasi dua, yaitu, daftar semua penulis dan informasi rinci masing-masing penulis. Perilaku aspek dari antarmuka pengguna, seperti interaksi resensi untuk menavigasi ke makalah yang ditugaskan kepadanya untuk meninjau, dapat dimodelkan dengan cara diagram perilaku, seperti, ditunjukkan pada Gambar 3-10,, 3-11 dan 3-12. Secara umum, interaksi pengguna dengan aplikasi Web tidak hanya melibatkan tingkat presentasi, melainkan juga diteruskan ke tingkat hypertext dan tingkat konten, tergantung pada jenis interaksi. Kita bisa melihat di urutan disederhanakan diagram pada Gambar 3-11 dan 3-12, bahwa resensi mengaktifkan navigasi ke indeks ditugaskan makalah dengan menggunakan bar navigasi dari dalam halaman rumah konferensi. ini informasi, pada gilirannya, terdiri dari makalah yang relevan pada tingkat konten. Daftar ini memungkinkan pengguna untuk memilih kertas keluar dari daftar kertas yang ditugaskan. Pengguna kemudian dapat menavigasi untuk memilih salah satu kertas, yang akan ditampilkan dalam tampilan rincian.

Istilah yang ada di Rekayasa Web

1. Web Engineering (Rekayasa Web) : Suatu model rakayasa perangkat lunak, yang digunakan untuk pengembangan aplikasi ‐aplikasi berbasis web. Sebuah aplikasi web adalah suatu sistem software yang berbasiskan teknologi dan standard dari konsorsium world wide web (W3C) yang menyediakan sumber yang bersifat spesifik seperti konten atau layanan melalui sebuah user interface yang disebut web browser.
2. Hypermedia engineering adalah Suatu halaman-halaman multimedia yang berhubungan dengan situs web Hypermedia istilah hypertext di mana grafik, audio, video, teks biasa dan hyperlink jalin untuk menciptakan umum non-linear media informasi. Ini kontras dengan istilah yang lebih luas multimedia, yang dapat digunakan untuk menggambarkan non-linear presentasi interaktif serta hypermedia. Hal ini juga terkait dengan bidang sastra elektronik.
3. Document engineering adalah Suatu bagian pelengkap dari informasi, analisis sistem, penerbitan elektronik, analisis proses bisnis, dan informatika bisnis untuk memastikan bahwa dokumen dan proses masuk akal untuk orang-orang dan aplikasi yang membutuhkannya. Tahapan dalam model biasanya menghasilkan sejumlah tulisan, diagram, gambar atau bentuk-bentuk lain yang harus didokumentasikan.
4. Content engineering adalah Istilah yang digunakan untuk suatu rekayasa khusus berurusan dengan isu-isu seputar penggunaan konten di komputer yang difasilitasi lingkungan. Konten produksi, penggunaan manajemen konten, pemodelan konten, konversi konten, dan konten dan repurposing semua daerah yang melibatkan khusus ini.
5. Internet software engineering adalah Aplikasi dari pendekatan yang sistematis dan disiplin, dihitung untuk, pengembangan desain operasi, dan pemeliharaan perangkat lunak, dan studi ini pendekatan.

Hak Akses di Windows

Izin berkas dan map

Hak akses folder termasuk Kontrol penuh, Memodifikasi, Membaca & mengeksekusi, Buat Daftar Isi Map, Baca, dan Menulis. Masing-masing izin ini terdiri dari sekelompok logis izin khusus yang terdaftar dan didefinisikan dalam bagian berikut.

Izin khusus yang didefinisikan

Anda dapat mengatur setiap atau semua berikut khusus perizinan berkas dan map.

·         Melintasi Folder/menjalankan File

Untuk folder: Melintasi Folder izin hanya berlaku untuk folder. Izin ini memungkinkan atau menyangkal pengguna dari bergerak melalui folder untuk mencapai lainnya file atau folder, bahkan jika pengguna memiliki tidak ada izin untuk map traversed. Melintasi Folder berlaku hanya ketika grup atau pengguna tidak diberikan Bypass melintasi memeriksa pengguna benar. The Bypass melintasi memeriksa pengguna benar cek hak-hak pengguna dalam snap-in kebijakan grup. Secara default, Semua orang kelompok diberikan Bypass melintasi memeriksa pengguna benar.
Untuk file: Mengeksekusi File izin memungkinkan atau menolak akses ke file program yang sedang berjalan.

Jika Anda menetapkan Melintasi Folder izin pada folder, Mengeksekusi File izin tidak secara otomatis diatur pada semua file dalam folder.

·         Daftar Folder/membaca Data

Daftar Folder izin memungkinkan atau menyangkal pengguna dari melihat nama file dan nama-nama subfolder dalam folder. The Daftar Folder izin hanya berlaku untuk folder dan mempengaruhi hanya konten dari map tersebut. Izin ini tidak terpengaruh jika map yang Anda menetapkan izin pada tercantum dalam daftar folder.
The Baca Data izin hanya berlaku untuk file dan memungkinkan atau menyangkal pengguna melihat data dalam file.

·         Membaca atribut

Membaca atribut izin memungkinkan atau menyangkal pengguna dari melihat atribut file atau folder, seperti read-only dan tersembunyi atribut. Atribut ditentukan oleh NTFS.

·         Baca diperpanjang atribut

Baca diperpanjang atribut izin memungkinkan atau menyangkal pengguna dari melihat diperpanjang dengan atribut dari file atau folder. Diperpanjang dengan atribut yang didefinisikan oleh program dan mereka dapat bervariasi oleh program.

·         Membuat file/menulis Data

Membuat file izin hanya berlaku untuk folder dan memungkinkan atau menyangkal pengguna dari membuat file dalam folder.
Menulis Data izin hanya berlaku untuk file dan memungkinkan atau menyangkal pengguna dari membuat perubahan ke file dan mengganti konten yang ada dengan NTFS.

·         Membuat folder/menambahkan Data

Membuat folder izin hanya berlaku untuk folder dan memungkinkan atau menyangkal pengguna dari membuat folder dalam folder. Menambahkan Data izin hanya berlaku untuk file dan memungkinkan atau menyangkal pengguna dari membuat perubahan ke akhir file tetapi bukan dari mengubah, menghapus, atau Timpa data yang ada.        

·         Menulis atribut 

Menulis atribut izin memungkinkan atau menyangkal pengguna agar tidak mengubah atribut file atau folder, seperti hanya-baca atau tersembunyi. Atribut ditentukan oleh NTFS. Menulis atribut izin tidak menyiratkan bahwa Anda dapat membuat atau menghapus file atau folder. Ini mencakup hanya izin untuk membuat perubahan pada atribut file atau folder. Untuk mengizinkan atau menolak membuat atau menghapus operasi, lihat Membuat file/menulis Data, Membuat folder/menambahkan Data, Menghapus file dan subfolder, dan Hapus.

·         Menulis diperpanjang dengan atribut

Menulis diperpanjang dengan atribut izin memungkinkan atau menyangkal pengguna agar tidak mengubah diperpanjang dengan atribut dari file atau folder. Diperpanjang dengan atribut yang didefinisikan oleh program dan dapat bervariasi oleh program. Menulis diperpanjang dengan atribut izin tidak menyiratkan bahwa pengguna dapat membuat atau menghapus file atau folder, termasuk hanya izin untuk membuat perubahan pada atribut file atau folder. Untuk mengizinkan atau menolak membuat atau menghapus operasi, lihat Membuat file/menulis Data, Membuat folder/menambahkan Data, Menghapus file dan subfolder, dan Hapus bagian dalam artikel ini.

·         Menghapus file dan subfolder

Menghapus file dan subfolder izin hanya berlaku untuk folder dan memungkinkan atau menyangkal pengguna menghapus subfolder dan file, bahkan jika Hapus izin tidak diberikan pada subfolder atau file.

·         Hapus

The Hapus izin memungkinkan atau menyangkal pengguna menghapus file atau folder. Jika Anda tidak memiliki Hapus izin pada file atau folder, Anda dapat menghapus file atau folder jika Anda diberikan Menghapus file dan subfolder izin pada folder induk.

·         Baca ijin

Baca ijin izin memungkinkan atau menyangkal pengguna dari membaca izin tentang file atau folder, seperti Kontrol penuh, Baca, dan Menulis.

·         Ubah izin

Ubah izin izin memungkinkan atau menyangkal pengguna agar tidak mengubah hak akses pada file atau folder, seperti Kontrol penuh, Baca, dan Menulis.

·         Mengambil kepemilikan

Mengambil kepemilikan izin memungkinkan atau menyangkal pengguna dari mengambil kepemilikan atas berkas atau map. Pemilik file atau folder dapat mengubah hak akses pada itu, terlepas dari izin ada yang melindungi file atau folder.

·         Menyinkronkan

Menyinkronkan izin memungkinkan atau menyangkal benang yang berbeda menunggu pada pegangan untuk file atau folder dan menyinkronkan dengan benang lain yang mungkin sinyal itu. Izin ini berlaku hanya untuk multi-threaded, multi-proses program.

Mengubah Setting Hak Akses di Windows

Masuk pada lokasi instalasi BeeAccouniting => Klik "Properties"

Klik Button "Add..."

Ketik "Everyone" => Tekan "Ok"

 Pada  Group or User names, pilih "Everyone" =>   Klik pada "Full Control" => Tekan "Ok"

Cara Compile Kernel

Compile kernel bertujuan untuk meringankan tugas sistem dalam me-load kernel yang ada. Hal ini karena tidak semua komponen yang digunakan ketika kita menggunakan komputer. Dengan demikian, proses boot akan menjadi lebih cepat.

Berikut ini langkah yang harus dilakukan untuk compile kernel, yaitu :
1.    Pertama download dulu kernelnya di kernel.org atau klik ini. Ingat download yang versi stabil ya..
2.    Setelah di download langsung aja ekstrak ke direktory /usr/src. (misalnya kernel tadi ada di direktory /home/aim/Downloads), jadi kita ke direktory tersebut dulu dengan mengetikkan kode di terminal:
# cd /home/aim/Downloads.
3.    Setelah itu ketik # ls dan lihat adakah file kernel kita?
4.    Kalau ada langsung aja kita ekstrak filenya dengan code:
# tar xjvf linux-3.0.tar.bz2 -C /usr/src/
5.    Setelah di ekstrak tadi maka langsung aja kita ke direktory /usr/src. Codenya:
# cd /usr/src
6.    Lalu liat kernel yang udah di ekstrak tadi ada tidak dengan code # ls. Maka akan menghasilkan file:
linux linux-2.6.37.6 linux-3.0
7.    Setelah itu kita masuk ke direktory linuxnya dengan code:
# cd /usr/src/linux-3.0
(karena kernel yang saya pakai dan ekstrak tadi adalah versi 3.0). Lalu baca file README-nya dengan code:
# cat /usr/src/linux-3.0/README
8.    Apabila ada perintah kayak gini make mrproper (untuk install), maka kita harus kutin dulu baru kelangkah selanjutnya. code:
# make mrproper
9.    Ini adalah tahap pertama kompile. Karena kita hanya akan meng-upgrade kernel pada saat ini, jadi kita copy config kernel yang lama dari direktori /boot. caranya kita liat dulu dengan perintah
# ls /boot. Misal akan keluar seperti ini:
README.initrd config-huge-smp-2.6.37.6-smp
System.map diag1.img
System.map-generic-2.6.37.6 diag2.img
System.map-generic-smp-2.6.37.6-smp initrd-tree
System.map-huge-2.6.37.6 initrd.gz
System.map-huge-smp-2.6.37.6-smp map
boot.0800 slack.bmp
boot_message.txt vmlinuz
config vmlinuz-generic-2.6.37.6
config-generic-2.6.37.6 vmlinuz-generic-smp-2.6.37.6-smp
config-generic-smp-2.6.37.6-smp vmlinuz-huge-2.6.37.6
config-huge-2.6.37.6 vmlinuz-huge-smp-2.6.37.6-smp
10.    Copy file confignya dengan code:
# cp /boot/config-generic-2.6.37.6 /usr/src/linux-3.0/.config
11.    Oke selanjutkan kita akan membuat Sym-link arsip kernel baru. Pada bagian ini kita harus membuat symbolic link (shortcut) buat kernel linux yang baru. Tapi sebelum itu kita hapus dulu symbolic link yang dibuat oleh Slackware/linux ente (default). Codenya:
# cd /usr/src/
# rm linux
# ln -s linux-3.0 linux
12.    Kalau udah sekarang saatnya kita ke direktory linuxnya dengan code:
# cd /usr/src/linux
13.    Nah sekarang kita memasuki tahap yang membutuhkan ketelitian yang tinggi dan jangan sampai salah
14.    make menuconfig (modus text)
make xconfig (modus grafik, QT)
make gconfig (modus grafik, GTK)
make oldconfig (modus text pake konfigurasi kernel yang lama)
Ane saranin si pake menuconfig aja. dengan code:
# make menuconfig
(abis itu langsung save lagi ya)
15.    Nah dalam menuconfig itu kita harus hati-hati ya dan teliti. Harus sesuah dengan spesifikasi kompi kita. Untuk mengetahui spesifikasi kompi kita bisa ketik diterminal #lspci dan # cat /proc/cpuinfo
16.    Nah kalau sudah dan saya anggap anda sudah benar mengeditnya, kita langsung kompile kernel aja ya? Code:
# make bzImage (untuk membuat image kernel).
Lumayan di kompi ane set jam.
17.    Selanjutnya adalah kita mengkompile modules (lumayan 1 jam di kompi ane). Code:
# make modules
18.    Nah yang ini adalah untuk mengistal modulesnya (sebentar gak nyampe 10 menit). COde:
# make modules_install
19.    Sekarang copy Image kernel,config, dan System.map baru Kalau ditemukan error, silahkan liat-liat lagi step-stepnya. Kalau normal dan ga ada masalah, kita akan mengcopy kernel image yang telah di kompile tersebut ke direktori /boot. Code:
# cp arch/i386/boot/bzImage /boot/vmlinuz-3.0.0-kernel-baru
# cp System.map /boot/System.map-3.0.0-kernel-baru
# cp .config /boot/config-3.0.0-kernel-baru
# cd /boot
# rm System.map (Hapus symbolic link System.map lama)
# rm config (Hapus symbolic link config lama)
# rm vmlinuz (Hapus symbolic link kernel image yg lama)
# ln -s vmlinuz-3.0.0-kernel-baru vmlinuz (symbolic link kernel baru)
# ln -s config-3.0.0-kernel-baru config (symbolic link config baru)
# ln -s System.map-3.0.0-kernel-baru System.map (symbolic link System.Map baru)
20.    Nah sekarang waktunya membuat Initrd (ini penting, jangan sampe kelewat ya)? Silakan membuat initrd agar kernel dapat meload partisi root. Masih di direktori /boot. Code:
# mkinitrd -c -k 3.0.0 -m jbd:ext4 -f ext4 -r /dev/sda1
(ini untuk file system ext2 samapi ext4 kalau gak salah dan untuk selain itu beda codenya). Oya jangan sampai salah ya untuk /dev/sda1-nya. Untuk itu harus di cek dulu dimana partisi root linux kita denga perintah
# fdisk -l.
21.    Terakhir kita edit liloya (atau grub). Karena disini saya pakai lilo, maka saya akan jelaskan cara memakai lilo. Untuk grub silahkan cari di www.google.com :D.
pertama lihat dulu direktory /boot dengan ls /boot. Code:
# ls /boot
README.initrd config initrd.gz
System.map config-3.0.0 map
System.map-3.0.0 config-generic-2.6.37.6 slack.bmp
System.map-generic-2.6.37.6 config-generic-smp-2.6.37.6-smp vmlinuz
System.map-generic-smp-2.6.37.6-smp config-huge-2.6.37.6 vmlinuz-3.0.0
System.map-huge-2.6.37.6 config-huge-smp-2.6.37.6-smp vmlinuz-generic-2.6.37.6
System.map-huge-smp-2.6.37.6-smp diag1.img vmlinuz-generic-smp-2.6.37.6-smp
boot.0800 diag2.img vmlinuz-huge-2.6.37.6
boot_message.txt initrd-tree vmlinuz-huge-smp-2.6.37.6-smp
Barulah atur lilonya
# nano /etc/lilo.conf
(akan menghasilkan dan edit menjadi sepeti ini contohnya)
# LILO configuration file
# generated by ‘liloconfig’
#
# Start LILO global section
boot = /dev/sda
#compact # faster, but won’t work on all systems.
# Boot BMP Image.
# Bitmap in BMP format: 640×480×8
bitmap = /boot/slack.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), “spill” (this is how many
# entries must be in the first column before the next begins to
# be used. We don’t specify it here, as there’s just one column.
bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
bmp-timer = 65,27,0,255
# Standard menu.
# Or, you can comment out the bitmap menu above and
# use a boot message with the standard menu:
#message = /boot/boot_message.txt
# Append any additional kernel parameters:
append=” vt.default_utf8=0″
prompt
timeout = 50
# Normal VGA console
vga = normal
# Ask for video mode at boot (time out to normal in 30s)
#vga = ask
# VESA framebuffer console @ 1024×768×64k
# vga=791
# VESA framebuffer console @ 1024×768×32k
# vga=790
# VESA framebuffer console @ 1024×768×256
# vga=773
# VESA framebuffer console @ 800×600×64k
# vga=788
# VESA framebuffer console @ 800×600×32k
# vga=787
# VESA framebuffer console @ 800×600×256
# vga=771
# VESA framebuffer console @ 640×480×64k
# vga=785
# VESA framebuffer console @ 640×480×32k
# vga=784
# VESA framebuffer console @ 640×480×256
# vga=769
# ramdisk = 0 # paranoia setting
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz
initrd = /boot/initrd.gz
root = /dev/sda1
label = Slackware
read-only
# Linux bootable partition config ends
# Linux Kernel Dokter jaga 24 jam
image = /boot/vmlinuz-huge-2.6.37.6
initrd = /boot/initrd.gz
root = /dev/sda1
label = LinuxDarurat
read-only
# Linux bootable partition config ends
22.    Lalu jalankan lilo -v di terminal
23.    Kita restart
Bila ada yang error itu adalah alsactl error saat hidupin kompi (dan cara benerinnya cukup ketik alsactl restore). Lalu setelah itu touchpad laptop saya tidak bisa scroll ke atas/ke bawah/kiri/kanan. Sebenarnya itu bukan error kok, tapi untuk mengatasinya agar bisa scroll cukup taruh aja 2 jari ke touchpadnya, lalu drag, alhasil bisa di scroll.

Deadlock

Deadlock adalah suatu kondisi dimana proses tidak berjalan lagi ataupun tidak ada komunikasi lagi antar proses di dalam sistem operasi. Deadlock disebabkan karena proses yang satu menunggu sumber daya yang sedang dipegang oleh proses lain yang sedang menunggu sumber daya yang dipegang oleh proses tersebut.



Ketika deadlock pada UNIX bagaimana cara mengatasi nya …Jika pada windows adam 3 ,yaitu
1. Preemption
2. Melacak kembali
3. Menghentikan (membunuh) proses
Strategi untuk menghadapi deadlock dapat dibagi menjadi tiga pendekatan, yaitu:
1. Mengabaikan adanya deadlock.
2. Memastikan bahwa deadlock tidak akan pernah ada, baik dengan metode Pencegahan, dengan mencegah empat kondisi deadlock agar tidak akan pernah terjadi. Metode Menghindari deadlock, yaitu mengizinkan empat kondisi deadlock, tetapi menghentikan setiap proses yang kemungkinan mencapai deadlock.
3. Membiarkan deadlock untuk terjadi, pendekatan ini membutuhkan dua metode yang saling mendukung, yaitu:
1. Pendeteksian deadlock, untuk mengidentifikasi ketika deadlock terjadi.
2. Pemulihan deadlock, mengembalikan kembali sumber daya yang dibutuhkan pada proses yang memintanya.
Dari penjabaran pendekatan diatas, terdapat empat metode untuk mengatasi deadlock yang akan terjadi, yaitu:
Strategi Ostrich
Pendekatan yang paling sederhana adalah dengan menggunakan strategi burung unta: masukkan kepala dalam pasir dan seolah-olah tidak pernah ada masalah sama sekali. Beragam pendapat muncul berkaitan dengan strategi ini. Menurut para ahli Matematika, cara ini sama sekali tidak dapat diterima dan semua keadaan deadlock harus ditangani. Sementara menurut para ahli Teknik, jika komputer lebih sering mengalami kerusakkan disebabkan oleh kegagalan hardware, error pada kompilator atau bugs pada sistem operasi. Maka ongkos yang dibayar untuk melakukan penanganan deadlock sangatlah besar dan lebih baik mengabaikan keadaan deadlock tersebut. Metode ini diterapkan pada sistem operasi UNIX dan MINIX.
•    Pada windows NT, deteksi deadlock yaitu berupa BSOD(Blue Screen Of Death), recoverynya adalah reboot sederhana
•    Pada linux untuk mengetahui apakah terjadi deadlock yaitu dengan menggunakan xosview untuk mengetahui proses yang menggunakan CPU 100%, lalu kill saja proses tersebut.
•    Linux dengan kernel versi 2.4 mengalami deadlock pada sistem dengan prosesor lebih dari 2 unit
•    Deadlock ini pada umumnya terjadi bila akses melalui Ethernet dilakukan, terutama bila melakukan teaming pada jaringan. Proses akan terblock dan saling menunggu resource Ethernet tersebut bebas.
•    Beberapa kasus deadlock juga terjadi ketika OS Linux dijalankan dari kondisi sleep, proses yang mengakses USB device akan mengalami deadlock
•    Hal ini disebabkan fungsi scheduler pada kernel yang digunakan tidak menyimpan state sebelum sleep, sehingga ketika kernel dijalankan kembali, Proses-proses yang mengakses USB device tersebut menunggu giliran mengakses, sementara scheduler belum menjadwalkan masing-masing proses.
•    Kasus ini juga terjadi pada Serial device
•    Deadlock bisa diatasi oleh berbagai strategi : prevention, avoidance, detection and recovery.
•    Prevention : memastikan paling sedikit satu penyebab Deadlock tidak berlaku
Mutual Exclusion : membuat file spool untuk resource yang digunakan bersama-sama
Hold and Wait : memaksa sebuah proses untuk melepaskan resource yang dimilikinya ketika meminta resource baru
Circular Waiting : memberikan penamaan resource berdasarkan urutan atau level
No Preemption : membolehkan adanya preemption
•    Avoidance : sistem menolak request terhadap resource yang berpotensi deadlock, Algoritma Banker.
Resource manager menolak proses yang meminta resource yang berpotensi deadlock
Jika ada permintaan resource yang maksimum digunakan, maka proses tersebut akan dipaksa untuk melepaskan resource yang sudah dimiliknya
Perlu adanya informasi tambahan
•    Detection and Recovery : membiarkan Deadlock terjadi, lalu mendeteksinya, kemudian melakukan recovery, Algoritma Ostrich
Membiarkan deadlock terjadi lalu mendeteksinya kemudian melakukan tindakan recovery seperlunya
Algoritma yang paling dikenal adalah algoritma Ostrich
Tindakan recovery yang dilakukan adalah : melakukan preemption, membuat checkpoint untuk rollback lalu membunuh proses yang prioritasnya kecil.

Integrasi Sistem dari SOA

Integrasi sistem
Dalam konteks sistem informasi, sistem integrasi (integrated system) merupakan sebuah rangkaian proses untuk mengubungkan beberapa sistem-sistem komputerisasi dan software aplikasi baik secara fisik maupun secara fungsional. Sistem integrasi akan menggabungkan komponen sub-sub sistem ke dalam satu sistem dan menjamin fungsi-fungsi dari sub sistem tersebut sebagai satu kesatuan sistem. Sistem integrasi merupakan tantangan menarik dalam software development karena pengembangannya harus terus mengacu pada konsistensi sistem, agar sub-sub sistem yang sudah ada dan tetap dimanfaatkan secara operasional masih tetap berfungsi sebagaimana mestinya baik ketika proses mengintegrasikan sistem maupun setelah terintegrasi. Tantangannya adalah bagaimana merancang sebuah mekanisme mengintegrasikan sistem-sistem tersebut dengan effort paling minimal – bahkan jika diperlukan, tidak harus melakukan refactoring atau re-developing lagi sistem-sistem yang sudah ada.
Ada beberapa metode yang dapat dipergunakan dalam membangun sistem terintegrasi, yaitu :
•    Vertical Integration, merupakan proses mengintegrasikan sub-sub sistem berdasarkan fungsionalitas dengan menghubungkan sub-sub sistem yang sudah ada tersebut supaya bisa berinteraksi dengan sistem terpusat dengan tetap berpijak pada arsitektur sub sistem yang lama. Metode ini memiliki keuntungan yaitu dapat dilakukan dengan cepat dan hanya melibatkan beberapa entitas development yang terkait dalam proses pembuatan sistem lama. Kelemahannya, metode ini tidak memungkinkan untuk mengimplementasikan fungsi-fungsi baru atau proses bisnis baru ke dalam sub-sistem yang sudah ada – karena effort lebih tinggi ada di proses“mempelajari” arsitektur sistem lama dan menjadikannya acuan untuk membuat sistem terintegrasi. Untuk menghadirkan ekspansi fungsionalitas atau proses bisnis baru adalah harus membuat sub-sistem baru.
•    Star Integration, atau lebih dikenal sebagai spaghetti integration, adalah proses mengintegrasikan sistem dengan cara menghubungkan satu sub sistem ke semua sub-sub sistem lainnya. Sebuah fungsi bisnis yang diimplementasikan dalam sebuah sub sistem akan di-broadcast ke semua sub-sub sistem lain yang dependen terhadap fungsi bisnis tersebut supaya dapat dipergunakan sebagaimana mestinya. Untuk integrasi sistem dengan ruang lingkup kecil atau menengah dan dengan pemisahan fungsi bisnis yang jelas dan spesifik, metode integrasi ini layak untuk dipertimbangkan. Namun jika fungsi bisnis banyak terlibat di beberapa sub sistem secara dependen, pada akhir proses integrasi sistem akan terlihat sedikit “kekacauan” dalam diagram – proses interkoneksi antar sub sistem akan tampak seperti spaghetti. Efeknya, biaya perawatan dan ekspansi sistem di masa yang akan datang akan memerlukan effort yang sangat berat untuk mempelajari skema integrasi sistem berikut dependency-nya.
•    Horizontal Integration, atau ada yang mengistilahkan dengan Enterprise Service Bus (ESB), merupakan sebuah metode yang mengintegrasikan sistem dengan cara membuat suatu layer khusus yang berfungsi sebagaiinterpreter, dimana semua sub-sub sistem yang sudah ada akan berkomunikasi ke layer tersebut. Model ini lebih menawarkan fleksibilitas dan menghemat biaya integrasi, karena yang perlu difokuskan dalam implementasi proses pengintegrasian hanya layer interpreter tersebut.  Untuk menangani ekspansi proses bisnis juga hanya perlu diimplementasikan di layer interpreter itu juga, dan sub sistem baru yang akan menangani interface dari proses bisnis ekstensi tersebut akan berkomunikasi langsung ke layer dan layer akan menyediakan keperluan-keperluan data/interface untuk sub sistem lain yang memerlukannya.
Arsitektur dari SOA
Arsitektur berorientasi layanan atau disebut dengan SOA adalah suatu gaya arsitektur sistem yang membuat dan menggunakan proses bisnis dalam bentuk paket layanan sepanjang siklus hidupnya.  SOA juga mendefinisikan dan menentukan arsitektur TI yang dapat menunjang berbagai aplikasi untuk saling bertukar data dan berpartisipasi dalam proses bisnis. Fungsi-fungsi ini tidak terikat dengan sistem operasi dan bahasa pemrograman yang mendasari aplikasi-aplikasi tersebut.



SOA membagi fungsi-fungsi menjadi unit-unit yang berbeda (layanan), yang dapat didistribusikan melalui suatu jaringa dan dikombinasikan serta digunakan ulang untuk membentuk aplikasi bisnis. Layanan-layanan ini saling berkomunikasi dengan mempertukarkan data antar mereka atau dengan mengkoordinasikan
aktivitas antara dua atau lebih layanan.


Layer 1 OPERATIONAL SYSTEMS
Di layer ini meliputi sistem operasional yang telah ada disuatu perusahaan yang membantu aktifitas bisnis. Sistem operasional terdiri atas semua aplikasi buatan, system yang ada, system transaction-processing, serta database.
Layer 2 SERVICE COMPONENT LAYER
Komponen di layer ini disesuaikan dengan contract yang didefinisi oleh service yang ada di layer services. konsumer tidak menyadari service component, yang menenkapsulasi compleksitas dalam implementasi. keuntungan dari komponen facade ini adalah fleksibilitas terhadap perubahan system operasional tanpa merubah service definition.
Layer 3 SERVICES LAYER
Dalam layer ini meliputi semua services yang di definisi. definisi dari setiap service, seperti informasi syntatic dan semantic dijelaskan di layer ini. sedangkan informasi syntactic adalah dasar dari seluruh operasi dari service, seperti input output pesan, dan definisi dari kesalahan service, sedangkan informasi semantic adalah dasar dari polis service, seperti service management desicions, service access requirements, dan sebagainya.
Layer 4 BUSINESS PROCESS LAYER
Bisnis proses menjelaskan bagaimana sebuah bisnis berjalan. proses bisnis dalam representasi IT tentang bermacam-macam aktifitas yang terkoordinasi dan terkolaborasi di dalam enterprise untuk membentuk suatu fungsi bisnis tingkat tinggi yang spesifik. layer ini mewakili proses seperti orchestration atau composition of loosely coupled services. layer ini juga bertanggung jawab atas semua managemen lifecycle dari proses beserta dengan orchestration dan choreography.
Layer 5 COMSUMER LAYER
Layer ini menggambarkan berbagai saluran dimana fungsi-fungsi IT disalurkan.saluran tersebut dapat berupa tipe user yang berbeda beda seperti contohnya, komsumer external dan internal yang mengakses kemampuan aplikasi melalui mekanisme pengaksesan seperti B2B system, portals, rich clients, dan bentuk lainnya.

Arsitektur dari Codeigniter

Arsitektur dari Codeigniter
CodeIgniter adalah Aplikasi open source yang berupa framework dengan model MVC (Model, View, Controller) untuk membangun website dinamis dengan menggunakan PHP yang dikembangkan oleh EllisLab. CodeIgniter memudahkan developer untuk membuat aplikasi web dengan cepat dan mudah dibandingkan dengan membuatnya dari awal. Framework secara sederhana dapat diartikan kumpulan dari fungsi-fungsi/prosedur-prosedur dan class-class untuk tujuan tertentu yang sudah siap digunakan sehingga bisa lebih mempermudah dan mempercepat pekerjaan seorang pemrograman, tanpa harus membuat fungsi atau class dari awal.



Ada beberapa kelebihan CodeIgniter (CI) dibandingkan dengan Framework PHP lain,
* Performa sangat cepat : salah satu alasan tidak menggunakan framework adalah karena eksekusinya yang lebih lambat daripada PHP from the scracth, tapi Codeigniter sangat cepat bahkan mungkin bisa dibilang codeigniter merupakan framework yang paling cepat dibanding framework yang lain.
* Konfigurasi yang sangat minim (nearly zero configuration)  : tentu saja untuk menyesuaikan dengan database dan keleluasaan routing tetap diizinkan melakukan konfigurasi dengan mengubah beberapa file konfigurasi seperti database.php atau autoload.php, namun untuk menggunakan codeigniter dengan setting standard, anda hanya perlu merubah sedikit saja file pada folder config.
* Banyak komunitas: dengan banyaknya komunitas CI ini, memudahkan kita untuk berinteraksi dengan yang lain, baik itu bertanya atau teknologi terbaru.
* Dokumentasi yang sangat lengkap : Setiap paket instalasi codeigniter sudah disertai user guide yang sangat bagus dan lengkap untuk dijadikan permulaan, bahasanya pun mudah dipahami.



Dibawah folder codeigniter yang sudah ditaruh di webserver tersebut terdapat 2 folder di dalamnya, yaitu folder system dan user guide, anda tidak bekerja dengan folder user guide, jadi menghapus folder tersebut tidak berimbas apapun pada aplikasi web anda.
Langsung saja menuju folder system, di dalam folder tersebut terdapat banyak folder yang sedikit membuat anda bertanya-tanya, untuk apakah folder tersebut? Tenang saja, kita juga tidak akan menggunakan semua folder yang berada disitu.
Dimanakah kita akan meletakkan file-file php kita saat membuat aplikasi? Sekarang buka folder application, disini kita akan mulai berkreatifitas dengan codeigniter. Perhatian kita pusatkan saja pada folder config, controller, models, dan views. Folder config berisi file-file yang dibutuhkan untuk konfigurasi aplikasi yg akan dibuat, seperti konfigurasi database, autoloads, routes. Di dalam folder controllers adalah tempat kita meletakkan semua controller aplikasi.
Ada beberapa kelebihan CodeIgniter (CI) dibandingkan dengan Framework PHP lain,
Performa sangat cepat : salah satu alasan tidak menggunakan framework adalah karena eksekusinya yang lebih lambat daripada PHP from the scracth, tapi Codeigniter sangat cepat bahkan mungkin bisa dibilang codeigniter merupakan framework yang paling cepat dibanding framework yang lain.
Konfigurasi yang sangat minim (nearly zero configuration) : tentu saja untuk menyesuaikan dengan database dan keleluasaan routing tetap diizinkan melakukan konfigurasi dengan mengubah beberapa file konfigurasi seperti database.php atau autoload.php, namun untuk menggunakan codeigniter dengan setting standard, anda hanya perlu merubah sedikit saja file pada folder config.
Banyak komunitas: dengan banyaknya komunitas CI ini, memudahkan kita untuk berinteraksi dengan yang lain, baik itu bertanya atau teknologi terbaru.
Dokumentasi yang sangat lengkap : Setiap paket instalasi codeigniter sudah disertai user guide yang sangat bagus dan lengkap untuk dijadikan permulaan, bahasanya pun mudah dipahami.
Dan banyak lagi yang lainnya.


1.    index.php berfungsi sebagai controller depan, mnginisialisasi basic resource yang dibutuhkah untuk menjalankan CI.
2.    Router menganalisa HTTP request untuk menentukan apa yang harus dilakukan dengan HTTP request itu.
3.    Jika file cache masih ada , maka akan dikirim langsung ke browser, tanpa melewati eksekusi normal sistem.
4.    Keamanan, sebelum controller aplikasi di panggil, HTTP request dan data yang dikirim user, di filter untuk alasan keamanan.
5.    Controller memanggil model, librari inti , plugin, helper, dan resource lainnya yang di butuhkan untuk memroses request tertentu.

MVC dan Struts

Model-View-Controller atau MVC adalah sebuah metode untuk membuat sebuah aplikasi web dengan memisahkan data (Model) dari tampilan (View) dan cara bagaimana memprosesnya (Controller). Dalam implementasinya kebanyakan framework  dalam apilaksi website  adalah berbasis arsitektur  MVC. MVC memisahkan pengembangan aplikasi berdasarkan komponen utama yang membangun sebuah aplikasi seperti manipulasi data, antarmuka pengguna, dan bagian yang menjadi kontrol dalam sebuah aplikasi web.
Bagian dari MVC :
1. Model, Model mewakili struktur data. Biasanya model berisi fungsi-fungsi yang membantu seseorang dalam pengelolaan basis data seperti memasukkan data ke basis data, pembaruan data dan lain-lain.
2. View, View adalah bagian yang mengatur tampilan ke pengguna. Bisa di katakan berupa halaman web web.
3. Controller, Controller merupakan bagian yang menjembatani model dan view. Controller berisi skrip-skrip php yang berfungsi untuk memproses suatu data dan mengirimkannya ke halaman web.



Dengan menggunakan metode MVC maka aplikasi akan lebih mudah untuk dirawat dan dikembangkan. Untuk memahami metode pengembangan aplikasi menggunakan MVC diperlukan pengetahuan tentang pemrogram berorientasi objek (Object Oriented Programming).
Jenis MVC pada website
* Server Side MVC, Server Side MVC biasa terjadi pada aplikasi web tradisional, yang tidak melibatkan client side seperti Javascript, Java applet, Flash, dan lain-lain. Server Side MVC menyerahkan keseluruhan proses bisnis pada server, aplikasi pada sisi pengguna hanya dapat menerima. MVC jenis ini kadang-kadang disebut juga dengan nama Thin Client.[2]
* Mixed Client Side and Server Side MVC, Pada Mixed Client Side and Server Side MVC 1 client tidak menggunakan model sebagai jembatan untuk melakukan komunikasi pada server, dibandingkan dengan Server Side MVC, arsitektur ini memiliki tingkat kompleksitas yang lebih tinggi karena lebih banyak komponen yang terlibat. Untuk selanjutnya arsitektur ini disebut, dengan Mixed MVC 1. Pada Mixed Client Side and Server Side MVC 2, client menggunakan model sebagai jembatan untuk melakukan komunikasi pada server, dibandingkan dengan arsitektur MVC yang lain, arsitektur ini memiliki tingkat kompleksitas yang paling tinggi karena lebih banyak komponen yang terlibat, sehingga membutuhkan  sumber daya yang lebih besar pula. Untuk selanjutnya arsitektur ini disebut dengan Mixed MVC 2.[2]
* Rich Internet Application MVC, Application MVC Rich Internet Application (RIA) disebut juga dengan nama Fat Client, merupakan aplikasi web yang memiliki kemampuan dan fungsi hampir seperti aplikasi desktop. RIA pada sisi client, memiliki mesin untuk mengambil data yang berada pada server, sehingga pada client terdapat bagian MVC sendiri dan hanya membutuhkan bagian model pada sisi server.[2]

Struts adalah Frame Work Open Source yang di pakai untuk membangun aplikasi berbasis Web. yang sudah terinstregasi dengan standard technologi seperti Servlet, Java Beans dan Java Server Pages. Struts memiliki banyak keuntungan bagi pengembang web aplikasi. Juga sangat cocok dalam penerapan MVC di aplikasi berbasis web.

Kebutuhan Rekayasa

Kebutuhan Rekayasa (RE) meliputi kegiatan yang sangat penting bagi keberhasilan rekayasa Web. Persyaratan tidak lengkap, ambigu, atau tidak benar dapat menyebabkan kesulitan berat dalam pembangunan, atau bahkan menyebabkan pembatalan proyek. RE berkaitan dengan prinsip-prinsip, metode, dan alat untuk memunculkan, menjelaskan, validasi, dan mengelola persyaratan. Dalam rekayasa Web RE harus mengatasi tantangan khusus seperti stakeholders tidak tersedia, persyaratan mudah menguap dan kendala, lingkungan operasional tak terduga, pengalaman dengan teknologi web, pentingnya aspek tertentu dari kualitas seperti kegunaan, atau kinerja. Oleh karena itu, ketika mengadopsi metode RE yang ada dalam rekayasa Web, prinsip penting yang harus disimpan dalam pikiran yaitu : keterlibatan stakeholder, berulang identifikasi persyaratan, kesadaran arsitektur sistem ketika mendefinisikan persyaratan, dan orientasi resiko konsekuen.
Pengenalan
RE berkaitan dengan prinsip-prinsip, metode, dan alat untuk mengidentifikasi, mendeskripsikan, memvalidasi, dan mengelola persyaratan dalam pengembangan sistem. Saat ini, metode RE banyak dan alat yang tersedia. Namun, pendekatan ini sering tidak diterapkan oleh para praktisi dan RE sering dilakukan dalam cara ad-hoc, khususnya di bidang teknik Web. Meskipun kompleksitas aplikasi web hari ini memerlukan pendekatan yang lebih sistematis, kematangan proses RE sering tidak cukup.
Pada tahun 1976 dalam artikel berjudul Persyaratan Software, Bell dan Thayer menekankan bahwa persyaratan tidak berubah secara otomatis, tetapi harus diidentifikasi dalam suatu kegiatan rekayasa.
Pada awal 1980-an, Boehm mempelajari biaya cacat dalam persyaratan dan menemukan bahwa penghapusan akhir dari cacat yang belum ditemukan adalah sampai 200 kali lebih mahal dari pada identifikasi awal dan koreksi. dan Dalam artikelnya Silver Bullet, Brooks menekankan bahwa iteratif pengumpulan dan penyempurnaan persyaratan yang yang paling penting fungsi seorang insinyur perangkat lunak untuk pelanggan.
Fundamentals
Tujuan individu dan harapan stakeholder adalah titik awal dari persyaratan proses elisitasi. Stakeholder adalah orang-orang atau organisasi yang memiliki pengaruh langsung atau tidak langsung pada persyaratan dalam pengembangan sistem (Kotonya dan Sommerville 1998). Yang terpenting stakeholder adalah pelanggan, pengguna, dan pengembang. Stakeholder Khas untuk aplikasi Web yaitu termasuk  konten penulis, pakar domain, ahli kegunaan, atau profesional pemasaran. Tujuan dan harapan stakeholder sering cukup beragam, seperti yang ditunjukkan oleh beberapa contoh :
• Aplikasi Web akan tersedia secara online tanggal 1 September 2006 (kendala pelanggan).
• Aplikasi Web akan mendukung minimal 2500 pengguna bersamaan (kualitas obyektif pelanggan).
• J2EE harus digunakan sebagai platform pengembangan (teknologi harapan pengembang).
• Semua data pelanggan harus aman disampaikan (kualitas obyektif dari pengguna).
• User interface akan mendukung layout untuk kelompok pelanggan yang berbeda (tujuan kualitas customer).
• Seorang pengguna sewenang-wenang akan dapat menemukan produk yang diinginkan dalam waktu kurang dari tiga menit (kegunaan Tujuan pelanggan).
• Seorang pengguna akan dapat memilih ikon untuk menampilkan artikel termasuk dalam keranjang belanja setiap diberi waktu (kemampuan tujuan pengguna).
Kegiatan Kebutuhan Rekayasa
RE meliputi elisitasi, dokumentasi, verifikasi dan validasi, serta persyaratan manajemen seluruh proses pembangunan.
- Persyaratan elisitasi dan Negosiasi
Para peneliti telah menunjukkan bahwa “persyaratan tidak keluar untuk dikumpulkan dengan meminta hak pertanyaan “(Nuseibeh dan Easterbrook 2000). Sebaliknya, persyaratan adalah hasil belajar yang dan konsensus-proses pembangunan (Boehm et al 2001,. Lowe dan Eklund 2002). Dalam proses ini, komunikasi antara para pemangku kepentingan sangat penting, karena hanya keahlian mereka bersama dapat menyebabkan saling diterima solusi. Satu set macam metode dan alat kolaboratif yang tersedia untuk memfasilitasi komunikasi dan pertukaran pengetahuan di RE. Contoh termasuk teknik kreativitas, berbasis skenario metode, proses keputusan multikriteria, teknik fasilitasi, wawancara, atau analisis dokumen (Nuseibeh dan Easterbrook 2000).
- Persyaratan Dokumentasi
Jika stakeholder mencapai konsensus, kesepakatan mereka harus disempurnakan dan dijelaskan dalam persyaratan dokumen tingkat detail dan formalitas yang sesuai untuk proyek konteks. Pemilihan tingkat yang sesuai detail dan formalitas tergantung pada kedua risiko proyek diidentifikasi dan pengalaman serta keterampilan dari para pembaca yang diharapkan. Informal deskripsi seperti cerita pengguna, dan semi formal deskripsi seperti kasus penggunaan, terutama relevan dalam rekayasa web.
- Persyaratan Verifikasi dan Validasi
Persyaratan harus divalidasi  dan diverifikasi. Ada beberapa metode konvensional untuk tujuan ini, seperti ulasan, inspeksi, atau prototyping (Halling et al. 2003). Dalam Rekayasa Web, keterbukaan Internet memfasilitasi bentuk-bentuk baru dari partisipasi pengguna langsung dalam validasi persyaratan, misalnya, melalui koleksi online dari umpan balik pengguna (Deshpande et al. 2002).
- Persyaratan Manajemen
Alih-alih menjadi stabil, persyaratan yang sering tunduk pada perubahan. Perubahan persyaratan dan kendala adalah karakteristik utama dari proyek Web. Metode dan alat untuk mendukung kebutuhan manajemen baik integrasi persyaratan baru dan perubahan dengan persyaratan yang ada. Mereka juga membantu dalam mengevaluasi dampak dari perubahan dengan mengelola saling ketergantungan di antara persyaratan, dan antara kebutuhan dan pembangunan lainnya artefak (traceability). Karena kesulitan manajemen persyaratan bahkan cukup sistem yang kompleks, alat-alat yang biasanya digunakan untuk mendukung tugas ini.
RE Spesifik Teknik Web
RE untuk teknik Web berbeda dari RE untuk sistem software konvensional. Perbedaan tampaknya diabaikan oleh para peneliti di lapangan: “Meskipun ada banyak perbedaan antara pengembangan Web dan pengembangan perangkat lunak ada juga kesamaan di antara Persyaratan elisitasi (Deshpande et al. 2002). Namun, jika kita melihat lebih dekat di beberapa spesifik, perbedaan menjadi jelas. Itu sub bagian berikut mengeksplorasi tersebut dengan menggunakan karakteristik aplikasi Web dibahas dalam Bab 1 (Lowe 2003).
- Multidisciplinarity
Pengembangan aplikasi Web memerlukan partisipasi dari para ahli dari berbagai disiplin. Contoh termasuk ahli multimedia, penulis konten, arsitek software, kegunaan ahli, spesialis database, atau ahli domain. Heterogenitas dan multidisciplinarity dari stakeholder membuatnya menantang untuk mencapai konsensus ketika mendefinisikan persyaratan. Masalah ini diperparah sebagai orang-orang dari berbagai disiplin ilmu memiliki bahasa mereka sendiri dan jargon yang perlu didamaikan.
- Ketidaktersediaan Stakeholder
Banyak pihak, seperti pengguna Web potensial, masih belum diketahui selama kegiatan RE. Proyek
manajemen perlu mencari perwakilan yang cocok yang dapat memberikan persyaratan yang realistis. Untuk Misalnya, sering ada spektrum yang luas dari pengguna mungkin dalam proyek Web dan menemukan wajar set perwakilan sulit.
- Persyaratan Volatilitas dan Kendala
Persyaratan dan kendala seperti sifat dari platform penyebaran atau komunikasi protokol sering lebih mudah untuk menentukan untuk sistem perangkat lunak konvensional daripada untuk Aplikasi Web.Aplikasi Web dan lingkungan mereka sangat dinamis dan persyaratan dan kendala biasanya sulit untuk menstabilkan. Contoh Sering perubahan inovasi teknologi tersebut sebagai pengenalan platform pengembangan baru dan standar, atau perangkat baru bagi pengguna akhir.
- Tak Terduga Operasional Lingkungan
Lingkungan operasional dari aplikasi Web juga sangat dinamis dan sulit diprediksi. Pengembang merasa sulit atau tidak mungkin untuk mengontrol faktor-faktor penting yang menentukan bagi userperceived kualitas Aplikasi Web. Misalnya, bandwidth perubahan mempengaruhi respon waktu aplikasi mobile, tetapi berada di luar lingkup tim pengembangan (Finkelstein dan Savigni 2001).
- Dampak Sistem Warisan
Pengembangan Aplikasi Web ditandai dengan integrasi perangkat lunak yang ada komponen seperti dari rak produk komersial atau perangkat lunak open source. Secara khusus, Pengembang web yang sering menghadapi tantangan untuk mengintegrasikan sistem warisan, misalnya ketika membuat sistem TI yang ada dari sebuah perusahaan dapat diakses melalui Web. Pengembang sering diminta untuk menggunakan komponen yang ada untuk alasan ekonomi. Komponen yang perlu diintegrasikan sangat mempengaruhi persyaratan dan gaya arsitektur dari sistem di masa depan. Dalam keadaan seperti pendekatan air terjun untuk mendapatkan arsitektur sistem dari persyaratan tidak akan berhasil, sebagai komponen yang ada, jasa, dan infrastruktur yang menentukan berbagai kemungkinan dan keterbatasan untuk pengembang. Ini berarti bahwa, ketika mengidentifikasi dan mendefinisikan persyaratan, pengembang web harus menyadari arsitektur sistem dan arsitektur kendala. Pendekatan iteratif seperti yang diusulkan dalam model Twin Peaks.









 - Signifikansi dari Aspek Kualitas
Aspek kualitas yang menentukan bagi keberhasilan aplikasi Web. Contohnya termasuk kinerja dari aplikasi Web seperti keamanan dalam e-commerce, ketersediaan, atau kegunaan. Meskipun signifikansi dari aspek kualitas, pengembang harus berurusan dengan masalah bahwa spesifikasi yang tepat kualitas persyaratan seringkali sulit atau bahkan sia-sia sebelum sistem sebenarnya dibangun. Sebagai contoh, waktu respon dari aplikasi Web tergantung pada banyak faktor yang berada di luar kendali pengembangan tim. Pendekatan layak untuk mendefinisikan persyaratan mutu adalah untuk menentukan kriteria untuk tes penerimaan menunjukkan apakah atau tidak persyaratan telah dipenuhi.
- Kualitas User Interface
Kualitas dari user interface adalah aspek lain keberhasilan kritis Aplikasi Web. Ketika mengembangkan Aplikasi Web pengembang perlu menyadari fenomena IKIWISI (I Know It When I See It). Pengguna tidak akan dapat memahami dan mengevaluasi aplikasi Web oleh hanya melihat model abstrak dan spesifikasi, melainkan mereka perlu bereksperimen dengan itu. Sekarang sehingga sangat penting untuk melengkapi definisi dan deskripsi persyaratan dengan menambahkan prototipe skenario aplikasi.
- Kualitas Konten
Banyak RE metode tradisional mengabaikan konten Web, meskipun merupakan aspek yang sangat penting dari aplikasi Web. Selain masalah teknologi perangkat lunak, pengembang harus mempertimbangkan isi, khususnya penciptaan dan pemeliharaan. Dalam konteks RE, itu sangat penting untuk menentukan kualitas yang dibutuhkan dari konten. Karakteristik kualitas penting termasuk akurasi, objektivitas, kredibilitas, relevansi, aktualitas, kelengkapan, atau kejelasan. Sistem manajemen konten (CMS) pentingnya keuntungan dan memungkinkan mewakili konten ringkas dan konsisten dengan memisahkan konten dari tata letak, dan menawarkan mengedit konten alat.
- Kurangnya pengalaman pengembang
Banyak dari teknologi yang mendasari dalam aplikasi web masih cukup baru. pengalaman dengan
teknologi ini pengembangan alat, standar, bahasa, dll dapat menyebabkan perkiraan yang salah ketika menilai kelayakan dan biaya pelaksanaan persyaratan.
- Tanggal Perusahaan Pengiriman
Proyek web Banyak desain untuk jadwal proyek, di mana semua kegiatan dan keputusan harus memenuhi deadline proyek tetap akhir.
Prinsip RE Aplikasi Web
Karakteristik Bagian sebelumnya membahas aplikasi Web dan spesifik RE di Web rekayasa. Kami telah menunjukkan bahwa RE untuk aplikasi Web harus berurusan dengan risiko dan ketidakpastian
seperti volatilitas persyaratan dan kendala, pengalaman dari para pengembang, atau dampak dari
warisan solusi. Pendekatan risiko berorientasi adalah pilihan yang baik untuk menghadapi tantangan ini. Dalam hal ini Bagian kita menggambarkan prinsip-prinsip dasar untuk RE Aplikasi Web. Pengembang web harus menjaga prinsip-prinsip berikut  ketika melakukan kegiatan RE :
- Memahami Konteks Sistem
- Melibatkan Stakeholder
- Iteratif Definisi Persyaratan
- Fokus pada Arsitektur Sistem
- Risiko Orientasi
Beradaptasi Metode RE untuk Pengembangan Aplikasi Web
Pada saat ini berbagai metode, pedoman, notasi, daftar periksa, dan alat-alat yang tersedia untuk semua kegiatan di RE. Namun, dalam rangka untuk berhasil pengembang harus menghindari “satu ukuran cocok untuk semua” Pendekatan, dan RE metode akibatnya harus disesuaikan dengan spesifikasi teknik Web dan situasi dari proyek-proyek tertentu. memandu definisi pendekatan proyek-spesifik RE untuk rekayasa Web. Antara lain, pengembang harus memperjelas aspek-aspek berikut selama proses adaptasi :
- Yang jenis persyaratan penting untuk Aplikasi Web?
- Bagaimana persyaratan untuk Aplikasi Web dijelaskan dan didokumentasikan?
- Haruskah penggunaan alat dipertimbangkan?
Persyaratan Jenis
Kedua badan standardisasi dan organisasi komersial telah mengembangkan sejumlah besar taksonomi untuk mendefinisikan dan mengklasifikasikan berbagai jenis kebutuhan. Contohnya adalah Volere . Taksonomi Kebanyakan membedakan antara persyaratan fungsional dan non-fungsional. Persyaratan fungsional menggambarkan kemampuan sistem dan layanan , Non-fungsional menggambarkan sifat kemampuan dan tingkat yang diinginkan dari layanan . Berikut ini secara singkat membahas jenis kebutuhan sangat relevan di Web proyek-proyek pembangunan :
•    Persyaratan Fungsional
•    Isi Persyaratan
•    Kualitas Persyaratan Meliputi : Fungsi, Keahlian, Usability, Efisiensi, Perawatan, portabilitas, Persyaratan Sistem Lingkungan, Persyaratan User Interface, Persyaratan evolusi dan Kendala Proyek.
Notasi
Sebagian besar notasi yang tersedia untuk menentukan persyaratan dalam derajat yang berbeda dari detail dan formalitas. Contoh termasuk cerita, spesifikasi diformat, atau spesifikasi formal. Resiko proyek yang diidentifikasi memberikan pengarahan dalam pemilihan tingkat yang cocok kualitas spesifikasi, yaitu, untuk menentukan berapa banyak RE cukup dalam proyek tertentu. Secara umum, pendekatan informal dan semi formal sangat cocok untuk Aplikasi Web.
Sejarah
Sejarah digunakan untuk menghasilkan pemahaman umum antara pelanggan dan pengembang. Sejarah pengguna diformulasikan oleh seorang pelanggan dalam bahasa dan istilah, dan menjelaskan masalah dan hal sistem yang harus dipecahkan.
Persaratan Terperinci
Spesifikasi sederhana dalam bahasa alami. Kebutuhan masing-masing memiliki unik identifier. Salah satu contoh yang baik adalah deskripsi item data sebagaimana ditentukan dalam IEEE/EIA-J-STD-016.
Spesifikasi Terformat
Spesifikasi diformat menggunakan sintaks akurat didefinisikan, tetapi memungkinkan bahasa alami deskripsi dalam bingkai ini. Contoh termasuk deskripsi kasus digunakan dalam Unified Modeling Language (UML) (Cockburn 2001), yang DRD-100 Persyaratan Bahasa Spesifikasi, MBASE tersebut SSRD Pedoman (Kitapci et al. 2003), atau Shell Volere (Robertson dan Robertson 1999).
Spesifikasi Formal
Spesifikasi resmi ditulis dalam bahasa yang menggunakan sintaks yang ditetapkan secara formal dan semantik. Contoh yang paling menonjol adalah “Z” (ISO/IEC13, 568:2002). Spesifikasi formal tidak digunakan untuk menentukan aplikasi Web, kecuali di daerah niche.
Kesesuaian
Membandingkan notasi yang berbeda berkaitan dengan atribut akurasi, mudah validasi, efektivitas biaya, kesesuaian untuk non-ahli, dan skalabilitas. Rendahnya untuk akurasi akan cukup untuk menentukan persyaratan Aplikasi Web dan validasi resmi biasanya tidak diperlukan.
Tools
Tools menggunakan kegiatan RE dasar. RE alat ada yang tidak terbatas pada aplikasi Web, tetapi dapat disesuaikan dengan spesifikasi Web pengembangan aplikasi.
- Persyaratan elisitasi
- Persyaratan Validasi
- Persyaratan Manajemen
Outlook
Spesifik RE untuk aplikasi Web. Pengantar singkat RE dan analisis dampak pengembangan aplikasi Web pada RE. Perkembangan beberapa di RE untuk Aplikasi Web di bawah ini:
- Menghilangkan perbatasan antara pengembangan dan penggunaan sistem
- Lebih baik integrasi persyaratan dan arsitektur
- Alat baru untuk rekayasa persyaratan didistribusikan
- RE dalam sistem terbuka

Perbedaan antara Pattern dan Framework

Pattern adalah Sebuah solusi untuk mengulang masalah design atau solusi umum yang dapat digunakan kembali pada permasalahan umum yang sering terjadi pada software design. Design pattern bukan desain final yang dapat ditransformasikan secara langsung kedalam kode  untuk mengetahui bagaimana menyelesaikan permasalahan yang dapat digunakan pada berbagai macam situasi yang berbeda. Design pattern dari object-oriented secara tipikal menunjukkan hubungan dan interaksi antara kelas dan objek tanpa menspesifikasikan kelas atau objek dari aplikasi final yang terlibat didalamnya.
Framework adalah Suatu struktur konseptual dasar yang digunakan untuk memecahkan atau menangani suatu masalah kompleks. Istilah ini sering digunakan antara lain dalam bidang perangkat lunak untuk menggambarkan suatu desain sistem perangkat lunak yang dapat digunakan kembali, serta dalam bidang manajemen untuk menggambarkan suatu konsep yang memungkinkan penanganan berbagai jenis atau entitas bisnis secara homogen. Framework dapat diartikan sebagai sebuah Kerangka kerja. Kerangka kerja dimana dapat memudahkan pekerjaan kita. Jika dikaitkan dengan PHP maka dapat diartikan sebagai suatu kerangka kerja yang telah terpola dan memudahkan pengembang web dalam pembuatan web yang menggunakan script PHP. Mempermudah yang dimaksud misalnya, Dalam membuat sebuah aplikasi web kita sering menulis script PHP secara keseluruhan (konvensional) dan itu pun kita ulang pada halaman yang lain. Bukankah itu begitu tidak efesien disamping berat ketika diload ? Dengan PHP Framework semua bisa teratasi. Semuanya sudah diatur menjadi pola-pola tertentu yang disebut dengan class. Pola/class inilah yang meringankan kita dalam penulisan script dan load halaman web.Framework yang dibangun harus menggunakan pola perancangan yang memisahkan logic application dan juga presentation view. Selain itu juga mampu mengoptimalkan penggunaan komponen yang dapat digunakan kembali, namun juga memberi keleluasaan untuk kostumisasi untuk kebutuhan tertentu.



Ada beberapa alasan mengapa menggunakan Framework:
- Mempercepat dan mempermudah pembangunan sebuah aplikasi web.
- Relatif memudahkan dalam proses maintenance karena sudah ada pola tertentu dalam  sebuah framework (dengan
syarat programmer mengikuti pola standar yang ada)
- Umumnya framework menyediakan fasilitas-fasilitas yang umum dipakai sehingga kita tidak perlu membangun dari awal
(misalnya validasi, ORM, pagination, multiple database, scaffolding, pengaturan session, error handling, dll
- Lebih bebas dalam pengembangan jika dibandingkan CMS.