BAB 4 PERANCANGAN, IMPLEMENTASI, DAN EVALUASI. Teori umum yang dibahas dalam penulisan skripsi ini mencakup teori sistem

Transkripsi

1 BAB 4 PERANCANGAN, IMPLEMENTASI, DAN EVALUASI 4.1 Perancangan Basis Data Teori umum yang dibahas dalam penulisan skripsi ini mencakup teori sistem basis data, Database Management System (DBMS), Database Lifecycle, serta metodologi perancangan basis data Perancangan Basis Data Konseptual Whitten (2007: 523) mendefinisikan data sebagai sumber yang harus dikontrol dan dikelola. Dalam lingkungan basis data, data menjadi suatu sumber bisnis yang menyediakan akses kepada end-user dan programmer untuk membangun suatu sistem informasi. Arsitektur data yang baik dapat menjelaskan bagaimana bisnis dapat mengembangkan dan menggunakan file serta database untuk menyimpan seluruh data Identifikasi Tipe Entitas Langkah awal untuk membangun conceptual data model adalah mengidentifikasi tipe entitas utama yang dibutuhkan oleh user. Berikut ini merupakan entitas-entitas berdasarkan analisa spesifikasi kebutuhan user: Tabel 4.1 Identifikasi Tipe Entitas Entity Name Description Aliases Occurence User Merupakan entitas yang berisi informasi Pengguna Setiap pengguna yang memakai Document Imaging. 76

2 77 mengenai keterangan pengguna aplikasi. Branch Merupakan Cabang Setiap wilayah entitas yang memiliki satu berisikan branch. informasi mengenai cabang. Box Merupakan Kotak Setiap dokumen entitas yang disimpan dalam satu berisikan box. informasi mengenai box. Role Merupakan Peran Setiap pengguna entitas yang memiliki satu role. berisikan informasi mengenai role dan privilege. Document_type Merupakan Tipe Setiap tipe dokumen entitas yang Dokumen yang dipakai dalam

3 78 berisikan Document Imaging. informasi mengenai tipe dokumen yang akan digunakan. Document_field Merupakan Field Setiap field dokumen entitas yang Dokumen memiliki satu berisikan Document_type informasi mengenai apa saja field yang dibutuhkan Saat mengisi dokumen Document Merupakan entitas yang berisikan informasi mengenai dokumen yang di-upload oleh pengguna. Dokumen Setiap dokumen yang di-upload dengan menggunakan Document Imaging.

4 79 Sequence Merupakan Urutan Setiap dokumen, entitas yang box, dan tipe berisikan dokumen yang informasi terbentuk akan mengenai mempengaruhi isi sequence yang dari entitas sequence. digunakan oleh entitas document, box, dan document_type Identifikasi Tipe Relationship Tujuan dari langkah ini ialah untuk menentukan hubungan yang terjadi antara tipe-tipe entitas yang telah diidentifikasi. Berikut ini merupakan hubungan-hubungan antar entitas yang telah diidentifikasi:

5 80 Tabel 4.2 Identifikasi Tipe Relationship Antar Entitas Entity Name Multiplicity Relationship Entity Name Multiplicity Role 1..1 Memiliki User 0..* Branch 1..1 Memiliki User 0..* 1..1 Melibatkan Sequence 0..* 1..1 Memiliki Box 0..* Box 1..1 Memiliki Document 0..* Document_ 1..1 Memiliki Document_field 1..* type 1..1 Memiliki Document 0..* Document_ 1..1 Melibatkan Document 0..* field Identifikasi dan Asosiasikan Atribut dengan Entitas atau Tipe Relationship Setelah mengidentifikasi tipe-tipe entitas serta relationship antar entitas, langkah selanjutnya adalah mengasosiasikan atribut-atribut dengan tipe entitas dan relationship yang sesuai.

6 81 Gambar 4.1 Entity Relationship Diagram Konseptual Awal Tabel 4.3 Identifikasi Entitas User Entity Attribute Description Date type & Null Multi Name Length Valued User User_id ID User Smallint(6) Username Username Varchar(20) Password Sandi Char(32) Name Nama User Varchar(100) Branch_id ID Cabang Smallint(6) Role_id ID Role Smallint(6) Created_by Pembuat Varchar(20) Created_date Tanggal dibuat Timestamp

7 82 Tabel 4.4 Identifikasi Entitas Role Entity Attribute Description Date type & Null Multi Name Length Valued Role Role_id ID Role Smallint(6) Role_name Nama Role Varchar(30) Upload_flag Tanda Upload Char(1) Read_flag Tanda Read Char(1) Edit_flag Tanda Edit Char(1) Delete_flag Tanda Delete Char(1) Add_user_flag Tanda Add User Char(1) Box_flag Tanda Box Char(1) Created_by Pembuat Varchar(20) Created_date Tanggal dibuat Timestamp Tabel 4.5 Identifikasi Entitas Branch Entity Attribute Description Date type & Null Multi Name Length Valued Branch Branch_id ID Cabang Smallint(6) Branch_name Nama Cabang Varchar(30) Branch_code Kode Cabang Char(5) Branch_ Nama singkat Char(3) Nickname Cabang

8 83 Tabel 4.6 Identifikasi Entitas Box Entity Attribute Description Date type & Null Multi Name Length Valued Box Box_id ID Box Char(11) Box_code Kode Box Varchar(15) Box_status Status Box Tinyint(4) Branch_id Kode cabang Smallint(6) Created_by Pembuat Varchar(20) Created_date Tanggal dibuat Timestamp Last_updated_by Pengubah Varchar(20) Yes terakhir Last_updated_date Tanggal Timestamp Yes diubah terakhir Tabel 4.7 Identifikasi Entitas Document_Type Entity Attribute Description Date type & Null Multi Name Length Valued Document Doc_type_id ID Document_ Char(3) _type type Doc_type_name Nama Varchar(30) Document_type Created_by Pembuat Varchar(20) Created_date Tanggal dibuat Timestamp

9 84 Last_updated_by Pengubah Varchar(20) Yes terakhir Last_update_date Tanggal diubah Timestamp Yes terakhir Tabel 4.8 Identifikasi Entitas Document_Field Entity Attribute Description Date type & Null Multi Name Length Valued Document Detail_id ID Document_ Smallint(6) _Field field Doc_type_id ID Document_ Char(3) type Field_name Nama Field Varchar(30) Nullable Nullable Char(1) Yes Mandatory Mandatory Char(1) Yes Tabel 4.9 Identifikasi Entitas Document Entity Attribute Description Date type & Null Multi Name Length Valued Document Doc_id ID Dokumen Char(15) Doc_type_id ID Document_ Char(3) type Box_id ID Box Char(11)

10 85 Doc_path Dokumen Path Varchar(255) Description Deskripsi Varchar(255) Yes Detail_id ID Document_ Smallint(6) field Value Isi dari field Varchar(255) Created_by Pembuat Varchar(20) Created_Date Tanggal dibuat Timestamp Last_updated_by Pengubah Varchar(20) Yes terakhir Last_updated_date Tanggal diubah Timestamp Yes terakhir Tabel 4.10 Identifikasi Entitas Sequence Entity Attribute Description Date type & Null Multi Name Length Valued Sequence Sequence_code Kode Sequence Varchar(5) Branch_id Id Cabang Smallint(6) Sequence_no mor urut Smallint(6) Date_cycle Tahun dibuat Smallint(6) Created_date Tanggal dibuat Timestamp Created_by Pembuat Varchar(20) Last_updated_date Tanggal diubah Timestamp Yes terakhir

11 86 Last_updated_by Pengubah terakhir Varchar(20) Yes Identifikasi Domain Attribute Langkah ini bertujuan untuk menentukan domain attribute pada model data konseptual. Berikut ini ialah domain attribute dari masing-masing attribute yang telah diidentifikasi sebelumnya. Tabel 4.11 Identifikasi Domain Attribute Entity Name Attribute Domain User User_id Username Password Name Branch_id Role_id Created_by Bilangan bulat panjang maksimal 6 digit String dengan panjang maksimal 20 karakter String dengan panjang maksimal 32 karakter String dengan panjang maksimal 100 karakter Bilangan bulat panjang maksimal 6 digit Bilangan bulat panjang maksimal 6 digit String dengan panjang maksimal 20 karakter

12 87 Role Branch Created_date Role_id Role_name Upload_flag Read_flag Edit_flag Delete_flag Add_user_flag Box_flag Created_by Created_date Branch_id Branch_name Timestamp Bilangan bulat panjang maksimal 6 digit String dengan panjang maksimal 30 karakter String dengan panjang maksimal 1 karakter berupa huruf N atau Y String dengan panjang maksimal 1 karakter berupa huruf N atau Y String dengan panjang maksimal 1 karakter berupa huruf N atau Y String dengan panjang maksimal 1 karakter berupa huruf N atau Y String dengan panjang maksimal 1 karakter berupa huruf N atau Y String dengan panjang maksimal 1 karakter berupa huruf N atau Y String dengan panjang maksimal 20 karakter Timestamp Bilangan bulat panjang maksimal 6 digit String dengan panjang maksimal

13 88 30 karakter Branch_code String dengan panjang maksimal 5 karakter berupa digit 0-9 Branch_nickname String dengan panjang maksimal Box Box_id Box_code Box_status Branch_id Created_by Created_date Last_updated_by Last_updated_date 3 karakter String dengan panjang maksimal 11 karakter, berupa karakter pertama adalah B dan sisanya antara digit 0-9 String dengan panjang maksimal 15 karakter Bilangan bulat panjang maksimal 4 digit Bilangan bulat panjang maksimal 6 digit String dengan panjang maksimal 20 karakter Timestamp String dengan panjang maksimal 20 karakter Timestamp Document_type Doc_type_id String dengan panjang maksimal 3 karakter, berupa karakter

14 89 pertama adalah T dan sisanya adalah digit 0-9 Doc_type_name String dengan panjang maksimal 30 karakter Created_by String dengan panjang maksimal 20 karakter Created_date Last_updated_by Timestamp String dengan panjang maksimal 20 karakter Document_Field Last_updated_date Detail_id Doc_type_id Field_name Nullable Mandatory Timestamp Bilangan bulat panjang maksimal 6 digit String dengan panjang maksimal 3 karakter, berupa karakter pertama adalah T dan sisanya adalah digit 0-9 String dengan panjang maksimal 30 karakter String dengan panjang maksimal 1 karakter berupa huruf N atau Y String dengan panjang maksimal 1 karakter berupa huruf N atau Y Document Doc_id String dengan panjang maksimal

15 90 15 karakter, berupa karakter pertama adalah D, karakter ke-13 adalah T, dan sisanya adalah digit 0-9 Doc_type_id String dengan panjang maksimal 3 karakter, berupa karakter pertama adalah T dan sisanya adalah digit 0-9 Box_id String dengan panjang maksimal 11 karakter, berupa karakter pertama adalah B dan sisanya antara digit 0-9 Doc_path String dengan panjang maksimal 255 karakter Detail_id Bilangan bulat panjang maksimal 6 digit Value String dengan panjang maksimal 255 karakter Description String dengan panjang maksimal 255 karakter Created_by String dengan panjang maksimal 20 karakter Created_Date Timestamp

16 91 Last_updated_by String dengan panjang maksimal 20 karakter Sequence Last_updated_date Sequence_code Branch_id Sequence_no Date_cycle Created_date Created_by Last_updated_date Last_updated_by Timestamp String dengan panjang maksimal 5 karakter Bilangan bulat panjang maksimal 6 digit Bilangan bulat panjang maksimal 6 digit Bilangan bulat panjang maksimal 6 digit Timestamp String dengan panjang maksimal 20 karakter Timestamp String dengan panjang maksimal 20 karakter Identifikasi Candidate Key, Primary Key, dan Alternate Key Attributes Langkah ini bertujuan untuk mengidentifikasikan candidate key, primary key, dan alternate key dari setiap entitas. Jika ada lebih dari satu candidate key, maka satu dari candidate key tersebut harus dipilih menjadi primary key dan atribut selain primary key akan menjadi alternate key.

17 92 Tabel 4.12 Identifikasi Candidate Key, Primary Key, dan Alternate Key Entity Name Candidate Keys Primary Keys Alternate Keys User User_id User_id Username Username Password Password Name Name Branch_id Branch_id Role_id Role_id Created_by Created_by Created_date Created_date Role Role_id Role_id Role_name Role_name Upload_Flag Upload_Flag Read_flag Read_flag Edit_flag Edit_flag Delete_flag Delete_flag Add_user_flag Add_user_flag Box_flag Box_flag Created_by Created_by Created_date Created_date Branch Branch_id Branch_id Branch_name Branch_name Branch_code Branch_code Branch_nickname

18 93 Branch_nickname Box Box_id Box_code Box_status Branch_id Created_by Created_date Last_updated_by Last_updated_date Box_id Box_code Box_status Branch_id Created_by Created_date Last_updated_by Last_updated_date Document_ Type Doc_type_id Doc_type_name Created_by Created_date Last_updated_by Last_updated_date Doc_type_id Doc_type_name Created_by Created_date Last_updated_by Last_updated_date Document_ Field Detail_id Doc_type_id Field_name Nullable Mandatory Detail_id Doc_type_id Field_name Nullable Mandatory Document Doc_id Doc_type_id Box_id Doc_id Detail_id Doc_type_id Box_id Doc_path

19 94 Doc_path Description Detail_id Value Created_by Created_date Description Value Created_by Created_date Last_updated_by Last_updated_date Last_updated_by Last_updated_date Sequence Sequence_code Sequence_ Sequence_no Branch_id code Date_cycle Sequence_no Branch_id Created_by Date_cycle Created_date Created_by Last_updated_date Created_date Last_updated_by Last_updated_date Last_updated_by

20 95 Gambar 4.2 Entity Relationship Diagram Konseptual dengan Primary Key Mempertimbangkan Penggunaan Enhanced Modelling Concept Langkah ini bertujuan untuk mempertimbangkan penggunaan Enhanced Modeling Concepts seperti generalisasi, spesialisasi, agregasi, dan komposisi. Namun, perancangan basis data untuk aplikasi Document Imaging tidak menggunakan Enhanced Modeling Concepts karena entitasentitas di atas memiliki karakteristik yang berbeda-beda, sehingga tidak ada entitas yang perlu digeneralisasikan Memeriksa Redundansi pada Model Tujuan dari langkah ini adalah untuk memeriksa adanya entitas atau relationship yang redundan dalam model konseptual, dan menghapusnya bila ada. Ada tiga hal yang harus dilakukan dalam tahap ini, yaitu:

21 96 1. Memeriksa Kembali One-to-One (1:1) Relationship Pada perancangan basis data untuk aplikasi Document Imaging, tidak ada One-to-One (1:1) Relationship antara entitas-entitas yang ada. 2. Menghilangkan Redundant Relationship Tahap ini dilakukan untuk menghasilkan model data yang lebih efisien dengan cara menghilangkan relasi redundan yang tidak diperlukan. Sebuah relasi dikatakan redundan apabila informasi yang sama dapat diperoleh melalui relasi lain. Dalam ERD Konseptual awal yang telah dibuat terdapat relasi yang redundan. a. Redundant Relationship antara Document dan Document_Type Gambar 4.3 Sebelum menghilangkan hubungan Document dan Document_Type

22 97 Gambar 4.4 Sesudah menghilangkan hubungan Document dan Document_Type Sequence Branch User 0..* * 1..1 PK,FK1 Branch_id Memiliki PK Branch_id PK User_id PK Sequence_code Memiliki Melibatkan * FK2 Branch_id FK1 Role_id * Memiliki Role PK Role_id Box PK Box_id FK2 Branch_id FK1 Detail_id Memiliki * Document PK Doc_id PK,FK3 Detail_id FK1 Box_id Document_Type PK Doc_type_id 0..* Memiliki 1..* Document_Field Melibatkan PK Detail_id FK1 Doc_type_id Gambar 4.5 ERD Konseptual Setelah Menghilangkan Hubungan yang Redundan

23 Validasi Model Data Konseptual dengan User Transactions Tujuan dari langkah ini ialah untuk memastikan bahwa model data konseptual telah mendukung semua transaksi yang dibutuhkan oleh user. Transaksi-transaksi yang diperlukan dalam aplikasi document imaging ini antara lain: A. Data Entry, meliputi: Memasukkan user baru Memasukkan user baru sesuai dengan cabang pembuat user Memasukkan tipe dokumen baru Memasukkan field pada tipe dokumen Memasukkan dokumen kelengkapan pada tipe dokumen Memasukkan role baru Memasukkan dokumen baru Memasukkan value field pada dokumen Memasukkan dokumen kelengkapan pada dokumen Memasukkan box baru B. Data Update/Delete, meliputi: Update cabang pada user Update role pada user Update tipe dokumen Update field pada tipe dokumen Update dokumen kelengkapan pada tipe dokumen Update privileges pada role

24 99 Update status box Update kode box Update value field pada dokumen Update dokumen kelengkapan pada dokumen Delete user Delete tipe dokumen Delete role Delete box Delete dokumen C. Data Queries, meliputi: a. Menampilkan kode cabang dan nama cabang b. Menampilkan nama role c. Menampilkan username, nama user, cabang dan role d. Menampilkan nama cabang e. Menampilkan username, nama user, cabang f. Menampilkan tipe dokumen g. Menampilkan nama field, nullable dan mandatory berdasarkan tipe dokumen h. Menampilkan sub dokumen berdasarkan tipe dokumen i. Menampilkan nama role dan privilegesnya j. Menampilkan data produktivitas (cabang, total dokumen yang diupload, total dokumen yang di-upload bulan ini, total dokumen yang diupload bulan lalu dan selisihnya) per cabang

25 100 k. Menampilkan nama role kecuali admin l. Menampilkan username, nama user dan role berdasarkan cabang m. Menampilkan nama box berdasarkan cabang n. Menampilkan nama box dan total dokumen dalam box yang status box-nya di cabang atau return from vendor berdasarkan cabang o. Menampilkan nama box yang status box-nya di cabang berdasarkan cabang p. Menampilkan nama box yang status box-nya sent to vendor berdasarkan cabang q. Menampilkan nama box dan status box berdasarkan cabang r. Menampilkan data dokumen dan value field berdasarkan tipe dokumen s. Menampilkan data dokumen, value field dan sub dokumen berdasarkan tipe dokumen

26 101 a,d b,i,k Sequence PK,FK1 Branch_id PK Sequence_code 0..* 1..1 Melibatkan * Branch PK Branch_id Memiliki Memiliki * c,e User PK User_id FK2 Branch_id FK1 Role_id 0..* 1..1 Memiliki c,l Role PK Role_id f m,n,o,p,q Box PK Box_id FK2 Branch_id FK1 Detail_id Memiliki * Document PK Doc_id PK,FK3 Detail_id FK1 Box_id j Document_Type PK Doc_type_id 0..* Melibatkan r,s 1..1 Memiliki g,h,r,s 1..* Document_Field 1..1 PK Detail_id FK1 Doc_type_id Gambar 4.6 Entity Relationship Diagram Konseptual dengan Jalur-Jalur Transaksi Melakukan Review Model Data Konseptual dengan User Langkah ini bertujuan untuk memastikan model data konseptual yang telah dibuat merupakan representasi dari persyaratan data perusahaan. Setelah melakukan review dengan pihak perusahaan, khususnya dari Departemen IT, maka model data konseptual ini telah disetujui dan sudah sesuai dengan persyaratan data perusahaan Perancangan Basis Data Logikal Perancangan basis data logikal bertujuan untuk membuat suatu model data dengan menggunakan informasi yang diperoleh dari perusahaan serta berdasarkan pada model data spesifik. Perancangan ini bermaksud untuk

27 102 mengubah model data konseptual menjadi model data logikal dan melakukan validasi untuk memeriksa kebenaran struktur dan kelengkapan model untuk mendukung transaksi-transaksi yang diperlukan. Langkah-langkah yang perlu dilakukan akan diuraikan lebih lanjut di bawah ini Menghilangkan Hal yang Tidak Cocok dengan Model Data Relational Logikal Tahap ini dimaksudkan untuk menghasilkan relasi pada model data logikal untuk menampilkan entitas, relasi, dan atribut yang telah diidentifikasikan. 1. Menghilangkan tipe relasi binary many-to-many (*:*) Pada model data logikal yang telah penulis bentuk tidak terdapat adanya relasi binary many-to-many. 2. Menghilangkan atribut multivalue Pada model data logikal yang telah penulis bentuk tidak terdapat adanya atribut yang bernilai banyak atau multivalue Penurunan Relasi untuk Logical Data Model Tujuan utama dari tahap ini ialah untuk membuat semua relasi pada logical data model yang mewakili semua entitas, relationship, dan atribut yang telah diidentifikasi pada perancangan basis data konseptual. Penurunan entitas dilakukan terhadap: 1. Strong entities & Weak entities 2. One-to-many binary relationships 3. One-to-one binary relationships 4. Superclass/subclass relationships

28 Many-to-many binary relationships 6. Multivalue Attribute Strong Entities & Weak Entities Untuk setiap strong entity dan weak entity pada model data konseptual, dibuat relasi yang mencakup semua simple attribute dari entitas tersebut. Berikut ini merupakan strong entities dan weak entities yang dihasilkan. Tabel 4.13 Strong Entities User (User_id, Username, Password, Name, Branch_id, Role_id, created_by, created_date) Primary Key: User_id Role (Role_id, Role_name, upload_flag, read_flag, edit_flag, delete_flag, add_user_flag, box_flag, created_by, created_date) Primary Key: Role_id Branch (Branch_id, Branch_name, Branch_code, branch_nickname) Primary Key: Branch_id Box (Box_id, box_code, box_status, branch_id, created_by, created_date, last_updated_by, last_updated_date) Primary Key : Box_id Document_type (Doc_type_id, doc_type_name, created_by, created_date, last_updated_by, last_updated_date) Primary Key: Doc_type_id

29 104 Document_field (Detail_id, Doc_type_id, field_name, nullable, mandatory) Primary Key: Detail_id Tabel 4.14 Weak Entities Sequence (Sequence_code, Branch_id, sequence_no, date_cycle, created_by, created_date, last_updated_by, last_updated_date) Primary Key : Sequence_code, Branch_id Document (Doc_id, box_id, doc_path, description, detail_id, value, created_by, created_date, last_updated_by, last_updated_date) Primary Key: Doc_id, detail_id One-to-many (1:*) Binary Relationships Untuk setiap hubungan one to many, entitas yang berada pada sisi one (parent entity) dihubungkan dengan entitas yang berada pada sisi many (child entity) menggunakan atribut primary key dari parent entity yang kemudian disalin ke child entity sebagai foreign key. Relasi-relasi yang dihasilkan dari langkah ini antara lain:

30 Memasukkan Role_id dari entitas role ke dalam entitas User untuk hubungan : Memiliki Post Role_id ke entitas User sebagai foreign key 2. Memasukkan Branch_id dari entitas Branch ke dalam entitas User untuk hubungan : Memiliki Post Branch_id ke entitas User sebagai foreign key

31 Memasukkan Branch_id dari entitas Branch ke dalam entitas Sequence untuk hubungan : "Melibatkan" Post Branch_id ke entitas Sequence sebagai foreign key 4. Memasukkan Branch_id dari entitas Branch ke dalam entitas Box untuk hubungan : Memiliki Post Branch_id ke entitas Box sebagai foreign key

32 Memasukkan Box_id dari entitas Box ke dalam entitas Document untuk hubungan : Memiliki Post Box_id ke entitas Document sebagai foreign key 6. Memasukkan Doc_type_id dari entitas Document_type ke dalam entitas Document_field untuk hubungan : Memiliki Post Doc_type_id ke entitas Document_field sebagai foreign key

33 Memasukkan Detail_id dari entitas Document_field ke dalam entitas Document dengan hubungan : Melibatkan Post Detail_id ke entitas Document sebagai foreign key One-to-one (1:1) Binary Relationships Penentuan parent dan child entity untuk menggambarkan one-to-one relationship tidak dapat dilakukan dengan melihat cardinality dari relationship tersebut, melainkan dengan memeperhatikan participant constraint di antara kedua entitas tersebut. Ada tiga jenis participant constraint yang dapat dipertimbangkan, yaitu: 1. Mandatary Participation pada kedua entitas 1: 1 relationship 2. Mandatary Participation pada salah satu entitas 1: 1 relationship 3. Optional Participation pada kedua entitas 1: 1 relationship Pada model data konseptual tidak ditemukan one to one relationships.

34 Superclass / Subclass relationships Untuk setiap hubungan superclass/subclass pada model data konseptual, superclass entity dianggap sebagai parent entity dan subclass entity sebagai child entity. Pada model data konseptual tidak ditemukan superclass / subclass relationships Many-to-many(*:*) Binary Relationships Untuk setiap many to many relationship pada model data konseptual, dibuat relasi yang menggambarkan hubungan tersebut beserta dengan semua atribut pada relationship tersebut. Primary key dari masingmasing entitas dalam relationship tersebut, turut dimasukkan ke dalam relasi yang baru terbentuk sebagai foreign key. Foreign key tersebut juga akan berperan sebagai primay key dalam relasi yang baru. Pada model data konseptual tidak ditemukan many to many relationships Multivalue Attribute Multivalue attribute merupakan atribut yang memiliki nilai multiple / lebih dari satu. Dalam model data yang telah dibentuk, tidak ada entitas yang memiliki atribut demikian. Setiap atribut dibuat dengan hanya memiliki satu nilai. Tabel 4.15 Dokumentasi Relasi Model Data Logikal Relations 1 User (User_id, Username, Password, Name, Branch_id, Role_id, created_by, created_date)

35 110 Primary Key: User_id Foreign Key: Role_id references Role Foreign Key: Branch_id references Branch 2 Role (Role_id, Role_name, upload_flag, read_flag, edit_flag, delete_flag, add_user_flag, box_flag, created_by, created_date) Primary Key: Role_id 3 Branch (Branch_id, Branch_name, Branch_code, branch_nickname) Primary Key: Branch_id 4 Box (Box_id, box_code, box_status, branch_id, created_by, created_date, last_updated_by, last_updated_date) Primary Key : Box_id Foreign Key: Branch_id references Branch 5 Document_type (Doc_type_id, doc_type_name, created_by, created_date, last_updated_by, last_updated_date) Primary Key: Doc_type_id 6 Document_field (Detail_id, doc_type_id, field_name, nullable, mandatory) Primary Key : Detail_id Foreign Key: Doc_type_id references Document_type 7 Document (Doc_id, box_id, doc_path, description, detail_id, value, created_by, created_date, last_updated_by, last_updated_date) Primary Key: Doc_id, Detail_id Foreign Key: Box_id references Box

36 111 Foreign Key: Detail_id references Document_field 8 Sequence (Sequence_code, Branch_id, sequence_no, date_cycle, created_by, created_date, last_updated_by, last_updated_date) Primary Key: Sequence_code, Branch_id Foreign Key: Branch_id references Branch Gambar 4.7 Entity Relationship Diagram Logikal Awal Validasi Relasi Menggunakan rmalisasi Tujuan dari langkah ini ialah untuk melakukan validasi relasirelasi pada data model logikal yang telah terbentuk dengan menggunakan normalisasi. Meskipun mayoritas relasi-relasi yang terbentuk telah

37 112 memenuhi kriteria normalisasi sampai tahap 3NF, masih ada beberapa relasi yang perlu dinormalisasi. Document Type UNF Document Type (Doc_type_id, Doc_type_name, {Detail_id, Field_Name, Nullable, Mandatory}) 1NF Document_Type Doc_type_name) Field_Name, Nullable, Mandatory) 2NF Document_Type Doc_type_name, Created_by, Created_date, Last_updated_by, Last_updated_date) Field_Name) Field_detail Nullable, Mandatory) 3NF Document_Type Doc_type_name, Created_by, Created_date, Last_updated_by, Last_updated_date) Field_Name) Field_detail Nullable, Mandatory)

38 113 Document UNF Document (Doc_id, Doc_path, Description, Box_code, {Detail_id, Doc_type_name, Field_Name, Value}) 1NF Document Doc_path, Description, Box_code) Doc_type_name, Field_Name, Value) 2NF Document Doc_path, Description, Box_code, Created_by, Created_date, Last_updated_by, Last_updated_date) Value) Document_Field Doc_type_name, Field_name) 3NF Document Doc_path, Description, Box_id, Created_by, Created_date, Last_updated_by, Last_updated_date) Box Box_code, Box_status, Branch_id, Created_by, Created_date, Last_updated_by, Last_updated_date) Value) Document_Field Doc_type_id, Field_name)

39 114 Document_Type Doc_type_name, Created_by, Created_date, Last_updated_by, Last_updated_date) Tabel 4.16 Dokumentasi Relasi Model Data Logikal Setelah Dilakukan rmalisasi Relations 1 User (User_id, Username, Password, Name, Branch_id, Role_id, created_by, created_date) Primary Key: User_id Foreign Key: Role_id references Role Foreign Key: Branch_id references Branch 2 Role (Role_id, Role_name, upload_flag, read_flag, edit_flag, delete_flag, add_user_flag, box_flag, created_by, created_date) Primary Key: Role_id 3 Branch (Branch_id, Branch_name, Branch_code, branch_nickname) Primary Key: Branch_id 4 Box (Box_id, box_code, box_status, branch_id, created_by, created_date, last_updated_by, last_updated_date) Primary Key : Box_id Foreign Key: Branch_id references Branch 5 Document_type (Doc_type_id, doc_type_name, created_by, created_date, last_updated_by, last_updated_date) Primary Key: Doc_type_id 6 Document_field (Detail_id, doc_type_id, field_name)

40 115 Primary Key : Detail_id Foreign Key: Doc_type_id references Document_type 7 Field_detail (Detail_id, nullable, mandatory) Primary Key: Detail_id Foreign Key: Detail_id references Document_field 8 Document (Doc_id, box_id, doc_path, description, created_by, created_date, last_updated_by, last_updated_date) Primary Key: Doc_id Foreign Key: Box_id references Box 9 Document_value (Doc_id, Detail_id, Value) Primary Key: Doc_id, Detail_id Foreign Key: Doc_id references Document Foreign Key: Detail_id references Document_field 10 Sequence (Sequence_code, Branch_id, sequence_no, date_cycle, created_by, created_date, last_updated_by, last_updated_date) Primary Key: Sequence_code, Branch_id Foreign Key: Branch_id references Branch

41 116 Berikut ini merupakan ERD Relasional Logikal setelah dilakukan normalisasi: Sequence PK,FK1 Branch_id PK Sequence_Code 0..* 1..1 Melibatkan Branch PK Branch_id Memiliki * User PK User_Id FK2 Branch_id FK1 Role_id 0..* 1..1 Memiliki Role PK Role_id * Memiliki Box PK Box_Id FK2 Branch_id Memiliki * Document PK Doc_Id FK1 Box_Id 1..1 Melibatkan 1..* Document_Value PK,FK2 Detail_id PK,FK1 Doc_Id 0..* Melibatkan 1..1 Document_Type PK Doc_type_id 1..1 Memiliki 1..* Document_Field PK Detail_id FK1 Doc_type_id 1..1 Melibatkan 0..1 Field_Detail PK,FK1 Detail_id Gambar 4.8 Entity Relationship Diagram Logikal Setelah rmalisasi

42 Validasi Relasi Terhadap User Transactions Semua user transactions seperti yang telah didefinisikan pada tahap di model data konseptual diperiksa kembali untuk memastikan relasi sudah benar dan dapat memenuhi semua transaksi yang dibutuhkan user. A. Data Entry, meliputi: Memasukkan user baru Memasukkan user baru sesuai dengan cabang pembuat user Memasukkan tipe dokumen baru Memasukkan field pada tipe dokumen Memasukkan dokumen kelengkapan pada tipe dokumen Memasukkan role baru Memasukkan dokumen baru Memasukkan value field pada dokumen Memasukkan dokumen kelengkapan pada dokumen Memasukkan box baru B. Data Update/Delete, meliputi: Update cabang pada user Update role pada user Update tipe dokumen Update field pada tipe dokumen Update dokumen kelengkapan pada tipe dokumen Update privileges pada role Update status box

43 118 Update kode box Update value field pada dokumen Update dokumen kelengkapan pada dokumen Delete user Delete tipe dokumen Delete role Delete box Delete dokumen C. Data Queries, meliputi: a. Menampilkan kode cabang dan nama cabang b. Menampilkan nama role c. Menampilkan username, nama user, cabang dan role d. Menampilkan nama cabang e. Menampilkan username, nama user, cabang f. Menampilkan tipe dokumen g. Menampilkan nama field, nullable dan mandatory berdasarkan tipe dokumen h. Menampilkan sub dokumen berdasarkan tipe dokumen i. Menampilkan nama role dan privileges-nya j. Menampilkan data produktivitas (cabang, total dokumen yang diupload, total dokumen yang di-upload bulan ini, total dokumen yang di-upload bulan lalu dan selisihnya) per cabang k. Menampilkan nama role kecuali admin

44 119 l. Menampilkan username, nama user dan role berdasarkan cabang m. Menampilkan nama box berdasarkan cabang n. Menampilkan nama box dan total dokumen dalam box yang status box-nya di cabang atau return from vendor berdasarkan cabang o. Menampilkan nama box yang status box-nya di cabang berdasarkan cabang p. Menampilkan nama box yang status box-nya sent to vendor berdasarkan cabang q. Menampilkan nama box dan status box berdasarkan cabang r. Menampilkan data dokumen dan value field berdasarkan tipe dokumen s. Menampilkan data dokumen, value field dan sub dokumen berdasarkan tipe dokumen

45 120 Gambar 4.9 Entity Relationship Diagram Logical dengan Jalur-Jalur Transaksi Memeriksa Integrity Constraints Tujuan dari langkah ini ialah untuk menentukan integrity constraints yang ada sehingga dapat melindungi database dari keadaan yang tidak konsisten. Ada 5 macam integrity constraints yaitu : 1. Required Data: memastikan beberapa atribut yang harus memiliki nilai valid (not null). Constraints ini telah diidentifikasi pada langkah dalam perancangan basis data konseptual, yaitu tahap identifikasi dan asosiasi atribut dengan entitas atau relationship tertentu.

46 121 Tabel 4.17 Penambahan Kamus Atribut Document_value pada Tahap Pengecekan Integrity Constraint Attribute Description Date type & Length Null Multi Valued Doc_id ID Dokumen Char(15) Detail_id ID Document_ Smallint(6) field Value Isi dari field Varchar(255) Tabel 4.18 Penambahan Kamus Atribut Field_detail pada Tahap Pengecekan Integrity Constraint Attribute Description Date type & Length Null Multi Valued Detail_id ID Document_ Smallint(6) field Nullable Nullable Char(1) Mandatory Mandatory Char(1) 2. Attribute Domain Constraints: menentukan domain atau nilai yang diperbolehkan untuk tiap atribut. Constraints ini telah dipenuhi pada langkah , yaitu pada tahap menentukan domain atribut.

47 122 Tabel 4.19 Penambahan Kamus Domain Document_value pada Tahap Pengecekan Integrity Constraint Attribute Domain Doc_id String dengan panjang maksimal 15 karakter, berupa karakter pertama adalah D, karakter ke-13 adalah T, dan sisanya adalah digit 0-9 Detail_id Bilangan bulat panjang maksimal 6 digit Value String dengan panjang maksimal 255 karakter Tabel 4.20 Penambahan Kamus Domain Field_detail pada Tahap Pengecekan Integrity Constraint Attribute Domain Detail_id Bilangan bulat panjang maksimal 6 digit Nullable String dengan panjang maksimal 1 karakter berupa huruf N atau Y Mandatory String dengan panjang maksimal 1 karakter berupa huruf N atau Y

48 Multiplicity: menentukan batasan jumlah yang ditempatkan pada hubungan antar data dalam basisdata. Constraints ini telah dipenuhi pada langkah , yaitu pada tahap identifikasi tipe relationship. 4. Entity Integrity: memastikan primary key suatu entitas tidak bernilai null. Constraints ini telah dipenuhi pada langkah , yaitu pada tahap menentukan Candidate Key, Primary Key, dan Alternate Key Attributes 5. Referential Integrity: jika sebuah foreign key memiliki sebuah nilai, maka nilai tersebut harus merujuk pada tuple yang ada pada relasi parent. Pertama, perlu diperhatikan apakah nilai null diijinkan dalam sebuah foreign key. Kemudian, tentukan cara menjamin adanya referential integrity dengan menentukan kondisi suatu foreign key dimasukkan (on insert), diubah (on update), atau dihapus (on delete). Tabel 4.21 Referential Integriy Relations 1 User (User_id, Username, Password, Name, Branch_id, Role_id, created_by, created_date) Primary Key: User_id Foreign Key: Role_id references Role (Role_id) ON UPDATE CASCADE ON DELETE RESTRICT

49 124 Foreign Key: Branch_id references Branch (Branch_id) ON UPDATE CASCADE ON DELETE RESTRICT 2 Role (Role_id, Role_name, upload_flag, read_flag, edit_flag, delete_flag, add_user_flag, box_flag, created_by, created_date) Primary Key: Role_id 3 Branch (Branch_id, Branch_name, Branch_code, branch_nickname) Primary Key: Branch_id 4 Box (Box_id, box_code, box_status, branch_id, created_by, created_date, last_updated_by, last_updated_date) Primary Key : Box_id Foreign Key: Branch_id references Branch (Branch_id) ON UPDATE CASCADE ON DELETE RESTRICT 5 Document_type (Doc_type_id, doc_type_name, created_by, created_date, last_updated_by, last_updated_date) Primary Key: Doc_type_id 6 Document_field (Detail_id, doc_type_id, field_name) Primary Key : Detail_id Foreign Key: Doc_type_id references Document_type_header (Doc_type_id) ON UPDATE CASCADE ON DELETE CASCADE 7 Field_detail (Detail_id, nullable, mandatory) Primary Key: Detail_id Foreign Key: Detail_id references Document_field (Detail_id) ON UPDATE CASCADE ON DELETE CASCADE

50 125 8 Document (Doc_id, box_id, doc_path, description, created_by, created_date, last_updated_by, last_updated_date) Primary Key: Doc_id Foreign Key: Box_id references Box (Box_id) ON UPDATE CASCADE ON DELETE RESTRICT 9 Document_value (Doc_id, Detail_id, Value) Primary Key: Doc_id, Detail_id Foreign Key: Doc_id references Document (Doc_id) ON UPDATE CASCADE ON DELETE CASCADE Foreign Key: Detail_id references Document_field (Detail_id) ON UPDATE CASCADE ON DELETE RESTRICT 10 Sequence (Sequence_code, Branch_id, sequence_no, date_cycle, created_by, created_date, last_updated_by, last_updated_date) Primary Key: Sequence_code, Branch_id Foreign Key: Branch_id references Branch (Branch_id) ON UPDATE CASCADE ON DELETE RESTRICT 6. General Constraints: constraint yang berasal dari persyaratan bisnis perusahaan. Hal ini akan lebih lanjut dibahas pada perancangan basis data fisikal.

51 Melakukan Pemeriksaan Kembali Logical Data Model dengan User Setelah dilakukan pemeriksaan kembali bersama user dari pihak PT. XYZ, rancangan basisdata logikal sampai tahap ini dianggap mampu mewakili kebutuhan user dalam penerapan aplikasi document imaging ini Gabungkan beberapa logical data model ke dalam global model (optional) Tahap ini hanya diperlukan untuk perancangan database dengan beberapa user views, dimana satu atau lebih user view digabungkan kedalam satu global logical data model yang mewakili semua user view pada database Mempertimbangkan Perkembangan di Masa Depan Tahap ini menentukan apakah ada perubahan signifikan yang mungkin terjadi di masa depan dan menganalisis apakah logical data model yang telah terbentuk mampu mengakomodasi perubahan tersebut. Setelah berdiskusi dengan pihak PT. XYZ, khususnya dengan departemen IT, tidak ada perubahan struktur database yang signifikan hingga 5 tahun mendatang. Perancangan logikal yang dirancang sekarang telah memenuhi segala kebutuhan sistem document imaging di PT. XYZ Pemilihan Database Management System (DBMS) Sebelum memilih DBMS, terlebih dahulu akan dijelaskan mengenai perbandingan tiga DBMS yang akan menjadi pilihan, yaitu Microsoft SQL Server 2000, Oracle 9i dan MySQL 5. Berikut ini merupakan table yang menunjukkan perbandingan ketiga DBMS tersebut :

52 127 Oracle 9i Tabel 4.22 Perbandingan DBMS Microsoft SQL Server 2000 MySQL 5 Dapat beroperasi pada hamper semua platform yang ada Kebutuhan hardware minimum Intel Pentium 166 Mhz atau AMD k6-ii 128 MB RAM (diutamakan 256 MB) Harddisk space: Typical installation : Minimal 450 s/d 550 MB Compact installation : Minimal 350 s/d 400 MB Custom installation : Minimal 350 s/d 700 MB Hanya dapat beroperasi pada platform berbasis windows Kebutuhan hardware minimum Intel Pentium 166 Mhz atau AMD k6- II 64 MB RAM (diutamakan 128 MB ataulebih) Harddisk space : 95 MB (Minimum) 270 MB (full installation) 250 MB (typical) Dapat beroperasi pada berbagai platform Kebutuhan hardware minimum processor Intel Pentium 166 Mhz 64 MB RAM (diutamakan 128 MB atau lebih) Harddisk space : 40 MB (Minimum) 100 MB (typical) Atas pertimbangan-pertimbangan yang ada untuk pemilihan DBMS dari sisi platform, keuntungan, hardware dan terutama harga, maka user (PT.

53 128 XYZ Finance) memutuskan untuk memilih MySQL sebagai DMBS yang akan digunakan karena MySQL mendukung platform lain tidak hanya windows, spesifikasi hardware yang dibutuhkan lebih sedikit dan dapat diperoleh tanpa perlu membeli karena MySQL merupakan software open source atau free software (selama tidak dikomersilkan) sehingga sangat cocok dengan aplikasi yang akan dibuat. Gambar 4.10 Entity Relationship Diagram Logikal dengan Atribut Lengkap

54 Perancangan Basis Data Fisikal Perancangan basis data fisikal merupakan proses pembuatan deskripsi implementasi basis data pada secondary storage yang mencakup relasi-relasi dasar, organisasi file, dan index yang digunakan untuk memperoleh akses data yang efisien terhadap data dan integrity constraints yang berhubungan serta ukuran keamanan lainnya. Tahap ini mengijinkan perancang untuk memutuskan bagaimana database akan diimplementasikan. Oleh karena itu, desain fisikal dihubungkan pada DBMS yang spesifik. Langkah-langkah yang dibutuhkan dalam merancang basis data fisikal ialah sebagai berikut: Menerjemahkan logical data model untuk DBMS yang digunakan Tujuan langkah ini ialah untuk membuat suatu skema relasional dari global logical data model yang dapat diimplementasikan ke DBMS yang digunakan. Ada 3 tugas pada langkah ini, yaitu: 1. Merancang relasi dasar Tugas ini bertujuan untuk menentukan bagaimana merepresentasikan relasi dasar yang diidentifikasi pada model data logikal global dalam DBMS yang digunakan. Oleh karena itu, digunakan bentuk perluasan dari Database Definition Language (DBDL) untuk menentukan domain, default value, dan indikator null.

55 130 Tabel 4.23 DBDL untuk User Domain User_id Domain Username Bilangan bulat panjang maksimal 6 digit String dengan panjang maksimal 20 karakter Domain Password String dengan panjang maksimal 32 karakter, berupa digit 0-9 dan huruf a-z (fixed) Domain Name String dengan panjang maksimal 100 karakter Domain Branch_id Domain Role_id Domain Created_by Domain Created_date Bilangan bulat panjang maksimal 6 digit Bilangan bulat panjang maksimal 6 digit String dengan panjang maksimal 20 karakter Timestamp User ( User_id User_id NOT NULL, Username Username NOT NULL, Password Password NOT NULL, Name Name NOT NULL, Branch_id Branch_id NOT NULL, Role_id Role_id NOT NULL, created_by created_by NOT NULL, created_date created_date NOT NULL Primary Key (User_id)

56 131 Foreign Key Role_id references Role (Role_id) Foreign Key Branch_id references Branch (Branch_id) ); Tabel 4.24 DBDL untuk Role Domain Role_id Domain Role_name Domain Upload_flag Bilangan bulat panjang maksimal 6 digit String dengan panjang maksimal 30 karakter String dengan panjang maksimal 1 karakter berupa huruf N atau Y (fixed) Domain Read_flag String dengan panjang maksimal 1 karakter berupa huruf N atau Y (fixed) Domain Edit_flag String dengan panjang maksimal 1 karakter berupa huruf N atau Y (fixed) Domain Delete_flag String dengan panjang maksimal 1 karakter berupa huruf N atau Y (fixed) Domain Add_user_flag String dengan panjang maksimal 1 karakter berupa huruf N atau Y (fixed) Domain Box_flag String dengan panjang maksimal 1 karakter berupa huruf N atau Y (fixed) Domain Created_by Domain Created_date String dengan panjang maksimal 20 karakter Timestamp

57 132 Role ( Role_id Role_id NOT NULL, Role_name Role_name NOT NULL, upload_flag upload_flag NOT NULL, read_flag read_flag NOT NULL, edit_flag edit_flag NOT NULL, delete_flag delete_flag NOT NULL, add_user_flag add_user_flag NOT NULL, box_flag box_flag NOT NULL, created_by created_by NOT NULL, created_date created_date NOT NULL Primary Key (Role_id) ) Tabel 4.25 DBDL untuk Branch Domain Branch_id Bilangan bulat panjang maksimal 6 digit Domain Branch_name String dengan panjang maksimal 30 karakter Domain Branch_code String dengan panjang maksimal 5 karakter berupa digit 0-9 (fixed) Domain Branch_nickname String dengan panjang maksimal 3 karakter (fixed)

58 133 Branch ( Branch_id Branch_id NOT NULL, Branch_name Branch_name NOT NULL, Branch_code Branch_code NOT NULL, branch_nickname branch_nickname NOT NULL Primary Key (Branch_id) ) Tabel 4.26 DBDL untuk Box Domain Box_id String dengan panjang maksimal 11 karakter, berupa karakter pertama adalah B dan sisanya antara digit 0-9 (fixed) Domain Box_code String dengan panjang maksimal 15 karakter Domain Box_status Domain Branch_id Bilangan bulat panjang maksimal 4 digit Bilangan bulat panjang maksimal 6 digit Domain Created_by String dengan panjang maksimal 20 karakter Domain Created_date Timestamp Domain Last_updated_by String dengan panjang maksimal 20 karakter

59 134 Domain Last_updated_date Timestamp Box ( Box_id Box_id NOT NULL, box_code box_code NOT NULL, box_status box_status NOT NULL, branch_id branch_id NOT NULL, created_by created_by NOT NULL, created_date created_date NOT NULL, last_updated_by last_updated_by NULL, last_updated_date last_updated_date NULL Primary Key (Box_id) Foreign Key Branch_id references Branch (Branch_id) ) Tabel 4.27 DBDL untuk Document_type Domain Doc_type_id String dengan panjang maksimal 3 karakter, berupa karakter pertama adalah T dan sisanya adalah digit 0-9 (fixed) Domain Doc_type_name String dengan panjang maksimal 30 karakter Domain Created_by String dengan panjang maksimal 20

60 135 karakter Domain Created_date Timestamp Domain Last_updated_by String dengan panjang maksimal 20 karakter Domain Last_updated_date Timestamp Document_type ( Doc_type_id Doc_type_id NOT NULL, doc_type_name doc_type_name NOT NULL, created_by created_by NOT NULL, created_date created_date NOT NULL, last_updated_by last_updated_by NULL, last_updated_date last_updated_date NULL Primary Key (Doc_type_id) ) Tabel 4.28 DBDL untuk Document_field Domain Detail_id Domain Doc_type_id Bilangan bulat panjang maksimal 6 digit String dengan panjang maksimal 3 karakter, berupa karakter pertama adalah T dan sisanya adalah digit 0-9 (fixed) Domain Field_name String dengan panjang maksimal 30 karakter

61 136 Document_field ( Detail_id detail_id NOT NULL, Doc_type_id doc_type_id NOT NULL, Field_name field_name NOT NULL, Primary Key (Detail_id) Foreign Key Doc_type_id references Document_type (Doc_type_id) ) Tabel 4.29 DBDL untuk Field_detail Domain Detail_id Domain Nullable Bilangan bulat panjang maksimal 6 digit String dengan panjang maksimal 1 karakter berupa huruf N atau Y (fixed) Domain Mandatory String dengan panjang maksimal 1 karakter berupa huruf N atau Y (fixed) Field_detail ( Detail_id Detail_id NOT NULL, nullable nullable NOT NULL, mandatory mandatory NOT NULL Primary Key (Detail_id) Foreign Key Detail_id references Document_field (Detail_id) )

62 137 Tabel 4.30 DBDL untuk Document Domain Doc_id String dengan panjang maksimal 15 karakter, berupa karakter pertama adalah D, karakter ke-13 adalah T, dan sisanya adalah digit 0-9 (fixed) Domain Box_id String dengan panjang maksimal 11 karakter, berupa karakter pertama adalah B dan sisanya antara digit 0-9 (fixed) Domain Doc_path String dengan panjang maksimal 255 karakter Domain Description String dengan panjang maksimal 255 karakter Domain Created_by String dengan panjang maksimal 20 karakter Domain Created_Date Timestamp Domain Last_updated_by String dengan panjang maksimal 20 karakter Domain Last_updated_date Timestamp Document ( Doc_id Doc_id NOT NULL, box_id box_id NOT NULL, doc_path doc_path NOT NULL,

63 138 description description NOT NULL, created_by created_by NOT NULL, created_date created_date NOT NULL, last_updated_by last_updated_by NULL, last_updated_date last_updated_date NULL Primary Key (Doc_id) Foreign Key Box_id references Box (Box_id) ) Tabel 4.31 DBDL untuk Document_value Domain Doc_id String dengan panjang maksimal 15 karakter, berupa karakter pertama adalah D, karakter ke-13 adalah T, dan sisanya adalah digit 0-9 (fixed) Domain Detail_id Bilangan bulat panjang maksimal 6 digit Domain Value String dengan panjang maksimal 255 karakter Document_value ( Doc_id Doc_id NOT NULL, Detail_id Detail_id NOT NULL, Value Value NOT NULL

64 139 Primary Key (Doc_id, Detail_id) Foreign Key Doc_id references Document (Doc_id) Foreign Key Detail_id references Document_field (Detail_id) ) Tabel 4.32 DBDL untuk Sequence Domain Sequence_code Domain Branch_id Domain Sequence_no Domain Date_cycle Domain Created_date Domain Created_by Domain Last_updated_date Domain Last_updated_by String dengan panjang maksimal 5 karakter Bilangan bulat panjang maksimal 6 digit Bilangan bulat panjang maksimal 6 digit Bilangan bulat panjang maksimal 6 digit Timestamp String dengan panjang maksimal 20 karakter Timestamp String dengan panjang maksimal 20 karakter Sequence ( Sequence_code Sequence_code NOT NULL, Branch_id Branch_id NOT NULL, sequence_no sequence_no NOT NULL, date_cycle date_cycle NOT NULL, created_by created_by NOT NULL, created_date created_date NOT NULL,

65 140 last_updated_by last_updated_by NULL, last_updated_date last_updated_date NULL Primary Key (Sequence_code, Branch_id) Foreign Key Branch_id references Branch (Branch_id) ) 2. Merancang representasi dari data turunan Data yang diturunkan merupakan atribut yang nilainya didapat dengan mengetahui nilai dari atribut lain. Pada kasus ini, tidak terdapat data turunan. 3. Merancang general constraints. Tujuan dari tugas ini ialah untuk merancang integrity constraints perusahaan pada DBMS yang akan digunakan. Rancangan basis data ini menggunakan beberapa integrity constraints, yaitu adalah sebagai berikut. 1. Setiap Document memiliki Doc_id dari D T00 sampai D T99 CONSTRAINT CheckDocId CHECK (Doc_id LIKE D[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9] ) 2. Setiap Box memiliki Box_id dari B sampai B CONSTRAINT CheckBoxId CHECK (Box_id LIKE B[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9] )

66 SetiapDocument_type memiliki Doc_type_id dari T00 sampai T99 CONSTRAINT CheckDocTypeId CHECK (Doc_type_id LIKE T[0-9][0-9] ) 4. Setiap Branch memiliki Branch_code dari sampai CONSTRAINT CheckBranchCode CHECK (Branch_code LIKE [0-9][0-9][0-9][0-9][0-9] ) 5. Setiap Box memiliki Box_status antara 1 sampai 4 CONSTRAINT CheckBoxStatus CHECK (Box_status > BETWEEN 1 AND 4) 6. Setiap Field_detail memiliki Nullable dan Mandatory bernilai Y atau N CONSTRAINT CheckNullable CHECK (Nullable = Y OR Nullable = N ) CONSTRAINT CheckMandatoryCHECK (Mandatory = Y OR Mandatory = N ) Perancangan file organizations dan indexes Tahap ini bertujuan untuk menentukan file organizations yang optimal untuk menyimpan relasi dasar dan indeks-indeks yang dibutuhkan untuk mencapai performa yang dapat diterima, dimana relasi dan tuple diletakkan pada secondary storage. Ada 4 tugas pada langkah ini, yaitu:

67 Menganalisis transaksi Langkah ini bertujuan untuk memahami fungsionalitas transaksi yang akan berjalan di dalam database dan menganalisis transaksitransaksi penting yang akan digunakan. Transaksi-transaksi yang akan berjalan dalam database antara lain: A. Memasukkan user baru B. Memasukkan user baru sesuai dengan cabang pembuat user C. Memasukkan tipe dokumen baru D. Memasukkan field pada tipe dokumen Tabel 4.33 AnalisisTransaksi Transaksi/Relasi A B C D I R U D I R U D I R U D I R U D Box Branch Document Document_field X Document_type X Document_value Field_detail X Role

68 143 Sequence User X X I = Insert, R = Read, U = Update, D = Delete E. Memasukkan dokumen kelengkapan pada tipe dokumen F. Memasukkan role baru G. Memasukkan dokumen baru H. Memasukkan value field pada dokumen Tabel 4.34 AnalisisTransaksi (lanjutan) Transaksi/Relasi E F G H I R U D I R U D I R U D I R U D Box Branch Document X Document_field X Document_type Document_value X Field_detail Role X Sequence User I = Insert, R = Read, U = Update, D = Delete

69 144 I. Memasukkan dokumen kelengkapan pada dokumen J. Memasukkan box baru Tabel 4.35 AnalisisTransaksi (lanjutan) Transaksi/Relasi I J I R U D I R U D I R U D I R U D Box X Branch Document Document_field Document_type Document_value X Field_detail Role Sequence User I = Insert, R = Read, U = Update, D = Delete K. Update cabang pada user L. Update role pada user M. Update tipe dokumen N. Update field pada tipe dokumen

70 145 Tabel 4.36 AnalisisTransaksi (lanjutan) Transaksi/Relasi K L M N I R U D I R U D I R U D I R U D Box Branch Document Document_field X Document_type X Document_value Field_detail X Role Sequence User X X I = Insert, R = Read, U = Update, D = Delete O. Update dokumen kelengkapan pada tipe dokumen P. Update privileges pada role Q. Update status box R. Update kode box Tabel 4.37 AnalisisTransaksi (lanjutan) Transaksi/Relasi O P Q R I R U D I R U D I R U D I R U D Box X X

71 146 Branch Document Document_field X Document_type Document_value Field_detail Role X Sequence User I = Insert, R = Read, U = Update, D = Delete S. Update value field pada dokumen T. Update dokumen kelengkapan pada dokumen U. Delete user V. Delete tipe dokumen Tabel 4.38 AnalisisTransaksi (lanjutan) Transaksi/Relasi S T U V I R U D I R U D I R U D I R U D Box Branch Document Document_field Document_type X

72 147 Document_value X X Field_detail Role Sequence User X I = Insert, R = Read, U = Update, D = Delete W. Delete role X. Delete box Y. Delete dokumen Tabel 4.39 AnalisisTransaksi (lanjutan) Transaksi/Relasi W X Y I R U D I R U D I R U D I R U D Box X Branch Document X Document_field Document_type Document_value

73 148 Field_detail Role X Sequence User I = Insert, R = Read, U = Update, D = Delete Z. Menampilkan kode cabang dan nama cabang AA. Menampilkan nama role BB. Menampilkan username, nama user, cabang dan role CC. Menampilkan nama cabang Tabel 4.40 AnalisisTransaksi (lanjutan) Transaksi/Relasi Z AA BB CC I R U D I R U D I R U D I R U D Box Branch X X X Document Document_field Document_type Document_value Field_detail Role X X

74 149 Sequence User X I = Insert, R = Read, U = Update, D = Delete DD. Menampilkan username, nama user, cabang EE. Menampilkan tipe dokumen FF. Menampilkan nama field, nullable dan mandatory berdasarkan tipe dokumen GG. Menampilkan dokumen kelengkapan berdasarkan tipe dokumen Tabel 4.41 AnalisisTransaksi (lanjutan) Transaksi/Relasi DD EE FF GG I R U D I R U D I R U D I R U D Box Branch X Document Document_field X X Document_type X Document_value Field_detail X Role Sequence User X I = Insert, R = Read, U = Update, D = Delete

75 150 EE. Menampilkan nama role dan privileges-nya FF. Menampilkan data produktivitas (cabang, total dokumen yang diupload, total dokumen yang diupload bulan ini, total dokumen yang diupload bulan lalu dan selisihnya) per cabang JJ. Menampilkan nama role kecuali admin KK. Menampilkan username, nama user dan role berdasarkan cabang Tabel 4.42 AnalisisTransaksi (lanjutan) Transaksi/Relasi HH II JJ KK I R U D I R U D I R U D I R U D Box Branch Document X Document_field Document_type Document_value Field_detail Role X X X Sequence User X I = Insert, R = Read, U = Update, D = Delete

76 151 LL. Menampilkan nama box berdasarkan cabang MM. Menampilkan nama box dan total dokumen dalam box yang status box-nya di cabang atau return from vendor berdasarkan cabang NN. Menampilkan nama box yang status box-nya di cabang berdasarkan cabang OO. Menampilkan nama box yang status box-nya sent to Vendor berdasarkan cabang Tabel 4.43 AnalisisTransaksi (lanjutan) Transaksi/Relasi LL MM NN OO I R U D I R U D I R U D I R U D Box X X X Branch Document X Document_field Document_type Document_value Field_detail Role Sequence User I = Insert, R = Read, U = Update, D = Delete

77 152 PP. Menampilkan nama box dan status box berdasarkan cabang QQ. Menampilkan data dokumen dan value field berdasarkan tipe dokumen RR. Menampilkan data dokumen, value field dan dokumen kelengkapan berdasarkan tipe dokumen Tabel 4.44 AnalisisTransaksi (lanjutan) Transaksi/Relasi PP QQ RR I R U D I R U D I R U D I R U D Box X Branch Document X X Document_field X X Document_type X X Document_value X X Field_detail X X Role Sequence User I = Insert, R = Read, U = Update, D = Delete

78 Memilih file organizations DBMS yang digunakan untuk mengimplementasikan database adalah MySQL. 3. Memilih indeks Tujuan melakukan penambahan indeks adalah untuk meningkatkan kinerja sistem. Tabel 4.45 Pemilihan Indeks. Nama Tabel Indeks Nama Indeks 1. User User_id PRIMARY (Primary Index) 2. Role Role_id PRIMARY (Primary Index) 3. Branch Branch_id PRIMARY (Primary Index) 4. Box Box_id PRIMARY (Primary Index) 5. Document_type Doc_type_id PRIMARY (Primary Index) 6. Document_field Detail_id PRIMARY

79 154 (Primary Index) 7 Field_detail Detail_id PRIMARY (Primary Index) 8. Document Doc_id PRIMARY (Primary Index) 9. Document_value Doc_id, Detail_id PRIMARY (Primary Index) 10. Sequence Sequence_code, PRIMARY Branch_id (Primary Index) 4. Estimasi Kebutuhan Disk Space. Tabel 4.46 Estimasi Kapasitas Tabel User Field Tipe Data Ukuran (Byte) User_id Smallint 2 Username Varchar 21 Password Char 32 Name Varchar 101 Branch_id Smallint 2

80 155 Role_id Smallint 2 Kapasitas dari tabel User adalah 160 bytes Diperkirakan dalam 1 minggu menghasilkan 1 data baru Dalam satu tahun pertumbuhan tabel User adalah 160 * 52 * 1 = 8320 bytes Dalam lima tahun pertumbuhan tabel User adalah 8320 * 5 = bytes Data awal pada tabel adalah 160 bytes Total = = bytes Tabel 4.47 Estimasi Kapasitas Tabel Role Field Tipe Data Ukuran (Byte) Role_id Smallint 2 Role_name Varchar 31 Upload_flag Char 1 Read_flag Char 1 Edit_flag Char 1 Created_by Varchar 21

81 156 Created_date Timestamp 4 Kapasitas dari tabel Role adalah 61 bytes Diperkirakan dalam 1 tahun menghasilkan 1 data baru Dalam satu tahun pertumbuhan tabel Role adalah 61 * 1 = 61 bytes Dalam lima tahun pertumbuhan tabel Role adalah 61 * 5 = 305 bytes Data awal pada tabel adalah 183 bytes Total = = 488 bytes Tabel 4.48 Estimasi Kapasitas Tabel Branch Field Tipe Data Ukuran (Byte) Branch_id Smallint 2 Branch_name Varchar 31 Branch_code Char 5 Branch_nickname Char 3 Kapasitas dari tabel Branch adalah 41 bytes Diperkirakan dalam 1 tahun menghasilkan 20 data baru Dalam satu tahun pertumbuhan tabel Branch adalah 41 * 20 = 820 bytes Dalam lima tahun pertumbuhan tabel Branch adalah 820 * 5 = 4100

82 157 bytes Data awal pada tabel adalah 2050 bytes Total = = 6150 bytes Tabel 4.49 Estimasi Kapasitas Tabel Box Field Tipe Data Ukuran (Byte) Box_id Char 11 Box_code Varchar 16 Branch_id Smallint 2 Box_status Tinyint 1 Created_by Varchar 21 Created_date Timestamp 4 Last_updated_by Varchar 21 Last_updated_date Timestamp 4 Kapasitas dari tabel Box adalah 80 bytes Diperkirakan dalam 1 minggu menghasilkan 50 data baru Dalam satu tahun pertumbuhan tabel Box adalah 80 * 52 * 50 = bytes Dalam lima tahun pertumbuhan tabel Box adalah * 5 =

83 158 bytes Data awal pada tabel adalah 0 bytes Total = = bytes Tabel 4.50 Estimasi Kapasitas Tabel Document_type Field Tipe Data Ukuran (Byte) Doc_type_id Char 3 Doc_type_name Varchar 31 Created_by Varchar 21 Created_date Timestamp 4 Last_updated_by Varchar 21 Last_updated_date Timestamp 4 Kapasitas dari tabel Document_type adalah 84 bytes Diperkirakan dalam 1 tahun menghasilkan 2 data baru Dalam satu tahun pertumbuhan tabel Document_type adalah 84 * 2 = 168 bytes Dalam lima tahun pertumbuhan tabel Document_type adalah 168 * 5 = 840 bytes Data awal pada tabel adalah 84 bytes

84 159 Total = = 924 bytes Tabel 4.51 Estimasi Kapasitas Tabel Document_field Field Tipe Data Ukuran (Byte) Detail_id Smallint 2 Doc_type_id Char 3 Field_name Varchar 31 Kapasitas dari tabel Document_field adalah 36 bytes Diperkirakan dalam 1 tahun menghasilkan 20 data baru Dalam satu tahun pertumbuhan tabel Document_field adalah 36 * 20 = 720 bytes Dalam lima tahun pertumbuhan tabel Document_field adalah 720 * 5 = 3600 bytes Data awal pada tabel adalah 360 bytes Total = = 3960 bytes Tabel 4.52 Estimasi Kapasitas Tabel Field_detail Field Tipe Data Ukuran (Byte) Detail_id Smallint 2 Nullable Char 1 Mandatory Char 1

85 160 Kapasitas dari tabel Field_detail adalah 4 bytes Diperkirakan dalam 1 tahun menghasilkan 16 data baru Dalam satu tahun pertumbuhan tabel Field_detail adalah 4 * 16 = 64 bytes Dalam lima tahun pertumbuhan tabel Field_detail adalah 64 * 5 = 320 bytes Data awal pada tabel adalah 32 bytes Total = = 352 bytes Tabel 4.53 Estimasi Kapasitas Tabel Document Field Tipe Data Ukuran (Byte) Doc_id Char 15 Box_id Char 11 Doc_path Varchar 256 Description Varchar 256 Created_by Varchar 21 Created_Date Timestamp 4 Last_updated_by Varchar 21 Last_updated_date Timestamp 4

86 161 Kapasitas dari tabel Document adalah 588 bytes Diperkirakan dalam 1 minggu menghasilkan 5000 data baru Dalam satu tahun pertumbuhan tabel Document adalah 588 * 52 * 5000 = bytes Dalam lima tahun pertumbuhan tabel Document adalah * 5 = bytes Data awal pada tabel adalah 0 bytes Total = = bytes Tabel 4.54 Estimasi Kapasitas Tabel Document_value Field Tipe Data Ukuran (Byte) Doc_id Char 15 Detail_id Smallint 2 Value Varchar 256 Kapasitas dari tabel Document_value adalah 273 bytes Diperkirakan dalam 1 minggu menghasilkan data baru Dalam satu tahun pertumbuhan tabel Document_value adalah 273 * 52 * = bytes Dalam lima tahun pertumbuhan tabel Document_value adalah

87 * 5 = bytes Data awal pada tabel adalah 0 bytes Total = = bytes Tabel 4.55 Estimasi Kapasitas Tabel Sequence Field Tipe Data Ukuran (Byte) Sequence_code Varchar 6 Branch_id Smallint 2 Sequence_no Smallint 2 Date_cycle Smallint 2 Created_by Varchar 21 Created_Date Timestamp 4 Last_updated_by Varchar 21 Last_updated_date Timestamp 4 Kapasitas dari tabel sequence adalah 62 bytes Diperkirakan dalam 1 tahun menghasilkan 100 data baru Dalam satu tahun pertumbuhan tabel sequence adalah 62 * 100 = 6200 bytes

88 163 Dalam lima tahun pertumbuhan tabel sequence adalah 6200 * 5 = bytes Data awal pada tabel adalah 0 bytes Total = = bytes Tabel 4.56 Total Keseluruhan Disk Space Total Ukuran disk space User bytes Role 488 bytes Branch 6150 bytes Box bytes Document_type 924 bytes Document_field 3960 bytes Field_detail 352 bytes Document bytes Document_value bytes Sequence bytes Total bytes atau GB

89 Perancangan user views User view merupakan sebuah table yang bertujuan untuk memudahkan user untuk melihat beberapa informasi yang ada pada berbagai entitas. Aplikasi Document Imaging ini tidak membutuhkan user view karena keamanan data pada entitas sudah dibatasi oleh privilege system pada aplikasi, yang dapat ditentukan secara langsung oleh admin, sehingga tidak lagi membutuhkan perancangan user view Perancangan security mechanisms Tujuan dari langkah ini adalah untuk merancang security mechanism pada basis data yang telah dispesifikasikan oleh admin. Security mechanisms yang dirancang adalah: 1. Telah dibuat halaman khusus yang berfungsi untuk menentukkan privileges bagi setiap user. 2. Tidak semua karyawan dapat mengakses halaman tersebut dan hanya admin saja yang dapat mengakses halaman tersebut. 3. Untuk mengakses halaman tersebut, maka admin harus melakukan login terlebih dahulu. Sistem login menggunakan username dan password.

90 165 Tabel 4.57 Security Mechanism Relasi\User Admin Super User User I R U D I R U D I R U D Box X X X X X X X Branch X X X Document X X X X X X X Document_field X X X X X X Document_type X X X X X X Document_value X X X X X X X Field_detail X X X X X X Role X X X X X X Sequence X X User X X X X X X X X X I = Insert, R = Read, U = Update, D = Delete 4.2 Perancangan Aplikasi Setelah merancang database, maka aplikasi pun perlu dirancang untuk mendukung database yang telah dirancang. Kejelasan perancangan sistem akan ditunjukkan melalui struktur menu, State Transition Diagram (STD), serta perancangan layar.

91 Class Diagram Gambar 4.11 Class Diagram

92 Usecase Diagram Usecase Manage User Add role Edit role Delete role Admin Add user Super User Edit user Delete user Gambar 4.12 Usecase Manage User

93 168 Use Case Name: Add Role Use Case ID: UC-001 Precondition: Admin telah berada di Home Page dan menekan pilihan Role di menu samping kiri Flow of Events: Basic Path 1. Use case dimulai ketika Admin telah berada di Home Page dan menekan pilihan Role di menu samping kiri. 2. Sistem menampilkan halaman Role dengan 3 menu utama yang dapat dipilih yaitu Add, Edit, dan Delete. 3. Admin memilih menu Add dan menekan tombol Next. 4. Sistem menampilkan halaman Add Role yang berisi input box nama Role baru yang ingin ditambah dan pilihan privilege dari role baru tersebut. 5. Admin mengisi nama role baru, mencentang pilihan privilege yang diinginkan untuk role tersebut. 6. Admin menekan tombol Submit. 7. Sistem menampilkan success response di halaman Role 8. Use case berakhir.. Alternative Path Alternative 1: Alternative Behavior 1. Alternatif ini dimulai setelah langkah 5 dari basic path ketika Admin telah mengisi nama role baru dan privilege yang diinginkan. 2. Admin menekan tombol Reset 3. Sistem menampilkan kembali halaman Add Role dengan input box nama role dan privilege yang kosong. 4. Basic path akan dilanjutkan kembali dari langkah 5. Alternative 2: Blank Input 1. Alternatif ini dimulai setelah langkah 4 dari basic path ketika sistem telah menampilkan halaman Add Role. 2. Admin menekan tombol Submit. 3. Sistem menampilkan warning box yang meminta user untuk mengisi nama role dan minimal 1 privilege harus diisi. 5. Basic path akan dilanjutkan kembali dari langkah 4. Postcondition: Admin berada di halaman Role dan dapat memilih menu lainnya. Use Case Name: Edit Role Use Case ID: UC-002 Precondition: Admin telah berada di Home Page dan menekan pilihan Role di menu samping kiri Flow of Events: Basic Path 1. Use case dimulai ketika Admin telah berada di Home Page dan menekan pilihan

94 169 Role di menu samping kiri. 2. Sistem menampilkan halaman Role dengan 3 menu utama yang dapat dipilih yaitu Add, Edit, dan Delete. 3. Admin memilih menu Edit dan menekan tombol Next. 4. Sistem menampilkan halaman Edit Role yang berisi daftar nama role yang telah dibuat sebelumnya beserta privilegenya. 5. Admin mengubah privilege dari role yang ada pada daftar dengan check atau uncheck 6. Admin menekan tombol Update. 7. Sistem menampilkan success response di halaman Role 8. Use case berakhir. Alternative Path Alternative 1: Alternative Behavior 1. Alternatif ini dimulai setelah langkah 5 dari basic path ketika Admin telah mengisi nama role baru dan privilege yang diinginkan. 9. Admin menekan tombol Reset 2. Sistem menampilkan kembali halaman Edit Role dengan kondisi privilege semula. 3. Basic path akan dilanjutkan kembali dari langkah 5. Postcondition: Admin berada di halaman Role dan dapat memilih menu lainnya. Use Case Name: Delete Role Use Case ID: UC-003 Precondition: Admin telah berada di Home Page dan menekan pilihan Role di menu samping kiri Flow of Events: Basic Path 1. Use case dimulai ketika Admin telah berada di Home Page dan menekan pilihan Role di menu samping kiri. 2. Sistem menampilkan halaman Role dengan 3 menu utama yang dapat dipilih yaitu Add, Edit, dan Delete. 3. Admin memilih menu Delete dan menekan tombol Next. 4. Sistem menampilkan halaman Delete Role yang berisi daftar nama role yang telah dibuat sebelumnya. 5. Admin mencentang nama role yang ingin dihapus dan menekan tombol Delete. 6. Sistem menampilkan warning box yang meminta konfirmasi Admin untuk menghapus role tersebut. 7. Admin menekan tombol OK. 8. Sistem menampilkan success response di halaman Role 9. Use case berakhir. Alternative Path Alternative 1: Alternative Behavior

95 Alternatif ini dimulai setelah langkah 6 dari basic path ketika sistem menampilkan warning box yang meminta konfirmasi Admin untuk menghapus username 2. Admin menekan tombol Cancel. 3. Sistem kembali menampilkan halaman Delete Role. Alternative Path Alternative 2: Incorrect Behavior 1. Alternatif ini dimulai setelah langkah 7 dari basic path ketika Admin mengkonfirmasi penghapusan tipe dokumen dengan menekan tombol OK 2. Sistem menampilkan error message yang menyatakan bahwa role yang dipilih masih digunakan oleh user tertentu dan tidak dapat dihapus. 3. Basic path akan dilanjutkan kembali dari langkah 1. Postcondition: Admin berada di halaman Role dan dapat memilih menu lainnya. Use Case Name: Add User Use Case ID: UC-004 Precondition: User telah berada di Home Page dan menekan pilihan User di menu samping kiri Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Home Page dan menekan pilihan User di menu samping kiri. 2. Sistem menampilkan halaman User dengan 3 menu utama yang dapat dipilih yaitu Add, Edit, dan Delete. 3. User memilih menu Add dan menekan tombol Next. 4. Sistem menampilkan halaman Add User yang berisi form register yang menampilkan input box username, password, re-password, nama, pilihan branch dan pilihan role untuk user baru tersebut. 5. User mengisi Form Register. 6. User menekan tombol Submit. 7. Sistem menampilkan success response di Home Page. 8. Use case berakhir. Alternative Path Alternative 1: Alternative Behavior 1. Alternatif ini dimulai setelah langkah 5 dari basic path ketika User telah mengisi Form Register. 2. User menekan tombol Reset 3. Sistem menampilkan kembali halaman Add User dengan form register yang kosong. 4. Basic path akan dilanjutkan kembali dari langkah 5.

96 171 Alternative 2: Blank Input 1. Alternatif ini dimulai setelah langkah 4 dari basic path ketika sistem telah menampilkan halaman Add User. 2. User menekan tombol Submit. 3. Sistem menampilkan warning box yang meminta user untuk mengisi semua field. 5. Basic path akan dilanjutkan kembali dari langkah 4. Alternative 3: Incorrect Input 1. Alternatif ini dimulai setelah langkah 5 dari basic path ketika User telah mengisi form Register. 2. User menekan tombol Submit. 3. Sistem menampilkan warning box yang menyatakan bahwa password dan repassword tidak sama. 4. Basic path akan dilanjutkan kembali dari langkah 5. Postcondition: User berada di Home Page Use Case Name: Edit User Use Case ID: UC-005 Precondition: User telah berada di Home Page dan menekan pilihan User di menu samping kiri Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Home Page dan menekan pilihan User di menu samping kiri. 2. Sistem menampilkan halaman User dengan 3 menu utama yang dapat dipilih yaitu Add, Edit, dan Delete. 3. User memilih menu Edit dan menekan tombol Next. 4. Sistem menampilkan halaman Edit User yang berisi daftar nama, username, branch dan role dari semua user. 5. User mengubah branch dan role dari user dengan memilih pilihan yang ada 6. User menekan tombol Update. 7. Sistem menampilkan success response di Home Page. 8. Use case berakhir. Postcondition: Admin berada di Home Page Use Case Name: Delete User Use Case ID: UC-006 Precondition: Admin telah berada di Home Page dan menekan pilihan User di menu samping kiri Flow of Events: Basic Path 1. Use case dimulai ketika Admin telah berada di Home Page dan menekan pilihan User di menu samping kiri.

97 Sistem menampilkan halaman User dengan 3 menu utama yang dapat dipilih yaitu Add, Edit, dan Delete. 3. Admin memilih menu Delete dan menekan tombol Next. 4. Sistem menampilkan halaman Delete User yang berisi daftar nama, username, dan branch dari semua user. 5. Admin mencentang username yang ingin dihapus, lalu menekan tombol Delete. 6. Sistem menampilkan warning box yang meminta konfirmasi Admin untuk menghapus username tersebut 7. Admin menekan tombol OK 8. Sistem menampilkan success response di Home Page. 9. Use case berakhir. Alternative Path Alternative 1: Alternative Behavior 1. Alternatif ini dimulai setelah langkah 6 dari basic path ketika sistem menampilkan warning box yang meminta konfirmasi Admin untuk menghapus username 2. Admin menekan tombol Cancel. 3. Sistem kembali menampilkan halaman Delete User. 4. Basic path akan dilanjutkan kembali dari langkah 6 Postcondition: Admin berada di Home Page

98 Gambar 4.13 Usecase Document Imaging 173

99 174 Use Case Name: Upload Dokumen Use Case ID: UC-007 Precondition: Super User telah berada di Home Page dan menekan pilihan Document di menu samping kiri Flow of Events: Basic Path 1. Use case dimulai ketika Super User telah berada di Home Page dan menekan pilihan Document di menu samping kiri. 2. Sistem menampilkan halaman Add Document dengan pilihan tipe dokumen yang akan ditambah 3. Super User menekan tombol Next. 4. Sistem menampilkan pilihan box tempat menyimpan dokumen, file uploader, deskripsi, serta field requirement dan field completeness yanng sesuai dengan spesifikasi tipe dokumen. 5. Super User mengisi semua field 6. Super User menekan tombol Submit 7. Sistem menampilkan success response di Add Document Page. 8. Use case berakhir. Alternative Path Alternative 1: Incorrect Input 1. Alternatif ini dimulai setelah langkah 4 dari basic path ketika sistem menampilkan field-field yang harus diisi pada Add Document Page. 2. Super User mengisi semua field namun file yang diupload tidak memiliki format PDF atau size file yang diupload lebih besar dari 5MB atau required field tidak diisi. 3. Sistem menampilkan warning box yang menyatakan bahwa file yang diupload harus berupa PDF, size tidak lebih besar dari 5MB, dan required field harus diisi. 4. Basic path akan dilanjutkan kembali dari langkah 4. Postcondition: Admin berada di Document Type Page Use Case Name: Baca Dokumen Use Case ID: UC-008 Precondition: User telah berada di Home Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Home Page 2. User mengisi keyword dan atau range tanggal dari dokumen yang ingin dilihat pada search box di bagian atas 3. Sistem menampilkan search result dari dokumen atau list dokumen yang dicari. 4. User menekan nama dokumen tersebut. 5. Sistem membuka di tab baru dokumen tersebut. 6. Use case berakhir.

100 175 Alternative Path Alternative 1: Incorrect Request 1. Alternatif ini dimulai setelah langkah 2 dari basic path ketika user mengisi keyword dan atau tanggal upload dokumen yang ingin dilihat. 2. Sistem menampilkan message yang menyatakan bahwa search result tidak ditemukan. 3. Basic path akan dilanjutkan kembali dari langkah 2. Postcondition: User berada di Home Page Use Case Name: Edit Dokumen Use Case ID: UC-009 Precondition: User telah berada di Home Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Home Page 2. User mengisi keyword dan atau range tanggal dari dokumen yang ingin dilihat pada search box di bagian atas 3. Sistem menampilkan search result dari dokumen atau list dokumen yang dicari serta tombol View/Edit Detail 4. User menekan tombol View/Edit Detail tersebut. 5. Sistem menampilkan detail dari dokumen tersebut dan input box untuk mengubah detail dokumen tersebut. 6. User melakukan perubahan pada input box yang tersedia. 7. User menekan tombol Update 8. Sistem menampilkan success response di Home Page. 9. Use case berakhir. Alternative Path Alternative 1: Incorrect Request 1. Alternatif ini dimulai setelah langkah 2 dari basic path ketika user mengisi keyword dan atau tanggal upload dokumen yang ingin dilihat. 2. Sistem menampilkan message yang menyatakan bahwa search result tidak ditemukan. 3. Basic path akan dilanjutkan kembali dari langkah 2. Alternative Path Alternative 1: Alternative Behavior 1. Alternatif ini dimulai setelah langkah 6 dari basic path ketika user telah mengisi perubahan yang diinginkan. 2. User menekan tombol Cancel. 3. Sistem menampilkan detail dokumen dengan input box perubahan yang kembali kosong. 4. Basic path akan dilanjutkan kembali dari langkah 6. Postcondition: User berada di Home Page

101 176 Use Case Name: Delete Dokumen Use Case ID: UC-010 Precondition: Admin telah berada di Home Page Flow of Events: Basic Path 1. Use case dimulai ketika Admin telah berada di Home Page 2. Admin mengisi keyword dan atau range tanggal dari dokumen yang ingin dilihat pada search box di bagian atas 3. Sistem menampilkan search result dari dokumen atau list dokumen yang dicari serta tombol View/Edit Detail 4. Admin menekan tombol View/Edit Detail tersebut. 5. Sistem menampilkan detail dari dokumen tersebut, input box untuk mengubah detail dokumen tersebut, serta tombol bersimbol x untuk delete dokumen. 6. Admin menekan tombol x tersebut 7. Sistem menampilkan warning box yang meminta konfirmasi Admin untuk menghapus dokumen tersebut 8. Admin menekan tombol OK 9. Sistem menampilkan success response di Home Page. 10. Use case berakhir. Alternative Path Alternative 1: Alternative Behavior 1. Alternatif ini dimulai setelah langkah 7 dari basic path ketika sistem menampilkan warning box yang meminta konfirmasi Admin untuk menghapus dokumen 2. Admin menekan tombol Cancel. 3. Sistem kembali menampilkan halaman Search Result. Postcondition: User berada di Home Page Use Case Name: Membuat Tipe Dokumen Use Case ID: UC-011 Precondition: Admin telah berada di Home Page dan menekan pilihan Document Type di menu samping kiri Flow of Events: Basic Path 1. Use case dimulai ketika Admin telah berada di Home Page dan menekan pilihan Document Type di menu samping kiri. 2. Sistem menampilkan halaman Document Type dengan 3 menu utama yang dapat dipilih yaitu Add, Edit, dan Delete. 3. Admin memilih menu Add dan menekan tombol Next. 4. Sistem menampilkan form Add New Document Type yang berisi input box nama dan total field requirement.

102 Admin mengisi nama tipe dokumen baru dan total field requirement. 6. Admin menekan tombol Next 7. Sistem menampilkan input box field requirement sesuai dengan total yang telah diisi sebelumnya, serta dengan sifat dari field yang harus dicentang: nullable atau mandatory 8. Admin mengisi nama field tersebut dan mencentang nullable atau mandatory 9. Admin menekan tombol Next. 10. Sistem menampilkan input box field completeness. 11. Admin mengisi kelengkapan dokumen pada tipe dokumen tersebut 12. Admin menekan tombol Submit. 13. Sistem menampilkan success response di Document Type Page. 14. Use case berakhir. Alternative Path Alternative 1: Blank Input 1. Alternatif ini dimulai setelah langkah 4 dari basic path ketika sistem telah menampilkan form Add New Document Type 2. Admin menekan tombol Next 3. Sistem menampilkan warning box yang meminta Admin untuk mengisi semua field. 4. Admin menekan tombol OK. 5. Sistem menampilkan kembali form Add New Document Type. 6. Basic path akan dilanjutkan kembali dari langkah 4. Alternative 2: Incorrect Input 1. Alternatif ini dimulai setelah langkah 5 dari basic path ketika Admin telah mengisi nama tipe dokumen baru dan total field requirement. 2. Admin menekan tombol Next. 3. Sistem menampilkan warning box yang menyatakan bahwa total field requirement harus berupa angka 4. Admin menekan tombol OK. 5. Basic path akan dilanjutkan kembali dari langkah 5. Alternative 3: Blank Input 1. Alternatif ini dimulai setelah langkah 7 dari basic path ketika Sistem menampilkan input box field requirement dan pilihan nullable atau mandatory yang harus dicentang. 2. Admin menekan tombol Next tanpa mengisi field dan atau mencentang sifat dari field. 3. Sistem menampilkan warning box yang menyatakan bahwa setidaknya field pertama harus diisi dan sifatnya harus dicentang 4. Admin menekan tombol OK. 5. Basic path akan dilanjutkan kembali dari langkah 7. Alternative 4: Blank Input 1. Alternatif ini dimulai setelah langkah 10 dari basic path ketika Sistem menampilkan input box field completeness. 2. Admin menekan tombol Submit tanpa mengisi field tersebut 3. Sistem menampilkan warning box yang menyatakan bahwa setidaknya field

103 178 pertama harus diisi. 4. Admin menekan tombol OK. 5. Basic path akan dilanjutkan kembali dari langkah 10. Postcondition: Admin berada di Document Type Page Use Case Name: Edit Tipe Dokumen Use Case ID: UC-012 Precondition: Admin telah berada di Home Page dan menekan pilihan Document Type di menu samping kiri Flow of Events: Basic Path 1. Use case dimulai ketika Admin telah berada di Home Page dan menekan pilihan Document Type di menu samping kiri. 2. Sistem menampilkan halaman Document Type dengan 3 menu utama yang dapat dipilih yaitu Add, Edit, dan Delete. 3. Admin memilih menu Edit dan menekan tombol Next. 4. Sistem menampilkan form Edit New Document Type yang berisi pilihan tipe dokumen yang ingin diubah. 5. Admin menekan tombol Next 6. Sistem menampilkan spesifikasi tipe dokumen yang dipilih. 7. Admin merubah nama tipe dokumen atau nama field requirement atau sifat field requirement atau nama field completeness. 8. Admin menekan tombol Update. 9. Sistem menampilkan success response di Document Type Page. 10. Use case berakhir. Alternative Path Alternative 1: Alternative Behavior 1. Alternatif ini dimulai setelah langkah 7 dari basic path ketika Admin telah melakukan perubahan pada tipe dokumen yang dipilih. 2. Admin menekan tombol Reset. 3. Sistem menampilkan spesifikasi semula dari tipe dokumen tersebut. 4. Basic path akan dilanjutkan kembali dari langkah 7. Postcondition: Admin berada di Document Type Page Use Case Name: Menghapus Tipe Dokumen Use Case ID: UC-013 Precondition: Admin telah berada di Home Page dan menekan pilihan Document Type di menu samping kiri Flow of Events: Basic Path 1. Use case dimulai ketika Admin telah berada di Home Page dan menekan pilihan

104 179 Document Type di menu samping kiri. 2. Sistem menampilkan halaman Document Type dengan 3 menu utama yang dapat dipilih yaitu Add, Edit, dan Delete. 3. Admin memilih menu Delete dan menekan tombol Next. 4. Sistem menampilkan semua tipe dokumen yang telah dibuat. 5. Admin mencentang tipe dokumen yang ingin dihapus dan menekan tombol Delete. 6. Sistem menampilkan warning box yang meminta konfirmasi Admin untuk menghapus tipe dokumen yang dipilih 7. Admin menekan tombol OK 8. Sistem menampilkan success response di Document Type Page. 9. Use case berakhir. Alternative Path Alternative 1: Blank Input 1. Alternatif ini dimulai setelah langkah 4 dari basic path ketika Sistem menampilkan semua tipe dokumen yang telah dibuat. 2. Admin menekan tombol Delete 3. Sistem menampilkan warning box yang menyatakan bahwa harus ada minimal satu tipe dokumen yang dicentang. 4. Admin menekan tombol OK. 5. Basic path akan dilanjutkan kembali dari langkah 4. Alternative Path Alternative 1: Alternative Behavior 1. Alternatif ini dimulai setelah langkah 6 dari basic path ketika Sistem menampilkan warning box yang meminta konfirmasi Admin untuk menghapus tipe dokumen yang dipilih 2. Admin menekan tombol Cancel. 3. Basic path akan dilanjutkan kembali dari langkah 5. Alternative Path Alternative 1: Incorrect Behavior 4. Alternatif ini dimulai setelah langkah 7 dari basic path ketika Admin mengkonfirmasi penghapusan tipe dokumen dengan menekan tombol OK 5. Sistem menampilkan error message yang menyatakan bahwa tipe dokumen yang dipilih masih dipakai dan tidak dapat dihapus. 6. Basic path akan dilanjutkan kembali dari langkah 2. Postcondition: Admin berada di Document Type Page

105 180 Gambar 4.14 Usecase Peminjaman Box Use Case Name: Mencari box berisi dokumen yang diinginkan Use Case ID: UC-014 Precondition: User telah berada di Home Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Home Page 2. User mengisi keyword dan atau range tanggal dari dokumen yang ingin dipinjam pada search box di bagian atas 3. Sistem menampilkan search result dari dokumen atau list dokumen yang dicari. 4. User mencatat kode box dari dokumen tersebut secara manual 5. Use case berakhir. Alternative Path Alternative 1: Incorrect Request 1. Alternatif ini dimulai setelah langkah 2 dari basic path ketika user mengisi keyword dan atau tanggal upload dokumen yang ingin dilihat. 2. Sistem menampilkan message yang menyatakan bahwa search result tidak ditemukan. 3. Basic path akan dilanjutkan kembali dari langkah 2. Postcondition: User berada di halaman Search Result Use Case Name: Membuat memo peminjaman box

106 181 Use Case ID: UC-015 Precondition: User telah berada di Home Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Home Page 2. User memilih pilihan Box di menu samping kiri 3. Sistem menampilkan Box Page berisi menu yang dapat dipilih 4. User memilih menu Print dan menekan tombol Next 5. Sistem menampilkan pilihan Print Box 6. User memilih radio button Print Peminjaman Box dan menekan tombol Next 7. Sistem menampilkan semua list box yang ada pada Cabang 8. User mencentang box yang ingin dipinjam serta menambahkan deskripsi jika diinginkan. 9. User menekan tombol Print Peminjaman Box 10. Sistem menampilkan file excel dari memo peminjaman box yang dapat segera dibuka atau disimpan oleh user. 11. User membuka atau menyimpn file tersebut dan klik OK 12. Sistem menampilkan memo tersebut dalam bentuk excel. 13. Use case berakhir. Alternative Path Alternative 1: Blank Input 1. Alternatif ini dimulai setelah langkah 7 dari basic path ketika Sistem menampilkan semua list box yang ada pada Cabang 2. Admin menekan tombol Print Peminjaman Box tanpa mencentang box manapun 3. Sistem menampilkan warning box yang menyatakan bahwa setidaknya satu box harus dicentang 4. Admin menekan tombol OK. 5. Basic path akan dilanjutkan kembali dari langkah 7. Postcondition: User berada di halaman Box Use Case Name: Update Status box menjadi borrowed from vendor Use Case ID: UC-016 Precondition: User telah berada di Box Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Box Page 2. Sistem menampilkan Box Page berisi menu yang dapat dipilih 3. User memilih menu Received dan menekan tombol Next 4. Sistem menampilkan pilihan Received Type dan input box dari kode Box yang ingin diupdate. 5. User memilih Received type Borrow from Vendor dan mengisi kode box yang dipinjam. 6. User menekan tombol Submit

107 Sistem menampilkan success response di Box Page 8. Use case berakhir. Alternative Path Alternative 1: Incorrect Input 1. Alternatif ini dimulai setelah langkah 5 dari basic path ketika user memilih Received type Borrow from Vendor dan mengisi kode box yang dipinjam. 2. User menekan tombol Submit 3. Sistem menampilkan error message yang menyatakan bahwa kode box yang dimasukkan salah. 4. Basic path akan dilanjutkan kembali dari langkah 5. Postcondition: User berada di halaman Box

108 183 Gambar 4.15 Usecase Pengadaan Box Use Case Name: Membuat memo request box Use Case ID: UC-017 Precondition: User telah berada di Box Page Flow of Events: Basic Path 1. Sistem menampilkan Box Page berisi menu yang dapat dipilih 2. User memilih menu Request dan menekan tombol Next 3. Sistem menampilkan input box tanggal request, jumlah box, dan kode box baru 4. User mengisi semua field. 5. User menekan tombol Print. 6. Sistem menampilkan file excel dari memo pengadaan box yang dapat segera dibuka atau disimpan oleh user. 7. User membuka atau menyimpan file tersebut dan klik OK 8. Sistem menampilkan memo tersebut dalam bentuk excel. 9. Use case berakhir. Alternative Path Alternative 1: Blank Input

109 Alternatif ini dimulai setelah langkah 3 dari basic path ketika Sistem menampilkan semua input box yang harus diisi. 2. User menekan tombol Print. 3. Sistem menampilkan error message yang menyatakan bahwa kode box yang dimasukkan salah. 4. Basic path akan dilanjutkan kembali dari langkah 3. Postcondition: User berada di halaman Box Use Case Name: Menambahkan Box Use Case ID: UC-018 Precondition: User telah berada di Box Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Box Page 2. Sistem menampilkan Box Page berisi menu yang dapat dipilih 3. User memilih menu Received dan menekan tombol Next 4. Sistem menampilkan pilihan Received Type dan input box dari kode Box yang ingin diupdate. 5. User memilih Received type Add dan mengisi kode box yang ingin ditambah. 6. User menekan tombol Submit 7. Sistem menampilkan success response di Box Page 8. Use case berakhir. Alternative Path Alternative 1: Incorrect Input 1. Alternatif ini dimulai setelah langkah 5 dari basic path ketika user memilih Received type Add dan mengisi kode box yang ingin ditambah 2. User menekan tombol Submit 3. Sistem menampilkan error message yang menyatakan bahwa kode box yang dimasukkan salah. 4. Basic path akan dilanjutkan kembali dari langkah 5. Postcondition: User berada di halaman Box Use Case Name: Edit Box Use Case ID: UC-019 Precondition: User telah berada di Box Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Box Page 2. Sistem menampilkan Box Page berisi menu yang dapat dipilih 3. User memilih menu Edit dan menekan tombol Next 4. Sistem menampilkan semua kode box yang ada

110 User mengadakan perubahan pada kode box yang ingin dirubah 6. User menekan tombol Submit 7. Sistem menampilkan success response di Box Page 8. Use case berakhir. Postcondition: User berada di halaman Box Use Case Name: Delete Box Use Case ID: UC-020 Precondition: User telah berada di Box Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Box Page 2. Sistem menampilkan Box Page berisi menu yang dapat dipilih 3. User memilih menu Delete dan menekan tombol Next 4. Sistem menampilkan semua kode box yang ada serta pilihan untuk mencentang kode box yang ingin dihapus. 5. User mencentang kode box yang ingin dihapus. 6. User menekan tombol Delete 7. Sistem menampilkan warning box yang meminta konfirmasi User untuk menghapus box yang dipilih 8. Admin menekan tombol OK 9. Sistem menampilkan success response di Box Page 10. Use case berakhir. Postcondition: User berada di halaman Box

111 186 Gambar 4.16 Usecase Penghancuran Box Use Case Name: Membuat memo penghancuran box Use Case ID: UC-021 Precondition: User telah berada di Box Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Box Page 2. Sistem menampilkan Box Page berisi menu yang dapat dipilih 3. User memilih menu Print dan menekan tombol Next 4. Sistem menampilkan pilihan Print Box 5. User memilih radio button Print Penghancuran Box dan menekan tombol Next 6. Sistem menampilkan semua list box yang ada pada Cabang 7. User mencentang box yang ingin dihancurkan. 8. User menekan tombol Print Penghancuran Box 9. Sistem menampilkan file excel dari memo Penghancuran box yang dapat segera dibuka atau disimpan oleh user. 10. User membuka atau menyimpn file tersebut dan klik OK 11. Sistem menampilkan memo tersebut dalam bentuk excel. 12. Use case berakhir. Alternative Path Alternative 1: Blank Input 1. Alternatif ini dimulai setelah langkah 7 dari basic path ketika Sistem menampilkan semua list box yang ada pada Cabang 2. Admin menekan tombol Print Penghancuran Box tanpa mencentang box manapun 3. Sistem menampilkan warning box yang menyatakan bahwa setidaknya satu box

112 187 harus dicentang 4. Admin menekan tombol OK. 5. Basic path akan dilanjutkan kembali dari langkah 7. Postcondition: User berada di halaman Box Use Case Name: Update Status box menjadi Destroy Use Case ID: UC-022 Precondition: User telah berada di Box Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Box Page 2. Sistem menampilkan Box Page berisi menu yang dapat dipilih 3. User memilih menu Issued dan menekan tombol Next 4. Sistem menampilkan semua list kode box, total dokumen pada box tersebut, dan input box comment yang dapat diisi user, serta pilihan centang pada box yang ingin dihancurkan 5. User mencentang kode box yang ingin dihancurkan 6. User menekan tombol Submit 7. Sistem menampilkan success response di Box Page 8. Use case berakhir. Alternative Path Alternative 1: Blank Input 1. Alternatif ini dimulai setelah langkah 4 dari basic path ketika sistem menampilkan semua list kode box, serta pilihan centang pada box yang ingin dihancurkan 2. User menekan tombol Submit 3. Sistem menampilkan warning box yang menyatakan bahwa minimal harus ada 1 box yang dicentang. 4. User menekan tombol OK 5. Basic path akan dilanjutkan kembali dari langkah 4. Postcondition: User berada di halaman Box

113 188 Gambar 4.17 Usecase Pengiriman Box Penuh Use Case Name: Membuat memo penghancuran box Use Case ID: UC-021 Precondition: User telah berada di Box Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Box Page 2. Sistem menampilkan Box Page berisi menu yang dapat dipilih 3. User memilih menu Print dan menekan tombol Next 4. Sistem menampilkan pilihan Print Box 5. User memilih radio button Print Penghancuran Box dan menekan tombol Next 6. Sistem menampilkan semua list box yang ada pada Cabang 7. User mencentang box yang ingin dihancurkan. 8. User menekan tombol Print Penghancuran Box 9. Sistem menampilkan file excel dari memo Penghancuran box yang dapat segera dibuka atau disimpan oleh user. 10. User membuka atau menyimpn file tersebut dan klik OK 11. Sistem menampilkan memo tersebut dalam bentuk excel. 12. Use case berakhir. Alternative Path Alternative 1: Blank Input 1. Alternatif ini dimulai setelah langkah 7 dari basic path ketika Sistem

114 189 menampilkan semua list box yang ada pada Cabang 2. Admin menekan tombol Print Penghancuran Box tanpa mencentang box manapun 3. Sistem menampilkan warning box yang menyatakan bahwa setidaknya satu box harus dicentang 4. Admin menekan tombol OK. 5. Basic path akan dilanjutkan kembali dari langkah 7. Postcondition: User berada di halaman Box Use Case Name: Update Status box menjadi Destroy Use Case ID: UC-022 Precondition: User telah berada di Box Page Flow of Events: Basic Path 1. Use case dimulai ketika User telah berada di Box Page 2. Sistem menampilkan Box Page berisi menu yang dapat dipilih 3. User memilih menu Issued dan menekan tombol Next 4. Sistem menampilkan semua list kode box, total dokumen pada box tersebut, dan input box comment yang dapat diisi user, serta pilihan centang pada box yang ingin dihancurkan 5. User mencentang kode box yang ingin dihancurkan 6. User menekan tombol Submit 7. Sistem menampilkan success response di Box Page 8. Use case berakhir. Alternative Path Alternative 1: Blank Input 1. Alternatif ini dimulai setelah langkah 4 dari basic path ketika sistem menampilkan semua list kode box, serta pilihan centang pada box yang ingin dihancurkan 2. User menekan tombol Submit 3. Sistem menampilkan warning box yang menyatakan bahwa minimal harus ada 1 box yang dicentang. 4. User menekan tombol OK 5. Basic path akan dilanjutkan kembali dari langkah 4. Postcondition: User berada di halaman Box

115 Activity Diagram Add User Gambar 4.18 Add User Activity Diagram Edit User Gambar 4.19 Edit User Activity Diagram Delete User Gambar 4.20 Delete User Activity Diagram Add Role Gambar 4.21 Add Role Activity Diagram

116 Edit Role Gambar 4.22 Edit Role Activity Diagram Delete Role Gambar 4.23 Delete Role Activity Diagram Upload Document Select Document Type Select Box / Incorrect Upload File / Incorrect Fill the field requirement Check Completeness Gambar 4.24 Upload Document Activity Diagram

117 Read Document Read Document / Don't have privilege / Have privilege Open Document Gambar 4.25 Upload Document Activity Diagram Edit Document Gambar 4.26 Edit Document Activity Diagram

118 Delete Document Delete the selected document / Dont' have privilege / Have privilege Gambar 4.27 Delete Document Activity Diagram Add Document Type Fill Add Document type name / Incorrect Fill Total field requirement / Incorrect Specify Requirement Field / Incorrect Specify Completeness Field Gambar 4.28 Add Document Type Activity Diagram

119 Edit Document Type Gambar 4.29 Edit Document Type Activity Diagram Delete Document Type Gambar 4.30 Delete Document Type Activity Diagram Request Box Gambar 4.31 Request Box Activity Diagram

120 Add Box Gambar 4.32 Add Box Activity Diagram Borrow Box Gambar 4.33 Borrow Box Activity Diagram Create Memo Gambar 4.34 Create Memo Activity Diagram Delete Box Delete the selected box / Invalid Gambar 4.35 Delete Box Activity Diagram

121 Destroy Box Gambar 4.36 Destroy Box Activity Diagram Edit Box Edit Box Code / Invalid Gambar 4.37 Edit Box Activity Diagram

122 Sequence Diagram Add User Gambar 4.38 Add User Sequence Diagram

123 Edit User Gambar 4.39 Edit User Sequence Diagram

124 Delete User Gambar 4.40 Delete User Sequence Diagram

125 Add Role <<view>> admin_role <<controller>>role Admin Submit Form () Check role () : boolean : available is_role_available () : true Register () set_add_role () : boolean : Success : Success message Gambar 4.41 Add Role Sequence Diagram

126 Edit Role Gambar 4.42 Edit Role Sequence Diagram

127 Delete Role <<view>> admin_role <<controller>>role <<model>>role Admin Submit () role_delete() set_delete_role(): boolean exists(): boolean : Success : Message Success Gambar 4.43 Delete Role Sequence Diagram

128 Upload Document <<view>> User_document <<controller>>document <<helper>>upload pdf <<model>>document Super User Submit Form () Upload PDF () Upload () : boolean : Success set_document_path () : boolean Send data () set_add_document () : boolean : Message Success : Success Gambar 4.44 Upload Document Sequence Diagram

129 Read Document <<view>> Search_result <<controller>>document <<model>>document User Submit Form () Send data () Search_by_data () exists(): boolean get_document(): string : Success :Show PDF Gambar 4.45 Read Document Sequence Diagram

130 Edit Document <<view>>edit document <<controller>>document <<model>>document User Submit Form () Edit () run () Check(): boolean set_update_document(): boolean : Success :Success Message Gambar 4.46 Edit Document Sequence Diagram

131 Delete Document <<view>>edit document <<controller>>document <<model>>document Admin Submit () Delete Document () set_delete_document () exists(): boolean Save() : boolean : Success :Success Message Gambar 4.47 Delete Document Sequence Diagram

132 Add Document Type <<view>> admin_document_type <<controller>>document_type Admin Submit Form () Send Data () Validate Document Type () Exists () : true Set_add_document_type () : boolean : Success : Message Success Gambar 4.48 Add Document Type Sequence Diagram

133 Edit Document Type <<view>> admin_document_type <<controller>>document_type <<model>>document_type Admin Submit Form () Send Data () Check Document Type () Exists () : true Set_update_document_type () : boolean : Success : Message Success Gambar 4.49 Edit Document Type Sequence Diagram

134 Delete Document Type <<view>> admin_document_type <<controller>>document_type <<model>>document_type <<model>>document Admin Submit Form () Send Data () Check Document Type () Exists () : true Check Document () : boolean Set_delete_document_type () : boolean : Message Success : Success Gambar 4.50 Delete Document Type Sequence Diagram

135 Request Box <<view>> User_box <<controller>>box Super User Submit Form () print_request_box() get_branch_user() : Success : Show Excel Gambar 4.51 Request Box Sequence Diagram

136 Add Box Gambar 4.52 Add Box Sequence Diagram

137 Borrow Box Gambar 4.53 Borrow Box Sequence Diagram

138 Create Memo Gambar 4.54 Create Memo Sequence Diagram

139 Delete Box Gambar 4.55 Delete Box Sequence Diagram

140 Destroy Box Gambar 4.56 Destroy Box Sequence Diagram

141 Edit Box Gambar 4.57 Edit Box Sequence Diagram

142 Perancangan Input dan Output Perancangan input berupa rancangan layar semua form dari aplikasi ini sedangkan perancangan output berupa rancangan layar untuk hasil dari form input yang akan ditampilkan pada halaman-halaman view di aplikasi ini Perancangan Input Gambar 4.58 Perancangan Layar Form Login

143 218 Gambar 4.59 Perancangan Layar Form Add User Gambar 4.60 Perancangan Layar Form Edit User

144 219 Gambar 4.61 Perancangan Layar Form Delete User Gambar 4.62 Perancangan Layar Form Add New Document Type

145 220 Gambar 4.63 Perancangan Layar Form Edit Document Type Gambar 4.64 Perancangan Layar Form Delete Document Type

146 221 Gambar 4.65 Perancangan Layar Form Add Role Gambar 4.66 Perancangan Layar Form Edit Role

147 222 Gambar 4.67 Perancangan Layar Form Delete Role Gambar 4.68 Perancangan Layar Form Request Box

148 223 Gambar 4.69 Perancangan Layar Form Received Box Gambar 4.70 Perancangan Layar Form Edit Box

149 224 Gambar 4.71 Perancangan Layar Form Issued Box Gambar 4.72 Perancangan Layar Form Print Peminjaman Box

150 225 Gambar 4.73 Perancangan Layar Form Delete Box Perancangan Output Gambar 4.74 Perancangan Layar Home Admin

151 226 Gambar 4.75 Perancangan Layar Monitoring Gambar 4.76 Perancangan Layar Print Register Arsip

152 227 Gambar 4.77 Perancangan Layar Status Box Gambar 4.78 Perancangan Layar Home User (dan Super User)

153 228 Gambar 4.79 Perancangan Layar Search Result Gambar 4.80 Perancangan Layar View / Edit Result

154 Implementasi Spesifikasi Perangkat Keras Perangkat keras sangat diperlukan dan sangat berpengaruh dalam kelancaran implementasi proses-proses pada aplikasi document imaging ini. Spesifikasi minimum perangkat keras ini meliputi perangkat keras pada server dan client. Representasi data perangkat keras yang diperlukan dapat dilihat di tabel berikut : Tabel 4.58 Spesifikasi Perangkat Keras Piranti Keras Server Client Processor Intel Xeon Quad Core 2.5 GHz Intel(R) Core(TM) 2 Duo CPU (2 CPUs) Main Memory 4096 Megabytes 2048 MB Scanner - Canon Canoscan Lide 110 Free Space 640 Gigabytes 250 Gigabytes

155 Spesifikasi Perangkat Lunak Perangkat lunak yang dibutuhkan untuk menjalankan semua sistem dalam aplikasi ini antara lain: Tabel 4.59 Spesifikasi Perangkat Lunak Piranti Lunak Server Client Operating System Windows Server 2003 R2 Windows XP Aplikasi Apache 2, PHP 5 Internet Explorer 8 DBMS MySQL Jadwal Implementasi Activity Sept '12 Oct '12 v '12 Dec '12 Jan' Requirement gathering and analysis Storyboard Design Database Design PHP Script Data Entry and Testing Evaluation

156 Petunjuk Pemakaian Sistem Aplikasi Document Imaging untuk PT. XYZ dapat diakses melalui web browser yang terhubung dengan internet. Berikut ini adalah detail prosedur pemakaian dari aplikasi tersebut Petunjuk Pemakaian Sistem Admin Gambar 4.81 Halaman Login Halaman pertama yang akan muncul pada saat aplikasi dijalankan ialah halaman Login. Halaman ini akan meminta user untuk memasukkan username dan password-nya, dimana keduanya tidak boleh kosong. Jika salah satu field atau kedua field kosong dan user telah klik button Login, maka alert box yang meminta user untuk mengisi kedua field akan muncul.

157 232 Gambar 4.82 Alert Box pada Login Page jika user tidak mengisi field username dan atau field password atau keduanya Gambar 4.83 Error Message pada Login Page jika username dan atau password yang dimasukkan salah Selain untuk menjaga keamanan aplikasi, halaman Login akan menyaring user yang memiliki hak akses berbeda-beda, yaitu peran sebagai admin, peran sebagai super user, dan peran sebagai user. Setelah mengisi semua field dan klik tombol login, maka user akan dialihkan ke halaman utama (Home Page).

158 233 Gambar 4.84 Home Page (Admin) Tampilan di atas merupakan halaman utama aplikasi Document Imaging untuk admin. Ada empat menu utama di samping kiri yaitu User, Document Type, Role, dan Monitoring. Jika admin memilih menu User, maka admin akan pindah ke halaman User, dan seterusnya. Pada bagian atas halaman ini juga terdapat fitur searching, dimana user dapat memasukkan keyword yang ingin dicari dan atau memasukkan range tanggal dari dokumen yang pernah dimasukkan ke dalam aplikasi. Sebagai contoh, jika user memasukkan keyword : karyawan, dan klik icon search (gambar lup), maka akan tampil search result dari dokumen yang mengandung keyword karyawan.

159 234 Gambar 4.85 Search Result dengan input keyword Jika user hanya memasukkan range tanggal dari 1 Desember sampai 1 Januari, dan klik icon search, maka akan muncul semua dokumen yang dimasukkan dari tanggal 1 Desember sampai 1 Januari. Jika user hanya memasukkan tanggal 1 Desember pada input box From, maka akan muncul semua dokumen yang dimasukkan dari tanggal 1 Desember sampai saat ini. Begitu sebaliknya, jika user hanya memasukkan tanggal 1 Januari pada input box To, maka akan muncul semua dokumen yang dimasukkan sampai tanggal 1 Januari. User juga dapat memasukkan kedua field, keyword dari dokumen yang dicari dan range tanggal yang diinginkan untuk menghasilkan hasil pencarian yang lebih spesifik.

160 235 Gambar 4.86 Search Result dengan input tanggal sebagai dasar pencarian dokumen Gambar 4.87 Search Result dengan input keyword dan tanggal sebagai dasar pencarian dokumen

161 236 Jika dokumen yang dicari ditemukan, maka user dapat menekan nama file dokumen atau tombol View/Edit Details untuk melihat lebih lanjut detail dari dokumen tersebut. Khusus untuk admin, tersedia icon x berwarna merah pada setiap dokumen. Ini berarti admin dapat langsung menghapus dokumen dengan menekan icon tersebut. Gambar 4.88 Pilihan Delete Document yang dicari pada fitur searching Jika admin memilih nama dokumen PDF yang berwarna biru tersebut, maka tab baru yang berisi dokumen pdf tersebut akan muncul. Gambar 4.89 Open New Tab dokumen PDF yang dicari

162 237 User akan dialihkan ke halaman View/Edit Result dimana user dapat melakukan perubahan pada tipe dokumen, box, deskripsi, field, kelengkapan dokumen, bahkan mengganti dokumen itu sendiri melalui pilihan Browse. Gambar 4.90 Halaman View/Edit Result dokumen yang dicari Gambar 4.91 Halaman Success Response setelah melakukan Edit Result Jika user menekan tombol reset, maka edit yang dilakukan oleh user sebelum menekan tombol edit akan dihapus dan spesifikasi dokumen kembali ke semula. Jika dokumen yang dicari tidak ditemukan, atau tidak ada input keyword dan range tanggal yang dimasukkan, maka akan muncul tampilan sebagai berikut:

163 238 Gambar 4.92 Response Search Result jika keyword tidak ditemukan atau tidak ada input Fitur searching ini berlaku sama untuk admin dan super user, hanya saja admin dapat menemukan semua dokumen yang di-upload oleh semua user, tidak terbatas user di cabang manapun. Sedangkan super user hanya dapat menemukan dokumen yang diupload oleh semua user di cabang yang sama dengan super user tersebut. Hal yang sama berlaku untuk user, dimana user dapat menemukan dokumen yang diupload oleh super user atau user di cabang itu. Bedanya, user tidak dapat melakukan edit result dokumen yang dicari. User hanya diperbolehkan melihat dokumen tersebut di tab baru. Di menu utama admin, jika admin memilih menu User, maka akan tampil halaman User dimana admin dapat menambah, meng-edit, atau menghapus user. Gambar 4.93 Halaman User pada Admin Page

164 239 Admin dapat memilih salah satu menu (default-nya Add), lalu klik next untuk masuk ke halaman yang dituju. Jika Admin memilih menu Add, maka akan tampil halaman Add User sebagai berikut: Gambar 4.94 Halaman Add User pada Admin Page Di halaman User seperti tampilan di atas, admin dapat membuat user baru dengan mengisi field-field pada Form Register yaitu username, password, Re-password atau confirm password, nama, cabang, dan peran dari user tersebut (admin, super user, atau user). Semua field pada Form Register harus diisi, jika ada field yang kosong, dan admin telah klik submit, maka akan muncul pop-up box yang berisi alert agar admin mengisi semua field.

165 240 Gambar 4.95 Alert Box pada form Add User jika Admin tidak mengisi semua field Jika semua field diisi, dan admin menekan tombol Submit, maka admin akan melihat success response seperti tampilan di bawah: Gambar 4.96 Response Success di Home Page setelah menambah user Jika admin menekan tombol Cancel sebelum menekan tombol Submit, maka form akan kembali ke semula dengan field-field yang masih kosong. Selain menu Add User, Admin dapat melakukan perubahan atau edit User dengan memilih radio button Edit lalu klik button next.

166 241 Gambar 4.97 Halaman Edit User pada Admin Page Pada halaman Edit User, akan tampil semua list user yang pernah dibuat sebelumnya oleh admin, dengan pilihan edit pada Branch dan Role di 2 kolom paling kanan. Admin dapat mengganti branch atau role dengan menekan panah down pada combo box dan memilih perubahan yang diinginkan, seperti tampilan di bawah ini: Gambar 4.98 Perubahan Role user bernama lala dari User menjadi Super User

167 242 Setelah memilih Role baru: super user, admin dapat menekan button Update. Success Response di Home Page akan muncul dan peran dari user lala akan berubah menjadi super user. Pilihan terakhir pada menu User adalah Delete User, pilih radio button Delete lalu klik button next, maka akan tampil halaman Delete User sebagai berikut: Gambar 4.99 Halaman Delete User pada Admin Page Di halaman ini, admin dapat menandai check atau tanda centang di sebelah kiri list user jika ingin menghapus user tersebut. Misalnya, jika ingin menghapus user Budi, maka klik kotak di samping username budi2 lalu tekan button Delete.

168 243 Gambar Delete User Budi Setelah menekan button Delete, maka akan tampil pop up box yang meminta konfirmasi admin untuk menghapus user tersebut. Gambar Alert Box untuk konfirmasi delete user

169 244 Klik OK untuk confirm atau cancel untuk membatalkan delete user Budi. Jika klik OK, maka akan muncul success response di Home Page. Admin juga dapat menghapus semua user sekaligus dengan member tanda centang pada kotak atas kiri pojok. Semua user akan diberi tanda centang secara otomatis dan admin dapat menghapus semua user sekaligus dengan menekan button Delete. Gambar Delete All User Document Type merupakan menu kedua dari Admin Page. Pilih bullet Document Type di samping kiri maka akan muncul Document Page Gambar Document Type Menu di Admin Page

170 245 Seperti pada menu User, di menu Document Type admin dapat menambah, mengubah, atau menghapus dokumen. Default-nya adalah menu Add. Pilih radio button Add dan klik next untuk lanjut ke halaman Add New Document Type. Gambar Form Add New Document Type Pada Form Add New Document Type di halaman ini, ada 2 field yang harus diisi oleh Admin, yaitu nama dari tipe dokumen yang akan dibuat dan total field yang dibutuhkan untuk tipe dokumen tersebut. Jika salah satu field tidak diisi, dan admin telah klik button Generate New Document, maka akan muncul alert box yang meminta admin mengisi semua field. Gambar Alert Box pada menu Add Document Type jika Admin tidak mengisi semua field

171 246 Perlu diingat bahwa total field requirement yang dimasukkan harus lebih dari 0, tidak boleh melebihi 10, dan harus berupa angka. Jika tidak, maka akan muncul alert box seperti berikut: Gambar Alert Box pada menu Add Document Type jika total field requirement yang dimasukkan = 0 Gambar Add New Document Type dengan nama Kredit dan total field 3 Setelah Add New Document Type dengan nama tipe dokumen Kredit dan total field 3 (contoh pada Gambar) lalu klik button Generate New Document, maka admin harus mengisi setidaknya field pertama serta memberi tanda centang apakah field tersebut

172 247 boleh kosong (nullable) atau harus diisi (mandatory), atau tidak dicentang jika tidak bersifat mandatory tapi tidak boleh dikosongkan (tidak nullable). Gambar Spesifikasi Field Requirement pada Add New Document Type Jika admin tidak mengisi apapun dan menekan button Next, maka akan muncul alert box yang meminta user untuk memasukkan setidaknya field pertama. Gambar Alert Box untuk mengisi setidaknya Field Requirement pertama

173 248 Jika admin ingin menambah field requirement, maka admin dapat klik icon + warna hijau, dan field baru akan secara otomatis ditambahkan di bawah field sebelumnya. Gambar Field 3 ditambahkan ketika admin klik icon + warna hijau Jika admin telah mengisi semua field beserta sifat nullable atau mandatory, maka user dapat menekan tombol next untuk lanjut ke tahap berikutnya: Gambar Add New Document Type Kredit dengan spesifikasi 3 Field Requirement yang telah diisi

174 249 Tahap berikutnya ialah mengisi field completeness atau field dari kelengkapan dokumen yang diinginkan, seperti gambar. Gambar Tahap pengisian Field Completeness pada Add New Document Type

175 250 Sama seperti pada field requirement, jika ingin menambahkan field completeness lagi, admin dapat mengklik icon + hijau untuk menambah field kedua, seperti berikut: Gambar Penambahan Field Completeness pada Add New Document Type

176 251 Jika belum mengisi Field pertama dan admin telah klik submit, maka akan muncul alert box: Gambar Alert Box untuk mengisi setidaknya 1 Field Completeness pertama Setelah mengisi setidaknya 1 Field Completeness pertama, dan klik button submit, maka akan keluar success response di Home page. Perlu diingat bahwa jika nama tipe dokumen yang disubmit sama dengan nama tipe dokumen yang telah ada, maka setelah klik submit, akan muncul error message sebagai berikut:

177 252 Gambar Error message ketika memasukkan nama tipe dokumen yang sama Selain menambah tipe dokumen, admin juga dapat mengubah detail dari tipe dokumen yang telah dibuat. Klik radio button Edit pada Document Type Page, lalu klik next. Maka akan muncul tampilan sebagai berikut: Gambar Tahap Pertama Edit Document Type pada Admin Page Pada form ini, admin dapat memilih tipe dokumen yang ingin diubah dari tipe-tipe dokumen yang sudah dibuat sebelumnya. Pada contoh di atas, admin memilih tipe dokumen Kredit lalu klik next, maka akan muncul tahap berikutnya :

178 253 Gambar Tahap Kedua Edit Document Type pada Admin Page Pada tahap ini, admin dapat mengubah nama dari tipe dokumen, spesifikasi field requirement dan spesifikasi field completeness. Selain mengubah detail sebelumnya, admin juga dapat menambah field dengan klik icon + warna hijau atau menghapus field dengan klik icon x warna merah. Perlu diperhatikan bahwa field requirement dengan sifat mandatory tidak dapat dihapus. Jika dihapus, maka akan muncul alert box seperti berikut:

179 254 Gambar Alert Box pada Edit Document Type ketika mandatory field dihapus Jika field requirement yang dihapus tidak bersifat mandatory, maka setelah klik icon x merah, akan muncul alert box yang meminta konfirmasi admin untuk menghapus field tersebut. Gambar Alert Box konfirmasi delete field pada Edit Document Type

180 255 Tekan OK untuk delete atau cancel untuk membatalkan penghapusan field. Perubahan akan diterapkan setelah admin menekan button Submit. Sebaliknya, jika admin ingin mengosongkan dan mengulangi perubahan, tekan button Reset. Untuk menghapus tipe dokumen yang telah dibuat, Admin dapat memilih radio button Delete pada Document Type Page seperti gambar berikut: Gambar Delete Menu pada Document Type di Admin Page Klik next lalu akan keluar tampilan list tipe dokumen pada database dan pilihan untuk mencentang tipe dokumen yang ingin dihapus. Pada contoh di bawah, admin akan menghapus tipe kredit. Gambar Delete Document Type Kredit di Admin Page

181 256 Admin dapat mencentang salah satu, beberapa, atau semua tipe dokumen yang ingin dihapus lalu klik button Delete. Alert box yang meminta konfirmasi user akan muncul. Jika admin yakin ingin menghapus tipe dokumen tersebut, klik Delete. Gambar Alert Box Delete Document Type di Admin Page Jika admin klik OK, maka admin akan melihat success response di Admin Page. Perlu diperhatikan bahwa document type yang masih dipakai tidak dapat dihapus. Jika klik delete padahal masih ada dokumen dengan document type tersebut, maka akan muncul alert box seperti ini: Gambar Error Message saat delete document type yang masih dipakai

182 257 Pada sidebar kiri, menu ketiga yang dapat dipilih oleh Admin ialah Role, dimana Admin dapat menambah, meng-edit atau menghapus role atau peran dari user yang telah dibuat. Gambar Role Menu di Admin Page Menu default-nya ialah menu pertama yaitu Add. Klik next untuk lanjut ke tahap Add Role. Gambar Add Role di Admin Page Disini, admin dapat mengisi nama peran baru yang diinginkan beserta hak atau privilege dari role tersebut. Admin dapat mencentang satu, beberapa, atau semua

183 258 privilege yang tersedia. Pada contoh berikut Admin membuat role baru bernama Newbie dengan privilege untuk mengakses Box Gambar Add Role dengan nama role Newbie dan Privilege Box Klik Submit untuk menambah role atau reset untuk mengosongkan kembali semua pilihan. Jika klik submit, maka akan muncul success response di Admin Page. Untuk mengubah role yang telah dibuat, klik radio button Edit seperti berikut: Gambar Edit Role Menu di Admin Page

184 259 Lalu klik button next maka akan muncul tampilan sebagai berikut: Gambar Edit Role Menu di Admin Page Pada menu ini akan ditampilkan semua role yang telah dibuat dan admin dapat melihat privilege yang telah dicentang dari setiap role, sehingga dapat melakukan perubahan dengan check atau uncheck privilege dari setiap role tersebut. Setelah melakukan perubahan, admin dapat menekan button Submit untuk menerapkan perubahan. Success response akan muncul di Home Page setelah menekan tombol submit. Pilihan menu terakhir untuk Role ialah Delete Role, dimana admin dapat menghapus role yang telah dibuat sebelumnya. Gambar Delete Role di Admin Page

185 260 Disini, admin dapat mencentang salah satu role yang ingin dihapus dan klik button Delete untuk menghapus role tersebut. Gambar Delete Role Newbie Ketika admin menekan button Delete, maka akan muncul alert box yang meminta konfirmasi admin untuk menghapus role tersebut: Gambar Alert Box Delete Role di Admin Page

186 261 Jika admin klik OK, maka akan muncul success response di admin page. Klik cancel untuk membatalkan penghapusan. Perlu diperhatikan bahwa role yang masih memiliki user tidak dapat dihapus. Jika dihapus, maka akan muncul alert box seperti berikut: Gambar Alert Box ketika menghapus role yang masih memiliki user Menu paling bawah di Admin Page ialah Monitoring dimana admin dapat melihat dan me-monitor jumlah dokumen yang diupload oleh setiap cabang per bulan, beserta difference atau selisih dokumen antara bulan saat ini dan bulan sebelumnya. Gambar Monitoring Menu di Admin Page

187 Petunjuk Pemakaian Sistem Super User Pertama kali membuka browser, super user akan dialihkan ke halaman Login seperti layaknya admin. Disini, super user akan mengisi username dan password yang telah ditentukan oleh admin. Gambar Halaman Login Super User Sama seperti pada admin, semua user harus mengisi field username dan password dan tidak boleh hanya salah satu. Setelah klik button login, maka akan tampil Super User Page.

188 263 Gambar Super User Page dengan username jeffry.tani Pada page super user, terdapat 3 menu utama di samping kiri, yaitu User, Document, dan Box. Pada bagian atas, super user juga dapat melakukan searching seperti layaknya admin. Jika admin dapat mencari, menemukan, melihat detail, dan menghapus dokumen yang diupload baik oleh admin, super user atau user, super user hanya dapat mencari dan menemukan dokumen yang di-upload oleh Super user atau user di cabang yang sama. Berikut merupakan menu pertama yaitu User, dimana super user dapat menambah atau mengubah user.

189 264 Gambar User Menu di Super User Page Di halaman ini, super user dapat memilih antara radio button Add dan Edit. Default-nya adalah Add. Untuk menambah user, klik add lalu klik next, maka akan muncul tampilan berikut: Gambar Form Register New User di Super User Page Pada form ini, super user dapat menambah user baru dengan mengisi username, password, confirm password, nama, dan role dari user tersebut, apakah super user atau user biasa. Semua field pada Form Register harus diisi, jika ada field yang kosong, dan

190 265 admin telah klik submit, maka akan muncul alert box yang meminta super user untuk mengisi semua field. Gambar Alert Box pada menu Add User jika Super User tidak mengisi semua field Jika semua field diisi, dan super user menekan tombol Submit, maka admin akan melihat success response di home page. Jika admin menekan tombol Cancel sebelum menekan tombol Submit, maka form akan kembali ke semula dengan field-field yang masih kosong. Selain menu Add User, Super User juga dapat melakukan perubahan atau edit user dengan memilih radio button Edit lalu klik button next, maka akan muncul semua list user yang pernah dibuat oleh super user jeffry.tani:

191 266 Gambar Edit User Menu di Super User Page Disini super user dapat mengubah role dari user-user yang ada dengan menekan menekan panah down pada combo box dan memilih perubahan yang diinginkan, seperti tampilan di bawah ini: Gambar Perubahan Role user bernama Ivandi dari User menjadi Super User Setelah memilih Role baru: super user, admin dapat menekan button Update. Success response akan muncul di home page dan peran dari user Ivandi akan berubah menjadi super user.

192 267 Menu kedua yang dapat diakses oleh Super User adalah Document. Pilih bullet Document di samping kiri maka akan muncul Document Page sebagai berikut : Gambar Document Menu di Super User Page Default-nya adalah menu Add. Pilih radio button Add dan klik next untuk lanjut ke halaman Add New Document Gambar Form Add Document di Super User Page

193 268 Pada form add document ini, super user dapat memilih kode box yang diinginkan untuk menampung dokumen tersebut. Super user juga harus memasukkan dokumen dengan menekan button Browse. File yang dipilih harus memiliki format PDF. Jika bukan PDF, maka pada saat super user klik button submit, akan muncul alert box seperti berikut: Gambar Alert Box di menu Add Document jika dokumen yang di-upload bukan PDF Super user dapat mengisi deskripsi dari dokumen tersebut, tapi tidak wajib. Selain itu, super user juga harus mengisi field requirement, field yang menjadi spesifikasi dari dokumen tersebut, misalnya Contract. dan Address pada tampilan berikut. Field yang diberi tanda *required berarti tidak boleh dikosongkan. Jika dikosongkan, dan super user telah klik button submit, maka akan muncul alert box sebagai berikut:

194 269 Gambar Alert Box pada menu Add Document jika Super User tidak mengisi required field Di bagian paling akhir, super user dapat memberi tanda centang pada kelengkapan dokumen (check completeness) yang telah dibuat oleh admin, contohnya pada field sign, picture, atau keduanya. Field kelengkapan dokumen ini bersifat optional, jadi super user tidak harus mencentang atau dapat kembali mencentang kelengkapan dokumen pada waktu lain saat edit result di pencarian keyword PDF dokumen tersebut.

195 270 Gambar Add Document di Super User Page Klik submit jika telah mengisi dengan benar, maka akan muncul success response pada home page. Untuk mengubah spesifikasi dokumen yang telah di-upload tadi, super user dapat melakukan pencarian di searching box dengan keyword nama dokumen PDF yang dicari dan atau tanggal upload dokumen tersebut di bagian atas page.

196 271 Gambar Pencarian dengan keyword nama dokumen kmk untuk melakukan edit dokumen KMK yang telah diupload Klik button view/edit details, maka akan muncul tampilan Edit Result dimana super user dapat melakukan perubahan. Klik edit untuk menerapkan perubahan atau reset untuk mengosongkan kembali editan tersebut. Gambar Edit Result dokumen KMK dari hasil pencarian Setelah klik edit, maka super user akan melihat success response di home page. Menu kedua yang dapat diakses super user adalah Box, yaitu kardus atau tempat penyimpanan dokumen-dokumen fisik. Klik menu Box di samping kiri, maka akan muncul pilihan menu pada Box Page.

197 272 Gambar Box Page pada Home Page (Super User) Ada 7 pilihan submenu yang dapat dipilih. Submenu pertama ialah Request, dimana super user dapat meminta box baru kepada vendor yang menyediakan box. Klik next, maka akan muncul form Request Box: Gambar Form Request Box pada Box Page (Super User) Di form ini, super user harus mengisi tanggal pengiriman box yang diinginkan, serta jumlah box yang diinginkan untuk setiap tipe dokumen. Di sebelah kanan setiap tipe dokumen, ada box code dimana 3 digit pertama (di gambar 4.124: 416) merupakan kode vendor dan digit setelah tanda merupakan kode cabang yang harus diisi oleh

198 273 super user di cabang tersebut. Jika tanggal pengiriman tidak diisi, atau banyak box tidak diisi, atau kode cabang tidak diisi atau ketiganya, dan super user telah klik print, maka akan muncul alert box yang meminta super user memasukkan field tersebut. Gambar Alert box yang meminta super user memasukkan field Tanggal Kirim Box Jika semua field telah diisi, dan super user klik print, maka aplikasi akan secara otomatis membuka excel file yang mencatat request letter dari box tersebut. Klik save untuk menyimpan atau cancel untuk membatalkan. Gambar Open excel file dari Surat Pengadaan Box

199 274 Gambar Excel file dari Surat Pengadaan Box Submenu kedua dari menu Box ialah Received, dimana setelah super user mendapatkan box yang diminta dari vendor, super user akan mengisi atau mendaftarkan detail dari box tersebut di form ini. Gambar Form Received Box pada Box Page (Super User)

200 275 Pilih tipe penerimaan box, menambah box baru (add) atau pinjam box sementara dari vendor (borrow from vendor), lalu masukkan kode box tersebut, kode cabang disusul dengan kode unik yang diberikan oleh vendor. Jika format kode box yang dimasukkan tidak lengkap, dan super user telah klik submit, maka akan muncul alert box seperti berikut: Gambar Alert Box di Form Received Box jika format kode box yang dimasukkan tidak lengkap Jika kode box benar dan super user klik submit, maka kode dan status box tersebut akan disimpan di database dan akan muncul success response di Home Page Submenu ketiga dari menu Box ialah Edit Box, dimana super user dapat mengubah kode box yang telah didaftarkan sebelumnya di submenu Received Box.

201 276 Gambar Form Edit Box pada Home Page (Super User) Klik submit untuk menyimpan perubahan dan success response akan muncul di Home Page Super User. Issued Box merupakan submenu keempat dari menu Box, dimana super user dapat mengirimkan box yang telah terisi penuh dengan dokumen ke vendor atau memusnahkan box yang sudah berumur 8 tahun. Gambar Form Issued Box pada Box Page (Super User)

202 277 Pilih tipe issued yang diinginkan, Send to Vendor atau Destroy, lalu centang box yang diinginkan dari semua list box yang ada di cabang tersebut. Super User juga dapat memberi pesan kepada vendor di input box comment. Jika tidak ada box yang dicentang namun super user telah klik submit, maka akan muncul alert box yang meminta untuk memilih setidaknya 1 box. Gambar Alert Box untuk memilih setidaknya 1 box yang diinginkan di submenu Issued Box Jika minimal salah satu box dicentang dan super user klik submit, maka status box yang baru tersebut akan disimpan di database dan akan muncul success response di Home Page. Submenu kelima di menu Box ialah Print. Klik next, maka akan muncul 2 pilihan print, yaitu Print Register Arsip dan Print Peminjaman Box.

203 278 Gambar Submenu Print Box pada Box Page (Super User) Defaultnya adalah Print Register Arsip. Klik next untuk masuk ke form print arsip. Maka akan muncul tampilan sebagai berikut: Gambar Print Register Arsip pada Submenu Print Box Maka semua box yang masih ada di cabang jeffry.tani (memiliki status Cabang ) akan ditampilkan dan super user dapat menekan button Print Register Arsip untuk mencetak isi dari box tersebut seperti jumlah dokumen dalam box dan nama dokumendokumennya. Setelah klik button tersebut, excel file akan otomatis terbuka, dan super user dapat membuka atau menyimpan file excel tersebut.

204 279 Gambar Open excel file dari Surat Register Arsip Gambar Excel File dari Surat Register Arsip Jika super user memilih Print Peminjaman Box dan klik next, maka form print peminjaman box akan ditampilkan, sebagai berikut:

205 280 Gambar Print Peminjaman Box pada Submenu Print Box List box yang ada di vendor akan ditampilkan dan Super user dapat mencentang box yang ingin dipinjam dari vendor. Super user juga dapat menulis deskripsi dari box yang ingin dipinjam lalu klik button print peminjaman box untuk membuka surat peminjaman box tersebut dalam bentuk excel. Perlu diingat bahwa harus ada minimal 1 box yang dicentang sebelum klik button print. Jika tidak, akan muncul alert box berikut : Gambar Alert Box untuk memilih setidaknya 1 box yang diinginkan di submenu Print Peminjaman Box

206 281 Jika super user memilih minimal 1 box dan klik button print peminjaman box, maka excel file akan otomatis terbuka, dan super user dapat membuka atau menyimpan file excel tersebut. Gambar Open excel file dari Surat Peminjaman Box

207 282 Gambar Excel File dari Surat Peminjaman Box Submenu keenam pada menu Box ialah Status, dimana super user dapat melihat semua status dari box yang ada pada cabangnya. Ada 4 status box saat ini: Cabang, jika box tersebut telah didaftarkan di submenu Received Box dan masih berada pada cabang, Sent To Vendor jika box telah dikirim ke vendor untuk disimpan atau dihancurkan (pada submenu Issued Box), Borrow From Vendor jika box tersebut sedang dipinjam dari vendor dan berada di cabang sementara, Destroyed jika box tersebut telah dihancurkan oleh vendor dan setelah statusnya diupdate di submenu Issued Box. Gambar Submenu Status Box pada Box Page (Super User)

208 283 Submenu terakhir yang dapat dipilih oleh Super User ialah Delete Box, dimana semua list box yang berada di cabang akan ditampilkan, dan super user dapat memilih box mana yang ingin dihapus. Gambar Submenu Delete Box pada Box Page (Super User) Minimal salah satu box harus dipilih sebelum menekan button submit. Jika tidak, akan muncul alert box yang meminta super user memilih minimal 1 box. Jika box yang ingin dihapus sudah dipilih dan button delete diklik, maka akan muncul alert box yang meminta konfirmasi super user. Klik ok untuk menghapus dan cancel untuk membatalkan.

209 284 Gambar Alert box yang meminta konfirmasi Super User pada submenu Delete Box Perlu diperhatikan bahwa box yang masih memiliki dokumen di dalamnya tidak dapat dihapus. Jika klik delete pada box tersebut, maka akan muncul error message seperti ini: Gambar Error message yang muncul saat akan melakukan Delete Box Petunjuk Pemakaian Sistem User Pada halaman login, login sebagai user, maka akan tampil user page dengan 3 menu di samping kiri sama seperti di Super User page. Namun, user tidak memiliki privilege untuk mengakses ketiga menu ini kecuali admin mengubah privilege dari role user.

210 285 Gambar Error message ketika user memilih salah satu dari menu User, Document, atau Box Jadi, user hanya memiliki privilege untuk mencari dan melihat detail dari dokumen yang berada pada cabangnya. Lakukan pencarian pada fitur searching di bagian atas, baik dengan memasukkan keyword dari dokumen atau range tanggal upload dokumen. Klik icon search untuk menampilkan search result. Gambar Search Result pada User Page Klik nama dokumen pdf yang diinginkan untuk membuka dokumen pdf tersebut atau klik button view detail untuk melihat tipe dokumen

211 286 Gambar View Detail Page dari dokumen yang dicari user Fitur searching pada user berbeda dengan super user dimana user tidak dapat mengedit atau melakukan perubahan pada dokumen. Hal ini ditandai dengan availability dari pengisian pada input box seperti gambar di atas. Semua user (admin, super user, dan user) dapat langsung memilih Log Out di atas kanan Home Page untuk kembali ke halaman Login. 4.4 Evaluasi Uji Integrity Rules Uji integrity rules dilakukan dengan pengujian terhadap Domain Integrity, Entity Integrity, References Integrity pada basis data yang telah dirancang. 1. Domain Integrity Uji ini dilakukan dengan memeriksa apakah nilai atribut yang dihasilkan sesuai dengan domain yang telah ditentukan sebelumnya. Hal-hal yang diuji antara lain:

212 287 a. Domain attribute primary key pada entitas Document diawali dengan D diikuti dengan kode cabang (5 digit), kode tahun (2 digit), nomor urut (maksimum 4 digit), dan kode tipe dokumen (3digit). Contoh: D T01 b. Domain attribute primary key pada entitas Box diawali dengan B diikuti dengan kode cabang (5 digit), kode tahun (2 digit), dan nomor urut (maksimum 3 digit). Contoh: B c. Hasil evaluasi domain integrity menunjukkan bahwa seluruh table yang diuji telah memiliki domain integrity yang tepat. 2. Entity Integrity Pengujian dilakukan dengan menguji semua entitas dan memastikan bahwa tidak ada atribut dari suatu primary key yang bernilai NULL dan tidak ada 2 record yang sama pada primary key pada strong entity. 3. References Integrity Pengujian dilakukan terhadap hubungan primary key dan foreign key dari entitas-entitas yang berhubungan, apakah nilai foreign key telah sesuai dengan primary key table yang terhubung. Hasil evaluasi domain integrity, entity integrity, dan references integrity membuktikan bahwa seluruh table telah layak uji.

213 Uji Security Uji security dilakukan untuk menguji apakah seluruh entitas memiliki mekanisme keamanan yang baik sehingga tidak terjadi penyimpangan atau penyalahgunaan data. Mekanisme keamanan yang telah ada pada aplikasi antara lain: a. User tidak dapat mengakses dan melakukan perubahan atau transaksi tanpa memasukkan username dan password yang benar di halaman login. b. Setiap user memiliki privilege atau hak akses dari role-nya masing-masing, yang hanya dapat ditentukan oleh pihak Admin Uji Aplikasi Evaluation by Performance Untuk uji performance pada aplikasi document imaging ini, digunakan aplikasi firebug yang ada pada Mozilla Firefox, yang berfungsi untuk menilai performa speed, tampilan, dan lain-lain yang akan ditampilkan pada lampiran.

214 289 Gambar Hasil Evaluasi Menggunakan Menu Page Speed pada Firebug di halaman Login Page Hasil dari evaluasi menggunakan menu Page Speed pada Firebug menampilkan nilai performa pada page tersebut. Semakin tinggi nilai tersebut, semakin bagus performa pada halaman page tersebut. Login Page mendapatkan nilai 77 dari 100. Aplikasi ini menunjukkan penyebab-penyebab dari nilai yang tidak sempurna. Seperti yang dilihat di gambar, adanya masalah pada Enable Compression. Selain menunjukkan penyebabnya, aplikasi ini juga menampilkan cara untuk memperbaiki masalah tersebut. Untuk Login Page ini, cara memperbaiki masalah pada Enable Compression adalah dengan melakukan compressing pada file jquery.js dan style.css yang merupakan bagian dari aplikasi.

215 290 Menu Page Speed pada Firebug menilai per halaman, jadi untuk setiap halaman pada aplikasi memiliki nilai yang berbeda-beda. Berikut adalah screenshot dari beberapa halaman yang di evaluasi menggunakan menu Page Speed pada Firebug. Gambar Hasil Evaluasi Menggunakan Menu Page Speed pada Firebug saat open new tab ketika ingin melihat isi dari document

216 291 Gambar Hasil Evaluasi Menggunakan Menu Page Speed pada Firebug di halaman Search Result Selain menggunakan menu Page Speed yang ada pada Firebug, penulis juga menggunakan menu YSlow pada Firebug. Perbedaan dari Page Speed dengan YSlow adalah dari scope-nya. YSlow menilai dari seluruh page pada aplikasi sehingga nilai yang dihasilkan adalah nilai dari rata-rata dari seluruh page. Berikut adalah screenshot dengan menggunakan YSlow.

217 292 Gambar Hasil Evaluasi Menggunakan Menu YSlow pada Firebug Hasil evaluasi dari aplikasi document imaging adalah sebagai berikut: 1. Kelebihan a. Pencarian dokumen dapat dilakukan dalam waktu yang jauh lebih singkat dan tepat. b. Aplikasi dapat secara otomatis menghasilkan memo transaksi untuk manajemen box dalam bentuk excel file seperti memo pengadaan box, memo penghancuran box, dan lain-lain. c. Seluruh data pada dokumen telah terintegritas dan tersentralisasi dalam penyimpanan basis data berbasis web yang terstruktur d. Interface yang user-friendly dan mudah digunakan oleh user.