BAB 2 
                                                          Landasan Teori 
                                                                     
                                                                     
                  2.1  Teori Umum 
                       2.1.1 Waterfall Model 
                         Software  Develoment  Life  Cycle  (SDLC)  merupakan  siklus  pengembangan 
                  aplikasi  yang  meliputi  prosedur  dan  langkah-langkah  yang  membimbing  suatu 
                  proyek  secara  teknis  dari  awal  sampai  akhir.  Secara  garis  besar  tahapan  dibagi 
                  menjadi empat kegiatan utama, yaitu analisis, desain, impelemtasi, dan perawatan. 
                  Software yang dikembangkan berdasarkan SDLC akan menghasilkan sistem dengan 
                  kualitas yang tinggi, memenuhi harapan penggunanya, tepat dalam waktu dan biaya, 
                  bekerja dengan efektif dan efisien dalam infrastruktur teknologi informasi yang ada 
                  atau  yang  direncanakan,  serta  murah  dalam  perawatan  dan  pengembangan  lebih 
                  lanjut (Pressman, 2010,p46). 
                           SDLC memiliki banyak bentuk model, salah satu yang terkenal dan sering 
                  dipakai adalah model waterfall. Model waterfall diagram prosesnya mirip dengan air 
                  terjun yang bertingkat dapat dilihat pada gambar 2.3 yang meliputi tahapan - tahapan 
                  sebagai berikut : 
                    1.   Perancangan Sistem (Sistem Engineering) 
                         Perancangan sistem diperlukan untuk bagian dari suatu sistem yang lebih besar 
                         nantinya  Pembuatan sebuah piranti lunak dapat dimulai dengan melihat dan 
                         mencari apa yang dibutuhkan oleh sistem. Dari kebutuhan sistem tersebut akan 
                         diterapkan kedalam piranti lunak yang dibuat. 
                    2.   Analisa Kebutuhan Piranti Lunak (Software Requirement Analysis) 
                         Merupakan proses pengumpulan kebutuhan piranti lunak. Untuk memahami 
                         dasar dari program yang akan dibuat, seorang analisis harus mengetahui ruang 
                         lingkup informasi, fungsi-fungsi  yang dibutuhkan, kemampuan kinerja yang 
                         ingin dihasilkan dan perancangan antarmuka pemakai piranti lunak tersebut. 
                    3.   Perancangan (Design) 
                         Perancangan piranti lunak terbagi atas 4 tahapan penting, yaitu: Struktur data, 
                         arsitektur piranti lunak, detil prosedur, dan karakteristik user interface. 
                                                                   9 
                   
                            10 
                             
                              4.   Pengkodean (Coding) 
                                   Pengkodean  piranti  lunak  merupakan  proses  penulisan  kedalam  bahasa 
                                   pemograman agar piranti lunak tersebut dapat digunakan oleh mesin. 
                            5.     Pengujian (Testing) 
                                    Proses ini akan menguji kode program yang telah dibuat dengan memfokuskan 
                                    pada bagian dalam piranti lunak. Tujuannya untuk memastikan bahwa semua 
                                    pernyataan telah diuji dan memastikan juga bahwa input yang digunakan akan 
                                    menghasilkan output yang sesuai. Pada tahap ini pengujian ini dibagi menjadi 
                                    dua bagian, pengujian internal dan pengujian eksternal. 
                            6.     Pemeliharaan (Maintenance) 
                                    Proses ini dilakukan setelah piranti lunak telah digunakan oleh user. Suatu 
                                    Perubahan  akan  dilakukan  jika  terdapat  kesalahan  dan  penyesuaian  akan 
                                    perubahan kebutuhan yang diinginkan user.  
                                        
                                        
                                        
                                        
                                        
                                        
                                        
                                                     Gambar 2.1 Model waterfall (Pressman, 2012:39) 
                                                                                   
                                 2.1.2 Unified Modelling Language 
                                          Menurut  Pressman  (2012,  p987)  Unified  Modeling  Language  (UML) 
                                 adalah bahasa standar untuk penulisan cetak biru perangkat lunak. UML dapat 
                                 digunakan       untuk     memvisualisasikan,        menentukan  mengonstruksi,  dan 
                                 mendokumentasikan  artifak  –  artifak  suatu  sistem.  Grady  Booch,  Jim 
                                 Rumbaugh, dan Ivar Jacobson mengembangkan UML pada pertengahan 1990-an 
                                 dengan banyak umpan balik dari komunitas pengembangan perangkat lunak. 
                                 UML menggabungkan sejumlah notasi pemodelan yang saling bersaing, yang 
                                 digunakan oleh industri perangkat lunak saat itu.  
                                          UML memberikan 13 diagram yang berbeda – beda untuk digunakan 
                                 pada  pemodelan  perangkat  lunak,  tetapi  tidak  semua  perlu  digunakan.  UML 
                                 yang dipakai hanya yang sesuai dengan kebutuhan dari pengembangan software. 
                                                                               
                             
                                                                                                                          11 
                    
                                  Tujuan penggunaan UML: 
                                  a) Membuat  bahasa  pemodelan  visual  yang  ekspresif  dari  berbagai 
                                     bahasa pemrograman dan proses rekayasa untuk mengembangkan dan 
                                     saling menukar model dengan mudah dan dimengerti secara umum. 
                                  b) Sebagai cetak biru (blue print) karena lengkap dan detail. 
                                      
                          2.1.2.1 Use Case Diagram 
                                  Use  case  diagram  merupakan  diagram  yang  menggambarkan 
                          fungsionalitas dan fitur – fitur perangkat lunak dari perspektif pengguna. Use 
                          Case  menggambarkan  bagaimana  seorang  pengguna  berinteraksi  dengan 
                          sistem  dengan  cara  menentukan  langkah  –  langkah  yang  diperlukan  untuk 
                          mencapai suatu tujuan tertentu (Pressman, 2012:993). 
                                  Dalam Use Case Diagram terdapat dua komponen utama, yaitu : 
                                  a)  Actor. 
                                     Actor menggambarkan orang atau pelaku yang menggunakan sistem. 
                                     Actor memberi input atau menerima sebuah informasi. Tidak boleh 
                                     ada komunikasi langsung antar aktor.  
                                  b) Use Case 
                                     Use case biasanya menggunakan kata kerja dan menggambarkan apa 
                                     yang dapat dilakukan oleh sebuah pelaku atau sistem. Gambar use 
                                     case berbentuk elips mendatar.  
                                                                                  
                          2.1.2.2 Class Diagram 
                                  UML menyediakan diagram kelas (class diagram) untuk memodelkan 
                          kelas – kelas, termasuk atribut – atribut, operasi – operasi, dan hubungan serta 
                          asosiasinya  dengan  kelas  –  kelas  lain.  Class  diagram  menyediakan  sudut 
                          pandang  statik  atau  struktural  dari  suatu  sistem.  Diagram  kelas  tidak 
                          menunjukkan sifat dinamis dari komunikasi – komunikasi antara objek – objek 
                          kelas pada diagram. 
                                  Berikut ini simbol yang dipakai pada class diagram: 
                            a.       Classes 
                                     Diilustrasikan dengan persegi panjang yang dibagi menjadi beberapa 
                                     komponen. Pada bagian pertama mengenai nama class, pada bagian 
                                                                         
                    
                            12 
                             
                                             kedua mengenai attribut yang dipakai dalam class tersebut dan bagian 
                                             ketiga berisi tentang operasi yang dapat dikerjakan oleh class tersebut. 
                                             (Pressman, 2010:842) 
                                     b.      Associations 
                                             Simbol ini digunakan untuk mewakili hubungan yang statis diantara 
                                             class  yang  ada.  Nama  association  diletakan  pada  atas  atau  bawah 
                                             garis. Untuk memberi arah dalam hubungan antar class menggunakan 
                                             tanda  panah  dan  roles  diletakan  di  akhir  association.  Roles 
                                             menerangkan  bagaimana  cara  dua  class  saling  berhubungan. 
                                             (Pressman, 2010:844) 
                                     c.      Visibility  
                                             Simbol visibility digunakan pada atribut dan operator di dalam class. 
                                             Visibility  untuk memberi informasi mengenai hak akses dari atribut 
                                             dan  operasi  yang  bersangkutan.  (Pressman,  2010:843).  Ada  tiga 
                                             simbol visibility antara lain: 
                                     d.      Multiplicity 
                                             Notasi ini diletakan dekat association. Simbol ini menunjukan jumlah 
                                             instance dari satu class yang dihubungkan dengan class yang lainnya. 
                                             (Pressman, 2010:844). Ada lima simbol yang digunakan antara lain: 
                                     e.      Composition dan Aggregation 
                                             Composition  adalah  simbol  khusus  dari  aggregasi.    Simbol  ini 
                                             digunakan pada saat objek dari suatu class berisi objek dari class yang 
                                             lain. Objek ini akan ada jika objek yang lain ada atau dengan kata lain, 
                                             objek  di  satu  class  bergantung  pada  objek  di  class  yang  lainnya. 
                                             Aggregation  adalah  simbol  khusus  dari  asosasi.  Simbol  ini 
                                             mempunyai  hubungan  dengan  class  yang  lainnya  dan  objek  yang 
                                             menggunakan simbol ini akan tetap ada walaupun objek  yang lain 
                                             tidak ada. (Pressman, 2010:845) 
                                     f.      Generalization 
                                             Simbol ini disebut juga dengan turunan atau inheritance. Simbol ini 
                                             menunjukan hubungan atara dua class dimana salah satu dari class 
                                             tersebut  merupakan  spesialisasi  dari  yang  lainnya.    (Pressman, 
                                             2010:843)