Structure Query Language

Structured Query Language (SQL) adalah sekumpulan perintah khusus yang digunakan untuk mengakses data dalam database relasional. SQL merupakan sebuah bahasa komputer yang mengikuti standar ANSI (American Nasional Standard Institute) yang digunakan dalam manajemen database relasional. Dengan SQL, kita dapat mengakses database, menjalankan query untuk mengambil data dari database, menambahkan data ke database, menghapus data di dalam database, dan mengubah data di dalam database. Saat ini hampir semua server database yang ada mendukung SQL untuk melakukan manajemen datanya.

Terdapat 3 (tiga) jenis perintah SQL, yaitu DDL, DML dan DCL

• DDL

DDL merupakan perintah-perintah yang biasa digunakan administrator database untuk mendefinisikan skema dan subskema database.
Data Definition Language (DDL) mempunyai fungsi utama untuk mendefinisikan data dalam database secara logika, diantaranya yaitu:
Digunakan untuk mendefinisikan karakteristik dari record (meliputi nama, tipe dan lebar dari field), untuk menentukan kunci field, menyediakan cara untuk menentukan hubungan dengan data di file lain, untuk mengubah struktur dari record, untuk menampilkan struktur dari record. DDL digunakan untuk mendefinisikan, mengubah, serta menghapus basis data dan objek-objek yang diperlukan dalam basis data, misalnya tabel. Perintah yang termasuk DDL:
CREATE » untuk membuat, termasuk diantaranya membuat database dan tabel baru.
ALTER » untuk mengubah struktur tabel yang telah dibuat.
DROP » untuk menghapus database dan tabel.

1. Create DataBase ( untuk membuat database)
Syntax SQL CREATE DATABASE

CREATE DATABASE database_name

contoh :

Create Database TokoBuku

2. Create Table (untuk membuat tabel)
Syntax SQL CREATE TABLE

CREATE TABLE table_name
(
column_name1 data_type,
column_name2 data_type,
column_name3 data_type,
….)

contoh:

Create table Buku

(

Id_Buku int, Judul varchar(225), Pengarang varchar (50),PRIMARY KEY (Id_Buku)

)

3. Alter Table (untuk menambah/memodifikasi field dalam tabel)
Syntax SQL ALTER TABLE

ALTER TABLE table_name
ADD column_name datatype

contoh:

Alter table Buku add TanggalBuku date

4. Drop Table (untuk menghapus tabel)
Syntax SQL DROP TABLE

DROP TABLE table_name

contoh:

Drop table Buku

Note:

- Untuk menghapus database juga kita bisa menggunakan syntax Drop
Syntax  SQL DROP DATABASE

Drop Database  Database_Name

contoh:

Drop Database TokoBuku

- Jika kita hanya inggin menghapus isi dari tabel tanpa menghapus tabel itu sendiri dengan menggunkan syntax Truncate.
Syntax  SQL TRUNCATE TABLE

TRUNCATE TABLE table_name

contoh:

Truncate table Buku

5. Create Index (untuk membuat index)
Syntax SQL CREATE INDEX

CREATE INDEX index_name
ON table_name (column_name)

contoh:

Create IndexP on Buku (Judul)

6. Drop Index (untuk menghapus index)
Syntax SQL DROP INDEX

DROP INDEX table_name.index_name

contoh:

Drop Index buku.indexp

• DML

DML merupakan merupakan perintah-perintah yang memungkinkan pengguna melakukan akses dan manipulasi data sebagaimana yang telah diorganisasikan sebelumnya dalam model data yang tepat, Data Manipulation Language digunakan untuk memanipulasi database yang telah didefinisikan dengan DDL. Perintah yang termasuk DML:
INSERT » untuk menyisipkan atau memasukan dalam tabel
UPDATE » untuk memperbaharui data lama menjadi data terkini
DELETE » untuk menghapus datadari tabel
SELECT » untuk mengambil data atau menampilkan data dari satu tabel atau beberapa tabel.

1. SELECT – menampilkan  data/ isi tabel dari database
Syntax SQL SELECT

Select * from table name

contoh:

Select * from Buku

2. INSERT INTO – menambah data baru didalam database
Syntax SQL INSERT INTO

INSERT INTO table_name
VALUES (value1, value2, value3,…)

contoh:

Insert Into Buku values (’001′,’Introduction SQL’,’Mark’,’19/02/2011′)

3. UPDATE – merubah data didalam database
Syntax SQL UPDATE

UPDATE table_name
SET column1=value, column2=value2,…
WHERE some_column=some_value

contoh:

Update Buku set judul = ‘Database System’ where Id_Buku =’001′

4. DELETE – menghapus  data dari database
Syntax SQL DELETE

DELETE FROM table_name
WHERE some_column=some_value

contoh:

Delete from Buku where Id_Buku =’001′

• DCL

DCL merupakan merupakan perintah-perintah yang digunakan untuk mengontrol data. Perintah yang termasuk DCL:
GRAND » untuk memberikan hak atau izin akses oleh administrator server kepada user
REVOKE » untuk menghilangkan atau mencabut hak akses yang telah diberikan kepada user oleh administrator.

UML

Pengertian UML (Unified Modelling Language)

UML (Unified Modelling Language) adalah sebuah “bahasa” yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.
Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun.
UML mendefinisikan diagramdiagram sebagai berikut:

• use case diagram
• class diagram
• statechart diagram
• activity diagram
• sequence diagram
• collaboration diagram
• component diagram
• deployment diagram

1.1 Macam-Macam Diagram UML
Penjelasan dari masing-masing diagram tersebut akan dijelaskan dalam bentuk sub bab berikut ini :
1.1.1 Use Case Diagram
Use Case diagram adalah gambar dari beberapa atau seluruh aktor dan use case dengan tujuan mengenali interaksi mereka dalam suatu sistem. Oleh karena itu, use case diagram dapat membantu menganalisa kebutuhan suatu sistem. Dalam use case diagram terdapat istilah seperti aktor, use case dan use case relationship.

• Aktor

Aktor mewakili siapa pun atau apa saja yang harus berinteraksi dengan sistem. Aktor bisa didefinisikan sebagai berikut :

1. Aktor hanya memberikan informasi kepada sistem.
2. Aktor hanya menerima informasi dari sistem.
3. Aktor memberikan dan menerima informasi ke dan dari sistem.

Adapun pertanyaan yang berguna untuk membantu mengenali aktor dalam suatu sistem:

1. Siapa orang yang berkepentingan dalam sistem?
2. Dimana organisasi sistem akan digunakan?
3. Siapa yang akan diuntungkan dari penggunaan sistem?
4. Siapa yang akan memenuhi sistem dengan informasi, menggunakan informasi dan menghapus informasi?
5. Siapa yang mendukung dan menggunakan sistem?
6. Apakah sistem menggunakan sebuah sumber dari luar?
7. Apakah satu bermain menjadi beberapa peran yang berbeda?
8. Apakah sistem mempengaruhi dengan sistem turunannya?

• Use Case

Use Case Model adalah dialog antara aktor dengan sistem yang akan menggambarkan fungsi yang diberikan oleh sistem.Ada beberapa pertanyaan yang dapat membantu mengenal use case untuk sistem, yaitu sebagai berikut:

1. Apakah tugas dari setiap aktor?
2. Dapatkah aktor melakukan, membuat, menyimpan, merubah, menghapus atau membaca informasi?
3. Apakah use case akan membuat, menyimpan, mengganti, menghapus atau membaca informasi?
4. Dapatkah aktor menginformasikan sistem tentang perubahan yang terjadi perubahan dari luar secara mendadak?
5. Apakah aktor perlu menginformasikan tentang kejadian dalam sistem?
6. Apakah use case akan mendukung dan mempertahankan sistem?
7. Bisakah semua fungsi use case memenuhi kebutuhan?

• Use Case Relationship

Use Case Relationship adalah suatu hubungan baik itu antara aktor dan use case atau antara use case dan use case. Hubungan antara aktor dan use case disebut dengan communicate association

1.1.2 Kelas Diagram
Kelas Diagram berfungsi untuk menjelaskan tipe dari object sistem dan hubungannya dengan object yang lain. Object adalah nilai tertentu dari setiap attribute kelas entity. Pada penggambaran kelas diagram ada dikenal dengan kelas analisis yaitu kelas ber-stereotype. Tapi yang biasanya dipakai adalah kelas diagram tanpa stereotype.

1.1.3 State Diagram
State diagram menggambarkan urutan keadaan yang dilalui object dalam suatu kelas, karena suatu kejadian menyebabkan suatu perpindahan aktivitas/state. State dari objek adalah penggolongan dari satu atau lebih nilai attribute pada kelas.
1.1.4 Activity Diagram
Activity Diagram berupa flow chart yang digunakan untuk memperlihatkan aliran kerja dari sistem. Notasi yang digunakan dalam activity diagram adalah sebagai berikut:

1. Activity

Notasi yang menggambarkan pelaksanaan dari beberapa proses dalam aliran pekerjaan.

1. Transition

Notasi yang digunakan untuk memperlihatkan jalan aliran kontrol dari activity ke activity.

1. Decision

Notasi yang menandakan kontrol cabang aliran berdasarkan decision point.

1. Synchronization Bars

Aliran kerja notasi ini menandakan bahwa beberapa aktivitas dapat diselesaikan secara bersamaan (pararel)

1.1.5 Sequence Diagram
Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.
1.1.6 Collaboration Diagram
Collaboration adalah cara alternatif untuk mengetahui tahap-tahap terjadinya suatu aktivitas. Perbedaan antara collaboration dan sequence diagram adalah collaboration diagram memperlihatkan bagaimana hubungan antara beberapa objek, sedangkan yang kedua sequence diagram memperlihatkan bagaimana urutan kejadian
1.1.7 Component Diagram
Component diagram berfungsi untuk menggambarkan komponen run-time dan executable yang dibuat untuk sistem. Komponen saling berelasi menggunakan depedecy relation (Hubungan ketergantungan, yang ditandai dengan garis putus-putus). Komponen run-time memperlihatkan pengelompokan kelas untuk run-time library seperti Java Applet, Active-X Component dan Dynamic Libraries. Komponen executable memperlihatkan interface dan memanggil dependencies beberapa executable. Interface kelas diperlihatkan seperti lollypop.
1.1.8 Deployment Diagram
Deployment Diagram memperlihatkan konfigurasi pada jalannya proses run-time elements  dan proses software yang ada pada diagram. Run-time elements menggambarkan node yang berkoneksi menandakan adanya komunikasi diantaranya. Diagram ini membantu tim untuk mengerti sistem topology
2. Tool Yang Mendukung UML
Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial
maupun opensource. Beberapa diantaranya adalah:

• Rational Rose (www.rational.com)
• Together (www.togethersoft.com)
• Object Domain (www.objectdomain.com)
• Jvision (www.object-insight.com)
• Objecteering (www.objecteering.com)
• MagicDraw (www.nomagic.com/magicdrawuml)
• Visual Object Modeller (www.visualobject.com)
• StarUML

3. Requirement
Requerement adalah pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem.
3.1 Jenis Requirements
3.1.1  Requirement Fungsional
Kebutuhan fungsional harus mendefinisikan aksi dasar yang harus diambil oleh
perangkat lunak untuk menerima dan memproses masukan dan menghasilkan keluaran.
3.3.2   Requuirement Non Fungsional
Bagian ini menspesifikasikan ukuran kuantitatif yang harus dipenuhi oleh perangkat
lunak. Uraian minimal pada bagian ini berisi sebuah tabel, dengan kolom: Kriteria
Kebutuhan, Tuntutan kebutuhan. Kebutuhan tersebut antara lain: Performansi,
Batasan Memori, Modus Operasi, Adaptasi Situs atau Ergonomi.
4. Testing (Pengujian Perangkat Lunak)
Adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain, dan pengkodean.
Sejumlah aturan yang berfungsi sebagai sasaran pengujian pada perangkat lunak adalah:

1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan
2. Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya
3. Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya

Sasaran utama desain test case adalah untuk mendapatkan serangkaian pengujian yang memiliki kemungkinan tertinggi di dalam pengungkapan kesalahan pada perangkat lunak. Untuk mencapai sasaran tersebut, digunakan 4 kategori yang berbeda dari tehnik desain test case: Pengujian white-box, pengujian black-box, Integrasi Bottom-Up dan Integrasi Top-Down.
4.1 Pengujian white-box berfokus pada struktur control program. Test case dilakukan untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diuji. Pengujian basic path, tehnik pengujian white-box, menggunakan grafik (matriks grafiks) untuk melakukan serangkaian pengujian yang independent secara linear yang akan memastikan cakupan.
Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program dan pengujian loop menyempurnakan tehnik white-box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi. Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.
4.2 Tehnik pengujian black-box berfokus pada domain informasi dari perangkat lunak, dengan melakukan test case dengan menpartisi domain input dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam.
Metode pengujian graph-based mengeksplorasi hubungan antara dan tingkah laku objek-objek program. Partisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai batas memeriksaa kemampuan program untuk menangani data pada batas yang dapat diterima.
Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat lunak dan area aplikasi. GUI, arsitektur client/ server, dokumentasi dan fasilitas help dan sistem real time masing-masing membutuhkan pedoman dan tehnik khusus untuk pengujian perangkat lunak.
4.3 Integrasi Top-Down adalah pendekatan incremental dengan menggerakkan ke bawah melalui hirarki control, dimulai dengan control utama. Strategi intergrasi top-down memeriksa control mayor atau keputusan pada saat awal di dalam proses pengujian. Pada struktur program yang difaktorkan dengan baik, penarikan keputusan terjadi pada tingkat hirarki yang lebih tinggi sehingga terjadi lebih dulu.
Strategi top-down kelihatannya tidak sangat rumit, tetapi di dalam praktenya banyak menimbulkan masalah logistic. Biasanya masalah ini terjadi jika dibutuhkan pemrosesan di dalam hirarki pada tingkat rendah untuk menguji secara memadai tingkat yang lebih tinggi.

4.4 Pengujian Integrasi Bottom-up memulai konstruksi dan pengujian dengan modul atomic (modul pada tingkat paling rendah pada struktur program). Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinate ke suatu tuingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi

Dalam pembahasan kali ini saya ingin membahas Apa sih UML itu ? dan jenis-jenis UML apa saja ? oke deh, langsung aja ya disimak.. :

Pengertian UML

              UML (Unified Modeling Language) adalah sebuah bahasa untuk menetukan, visualisasi, kontruksi, dan mendokumentasikan artifact (bagian dari informasi yang digunakan atau dihasilkan dalam suatu proses pembuatan perangkat lunak. Artifact dapat berupa model, deskripsi atau perangkat lunak) dari system perangkat lunak, seperti pada pemodelan bisnis dan system non perangkat lunak lainnya.

            UML merupakan bahasa standar untuk penulisan blueprint software yang digunakan untuk visualisasi, spesifikasi, pembentukan dan pendokumentasian alat-alat dari sistem perangkat  lunak.

 Jenis-jenis Diagram UML, yaitu :

1. Use Case Diagram

     Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai.

Lihat Gambar:

 Diagram Use Case berguna dalam tiga hal :

• Menjelaskan fasilitas yang ada (requirement)

• Komunikasi dengan klien

• Membuat test dari kasus-kasus secara umum

2. Activity Diagram

            Activity diagram menyediakan analis dengan kemampuan untuk memodelkan proses dalam suatu sistem informasi. Activity diagram dapat digunakan untuk alur kerja model, use case individual, atau logika keputusan yang terkandung dalam metode individual3. Activity diagram juga menyediakan pendekatan untuk proses pemodelan paralel. Activity diagram lebih lanjut .

            Pada dasarnya, diagram aktifitas canggih dan merupakan diagram aliran data yang terbaru. Secara teknis, diagram aktivitas menggabungkan ide-ide proses pemodelan dengan teknik yang berbeda termasuk model acara, statecharts, dan Petri Nets.

Lihat Gambar:

3. Package Diagram

            Package diagram utamanya digunakan untuk mengelompokkan elemen diagram UML yang berlainan secara bersama-sama ke dalam tingkat pembangunan yang lebih tinggi yaitu berupa sebuah paket. Diagram paket pada dasarnya adalah diagram kelas yang hanya menampilkan paket, disamping kelas, dan hubungan ketergantungan, disamping hubungan khas yang ditampilkan pada diagram kelas.

            Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka. 

Lihat Gambar:

4. State Machines Diagram

Statechart diagram digunakan untuk memodelkan perilaku dinamis satu kelas atau objek. Statechart diagram memperlihatkan urutan keadaan sesaat (state) yang dilalui sebuah objek, Kejadian yang menyebabkan sebuah transisi dari suatu state atau aktivitas kepada yang lainnya.

            Statechart diagram khusus digunakan untuk memodelkan tahap-tahap diskrit dari sebuah siklus hidup objek, sedangkan Activity diagram paling cocok untuk memodelkan urutan aktifitas dalam suatu proses.

Lihat Gambar:

5. Sequence Diagram
 

            Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.

Lihat Gambar:

6. Class Diagram

            Tujuan utama dari class diagram adalah untuk menciptakan sebuah kosa kata yang digunakan oleh analis dan pengguna. Diagram kelas biasanya merupakan hal-hal, ide-ide atau konsep yang terkandung dalam aplikasi. Misalnya, jika anda sedang membangun sebuah aplikasi penggajian, diagram kelas mungkin akan berisi kelas yang mewakili hal-hal seperti karyawan, cek, dan pendaftaran gaji. Diagram kelas juga akan menggambarkan hubungan antara kelas. 

Class memiliki 3 area pokok :

1. Name (dan stereotype);

2. Attribute;

3. Method.

Lihat Gambar:

7. Communication Diagram

            Collaboration diagram menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek. Setiap message memiliki sequence number, dimana message dari level tertinggi memiliki Nomor 1. Diagram membawa informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan.

Contoh : Diagram Collaboration “Pemesanan kamar di Hotel”.

Lihat Gambar:

8. Composite Structure Diagram

            Diagram struktur komposit adalah diagram yang menunjukan struktur internal classifier, termasuk poin interaksinya ke bagian lain dari system. Hal ini menunjukkan konfigurasi dan hubungan bagian, yang bersama-sama melakukan perilaku classifier. Diagram struktur komposit merupakan jenis diagram struktur yang statis dalam UML, yang menggambarkan struktur internal kelas dan kolaborasi.

Struktur komposit dapat digunakan untuk menjelaskan:

- Struktur dari bagian-bagian yang saling berkaitan;

- Run-time struktur yang saling berhubungan.

Lihat Gambar:

9. Object Diagram

            Object diagram merupakan sebuah gambaran tentang objek-objek dalam sebuah system pada satu titik waktu. Karena lebih menonjolkan perintah-perintah dari pada class, object diagram lebih sering disebut sebagai sebuah diagram perintah.

Lihat Gambar:

10. Timing Diagram

            Timing Diagram adalah bentuk lain dari interaction diagram, dimana focus utamanya lebih ke waktu. Timing diagram sangat berdaya guna dalam menunjukkan factor pembatas waktu diantara perubahan state pada objek yang berbeda.

Lihat Gambar:

11. Component Diagram

            Diagram ini bila dikombinasikan dengan diagram penyebaran dapat digunakan untuk menggambarkan distribusi fisik dari modul perangkat lunak melalui jaringan. Misalnya, ketika merancang sistem client-server, hal ini berguna untuk menunjukkan mana kelas atau paket kelas akan berada pada node klien dan mana yang akan berada di server.

            Diagram komponen juga dapat berguna dalam merancang dan mengembangkan sistem berbasis komponen. Karena berfokus pada analisis sistem berorientasi objek dan desain.

Lihat Gambar:

12. Deployment Diagram

            Deployment diagram menggambarkan detail bagaimana komponen di deploy dalam infrastruktur system, dimana komponen akan terletak (pada mesin, server atau piranti keras), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Hubungan antar node ( misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.

Lihat Gambar:

13. Interaction Overview Diagram

            Interaction Overview Diagram adalah pecangkolan secara bersama antara activity diagram dengan sequence diagram. Interaction Overview Diagram dapat dianggap sebagai activity diagram dimana semua aktivitas diganti dengan sedikit sequence diagram, atau bisa juga dianggap sebagai sequence diagram yang dirincikan dengan notasi activity diagram yang digunakan untuk menunjukkan aliran pengawasan.

Lihat Gambar:

Data Flow Diagram (DFD)

Pengertian Data Flow Diagram (DFD)

Data Flow Diagram atau sering disingkat DFD adalah perangkat-perangkat analisis dan perancangan yang terstruktur sehingga memungkinkan peng-analis sistem memahami sistem dan subsistem secara visual sebagai suatu rangkaian aliran data yang saling berkaitan.

gambar 1.1 Simbol-simbol dalam DFD

Entitas  biasanya diberi nama dengan kata benda.

Aliran data merupakan perpindahan data dari satu titik ke titik yang lain (penggambarannya dengan cara kepala tanda panah mengarah ke tujuan datanya.

Proses biasanya selalu menunjukkan suatu perubahan data dan terjadinya proses transformasi data.

Penyimpanan Data (data store) diberi nama dengan kata benda, sesuai dengan data yang disimpan didalamnya.

Didalam DFD terdapat 3 level, yaitu :

1. Diagram Konteks : menggambarkan satu lingkaran besar yang dapat mewakili seluruh proses yang terdapat di dalam suatu sistem. Merupakan tingkatan tertinggi dalam DFD dan biasanya diberi nomor 0 (nol). Semua entitas eksternal yang ditunjukkan pada diagram konteks berikut aliran-aliran data utama menuju dan dari sistem. Diagram ini sama sekali tidak memuat penyimpanan data dan tampak sederhana untuk diciptakan.

2. Diagram Nol (diagram level-1) : merupakan satu lingkaran besar  yang mewakili lingkaran-lingkaran kecil yang ada di dalamnya. Merupakan pemecahan dari diagram Konteks ke diagram Nol. di dalam diagram ini memuat penyimpanan data.

3. Diagram Rinci : merupakan diagram yang menguraikan proses apa yang ada dalam diagram Nol.

Fungsi DFD

Fungsi dari Data Flow Diagram adalah :

• Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan profesional sistem untuk menggambarkan sistem sebagai suatu jaringan proses fungsional yang dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi.
• DFD ini adalah salah satu alat pembuatan model yang sering digunakan, khususnya bila fungsi-fungsi sistem merupakan bagian yang lebih penting dan kompleks dari pada data yang dimanipulasi oleh sistem. Dengan kata lain, DFD adalah alat pembuatan model yang memberikan penekanan hanya pada fungsi sistem.
• DFD ini merupakan alat perancangan sistem yang berorientasi pada alur data dengan konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan sistem yang mudah dikomunikasikan oleh profesional sistem kepada pemakai maupun pembuat program.

• SYARAT MEMBUAT DFD

Syarat-syarat pembuatan DFD ini adalah :

1. Pemberian nama untuk tiap komponen DFD.

2. Pemberian nomor pada komponen proses.

3. Penggambaran DFD sesering mungkin agar enak dilihat.

4. Penghindaran penggambaran DFD yang rumit.

5. Pemastian DFD yang dibentuk itu konsiten secara logika.

• TIPS DALAM MEMBUAT DFD

Berikut ini tips-tips dalam membuat DFD :

1. Pilih notasi sehingga proses yang didekomposisi atau tidak didekomposisi dapat dibaca dengan mudah.
2. Nama proses harus terdiri dari kata kerja dan kata benda.
3. Nama yang dipakai untuk proses, data store, dataflow harus konsisten (identitas perlu).
4. Setiap level harus konsisten aliran datanya dengan level sebelumnya.
5. Usahakan agar external entity pada setiap level konsisten peletakannya.
6. Banyaknya proses yang disarankan pada setiap level tidak melebihi 7 proses.
7. Dekomposisi berdasarkan kelompok data lebih disarankan (memudahkan aliran data ke storage yang sama).
8. Nama Proses yang umum hanya untuk prose yang masih akan didekomposisi.
9. Pada Proses yang sudah tidak didekomposisi, nama Proses dan nama Data harus sudah spesifik.
10. Aliran ke storage harus melalui proses, tidak boleh langsung dari external entity.
11. Aliran data untuk Proses Report .. : harus ada aliran keluar. Akan ada aliran masuk jika perlu parameter untuk mengaktifkan report.Aliran data yang tidak ada datastorenya harus diteliti, apakah memang tidak mencerminkan persisten entity (perlu disimpan dalam file/tabel), yaitu kelak hanya akan menjadi variabel dalam program.

• LANGKAH MEMBUAT/MENGGAMBAR DFD

Tidak ada aturan baku untuk menggambarkan DFD. Tapi dari berbagai referensi yang ada, secara garis besar langkah untuk membuat DFD adalah :

1. Identifikasi Entitas Luar, Input dan Output

Identifikasi terlebih dahulu semua entitas luar, input dan ouput yang terlibat di sistem.

2. Buat Diagram Konteks (diagram context)

Diagram ini adalah diagram level tertinggi dari DFD yang menggambarkan hubungan sistem dengan    lingkungan luarnya. Caranya :

• Tentukan nama sistemnya.

• Tentukan batasan sistemnya.

• Tentukan terminator apa saja yang ada dalam sistem.

• Tentukan apa yang diterima/diberikan external entity dari/ke sistem.

• Gambarkan diagram konteks.

3. Buat Diagram Level Zero (Overview Diagram)

Diagram ini adalah dekomposisi dari diagram konteks. Caranya :

• Tentukan proses utama yang ada pada sistem.
• Tentukan apa yang diberikan/diterima masing-masing proses ke/dari sistem sambil memperhatikan konsep keseimbangan (alur data yang keluar/masuk dari suatu level harus sama dengan alur data yang masuk/keluar pada level berikutnya).
• Apabila diperlukan, munculkan data store (master) sebagai sumber maupun tujuan alur data.
• Hindari perpotongan arus data.
• Beri nomor pada proses utama (nomor tidak menunjukkan urutan proses).

4. Buat Diagram Level Satu

Diagram ini merupakan dekomposisi dari diagram level zero. Caranya :

• Tentukan proses yang lebih kecil (sub-proses) dari proses utama yang ada di level zero.
• Tentukan apa yang diberikan/diterima masing-masing sub-proses ke/dari sistem dan perhatikan konsep  keseimbangan.
• Apabila diperlukan, munculkan data store (transaksi) sebagai sumber maupun tujuan alur data.
• Hindari perpotongan arus data.
• Beri nomor pada masing-masing sub-proses yang menunjukkan dekomposisi dari proses sebelumnya.Contoh : 1.1, 1.2, 2

• KESALAHAN DALAM PEMBUATAN DFD

Umumnya kesalahan dalam pembuatan DFD adalah :

1. Proses mempunyai input tetapi tidak menghasilkan output. Kesalahan ini disebut dengan black hole (lubang hitam), karena data masuk ke dalam proses dan lenyap tidak berbekas seperti dimasukkan ke dalam lubang hitam.
2. Proses menghasilkan output tetapi tidak pernah menerima input. Kesalahan ini disebut dengan miracle (ajaib), karena ajaib dihasilkan output tanpa pernah menerima input.
3. Input yang masuk tidak sesuai dengan kebutuhan proses.
4. Data Store tidak memiliki keluaran.
5. Data Store tidak memiliki masukan.
6. Hubungan langsung antar entitas luar.
7. Masukan langsung entitas data store.
8. Keluaran langsun dari data store ke Entitas luar.
9. Hubungan langsung antar data store.
10. Data masukan dan keluaran yang tidak bersesuain dalam data store.

Proses Rekayasa Kebutuhan

Merupakan proses menemukan, memperbaiki, memodelkan dan menspesifikasikan.

Terdiri dari lima langkah pokok:

1. Identifikasi Masalah
2. Evaluasi dan sintesis
3. Pemodelan
4. Spesifikasi
5. Review

• Lengkap: Mendeskripsikan semua fasilitas yang diinginkan
• Konsisten: Tidak adanya konflik dan kontradiksi

Proses Rekayasa Kebutuhan

• sudah sesuai dengan tujuan organisasi

• dapat dikembangkan dengan teknologi terkini dan dana yang tersedia

• dapat diintegrasikan dengan sistem lain yang sudah digunakan

• Bank customers

• Representatives of other banks

• Hardware and software maintenance engineers

• Marketing department

• Bank managers and counter staff

• Database administrators and security staff

• Communications engineers

• Personnel department

• Penggambaran bagaiman sistem akan digunakan

• Membantu dalam menemukan kebutuhan dengan mempermudah dalam penggambaran proses dibandingkan pernyataan abstrak kebutuhan sistem

• Menambahkan detail ke outline deskripsi kebutuhan

• Sistem State pada awal scenario

• Alur Normal kejadian-kejadian di sistem

• Apa yang dapat berkembang dan bagaimana menanganinya

• Aktifitas-aktifitas yang bersamaan terjadi

• System state setelah proses selesai

• Skenario kejadian dapat digunakan untuk menggambarkan bagaimana sistem merespon ke suatu kejadian tertentu seperti awal transaksi

• VORD dapat berupa diagram untuk menggambarkan scenario kejadian

• Data yang dikirim dan disediakan

• Kontrol Informasi

• Pengecualiaan Proses

• Kejadian berikutnya

• Elips menyatakan data yang disediakan oleh dan dikirim ke viewpoint

• Data keluar dari sisi kanan setiap kotak

• Eksepsi ditunjukkan di bawah maisng-masing box

• Nama kejadian berikutnya berada di box dengan garis panah tebal

• Timeout: Pelanggan salah memasukkan nomor PIN selama waktu yang diberikan

• Invalid Card: Kartu tidak diknal oleh sistem dan dikembalikan

• Stolen Card: Kartu sudah diregister sebagai kartu yang sudah dicuri/hilang dan akan diambil oleh sistem (tidak dikembalikan)

• Bertujuan untuk meyakinkan bahwa kebutuhan yang sudah didefinisikan sesuai dengan yang diinginkan pengguna

• Menghindari Kesalahan pendefinisian kebutuhan karena akan menyebabkan penambahan biaya yang besar

• Memperbaiki definisi kebutuhan stelah software dikirim akan menyebabkan peningkatan biaya hingga 100 kali.

• Validasi. Apakah sudah sesuai dengan yang diinginkan

• Konsistensi. Adakah konflik dengan kebutuhan lainnya

• Lengkap: Apakah sudah termasuk semua fungsi yang dibutuhkan

• Realisasi: Dapatkan kebutuhan diimplementasikan ke dana dan teknologi yang tersedia

• Dapat diverifikasi: Dapatkah spesifikasi kebutuhan dicek

Teknik Validasi Kebutuhan
Review:
Prototyping
Test-Case Generator
Analisis Konsistensi Otomatis

Dalam menemukan Area permasalahan, perlu adanya komunikasi yang intensif dengan user. Hal yang perlu diperhatikan dalam berkomunikasi adalah menghindari salah interpretasi

Jenis Kebutuhan:

1. Kebutuhan Fungsional

Pendefinisian layanan yang harus disediakan, bagaimana reaksi sistem terhadap input dan apa yang harus dilakukan sistem pada situasi khusus (Kebutuhan sistem dilihat dari kacamata pengguna)

 2. Kebutuhan Non-Fungsional

Kendala pada pelayanan atau fungsi sistem seperti kendala waktu, kendala proses pengembangan, standard, dll. Contoh: kehandalan, waktu respon dan kebutuhan storage. Contoh kendala seperti: Keterbatasan kemampuan peralatan I/O, representasi sistem dll.

Domain Kebutuhan

Kebutuhan yang berasal dari domain aplikasi sistem dan merefleksikan karakteristik domain

Secara Prinsip, spesifikasi Kebutuhan harus:

Tipe Non-Fungsional

Studi kelayakan

Studi Kelayakan memutuskan apakah sistem software yang akan dibuat sudah mencakup seluruh aspek permasalahan. Melakukan studi untuk menguji apakah sistem:

- Feasibility Study 

sebuah analisa dan evaluasi dari proyek yang diusulkan untuk menentukan apakah secara teksis layak, layak dalam perkiraan biaya dan menguntungkan.

- Feasibility Report

analisis yang mengevaluasi satu atau lebih langkah-langkah tindakan potensial dan merekomendasikan bagaimana organisasi tersebut harus dilanjutkan. Diperkirakan biaya, mengidentifikasi manfaat yang diharapkan memperkirakan berapa lama proyek akan mengambil dan menguraikan kesulitan potensial.

- Requirements  Elicitation and Analysis

pengumpulan persyaratan sistem pengguna, pelanggan dan stakeholder lainnya. meliputi wawancara, kuisioner, observasi pengguna.

- System Model

sistem model konseptual yang menggambarkan dan mewakili suatu sistem. Sebuah sistem terdiri dari beberapa pandangan seperti perencanaan, persyaratan, desain, implementasi, penyebaran, struktur, perilaku, input data, dan data tampilan output.

Dalam system model terdapat 2 pendekatan, yaitu

1. Pendekatan non-arsitektur

terstruktur Sistem Metode Analisis dan Desain (SSADM), memilih bagan struktur untuk deskripsi struktur dan data flow diagram (DFD) untuk deskripsi perilaku.

2. Pendekatan arsitektur

arsitektur sistem menggunakan Bahasa Arsitektur Deskripsi (ADL) baik struktur dan perilaku deskripsi.

- Requirements spesification 

akibat langsung dari analisis kebutuhan dan dapat merujuk.

- User Requirements

kebutuhan pengguna, menggambarkan apa yang pengguna lakukan dengan sistem, seperti kegiatan yang pengguna harus dapat melakukan apa. Persyaratan pengguna umumnya didokumentasikan dalam Dokumen Persyaratan Pengguna (URD) menggunakan teks narasi. Persyaratan pengguna umumnya ditanda tangani oleh pengguna dan digunakan sebagai masukan utama untuk menciptakan persyaratan sistem.

- System Requirements 

persyaratan sistem diklarifikasikan sebagai persyaratan baik fungsional maupun tambahan. 

*Persyaratan fungsional menentuka sesuatu yang pengguna perlu untuk melakukan pekerjaan mereka. contoh : sistem mungkin diperlukan untuk mencetak dan masuk perkiraan biaya.

*Persyaratan non-fungsional atau tambahan menentukan semua persyaratan yang tersisa tidak tercakup oleh persyaratan fungsional 

- Requirements Validation

kepastian bahwa suatu produk, layanan, atau sistem memenuhi kebutuhan pelanggan dan stakeholder lainnyadidentifikasi. Ini sering melibatkan penerimaan dan kesesuaian dengan pelanggan eksternal.

- Requirements Document

dokumen yang ditulis oleh sebuah perusahaan yang mendefinisikan sebuah produk yang mereka buatatau persyaratan untuk satu atau lebih fitur baru untuk produk yang sudah ada. Fungsinya sebagai pemasaran persyaratan dokumen juga, terutama jika produk tersebut rumit atau kecil. 

Implementasi Studi Kelayakan

Proses analisis kebutuhan

Pemodelan Sistem

Dapat dilakukan dalam beberapa cara, seperti model structural, state machine, state chart, dll. Pemodelan tersebut dapat pula direpresentasikan sebagai formaliasi sudut pandang pengguna (viewpoint-oriented)

Viewpoint-oriented elicitation

Stakeholder merepresentatikan sudut pandang suatu masalah dalam beberapa cara. Analisis Multi perspektif adalah penting jika tidak terdapat suatu cara yang benar untuk menganalisa kebutuhan sistem.

Contoh: Sistem ATM Bank

Sistem ATM dapat menyediakan pelayanan bank secara otomatis. Pelayanan tersebut mencakup: penarikan tunai, pengiriman pesan untuk permintaan layanan, pemensanan, dan transfer.

Autoteller viewpoint

Identifikasi Viewpoint

Menemukan viewpoint sebagai penerima layanan sistem dan mengidentifikasikan layanan yang disediakan untuk masing-masing viewpoint

Pembentukan Struktur Viewpoint

Mengelompokkan viewpoint yang saling berhubungan secara hierarki. Layanan umum disediakan pada level yang lebih tinggi dalam hierarki

Dokumentasi Viewpoint : Memperbaiki deskripsi viewpoint dan layanan yang teridentifikasi

Viewpoint system mapping : Transformasi analisis ke perancangan berorientasi objek

Viewpoint Service Information

Skenario

Deskripsi Dan Skenario

Skenarion Kejadian

Notasi:

Pada contoh di atas, eksepsi adalah:

Validasi Kebutuhan

Pengujian Pendefinisian Kebutuhan

Managemen Perubahan Kebutuhan