« Perancangan Sistem Informasi Penentuan Angka Kredit Jabatan Fungsional Peneliti

Sistem Pendukung e-Learning di Web »

Posted on Tuesday, February 11th, 2003 at 11:37 am. About Jurnal, IT.

–>

Analisis dan Perancangan Prototipe Aplikasi E-Commerce

Dian Andriana

Abstract
Computer software application has been growing fast in this decade, also the web application, browser, and internet / intranet application. E-commerce has been long developed since when the EDI (Electronic Data Interchange) used in international business. This paper describes architecture, tool and configuration needed for implementing e-commerce web application, security system consideration, application flow diagram design, and database design. This application is developed using PHP programming language because it is easy to use, has many features for e-commerce implementation, capability for crossing platforms, also it is easy to deploy the application.

Abstrak
Aplikasi perangkat lunak komputer dan Internet telah berkembang pesat pada dasawarsa ini, demikian pula dengan aplikasi web dan browser internet maupun intranet. Aplikasi E-Commerce telah lama berkembang diawali dengan EDI (Electronic Data Interchange) yang telah berkembang dalam lingkup internasional. Dalam makalah ini diuraikan mengenai arsitektur sistem, tool dan konfigurasi yang diperlukan untuk mengimplementasi aplikasi web e-commerce, konsiderasi masalah keamanan sistem, juga perancangan dari sisi diagram alur aplikasi dan perancangan basis data. Digunakan bahasa pemrograman PHP karena kemudahan dalam pemrograman, dan kelengkapan fitur untuk mengimplementasi sistem e-commerce, kemampuan untuk cross platform, serta kemudahan untuk deployment bagi pengembang aplikasi.

1. Pendahuluan
Definisi E-Commerce ( Electronic Commerce) : E-commerce merupakan suatu cara berbelanja atau berdagang secara online atau direct selling yang memanfaatkan fasilitas Internet dimana terdapat website yang dapat menyediakan layanan “get and deliver“. E-commerce akan merubah semua kegiatan marketing dan juga sekaligus memangkas biaya-biaya operasional untuk kegiatan trading (perdagangan) .
Proses yang ada dalam E-commerce adalah sebagai berikut :
• Presentasi electronis (Pembuatan Web site) untuk produk dan layanan.
• Pemesanan secara langsung dan tersedianya tagihan.
• Otomasi account Pelanggan secara aman (baik nomor rekening maupun nomor Kartu Kredit).
• Pembayaran yang dilakukan secara Langsung (online) dan penanganan transaksi
Keuntungan yang diperoleh dengan menggunakan transaksi melalui E-commerce bagi suatu perusahaan adalah sebagai berikut :
• Meningkatkan pendapatan dengan menggunakan online channel yang biayanya lebih murah.
• Mengurangi biaya-biaya yang berhubungan dengan kertas, seperti biaya pos surat, pencetakan, report, dan sebagainya.
• Mengurangi keterlambatan dengan mengunakan transfer elektronik / pembayaran yang tepat waktu dan dapat langsung dicek.
• Mempercepat pelayanan ke pelanggan, dan pelayanan lebih responsif.

Gambar 1. Contoh Aplikasi E-Commerce : Pembelian CD dengan Kartu Kredit

2. Arsitektur dan Konfigurasi Sistem
Arsitektur dasar dari aplikasi web ini adalah arsitektur client/server. Artinya pemrosesan aplikasi ini dijalankan melibatkan kedua sisi yakni sisi mesin server pusat dan sisi client. Hal ini berbeda dengan misalnya aplikasi Microsoft Word yang hanya melibatkan satu sisi saja yaitu sisi client. Atau bagi pengguna mesin VAX yang hanya menggunakan sisi server saja sedangkan sisi client hanya dumb terminal saja yang tidak melakukan pemrosesan apapun di sisi client.

Gambar 2. Arsitektur Client/Server

2.1 Stateless Web Server
Untuk aplikasi E-Commerce ini web server harus dapat mengingat siapa / identitas pengguna yang sedang melakukan browsing setiap halaman. Pada dasarnya aplikasi web dan protokol HTTP adalah stateless. Artinya setiap merespon sebuah request HTTP, server akan selesai bekerja (complete) dan tidak melakukan pencatatan apa yang telah dilakukan oleh pengguna sebelumnya dan terhadap siapa identitas pengguna. Server memperlakukan informasi permintaan (request) secara serial, satu persatu pada saat request masuk. Tidak ada koneksi permanen (persistence) yang berjalan setelah sebuah halaman telah selesai dilayani / dikerjakan.

Gambar 3. Perbandingan State dalam Sistem Aplikasi: A.State yang kontinyu dalam aplikasi desktop, dan B.Stateless protokol dalam aplikasi web

Agar sebuah situs web mempunyai memori / state, dalam hal ini aplikasi ini mampu mengingat ‘siapa memesan apa’, beberapa informasi yang mengidentifikasi pengguna harus dikirim dengan setiap request halaman web. Informasi tersebut disimpan dengan menggunakan session.
Session tersebut dipergunakan untuk merekam / tracking aktivitas pengguna yang melalui sejumlah halaman pada website, misalnya pada jenis aplikasi Shopping Cart (kereta belanja). Direkam pula informasi identitas pengguna yang memiliki kereta belanja tersebut.
Dengan PHP, untuk penggunaan session ini mula-mula dilakukan pengaturan pada file php.ini yang menunjukkan session dimulai (start). Dengan ini PHP akan membuat suatu identifier unik dan file yang berkaitan, yang disimpan di server (lokasinya di atur di php.ini dan nilai defaultnya di direktori /tmp). Kemudian pada saat pengguna berkunjung pada halaman-halaman situs web, semua informasi variabel yang dipilih oleh pengguna akan disimpan dalam file pada server, dan semua script yang dibutuhkan untuk melacak sebagai identifier unik.
Implementasi session dapat mempergunakan cookie yang disimpan pada sisi client, atau dipropagasikan melalui alamat URL.
Untuk penggunaan cookie, yaitu dengan passing variabel melalui cookie yang menyimpan informasi semua elemen barang belanja dan harganya. Namun hal ini memiliki keterbatasan yaitu dari (http://www.netscape.com/newsref/std/cookie_spec.html) mengenai spesifikasi cookie yang hanya mengijinkan 20 cookie per domain dan berukuran hanya 4 bytes per cookie. Cara lain adalah dengan memberi identitas / identifier unik pada masing-masing pengguna, suatu nilai unik yang mengidentifikasi siapa pengguna tersebut. Sehingga pada saat pengguna menambahkan satu item pada kereta belanja, informasi yang berkaitan dengan identifier unik tadi disimpan di komputer server. Jika menggunakan cookie untuk fungsi penyimpan informasi tadi, diperlukan membuat string unik yang akan diletakkan dalam cookie, dalam direktori di server akan terdapat sebuah file yang memiliki nama yang sama sebagai ID pengguna yang unik. Dalam file tersebut dapat disimpan semua variabel yang berkaitan dengan pengguna. Contohnya terdapat array berisi item-item barang yang ditambahkan oleh seorang pengguna ke dalam kereta belanjanya.
Terdapat keterbatasan penggunaan cookie, yakni bila browser pengguna di atur untuk menolak (reject) cookie.
Metode lain yang dapat digunakan adalah dengan propagasi URL, yaitu dengan mengaktifkan flag –enable-trans-sid dalam konfigurasi PHP, hal ini berguna agar session id akan secara otomatis ditambahkan ke setiap relative link pada halaman-halaman web setiap kali session telah dimulai.

2.2 Konfigurasi Sistem dan Tool Yang Digunakan
Masalah lain dalam aplikasi ini adalah mengenai aspek keamanan dalam memperoleh informasi dari pengguna, terutama data mengenai penggunaan kartu kredit. Informasi ini perlu diverifikasi oleh institusi yang berkualifikasi dan memerlukan pengaturan konfigurasi serta penggunaan beberapa macam tool.
Dalam membangun aplikasi ini dipergunakan algoritma untuk memelihara (maintain) state, pengambilan informasi secara secure terhadap kartu kredit, menggunakan kode pemrograman khusus dan penggunaan opsi instalasi khusus.
Di bawah ini akan dibahas mengenai teori dasar enkripsi dan sekuriti Web. Kemudian akan dibahas tool mandatory untuk instalasi web server Apache.

2.2.1 Enkripsi Public-Key / Private-Key
Mesin di web menggunakan skema keamanan Public-key/Private-key. Artinya komputer yang akan berkomunikasi menggunakan data terenkripsi harus memiliki dua buah kunci untuk mengenkripsi data dan mendekripsinya. Pertama, public-key tersedia bagi siapa saja yang ingin melakukan komunikasi terhadapnya. Sehingga siapapun yang ingin melakukan komunikasi terhadap sebuah mesin secara secure akan memiliki salinan dari Public key mesin tersebut. Namun public key ini tidak cukup untuk dapat mendekripsi data, masih dibutuhkan Private key yang bersifat rahasia. Misalnya pada pemrosesan kartu kredit dengan sebuah bank, nasabah memiliki Public key bank tersebut dimana ia dapat melakukan dekripsi informasi, namun masih diperlukan Private key yang disimpan oleh bank tersebut, untuk dapat melakukan dekripsi data.

Gambar 4. Pengiriman Data Terenkripsi antara Pengguna dengan Server E-Commerce

2.2.2 Sertifikat
Meski masalah keamanan sudah ditangani dengan keberadaan Public key / Private key, masih ada masalah yang perlu diperhatikan yakni pesan / data yang diperoleh adalah benar dari pihak yang memiliki otorisasi, bukan dari pihak lain yang tidak berkepentingan atau yang menyalahgunakan. Untuk itu dibutuhkan pihak ketiga untuk memverifikasi pesan yang datang.
Pesan terenkripsi yang dikirim dan diterima akan memiliki semacam ‘signature’, dan verifikasi selanjutnya dilakukan terhadap ‘signature’ tersebut. Untuk itu, organisasi yang akan mempergunakan komunikasi melalui web memerlukan kerjasama dengan organisasi lain yang mengeluarkan sertifikat yang memverifikasi pengirim pesan. Organisasi ini pulalah yang memberikan Publik key dan Private key. Salah satu contoh organisasi yang menerbitkan sertifikat sekuriti adalah VeriSign.

2.2.3 Secure Protocol
Protokol HTTP secara alamiah bersifat terbuka terhadap penyusupan. Paket-paket data yang melintas melalui router Internet dapat disadap dan dibaca. Namun informasi kartu kredit diinginkan agar tidak mudah terbaca. Untuk itu dibutuhkan penggunaan Secure Socket Layer atau SSL. SSL adalah protokol tambahan dimana key dan sertifikat dari suatu situs e-commerce akan ditransfer ke browser atau ke server lain. Melalui SSL, browser akan dapat memverifikasi sertifikat dari situs tersebut sehingga dapat mengetahui identitas pengirim sebenarnya. Tata cara enkripsi ini masih mengandung kelemahan yakni pada aspek sumber daya manusia apabila kurang jujur, yakni apabila terjadi akses tidak sah dilakukan oleh orang yang sudah berada dalam sistem.

2.2.4 Enkripsi dan Tool Sekuriti
Untuk web server Apache, ditambahkan modul SSL pada saat instalasinya.
Untuk dapat melakukan autorisasi kartu kredit, diperlukan sertifikat. Contoh yang paling sering digunakan adalah VeriSign, yang memiliki layanan PayfloPro.
Setelah Apache dikonfigurasi dengan SSL, maka website aplikasi dapat berkomunikasi dengan browser secara secure. Cirinya: URL dimulai dengan https:// , browser akan mencari Port 443 dan mencari serifikat. Dalam PHP, banyak fitur yang dapat digunakan untuk dapat berhubungan dengan situs lain. Misalnya fungsi fopen(). Namun fungsi-fungsi berhubungan dengan filesystem atau URL tidak mendukung bekerja dengan SSL, sehingga diperlukan kumpulan fungsi khusus atau program diluar PHP. Opsi-opsi dalam PHP4 dapat mendukung layanan proses pembayaran.

Gambar 5. Komunikasi Antar Situs dalam Aplikasi E-Commerce

2.2.5 Penggunaan Firewall
Firewall digunakan untuk melindungi jaringan lokal dari serangan luar. Ada beberapa pilihan untuk menempatkan web server :
• web server ditempatkan di luar dari Firewall (lihat gambar 6), adapun keuntungan dengan menempatkan server diluar dari firewall adalah bahwa web server mungkin saja menjadi subject penyerangan dari pihak luar; maka mereka “sniffer” tidak akan dapat meningkatkan serangan berikutnya untuk merusak server-server lainnya. Dengan kata lain web server tidak akan dapat keuntungan dari segala macam bentuk pelindungan yang di usahakan firewall.

Gambar 6. Web Server di Luar Firewall

• Web server di dalam firewall (lihat gambar 7). Jika diterapkan seperti ini, perlu dikonfigurasi firewall menjadi akan melewatkan transaksi pada TCP port 80, atau dengan membolehkan secara langsung melewatkan paket maupun dengan menggunakan mekanisme proxy. Keuntungan dari menempatkan web server di dalam firewall yaitu firewall akan memblok akses dari luar yang menggunakan layanan Internet lainnya, seperti Telnet, FTP. Tetapi apabila penyusup “sniffer” tersebut menggunakan kesalahan dari program CGI script, mereka akan mempunyai akses tak terbatas ke jaringan lokal.

Gambar 7. Web Server yang Diletakkan Di dalam Firewall

• Pilihan ketiga, yang paling baik, yaitu menggunakan dua firewall: satu untuk melindungi jaringan internal / lokal dan yang satunya lagi untuk melindungi web server (lihat gambar 8).

Gambar 8. Webserver yang Diletakkan di Antara Internal Firewall dan External Firewall

2.2.6 PayFloPro dan Cybercash
Untuk penggunaan VeriSign untuk pemrosesan kartu kredit, diperlukan instalasi pustaka kode ( code library) yang diperoleh dari VeriSign. Selanjutnya dikompilasi ulang dengan PHP sehingga akan dapat mengenali fungsi-fungsi tersebut (fungsi-fungsi pfpro) . Fungsi-fungsi tersebut akan memproses permintaan (request) dan akan mengembalikan jawaban (response). Setelah itu response tersebut akan dibandingkan dengan kode yang telah diketahui, setelah itu akan diketahui apakah transaksi tersebut sukses atau tidak.
Selain PayFloPro, dapat juga digunakan Cybercash, yang diinstal sebagai pustaka / library pada PHP (fungsi-fungsi cybercash).

2.2.7 CURL
Merupakan akronim dari fungsi-fungsi pustaka Client URL. Kode pustaka ini dipergunakan untuk berkomunikasi melalui Internet menggunakan sembarang protokol di sisi lawan. Kode ini mendukung Gopher, Telnet, dan HTTPS. Untuk dapat menggunakan fungsi ini, konfigurasi instalasi PHP harus menyertakan flag –with-curl.

2.3 Pemrosesan Kartu Kredit
Pemrosesan kartu kredit dilakukan oleh perusahaan yang khusus untuk itu, terdapat beberapa nama perusahaan yang cukup dikenal, namun semuanya memiliki kesamaan cara kerja. Mula-mula dikirim permintaan / request dengan informasi kartu kredit: nomor, tanggal kadaluarsa, alamat, dan sebagainya, dan kemudian perusahaan tersebut akan mengirimkan kode kembalian sebagai respon. Kode PHP di sini adalah berfungsi untuk membandingkan kode yang diterima dengan nilai yang didapat sebelumnya dari agen pemrosesan. Untuk aplikasi ini dipergunakan Authorizenet.com sebagai pemroses kartu kredit.

3. Rancangan Aplikasi E-Commerce
Gambaran aplikasi e-commerce akan diuraikan sebagai berikut. Mula-mula aplikasi akan menampilkan daftar barang yang tersedia. Lalu pengguna dapat memilih beberapa item yang ingin dibeli. Pada saat pengguna memilih suatu item barang, identitas barang tersebut dicatat, dan selanjutnya user dapat melanjutkan berbelanja / memilih item yang lain. Server mengingat item apa saja yang telah dipesan. Pada saat pengguna melanjutkan browsing, server memelihara track pengguna tersebut dan pengguna tersebut dapat melakukan check out terhadap item-item yang telah dipesan.
Untuk dapat melaksanakan hal ini, digunakan metode untuk memelihara state seperti yang telah dibahas di bagian sebelum ini.

3.1 Rancangan Layar
Setiap halaman pada aplikasi ini memiliki tombol yang memungkinkan pengguna untuk langsung melakukan checkout. Pada halaman yang menampilkan daftar barang terdapat kumpulan form yang memungkin pengguna untuk memberi indikasi item mana yang akan dibeli. Setiap item dapat ditentukan secara lebih spesifik sesuai jenis barang yang ada, misalnya untuk aplikasi toko furniture online terlebih dahulu ditentukan jenis furniture meja, terdiri atas meja bulat, meja kotak, meja tulis, dan sebagainya. Form untuk pemesanan menggunakan kotak teks untuk jumlah pesanan, dan tombol ‘Order’, yang pada contoh meja tadi dicantumkan untuk masing-masing jenis meja.
Selanjutnya ditampilkan satu halaman yang berisi daftar semua item yang sedang berada dalam kereta belanja (shopping cart). Halaman ini memungkinkan pengguna untuk menambah atau mengurangi jumlah item yang dipesan, dan menghapus suatu item pesanan.
Pada akhir proses pemesanan, ditampilkan halaman yang mengumpulkan informasi pengguna, preferensi, dan halaman untuk memulai pemrosesan kartu kredit. Halaman ini juga menunjukkan pesan bila ada kesalahan informasi atau terdapat penolakan autorisasi kartu kredit oleh agen pemroses.
Selanjutnya, setelah transaksi selesai diproses, terdapat tanda terima transaksi yang mengkonfirmasi pesanan dan menyampaikan nomor id pesanan kepada pengguna.
Yang penting diperhatikan untuk pengembangan aplikasi e-commrce adalah informasi nomor kartu kredit dan informasi personal lainnya harus aman dan tidak mudah dilihat oleh orang yang tidak berhak.

Gambar 9. Diagram Alir Penggunaan Aplikasi E-Commerce

Gambar 10. Rancangan Layar Halaman Depan Web E-Commerce

Gambar 11. Rancangan Layar Halaman Daftar Barang

Gambar 12. Rancangan Layar Halaman Daftar Pesanan

Gambar 13. Rancangan Layar Halaman Pemrosesan Kartu Kredit

3.2 Rancangan Basis Data

Gambar 14. Rancangan Basis Data Aplikasi Web E-Commerce

Tabel utama yang digunakan dalam aplikasi ini adalah tabel Pesanan, yang mencatat order pemesanan. Tabel-tabel lain berelasi dengan tabel ini. Tabel Pesanan menyimpan informasi id_user, id_alamat, dan semua informasi yang dibutuhkan untuk pembayaran. Tabel Pesanan ini memiliki relasi one-to-many dengan tabel Item yang berisi informasi item-item barang yang terdapat dalam sebuah order. Informasi mengenai pengguna dan alamat pengguna dipisahkan, seorang pengguna dapat didentifikasi dari alamat e-mail yang dimilikinya, dan alamat terdiri atas alamat kantor dan rumah. Tabel Pengiriman berisi informasi opsi yang diberikan untuk pengiriman barang. Misalnya terdapat pilihan menggunakan UPS, DHL, TIKI, Pos, dan sebagainya. Tabel Status berisi catatan mengenai status pesanan, yaitu dapat berupa status dikembalikan (backordered), dikirim (shipped), atau dibatalkan (cancelled). Terdapat pula tabel Jenis_Kartu untuk menyimpan informasi jenis kartu kredit seperti Visa, Mastercard, dan sebagainya.

Tabel 1. Tabel Alamat

Field	Jenis	Kosong	Ekstra	Keterangan
Id_Alamat	Int(11)	Tidak	Auto_increment	PRIMARY KEY
Id_User	Varchar(40)	Tidak		KEY
Alamat	Varchar(40)	Ya
Alamat2	Varchar(40)	Ya
Kota	Varchar(40)	Ya
Prop	Varchar(40)	Ya
KodePos	Varchar(10)	Ya
Negara	Varchar(20)	Ya
Telepon	Varchar(20)	Ya
Fax	Varchar(20)	Ya

Tabel 2. Tabel Jenis_Kartu

Field	Jenis	Kosong	Ekstra	Keterangan
Kode_Jenis_Kartu	Char(3)	Tidak
Jenis_Kartu	Varchar(30)	Tidak

Tabel 3. Tabel Pesanan

Tinyint(4)

Field	Jenis	Kosong	Default	Ekstra	Keterangan
Id_pesanan	double	Tidak		Auto_ increment	PRIMARY KEY
Id_user	Int(11)	Tidak			KEY
Id_alamat	Int(11)	Tidak
Id_status	Tinyint(4)	Tidak
Total_harga	Double	Tidak	‘0.00’
Id_pengiriman	Tinyint(4)	Tidak
Biaya_kirim	Double	Tidak	‘0.00’
Tahun_exp_kartu	Int(11)	Tidak
Bulan_exp_kartu		Tidak
Kode_jenis_kartu	Char(3)	Tidak
Tgl_buat	Timestamp(14)	Ya

Tabel 4. Tabel Pengiriman

Field	Jenis	Kosong	Default	Ekstra	Keterangan
Id_Pengiriman	Tinyint(4)	Tidak		Auto_ increment	PRIMARY KEY
Pengiriman	Varchar(20)	Tidak
Per_Order	Double	Tidak	‘0.00’
Per_Item	Double	Tidak	‘0.00’

Tabel 5. Tabel Status

Field	Jenis	Kosong	Ekstra	Keterangan
Id_Status	Tinyint(4)	Tidak	Auto_ increment	PRIMARY KEY
Status	Varchar(20)	Tidak

Tabel 6. Tabel User

Field	Jenis	Kosong	Ekstra	Keterangan
Id_User	int(11)	Tidak	Auto_ increment	PRIMARY KEY
email	Varchar(255)	Tidak		UNIQUE
nama	Varchar(80)	Tidak

Tabel 7. Tabel Item

Field	Jenis	Kosong	Keterangan
Id_pesanan	double	Tidak	PRIMARY KEY
Kode_Katagori	Tinyint(4)	Tidak	PRIMARY KEY
Nomor_Barang	Double	Tidak	PRIMARY KEY
Kode_Register	Varchar(20)	Ya
Kode_Lokasi	Varchar(20)	Ya
Jumlah	Int(11)	Tidak
Harga	Double	Tidak

3.3 Keamanan Nomor Kartu Kredit dalam Basis Data
Nomor kartu kredit tidak disimpan di dalam basis data, karena dapat mengurangi keamanan. Perangkat komputer dapat dinilai sebagai suatu alat yang tidak aman, karena dapat diakses oleh orang lain. Bila digunakan ISP (Internet Service Provider) untuk hosting web site ini, tentunya akan sangat diragukan keamanannya, karena ISP menggunakan shared server yang digunakan secara bersama, meskipun telah menggunakan konfigurasi secure server yang ditawarkan oleh ISP tersebut. Nomor kartu kredit yang tersimpan dalam basis data akan dapat diakses oleh orang lain yang mempunyai akses terhadap mesin server. Juga tidak ada kebutuhan untuk menyimpan nomor kartu kredit dalam bentuk apapun. Yang diperlukan oleh aplikasi ini adalah memvalidasi nomor tersebut saja, dan segera menghapusnya dari memori setelah selesai. Jika nomor kartu kredit ini tidak pernah dituliskan ke hardisk, akan menjadi sangat aman karena akan terhindar dari kemungkinan pencurian oleh yang tidak berhak.

Gambar 15. Komunikasi Antar Situs dan Penghapusan Informasi Kartu Setelah Proses Selesai

4. Kode Program
Pemrograman untuk aplikasi e-commerce ini diimplementasikan dengan PHP. Fungsi-fungsi utama yang dipergunakan dalam kode program di sini adalah fungsi yang berhubungan dengan session dan fungsi yang berkaitan dengan pustaka cURL.
Konsep pemrograman berorientasi objek digunakan dalam kode program ini. Digunakan sifat inheritance, yakni jika sebuah kelas / class mewarisi properti dan metode (properties and methods) dari kelas induk / parent class, ia memiliki akses terhadap semua metode dan properti dari induknya. Dan sebuah aplikasi dapat dibangun dengan memperluas / extending sebuah kelas berdasarkan kelas lain yang telah ada.

4.1 Fungsi Session
Fungsi session_register() digunakan untuk menyatakan memulai session, sekaligus didefinisikan variabel apa saja yang akan disimpan dalam session. Fungsi session_register() diletakkan pada baris pertama program, karena fungsi ini mengirim cookies yang merupakan salah satu tipe dari HTTP header. Jika suatu tipe header dikirim setelah teks dikirim ke browser akan mengakibatkan error.
< ?
session_register(“var1�?);
$var1 = “nilai1�?;
?>
Pada waktu diakses pertama kali, halaman tersebut akan memulai session. Akan dikirim cookie atau session id yang akan ditambahkan ke dalam relative link. Perintah session_register akan memerintahkan PHP untuk melakukan pencarian variabel $var1 pada file session. Jika ada, variabel tersebut akan tersedia / available secara global, atau dapat pula diakses melalui array $HTTP_SESSION_VARS. Setelah halaman tersebut diproses, nilai terakhir dari variabel yang terdaftar akan dituliskan ke file session.
Fungsi-fungsi yang digunakan untuk session ini :
Session_destroy() : fungsi untuk menonaktifkan session dan semua variabel yang berkaitan dengannya.
Session_unregister() : fungsi untuk menghapus nilai dari suatu variabel dalam file session.
Session_set_save_handler() : fungsi yang memungkinkan untuk mengatur sendiri metode penyimpanan (storing), pengambilan (retrieving), dan penulisan (writing) session handler.
Metode session handler yang dipilih adalah yang manajemen session berdasarkan file-based. Namun metode ini tidak sesuai digunakan untuk lingkungan tercluster (clustered environment) dimana beberapa mesin bekerja secara bersama untuk melayani satu situs, untuk lingkungan seperti ini tidak dapat menggunakan local filesystem.
Session_encode(): fungsi untuk menuliskan variabel ke dalam basis data, variabel tersebut harus terlebih dahulu diubah formatnya ke dalam format yang dimengerti oleh basis data. Fungsi session_encode berguna untuk mengubah format ini.
$str = session_encode(string)
Session_decode() : fungsi untuk membalik proses encoding di atas, sehingga variabel dikembalikan kedalam representasi PHP.

4.2 Fungsi-fungsi cURL
Untuk aplikasi ini diperlukan komunikasi dengan layanan validasi kartu kredit, dilakukan dengan fungsi cURL. Cara kerjanya adalah mula-mula fungsi ini akan mengirim pesan yang secure melalui HTTPS, dan layanan yang memvalidasi kartu kredit tersebut akan mengembalikan response, yang kemudian diproses lebih lanjut dengan PHP.
Fungsi cURL yang digunakan :
Curl_init() : fungsi ini mengembalikan nilai integer yang serupa dengan nilai identifier kembalian yang dikembalikan oleh mysql_connect() atau pointer file yang dikembalikan oleh fopen(). Pada kasus seperti ini disebut dengan cURL handle, atau ch. Pada argument tunggal pada fungsi ini diberikan URL yang akan diakses.
Int curl_init ([string url])
$cc_company_url =
https://secure.process.site/transact.dll?exp=foo&cardtype=bar
$ch = curl_init($cc_company_url);
Fungsi ini akan memulai session cURL. Panggilan pada URL ini tidak akan berfungsi hingga fungsi curl_exec dieksekusi.
Curl_setopt() : sebelum komunikasi URL dieksekusi, perlu diset salah satu opsi cURL yaitu opsi CURLOPT_RETURNTRANSFER. Opsi ini untuk mengembalikan hasil dari request https ke dalam variabel PHP.
Curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
Curl_exec() : fungsi ini untuk mengeksekusi transfer. Sebuah argumen digunakan yaitu berasal dari hasil kembalian fungsi curl_init() dan digunakan pula pengesetan opsi-opsi lain.
Bool curl_exec (int ch)
Curl_close(): fungsi ini menutup koneksi cURL menggunakan curl handle :
Void curl_close (int ch)
Kumpulan fungsi-fungsi ini yang menjalankan transaksi dan mengembalikan hasil ke dalam variabel $data.
$ch = curl_init($authorize_net_url);
curl_setopt($ch, CURL_RETURNTRANSFER, 1);
$data = curl_exec($ch);
curl_close($ch);

5. Hasil dan Pembahasan
Hasil yang diperoleh dari kegiatan ini adalah dokumen analisis dan perancangan, serta prototipe perangkat lunak. Prototipe ini dibangun menggunakan perangkat lunak open source serta memiliki karakteristik cross-platform. Dari hasil diskusi dengan pengguna, diperoleh masukan mengenai kebutuhan pengguna akan perangkat lunak e-commerce, namun spesifik pada suatu produk tertentu, serta kebutuhan untuk memperkaya fungsi-fungsi multimedia sehingga secara visual lebih menarik.
Diperlukan kerja sama dengan supplier / distributor produk komersil untuk dapat menawarkan produk-produknya melalui e-commerce. Juga jasa kurir diperlukan untuk dapat melakukan layanan antar kepada konsumen dengan cepat.
Bagi lembaga penelitian atau lembaga pendidikan, perlu juga memperhatikan masalah HKI dalam layanan e-commerce untuk produk-produk karya intelektual. Diperlukan kerjasama dengan pemilik hak intelektual tersebut untuk menawarkan produk-produk karya intelektual tersebut secara komersil.
Dalam sebuah seminar mengenai e-commerce di Bandung dikemukakan bahwa faktor terpenting dalam aplikasi e-commerce adalah delivery. Adanya sistem distribusi multi level marketing juga diinformasikan dapat memotong jalur delivery supaya lebih cepat sampai ke tangan konsumen.

6. Kesimpulan
Pengembangan aplikasi e-commerce bagi sebuah perusahaan / lembaga merupakan proses yang cukup kompleks. Melibatkan beberapa organisasi / situs dalam penanganan sekuriti dan otorisasi.
Perangkat lunak ini dirancang untuk mengimplementasi sistem e-commerce dalam dunia bisnis yang mendukung pemotongan rantai distribusi sehingga konsumen dapat memperoleh suatu produk dengan harga yang lebih murah. Jenis antarmuka web dipilih dengan pertimbangan fleksibilitas implementasi perangkat lunak ini yang dapat dilakukan di jaringan intranet maupun internet, kemudahan untuk deployment, serta kemampuan cross platform.
Pengembangan sistem ini masih jauh dari sempurna, namun setidaknya dapat memberikan dasar dan dapat memberikan sumbangan bagi pemikiran untuk pengembangan teknologi yang dapat dirasakan manfaatnya oleh masyarakat di bidang ekonomi, khususnya untuk jalannya bisnis perdagangan secara online.

Daftar Pustaka

1. Buyens, Jim,(2001), Web Database Development, Elex Media Komputindo , Jakarta .
2. Minoli, Daniel Mindi Emma, (1998), Web Commerce Technology Handbook, Mc Graw Hill.
3. Atkins, Dorck and Buis, Paul, (1997), Internet Security Professional Reference, New Riders.
4. Rumbaugh, James dkk., (1991), Object Oriented Modelling and Design, Prentice-Hall International.,Inc.
5. Pressman, Roger S., (1992), Software Engineering A Practitioner’s Approach, third edition. McGraw-Hill International Edition.
6. http://www.php.net
7. http://www.mysql.com
8. Greenspan,Jay, and Bulger,Brad, (2001), MySQL/PHP Database Application, M&T Books.
9. Fery Soswanto, “E-Commerce dengan memanfaatkan Sistem Operasi Linux�?.

http://www.informatika.lipi.go.id/student-centered-collaborative-learning-using-qa-on-web

 

« Perkembangan Teknologi Informasi di Indonesia

Masyarakat Java Dikumpulkan di Bandung »

Posted on Tuesday, April 1st, 2003 at 3:40 pm. About Jurnal, IT.

–>

Student-Centered Collaborative Learning Using Q&A on Web

Ana Hadiana
Department of Information Engineering, Faculty of Engineering, Shinshu University
cana [at] softeng-mail [dot] cs [dot] shinshu-u.ac [dot] jp
Elan Djaelani
Research Center for Informatics, Indonesian Institute of Science
elan [at] informatika [dot] lipi [dot] go [dot]id

Abstract

We propose in this paper an educational learning environment named as Asynchronous collaborative learning environment on Web (ActiveWeb). This system provides collaboration functions among students, in order to make students more active and interactive in learning process based on Web technology without any restriction of time and place, and in order to decrease teacher’s load. In this system, students collaborate each other for constructing shared knowledge as much as possible according to their level of knowledge. Students can collaborate with each other through questions-answer to acquire further knowledge. In this paper we describe the development of a prototype system of ActiveWeb.
Keywords: Collaboration, Asynchronous, Distance Learning, Web, Q&A

Intisari
Kami mengajukan dalam makalah ini sebuah lingkungan pembelajaran pendidikan yang dinamakan sebagai Asynchronous collaborative learning environment on Web (ActiveWeb). Sistem ini menyediakan fungsi-fungsi kolaborasi di antara pelajar, dalam rangka membuat para pelajar lebih aktif dan interaktif dalam proses pembelajaran berbasis teknologi Web tanpa kendala ruang dan waktu, serta dalam rangka meringankan beban guru. Dalam sistem ini, para pelajar berkolaborasi satu sama lainnya untuk mengembangkan pengetahuan secara tersebar sebanyak mungkin sesuai dengan tingkat pengetahuan mereka. Para pelajar dapat berkolaborasi satu sama lain melalui tanya-jawab untuk meraih pengetahuan lebih lanjut. Dalam makalah ini kami memaparkan pembangunan dari sistem prototipe Active Web.
Kata Kunci : Kolaborasi, Asinkron, Distance Learning, Web, Q&A

1. Introduction
Recently, there are many network technologies including Web, which can be used for implementing educational support systems, so it becomes possible that learning can be performed in distance without any restriction of time and place. In general, the application of distance learning systems is divided into two types; the one is synchronous and the other is asynchronous. In this paper, we are focusing on asynchronous learning systems and their collaboration functions.

In many learning systems [3][4], the teacher has to answer many questions from students who do not comprehend the contents of teaching-materials, and there is a tendency that teacher’s load becomes large, because teacher directly has to answer the questions. On the other hand, collaboration among students plays important role in learning to increase knowledge [2][5], and also could reduce the teachers’ load. So that in ActiveWeb [1], we provide collaboration tools to motivate students to be more active in learning by teaching each other about some materials related to their comprehension. We propose asynchronous collaboration tools using question-answer (Q&A) suited for students’ level of knowledge concerning to teaching-materials. In ActiveWeb, if students have questions regarding teaching-materials, they can collaborate with each other settling the problem according to their pace of learning. In such collaboration learning, the teacher’s role is just to supervise the learning process, and to give advices indirectly to students in order to help the collaboration process.

2. Learning Sequence
In ActiveWeb, users (students and teachers) access the remote learning resources asynchronously through a web browser. Students progress their learning by reading the teaching-materials step by step according to a semi-ordered learning sequence. On the other hand, teachers supervise students’ learning progress, and according to each situation teachers give some hints or advices to students using a suitable tool. Students can follow teaching-materials according to their paces, and if they have any questions, they can get a suitable answer from other students. In principle, ActiveWeb allows students collaboratively perform learning together to increase knowledge as much as possible.

Students start and finish the learning process as shown in figure 1. Firstly, students have to be registered in order to participate in this system. Only the registered students can login to the system. After login, the system will load learning materials related to the students’ status or progress. During learning, students not only read or explore the materials, but also can collaborate with each other asynchronously to get more knowledge. Collaboration will give great influence on the final result of learning. The system will ask students to do tests at the end of every level of materials in order to recognize the degree of comprehension.

Fig. 1. Learning Process

If students fail in the test, they are forced to learn again the current or previous material until their comprehension become enough to learn the next material. Students continue their learning when they pass the tests, and ActiveWeb will guide them according to the semi-ordered learning sequence so that the students can follow the materials according to their pace and their interest to materials. Students can stop and logout from system every time.

3. Collaborative Q&A
During the learning process, students not only read the materials, but also are required to participate in many collaboration groups talking about some problems, because the collaboration plays important role on asynchronous learning systems. Collaboration gives many chances to find the solution of problems, and makes it impossible for students to acquire more knowledge that is not contained in the materials.
In ActiveWeb, students are not allowed to ask a question directly to teachers, and they are required to make collaboration with other students who have the knowledge to answer the question. Through Q&A subsystem, ActiveWeb will assist students to find qualified students who may know the answer, and also will assist students who act as respondents　to answer one question from the list of unanswered questions. Collaboration using Q&A provides many opportunities to find the solution of problems in learning, and make students acquire more knowledge than just reading the material. Collaboration also gives students motivation of learning through knowing other students’ activity, and rechecks each other.

3. 1. Flow of Questioners
When students have some questions regarding the material, they need to ask some questions. In this system, students are not allowed to ask some questions directly to teachers, but they are required to make collaboration with other students who have enough knowledge to give an appropriate answer for questions. Our system assists students who act as questioners to find knowledgeable students and to find an expected answers, and also assists students who act as respondents　to select and to answer the question from list of unanswered questions.

Fig. 2 shows a summary of the flow of questioners. Questioners write a question, and then the system attempts to search the similar questions from Q&A database according to this incoming question text. The incoming question will be accepted as a new question in one of the following cases occurs:
1. The system is not able to find similar questions.
2. The questioners can not find an intended questions from the similar question searched by the system.

In above two cases, question will be stored in to the system as a new question. Then, the system will notify appropriate respondents who have enough knowledge to answer it later. The respondents are selected by the system according to student model. On the other hand, when the intended question is found from the list of unanswered questions, the questioner will be registered into the system as an additional questioner of this question. Other way, if the system finds the intended question and it has answers, the questioner is allowed to evaluate these answers. This result of evaluation will be sent to the system to update the student model of respondent. According to the result of evaluation, the system can be notified that the intended question has been answered completely, or still needs more appropriate answers.

Fig. 2. Flow of Questioner

In current development, only the first questioner evaluates the answers. The evaluation uses three ranks of value: not enough, enough and perfect. If there are answers from different students, the questioners evaluate each answer. The questioners will evaluate all these answers whether collectively meet the question or not. This result will determine the completeness of a question and its answers.

3. 2. Flow of Respondents
The respondents browse and check the list of unanswered questions as shown in Fig. 3. The respondents browse the questions, and choose one of them to answer. However, according to the difficulty of question, the respondents are allowed to reject answering the question.

The system will also assist the respondents to select one question effectively according to the question’s attribute. We consider the question’s attributes as parameter of priority. There are three parameters:
- Waiting time of question
The elapsed time of question, since it is accepted as new question by the system until it is answered.
- Number of Questioner
This parameter shows the number of students who ask the same question, and the importance of question.
- Access time
This parameter shows the accessing the system. The more active students learn using the system, the higher value of priority of question to be selected firstly.

Fig. 3. Flow of Respondent

Using combination of these parameters as priority, the respondents can consider and choice one question more detail and answer it adequately. The system supports selecting question using priority, but the final decision of selecting question depends on the respondents according to the difficulty of questions.

3. 3. Searching Similar Question
Searching the similar questions plays important role to prevent duplication of questions that have similar content, and to make students easier to find the intended question.

Fig. 4. Searching Question

In ActiveWeb, we use the conventional searching method using keywords. Every question will be compared with questions stored in Q&A database. If a similar question having answer exists in the database, students can find its appropriate answer automatically. So that, in Q&A system the preventing duplication of questions is inevitable.

Fig. 4 shows the mechanism of our searching method. At the current position of learning material, students write a question, and then the system will extract keywords from this new question. The noun within the question will be the candidate to be selected as keywords. According to these extracted keywords and the current position of learning material, the system will search the similar question from the Q&A database according to the position of question in learning material. In this paper, in order to find the similar questions, we do not use OR logic, but we use AND logic to compare extracted keywords with the keywords of questions from database. If a number of similar questions exist, the system let the questioners check and choose the intended one. We can use ChaSen [6] for Japanese and WordNet [7] for English to extract and select the noun as keyword.

4. Implementation
We use WWW as the platform of ActiveWeb for implementing an asynchronous learning system as shown in figure 5. ActiveWeb consists of five subsystems as follows:

- Presenter subsystem
It is the most fundamental part that arranges and shows the teaching-materials prepared by this system to students according to their level of learning. We use Web browsers as user interface for students and teachers.
- Student Model subsystem
Basically we use an overlay student model that decides the knowledge level of students to participate in collaboration, so that students can join the collaboration according to their pace of learning.
- Monitor subsystem
All students will be analyzed using a learning history from database. Teacher can supervise the learning performance of all students and collaboration condition. If necessary, teacher can give advices using suitable function.

Fig. 5. Block Diagram of ActiveWeb

- Test subsystem
Teaching-materials consist of some modules that include tests for checking the degree of comprehension of students. The result of tests will be stored in a database and will be reused as learning data of tests for the analyzing learning performance of students. The result of tests at each material will determine how learning to be continued. If a student fails in the test, the system will force the student to learn again the current material, but if a student passes the test, the student can proceed to the next teaching-material.
- Collaboration subsystem
A collaboration function is used in order to acquire more satisfactory knowledge in addition to the knowledge acquired by reading teaching-materials. The main collaboration tools provided by the system are discussion and question & answer (Q&A) tools. Collaboration activity will give a big affection on result of learning, so the students’ participation in it is really required to acquire more knowledge.

5. Conclusion
In this paper we proposed the learning support system based on Web called ActiveWeb that has the characteristics of supporting students to do learning in collaboration with others in order to solve many problems during the learning. There are two main collaboration tools prepared by ActiveWeb; discussion and Q&A. In this system teachers do not participate in collaboration directly. Teachers mainly supervise the situation of collaboration, and if necessary, teachers can give some hints for directing learning process. Students can construct knowledge not only by reading the teaching-materials but also by collaborating each other, so that the final outcome of learning would be better.

Finally, during we have developed ActiveWeb as tool of distance learning, but we still have to make it better for supporting collaborative learning on Web. We also need to do experiment of this system in large scale in order to evaluate the performance and the effectiveness of it.

References
[1] Ana Hadiana, Kenji Kaijiri, “The Construction of Asynchronous Q&A Support System based on Collaboration�?, Information Technology Letters Forum on Information Technology, 2002, pp.249-250.
[2] Fumiaki Obayashi, et al, “Construction and Evaluation of a CAI System Based on Learning by Teaching to Virtual Student�?, Information Processing Seminar Journal, Vol.41 No.12, 2000, pp.3386-3393.
[3] Kenji Matsuura et al, “Agent-based Asynchronous Virtual Classroom�?, Advanced Research in Computers and Communications in Education, IOS Press, 1999, pp.133-140
[4] Osami Kagawa et al, “Selecting Essential Questions Using Question Support Facilities in a Distance Education System�?, IEICE Journal, Vol.J80-D-II, 1997, pp.1878-1886
[5] Yutaka Matsusita, Collaboration and Communication, Kyoritsu Publisher, 1995, pp.10-15.
[6] Computational Linguistics Laboratory, Nara Institute of Science and Technology University, “ChaSen�?, http://chasen.aist-nara.ac.jp/index.html.
[7] Cognitive Science Laboratory, Princeton University, “WordNet�?, http://www.cogsci.princeton.edu/~wn/.

Novas Design-for-Debug (DFD) Methodology Brief

System Validation Today

No standard methodology exists today for in situ silicon validation. To perform system validation, the validation team must typically:

• Plug the silicon device into the target system and turn on the power;
• Run system-level applications to ensure it operates according to specification;
• Reproduce scenarios using emulation or software simulation when unexpected silicon behavior arises; and
• Trace its origin once the bug has been reproduced.

Unfortunately, limited access to and visibility of internal signal data means that directly observing a design’s behavior for any errors that escaped the pre-silicon verification process is nearly impossible. This limitation also makes determining whether silicon errors are undetected functional design bugs or physical manufacturing defects increasingly difficult. With no internal signal observability, debugging erroneous silicon behavior is an extremely costly, time-consuming and unpredictable task.

To effectively debug silicon, a means of observing internal signal values to garner insight into the status of a device’s internal state machines, data and status registers is required.

DFD Minimizes Errors And Time

Design-for-Debug (DFD) is an emerging methodology that provides validation teams with insight into internal silicon device behavior during in-situ validation. It requires the use of upfront planning and involves the placement of structures on the silicon to help with its debug. Bridging the communication gap between the system validation engineer and designer, it provides excellent observability of silicon signal data, improves silicon debug productivity and minimizes system validation time. Validation teams can now efficiently validate silicon prototypes prior to volume production.

How It Works

The DFD methodology is consistent with what engineers currently perform today as part of an ad-hoc silicon debug flow. Where it differs is in how it enables the engineer to perform an examination of internal signal data. Use of the DFD methodology requires:

• The implementation of on-chip logic used to retrieve crucial signal data.
• Associated software and hardware to facilitate the transport of signal data off-chip.
• The extrapolation of the limited retrievable data using standard process automation and analysis techniques for system-level silicon validation.

To trace errors in silicon using the DFD methodology, first place DFD logic in the design and manufacture the silicon. After obtaining the first silicon prototypes:

• Run system-level applications while the device is in situ to ensure it operates according to specification.
• When an unexpected behavior arises, stop the device at the point of interest.
• Access the system-mode operation signal data, via the DFD logic.
• Next, transport the raw signal data off chip and translate it to correspond with the Hardware Description Language (HDL) design so that it can be exported to existing HDL-centric verification tools.
• Use familiar HDL-centric debug environments and techniques, such as Novas Verdi Debug System, to locate and fix the problem.

While there are a variety of different DFD options, like adding internal debug busses to the silicon, the most straightforward DFD methodology reuses existing Design-for-Test (DFT), such as scan chains, in conjunction with the IEEE 1149.1 test modules (also known as JTAG). Additionally, monitors can be inserted to observe internal behavior and note when illegal, unexpected or pre-programmed conditions occur (see Figure 1).

Figure 1. Example DFD architecture which reuses DFT and adds debug instruction registers, control and optional monitors.

In this scenario, the IEEE 1149.1 controller is extended to operate the DFD logic. Doing so enables it to halt system operation and shift the signal data out of the scan chains. An 1149.1 cable connects the system board to a personal computer (PC) and allows for the transport of debug instructions and data. Once on the PC, the data can be formatted for export to an appropriate debug environment (see Figure 2).

Figure 2. The silicon device (noted in the orange circle) is placed into the target board for system level validation. Under control of debug software application, scan register data travels out of the silicon, across a pod interface, to a PC where it is dumped into a usable form.

Faster, More Efficient Debug

DFD makes system validation of increasingly complex silicon viable. It significantly improves the efficiency of silicon debug, lowers development cost and accelerates time-to-volume production for integrated device manufacturers. Through adoption of a DFD methodology users can:

• Debug both functional bugs and physical defects.
• Use standard design tools and associated environments to extract and process data from the silicon.
• Use standard debug systems and apply pre-silicon techniques, while operating in the designer’s environment, to isolate the root cause of any problem.

Improved Silicon Validation

The Design-for-Debug methodology enables validation teams to efficiently validate silicon prototypes prior to volume production by re-using test structures, such as the IEEE 1149.1 test controller and scan chains, on the silicon to help with its debug. The re-use of existing DFT structures significantly minimizes the impact of this methodology on silicon area. Furthermore, this methodology makes use of DFT resources that would otherwise sit idle during system-level testing.

With DFD, validation teams can now easily extract and process data from the silicon for further exploration and analysis by standard debug systems and associated verification environments. Increased observability significantly improves the ability of validation teams to better understand internal silicon device behavior. In turn, this understanding enables quick resolution of erroneous silicon behavior. Because it directly cuts the time from receipt of silicon prototypes to volume product, the DFD methodology is continuing to gain interest.

The Technique of Data Flow Diagramming by Kenneth A. KozarSpring 1997

---

THE TECHNIQUE OF DATA FLOW DIAGRAMMING

This section describes in detail the data flow diagramming technique. It is intended to serve as a handbook to guide the reader in developing data flow diagramming skills.

Definition:

Data Flow Diagramming is a means of representing a system at any level of detail with a graphic network of symbols showing data flows, data stores, data processes, and data sources/destinations.

Purpose/Objective:

The purpose of data flow diagrams is to provide a semantic bridge between users and systems developers. The diagrams are:

• graphical, eliminating thousands of words;
• logical representations, modeling WHAT a system does, rather than physical models showing HOW it does it;
• hierarchical, showing systems at any level of detail; and
• jargonless, allowing user understanding and reviewing.

The goal of data flow diagramming is to have a commonly understood model of a system. The diagrams are the basis of structured systems analysis. Data flow diagrams are supported by other techniques of structured systems analysis such as data structure d iagrams, data dictionaries, and procedure-representing techniques such as decision tables, decision trees, and structured English.

Data flow diagrams have the objective of avoiding the cost of:

• user/developer misunderstanding of a system, resulting in a need to redo systems or in not using the system.
• having to start documentation from scratch when the physical system changes since the logical system, WHAT gets done, often remains the same when technology changes.
• systems inefficiencies because a system gets “computerized” before it gets “systematized”.
• being unable to evaluate system project boundaries or degree of automation, resulting in a project of inappropriate scope.

Description:

Data Flow Diagrams are composed of the four basic symbols shown below. The External Entity symbol represents sources of data to the system or destinations of data from the system.

The Data Flow symbol represents movement of data.

The Data Store symbol represents data that is not moving (delayed data at rest).

The Process symbol represents an activity that transforms or manipulates the data (combines, reorders, converts, etc.).

Any system can be represented at any level of detail by these four symbols.

---

External Entities:

1. are named with appropriate name.
2. can be duplicated, one or more times, on the diagram to avoid line crossing.
3. determine the system boundary. They are external to the system being studied. They are often beyond the area of influence of the developer.
4. can represent another system or subsystem.
5. go on margins/edges of data flow diagram.

---

Data Flows:

1. are represented with a line with an arrowhead on one end. A fork in a data flow means that the same data goes to two separate destinations. The same data coming from several locations can also be joined.
2. should only represent data, not control.
3. are ALWAYS named. Name is not to include the word “data”.
4. are referenced by a combination of the identifiers of the constructs that the data flow connects. (14-A references a data flow from process 14 to external entity A)

---

Data Stores:

1. are generic for physical files (index cards, desk drawers, magnetic disk, magnetic tape, shirt pocket, human memory, etc.)
2. are named with an appropriate name, not to include the word “file”, and numbered with a number preceded with a capital letter D
3. can be duplicated, one or more times, to avoid line crossing.
4. can show two or more systems that share a data store. This is done by adding a solid stripe on the left boundary. (Figure 5.34) This can occur in the case of one system updating the data store, while the other system only accesses the data. For ex ample, the data store could be a freight rate book that one system builds and maintains, but is used by the represented system.
5. are detailed in the data dictionary or with data description diagrams.

---

Processes:

1. show data transformation or change. Data coming into a process must be “worked on” or transformed in some way. Thus, all processes must have inputs and outputs. In some (rare) cases, data inputs or outputs will only be shown at more detailed levels of the diagrams. Each process in always “running” and ready to accept data.
2. are represented by a rounded corner rectangle
3. are named with one carefully chosen verb and an object of the verb. There is no subject. Name is not to include the word “process”. Each process should represent one function or action. If there is an “and” in the name, you likely have more than o ne function (and process).
4. have physical location shown only for existing physical systems or a physical design is being represented.
5. are numbered within the diagram as convenient. Levels of detail are shown by decimal notation. For example, top level process would be Process 14, next level of detail Processes 14.1-14.4, and next level with Processes 14.3.1-14.3.6.
6. should generally move from top to bottom and left to right.

---

Procedure:

The procedure for producing a data flow diagram is to:

1. identify and list external entities providing inputs/receiving outputs from system;
2. identify and list inputs from/outputs to external entities;
3. create a context diagram with system at center and external entities sending and receiving data flows;
4. identify the business functions included within the system boundary;
5. identify the data connections between business functions;
6. confirm through personal contact sent data is received and vice-versa;
7. trace and record what happens to each of the data flows entering the system (data movement, data storage, data transformation/processing)
8. attempt to connect any diagram segments into a rough draft;
9. verify all data flows have a source and destination;
10. verify data coming out of a data store goes in;
11. redraw to simplify–ponder and question result;
12. review with “informed”;
13. explode and repeat above steps as needed.

---

Guidelines/Gumption Traps:

(Places where DFDing can go astray)

1. System boundary establishment is an important judgment call. External entities aid in determining where the boundary is established. An interfacing system can be shown as an external entity. It may be necessary to dictate the input of the external entity to assure system control. For example, customers may be required to submit orders or refund requests containing specific information which may require that the system aid in completion of a form. Use of output such as reports by management may re quire some agreement on tactics to be performed which may mean the entity becomes part of the system, not external to it. When in doubt, include the external entity as processes within the system and then evaluate with those concerned.
2. Label your processes carefully and vividly. A process that is labeled “Produce Report” and has the output of “Report” tells a reviewer very little. If you have trouble labeling anything on the diagram, it often is because you do not have adequate un derstanding. Choose names carefully.
3. Think logical, not physical. Ignore media, color, font, layout, packaging, time, sequencing, etc. Think “what”, not “how”. Something logical can be implemented physically in more than one way. Including “when” and “where” and “how” means you are g etting physical.
4. Think data, not control, flow. Data flows are pathways for data. Think about what data is needed to perform a process or update a data store. A data flow diagram is not a flowchart and should not have loops or transfer of control. Think about the data flows, data processes, and data storage that are needed to move a data structure through a system.
5. Concentrate first on what happens to a “good” transaction. Systems people have a tendency to lose sight of the forest because they are so busy concentrating on the branches of the trees.
6. Reviewers will not be convinced by confusion. A quality data flow diagram will be so simple and straightforward that people will wonder what took you so long.
7. Data store to data store, external entity to external entity, or external entity to data store connection usually do not make sense. Data flows with an arrowhead on each end cause confusion in labeling. Do not use them.
8. Do not try to put everything you know on the data flow diagram. The diagram should serve as index and outline. The index/outline will be “fleshed out” in the data dictionary, data structure diagrams, and procedure specification techniques.

Good Luck, Have Fun, and Stay on those Happy Trails……

Data Flow Diagrams

Last edit October 2005

• • • • • Some Questions

    Data Flow Diagrams (DFDs)
    DFD Principles
    An example
    (SSADM) DFD Notations
    DFD Levels
    Notes

  • • System Development, Methodologies, and Modeling
    • System Development Lifecycles
    • Procedure Definitions – low level DFDs

See also:

---

Introduction
The three most important modeling techniques used in analysing and building information systems are: Data Flow Diagramming (DFDs), Logical Data Structure modelling (LDSs), and Entity Life Histories (ELHs)Data Flow Diagrams (DFDs) model events andprocesses(i.e. activities which transform data) within a system. DFDs examine how data flows into, out of, and within the system.
Logical Data Structures (LDSs) represent a system’s information and data in another way. LDSs map the underlying data structures as entity types, entity attributes, and the relationships between the entities
Entity Life Histories (ELHs) describe the changes which happen to ‘things’ (data) within the system.These three techniques are common to many methodologies and are widely used in system analysis. Notation and graphics style may vary across methodologies, but the underlying principles are generally the same.

In SSADM (Structured Systems Analysis and Design Methodology) - which has for a number of years been widely used in the UK – systems analysts and modelers use the above techniques to build up three, inter-related, views of the target system, which are cross-checked for consistency.

---

Data Flow Diagrams (DFDs)

• DFD Principles
• Basic DFD Notations
• (SSADM) DFD Notations
• DFD Levels

“… a structured, diagrammatic technique for showing the functions performed by a system and the data flowing into, out of, and within it ..”

Another way of looking at it is that, in SSADM, DFDs are used to answer the following data-oriented questions about a target system:

What processing is done? When? How? Where? By whom? What data is needed? By whom? for what? When?

However, we are not interested, here, in the development process in detail, only in the general modeling technique. Essentially, DFDs describe the information flows within a system.

DFD Principles

• The general principle in Data Flow Diagramming is that a system can be decomposed into subsystems, and subsystems can be decomposed into lower level subsystems, and so on.
• Each subsystem represents a process or activity in which data is processed. At the lowest level, processes can no longer be decomposed.
• Each ‘process’ (and from now on, by ‘process’ we mean subsystem and activity) in a DFD has the characteristics of a system.
• Just as a system must have input and output (if it is not dead), so a process must have input and output.
• Data enters the system from the environment; data flows between processes within the system; and data is produced as output from the system

An example:The ‘Context Diagram ‘ is an overall, simplified, view of the target system, which contains only one process box, and the primary inputs and outputs.

Context diagram 1

Context diagram 2

Both the above diagrams say the same thing. The second makes use of the possibility in SSADM of including duplicate objects. (In context diagram 2 the duplication of the Customer object is shown by the line at the left hand side. Drawing the diagram in this way emphasizes the Input-Output properties of a system. See also ‘Notes‘ below)The Context diagram above, and the decomposition which follows, are a first attempt at describing part of a ‘Home Catalogue’ sales system. In the modeling process it is likely that diagrams will be reworked and amended many times – until all parties are satisfied with the resulting model. A model can usefully be described as a co-ordinated set of diagrams.

The Top (1st level) DFD

The Top or 1st level DFD, describes the whole of the target system. It ‘bounds‘ the system under consideration.
(To simplify the diagram some notation has been left out – see ‘Notes‘ below)

---

Data Flow Diagrams show:

• the processes within the system
• the data stores (files) supporting the system’s operation
• the information flows within the system
• the system boundary
• interactions with external entities

---

DFD NotationsDFDs are used in most system analysis methodologies. Processes, in other methodologies, may be called ‘Activities’, ‘Actions’, ‘Procedures’, ‘Subsystems’ etc. They may be shown as a circle, an oval, or (typically) a rectangular box. Data are generally shown as arrows coming to, or going from the edge of a process box.(Note that there is no ‘Decision’ symbol. A decision is a Process.

General Data Flow Rules

1. Entities are either ’sources of’ or ’sinks’ for data input and outputs – i.e. they are the originators or terminators for data flows.
2. Data flows from Entities must flow into Processes
3. Data flows to Entities must come from Processes
4. Processes and Data Stores must have both inputs and outputs (What goes in must come out!)
5. Inputs to Data Stores only come from Processes.
6. Outputs from Data Stores only go to Processes.

The Process Symbol Processes transform or manipulate data. Each box has a unique number as identifier (top left) and a unique name (an imperative – e.g. ‘do this’ – statement in the main box area) The top line is used for the location of, or the people responsible for, the process. Processes are ‘black boxes’ – we don’t know what is in them until they are decomposed Processes transform or manipulate input data to produce output data. Except in rare cases, you can’t have one without the other.
Data Flows depict data/information flowing to or from a process. The arrows must either start and/or end at a process box. It is impossible for data to flow from data store to data store except via a process, and external entities are not allowed to access data stores directly. Arrows must be named. Double ended arrows may be used with care .
External Entities , also known as ‘External sources/recipients, are things (eg: people, machines, organisations etc.) which contribute data or information to the system or which receive data/information from it. The name given to an external entity represents a Type not a specific instance of the type. When modelling complex systems, each external entity in a DFD will be given a unique identifier. It is common practice to have duplicates of external entities in order to avoid crossing lines, or just to make a diagram more readable.
Data Stores are some location where data is held temporarily or permanently. In physical DFDs there can be 4 types. D = computerised Data M = Manual, e.g. filing cabinet. T = Transient data file, e.g. temporary program file T(M) = Transient Manual, e.g. in-tray, mail box. As with external entities, it is common practice to have duplicates of data stores to make a diagram less cluttered.

DFD LevelsThe Context and Top Level diagrams in the example start to describe ‘Home Catalogue’ type sales system. The two diagrams are just the first steps in creating a model of the system. (By model we mean a co-ordinated set of diagrams which describe the target system and provide answers to questions we need to ask about that system).As suggested the diagrams presented in the example will be reworked and amended many times – until all parties are satisfied. But the two diagrams by themselves are not enough; they only provide a high level description. On the other hand, the initial diagrams do start to break down, decompose, what might be quite a complex system into manageable parts.

A revision of the example Top Level DFD

The next step – the Next Level(s)

Each Process box in the Top Level diagram will itself be made up of a number of processes, and will need to be decomposed as a second level diagram.

Each box in a diagram has an identification number derived from the parent – in the top left corner. (The Context level is seen as box 0)Any box in the second level decomposition may be decomposed to a third and then a fourth level. Very complex systems may possibly require decomposition of some boxes to further levels.

Decomposition stops when a process box can be described with an Elementary Process Description using ordinary English, later on the process will be described more formally as a Function Description using, for example, pseudocode.

See also: Procedure Definitions – low level DFDs

---

Notes

• Redrawing the diagram makes it clear that Process 3, ‘Maintain Credit Rating’ requires some input – if it is to produce output.
• Note that ‘Goods’, while it is in reality a physical thing, is seen here as data. This is because this is a model. We will represent ‘Goods’ in our model by some description. In the model, ‘Goods’ becomes a set of data items. In the real-world, there will be some physical objects, but in our model we only have an astract description.

---

SSADM uses different sets of Data Flow Diagram to describe the target system in different ways, moving from analysis of the current system to specification of the required system:
.

WHAT the system does	- Current Physical DFD
HOW it does it	- Current Logical DFD
WHAT it should do	- Required Logical DFD
HOW it should do it	- Required Physical DFD

---

ReferencesC.Ashworth & M.Goodland (1990) ‘ SSADM A Practical Approach‘, McGraw-Hill.
D.E.Avison & G.Fitzgerald (1991) ‘Information Systems Development‘, Blackwell.
David A. Marca (1988), ‘SADT. Structured Analysis and Design Technique‘, McGraw-Hill.
Philip L. Weaver (1993) ‘Practical SSADM‘, Pitman

---

Questions

1. Explain the graphic and text notations used in Data Flow Diagrams (DFDs).
2. What are the principles of Data Flow Diagram (DFD) modellimg?
3. Why is DFD modelling useful?
4. Read the following description (which is meant to be fun – but not a joke) and draw up a DFD model for the system described:

There’s this man, see. He sleeps most of the year and only gets up at Christmas. He’s got this band of fairies and elves who do things for him. The elves take care of the mail that he gets all through the year, and the fairies deal with his stock, presents which are made to order by dwarves.Throughout the year this man (Santa) gets letters from boys and girls asking for presents.
When an elf gets a letter from a boy or girl who has been good , they send the letter to the dwarves, who make the requested present.
(Letters from boys and girls who have been bad, get sent back to the senders, with a ‘do better’ message.)
The dwarves send the newly-made presents to the fairies who pack them, taking care to put them in the right sacks so that Santa’s very full schedule on Christmas Eve runs without a hitch.
(A few years ago Santa replaced his sleigh with a second-hand police box, purchased from the BBC, and life is now much easier.)

---

Tony Drewry

Tony’s Home Page