Unified Modelling Language (UML)

Unified Modelling Language (UML)

UML itu singkatan dari Unified Modelling Language. Sesuai dengan kata terakhir dari kepanjangannya, UML itu adalah salah satu bentuk language atau bahasa. Menurut pencetusnya, UML di definisikan sebagai bahasa visual untuk menjelaskan, memberikan spesifikasi, merancang, membuat model, dan mendokumentasikan aspek-aspek dari sebuah system.

Karena tergolong bahasa visual, UML lebih mengedepankan penggunaan diagram untuk menggambarkan aspek dari system yang sedang dimodelkan. Memahami UML itu sebagai bahasa visual itu penting, karena penekanan tersebut membedakannya dengan bahasa pemrograman yang lebih dekat ke mesin. Bahasa visual lebih dekat ke mental model pikiran kita, sehingga pemodelan menggunakan bahasa visual bisa lebih mudah dan lebih cepat dipahami dibandingkan apabila dituliskan dalam sebuah bahasa pemrograman.

Pada tahun 2002 lahir UML versi 2.0, menjadi 13 buah diagram, dengan penambahan dan penggantian yaitu :

1. Use case diagram

2. Activity diagram

3. Sequence diagram

4.Communication Diagram (Collaboration diagram in versi 1.x)

5. Class diagram

6.State Machine Diagram (Statechart diagram in versi 1.x)

7. Component diagram

8. Deployment diagram

9. Composite Structure Diagram

10. Interaction Overview Diagram

11. Object Diagram

12. Package Diagram

13. Timing Diagram

1. Use Case Diagram

Pengertian :

● Use case class digunakan untuk memodelkan dan menyatakan unit fungsi/layanan yang disediakan oleh sistem (or bagian sistem: subsistem atau class) ke pemakai.
● Use case dapat dilingkupi dengan batasan sistem yang diberi label nama sistem.
● Use case adalah sesuatu yang menyediakan hasil yang dapat diukur ke pemakai atau sistem eksternal.

Karakteristik :

– Use cases adalah interaksi atau dialog antara sistem dan actor, termasuk pertukaran pesan dan tindakan yang dilakukan oleh sistem.

- Use cases diprakarsai oleh actor dan mungkin melibatkan peran actor lain. Use cases harus menyediakan nilai minimal kepada satu actor.

- Use cases bisa memiliki perluasan yang mendefinisikan tindakan khusus dalam interaksi atau use case lain mungkin disisipkan.

-  Use case class memiliki objek use case yang disebut skenario. Skenario menyatakan urutan pesan dan tindakan tunggal.

Komponen Pembentuk Use Case Diagram :

1. Actor
 Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat terciptanya suatu use case diagram diperlukan beberapa actor. Actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima, dan memberi informasi pada sistem. Actor hanya berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case. Actor digambarkan dengan stick man . Actor dapat digambarkan secara secara umum atau spesifik, dimana untuk membedakannya kita dapat menggunakan relationship.

Ciri – ciri :

·                     Actor dideskripsikan menggunakan kata benda.

·                     Dapat (bukan harus) melakukan inisiasi terhadap use case.

·                     Actor tidak harus orang, dapat saja sistem, atau entitas yang berhubungan dengan sistem tetapi berasal dari luar sistem.

·                     1 Actor dapat berinteraksi dengan beberapa use case

2. Use Case

Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga customer atau pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun. Ciri – ciri :

·                     Use Case dideskripsikan menggunakan kombinasi kata kerja dan kata benda.

·                     Use Case tidak dapat di-inisiasi oleh dirinyya sendiri.

Catatan : Use case diagram adalah penggambaran sistem dari sudut pandang pengguna sistem tersebut (user), sehingga pembuatan use case lebih dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan kejadian.

Cara menentukan Use Case dalam suatu sistem:

a. Pola perilaku perangkat lunak aplikasi.

b. Gambaran tugas dari sebuah actor.

c. Sistem atau “benda” yang memberikan sesuatu yang bernilai kepada actor.

d. Apa yang dikerjakan oleh suatu perangkat lunak (*bukan bagaimana cara mengerjakannya).

Relasi dalam Use Case

Ada beberapa relasi yang terdapat pada use case diagram:

1. Association, menghubungkan link antar element.

2. Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya.

3. Dependency, sebuah element bergantung dalam beberapa cara ke element lainnya.

4. Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya.

Tipe relasi/ stereotype yang mungkin terjadi pada use case diagram:

1. <<include>> , yaitu kelakuan yang harus terpenuhi agar sebuah event dapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya.

2. <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti menggerakkan alarm.

3. <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan asosiasinya adalah communicates association . Ini merupakan pilihan selama asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.

2. Activity diagram

Activity diagram memiliki pengertian yaitu lebih fokus kepada menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses. Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis. Memiliki struktur diagram yang mirip flowchart atau data flow diagram pada perancangan terstruktur. Memiliki pula manfaat yaitu apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan. Dan activity dibuat berdasarkan sebuah atau beberapa use case pada use case diagram.

Contoh activity Diagram :

Diagram Pendaftaran

Logika untuk table pendaftaran yaitu Siswa harus mendaftar terlebih dahulu kepada petugas, kemudian petugas registrasi dan membuatkan kartu untuk siswa tersebut, setelah kartu tersebut di buat maka siswa tersebut mendapatkan kartu dan syah menjadi anggota.

Diagram Peminjaman

Untuk diagram peminjaman anggota harus membawa kartu jika ia ingin meminjam buku, kemudoan kartu tersebut diserahkan kepasa petugas, dan petugas mengecek kartu tersebut dan mengecek buku yang ingin di pinjam oleh anggota tersebut jika anggota tersebut memenuhi syarat-syarat untuk meminjam buku maka anggota berhak menerima buku tersebut dan jika tidak memenuhi syarat-syaratnya maka anggota tidak menerima buku yang akan ia pinjam.

Diagram Pengembalian

Pada table pengembalian buku anggota harus membawa kartu untuk diserahkan kepada petugas, kemudian petugas mengecek validasi data dan cek buku maksudnya mengecek tanggal berakhirnya buku tersebut di kembalikan, jika melewati batas waktu yang ditentukan maka anggota tersebut harus membayar denda dan denda tersebut ditentikan oleh petugas. Anggota menerima jumlah denda yang sudah ditentukan oleh petugas dan jumlahnya tergantung validasi data yang diterima petugas. Jika anggota tersebut tidak terlambat mengembalikan buku maka anggota tersebut tidak dikenai denda.

3. Sequence diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.

Komponen utama dari sequence diagram terdiri atas obyek yang dituliskan dengan kotak segi empat bernama. Message diwakili garis dengan tanda panah dan waktu yang ditunjukan dengan progress vertical.

4. Class Diagram

Salah satu dari diagram UML yang digunakan untuk, perancangan sistem berbasis iterasi adalah Class Diagram. Dalam penjelasan teori tentang PBO, class diagram paling banyak digunakan, selain itu class diagram menjadi bagian dari static view pada perancangan sistem dengan memanfaatkan konsep forward or reserve.

Pada perancangan sistem yang menggunakan Class Diagram, mempunyai komponen-komponen yang berupa class dan interface beserta atributnya, operasi dari sistem, relasi dan constraint yang menghubungkan antar obyek. Selain itu class diagram memilki 3 unsur yaitu nama, atribut dan metoda. Atribut dan metoda memilik salah sifat public, private atau protected.

Private berarti sebuah class tidak dapat digunakan/ dipanggil dari luar class yang bersangkutan, sifat ini berlawanan dengan sifat public, dimana sebuah class dapat dipanggil oleh siapa saja. sedangkan protected berarti private dan hanya dapat dipanggil oleh kelas yang mewarisinya.

Class juga memiliki 3 area pokok (utama) yaitu : nama,atribut,dan operasi. Nama berfungsi untuk member identitas pada sebuah kelas, atribut fungsinya adalah untuk member karakteristik pada data yang dimiliki suatu objek di dalam kelas, sedangkan operasi fungsinya adalah memberikan sebuah fungsi ke sebuah objek . Dalam mendefinisikan metode yang ada di dalam kelas harus diperhatikan yang namanya Cohesion dan Coupling, Cohesion adalah ukuran keterkaitan sebuah instruksi di sebuah metode, Coupling adalah ukuran keterkaitan antar metode. Di dalam class diagram terdapat hubungan antar kelas secara konseptual, yang disebut Relasi antar Class, di UML disediakan macam-macam relasi antar Class, diantaranya: Asosiasi (Hubungan statis antar kelas), Agregasi (hubungan dari keseluruhan objek), Generalisasi (relasi beberapa subkelas ke super kelas), Dependency (keterhubungan tiap kelas.)

Atribut sebuah class memiliki bentuk umum penulisan

visibility name : type multiplicity = default{property-string}

Contoh + nama: String [10] = "Untitled" {readOnly}, memilki arti bahwa atribut tersebut public karena, + berarti public, - berarti private, # berarti protected, “Untitled” adalah nilai yang diberikan secara default jika tidak ditentukan saat objek dibuat, {readOnly} adalah properti tambahan dari atribut, dimana disini berarti tidak bisa dimodifikasi. Multiplicity memilki kemiripan relasi one to one dalam Entity Relathionship Digram yang menjelaskan berapa banyak obyek yang mengisi poperti ( 0,1 atau ...n)

Class yang dibuat berdasarkan analisa sistem memiliki hubungan dengan class yang lainnnya dalam sebuah class diagram, relasi atau hubungan itu antara lain Asosiasi(hubungan statis antar class), Agregasi(hubungan yang menyatakan bagian dari), Pewarisan(hubungan hirarkies antar class), Hubungan dinamis(rangkaian pesan yang dikrimkan antar class).

5. Communication diagram (Collaboration diagram in versi 1.x)

Communication diagram : memfokuskan pada komunikasi yang berhubungan dengan struktur dari objek yang terlibat dalam suatu tugas. Communication diagram bersama dengan sequence diagram adalah termasuk dalam diagram interaksi.

Collaboration diagram mirip dengan sequence diagram dalam hal tujuan yang ini dicapai; yaitu untuk menunjukkan interaksi dinamis dari obyek-obyek yang ada dalam suatu sistem. Yang membedakan collaboration diagram dari yang lain adalah diagram itu menunjukkan obyek-obyek dan asosiasi dengan obyek-obyek yang lain dalam sistem bersamaan dengan interaksinya. Asosiasi ini tidaklah dijelaskan dalam sequence diagram.

Suatu Collaboration diagram dengan mudah dapat direpresentasikan dengan obyek-obyek modelling dan asosiasi antar objek-objek tersebut yang berupa link-link (hubungan-hubungan). Interaksi antar objek ditunjukkan dengan anak panah. Dan untuk menunjukkan urutan dari mana objek ini berawal maka diberikan petunjuk yang berupa angka-angka.

Elemen-elemen dari suatu collaboration diagram:

Perbandingan dengan sequence diagram

Sequence diagram hanya menunjukkan objek-objek dan pesan-pesan yang ikut serta dalam interaksi tersebut serta urutan prosesnya. Tetapi tidak menunjukkan hubungan diantara objek-objek yang ada.

Collaboration diagrams biasa digunakan untuk:
Menyediakan suatu birds-eye view / helicopter view (pandangan menyeluruh) dari obyek-obyek yang berkolaborasi dalam suatu lingkungan yang nyata

·                     Mengalokasikan fungsionalitas ke kelas-kelas dengan cara menjabarkan kebiasaan-kebiasaan yang terjadi dalam suatu sistemMembuatkan suatu model dari logika dari penerapan operasi yang kompleks, khususnya yang memiliki interaksi dengan obyek-obyek yang berjumlah banyak

Membuat  satu Collaboration Diagram
Ketika kita membuat suatu Collaboration diagram, kita harus menempatkan obyek-obyek paling penting yang berkenaan dalam kolaborasi tersebut pada tengah-tengah dari diagram. Ini akan membantu menciptakan suatu stage / panggung / gambaran jelas dari yang secara jelas menunjukkan relasi antara obyek-obyek yang berkolaborasi.

Ketika mendesain collaboration diagram dari scratch (nol) daripada membuatnya secara otomatis dari sequence diagram, maka langkah-langkah dasar berikut harus dilakukan:

1. Tentukan scope / cakupan dari diagram tersebut. Sebagaimana dengan sequence diagram, cakupan dari suatu collaboration diagram dapat berperanan. 
2. Tempatkan obyek-obyek yang berpartisipasi dalam collaboration pada diagram. Ingatlah untuk menempatkan obyek-obyek paling penting sebisa mungkin mengarah pada tengah-tengah dari diagram. Bila suatu obyek tersebut memiliki properti atau menjaga suatu kondisi yang penting pada kolaborasi itu, maka tentukan lah nilai awal dari properti atau kondisi tersebut. 
3. Ciptakan link-link (hubungan) diantara obyek-obyeK.
4. Ciptakan message-message yang terasosiasikan dengan tiap link-nya. 
5. Tambahkanlah nomor urutan dari tiap message yang terkorespondensi pada urutan waktu dari message-message yang ada dalam kolaborasi tersebut.

Contoh kasus dalam bentuk yang lebih mudah:

Aktor-Aktor yang ikut andil:

    

Collaboration diagram yang terbentuk:

 

6.State Machine Diagram (Statechart diagram in versi 1.x)

Statechar Diagram menggambarkan semua satate(kondisi) yang dimiliki oleh suatu object dari suatu class dan keadaaan yang menyebabkan state berubah. kejadian dapat berupa object lian yang mengirim pesan. state class tidak digambarkan untuk semua class, hanya yang mempunyai sejumlah state yang terdefinisi dengan baik dan kondisi class berubah oleh state yang berbeda. Statechar diagram khususnya digunakan untuk memodelkan tarap-tarap diskrit dari sebuah siklus hidup objek, sedangakan activity diagram paling cocok di gubakan untuk memodelkan urutan aktivitas dalam suatu proses.

7. Component diagram

Componen Diagram dapat diartikan sebagai berikut :

·         Component diagram menggambarkan struktur dan hubungan antar komponen peranti lunak, termasuk ketergantungan (dependency) diantaranya.

·          Komponen peranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time maupun run time.

·         Pada umumnya komponen terbentuk dari bebrapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil.

·          Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.

Bentuk-bentuk component ada 3 yaitu:

1.       Deployment Component: Yang menjadi basis dari executable system. Contoh deployment component diantaranya: DAN LAIN-LAIN(Dynamic Library Link) file exe, Active X Control, Java Bean dan lain-lain.

2.       Work Product Component: Yaitu file-file yang dibutuhkan untuk pembuatan deployment component. Contoh untuk component kedua ini diantaranya file data, file source code dan lain-lain.

3.       Execution Component: Yang dibuat sebagai hasil dari sistem yang akan dijalankan.

Menurut Fowler(2004) hal penting pada component adalah component mewakili potongan-potongan yang independen yang bisa dipesan dan diperbaharui sewaktu-waktu. Dengan demikian, pembagian sistem kedalam component-component lebih banyak didorong oleh kepentingan marketing dari pada kepentingan teknis. Meskipun demikian harus juga diingat bahwa terlalu banyak component juga kurang bagus, karena susah mengatur dan memeliharanya khususnya yang menyangkut masalah versioning.

 Beberapa tipe komponen sebagai berikut :

a. Komponen

Notasi-notasi komponen mempresentasikan module perangkat lunak dengan sebuah antar muka yang di Devinisikan dengan baik. Para spesifikasi komponen, kita dapat menspesifikasi tipe komponen dalam kolom stereotype( Active X, Applet, Aplikasi, DLL, Executable). Dalam UML, notasi keadaan digambarkan sebagai berikut.

  

b. Subprogram specification and Body

Notasi ini mempresentasikan spesifikasi subprogram yang terlihat dan bagian implementasi. Subprogram secara tipikal adalah kumpulan beberapa subroutine. Subprogram tidak berisi devinisi kelas.

 

c.       Main program

Notasi ini mempresentasikan program utama. Program utama adalah berkas yang berisi root program. Contoh, pada power builder, ada berkas yang berisi obyek Aplikasi.

 

8. Deployment Diagram

Menggambarkan arsitektur fisik dari perangkat lunak sistem dan perangkat keras, menunjujkkan hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis hubungannya. di dalam nodes, executable dan object yang dialokasikanuntuk memperlihatkan unit perangkat lunak yang dieksekusi oleh node dan ketergantungan komponenDeployment diagram yang jika diartikan dalam bahasa Indonesia berarti diagram pendistribusian. Berarti bagaimana caranya kita mempermudah user bila ingin menggunakan sistem yang kita buat, bagian apa dan dimana kita pasang, apakah ada server khusus baik server database maupun web server? Diagram yang satu ini masih masuk dalam kategori statis.

Obyek sejenis dikumpulkan dalam satu class, class-class dalam satu bidang kerja, katakanlah satu transaksi (penjualan, pembelian dan lain-lain) dikelompokkan dalam satu package (paket) kemudian package-package itu dikelompokkan dalam satu component agar lebih memiliki dependency sehingga component yang rusak atau harus direvisi tinggal dicopot tanpa mengganggu kerja component lainnya.

Jika sistem yang kita buat harus didistribusikan dalam tiga sistem misalnya: database diletakkan di komputer khusus, demikian pula dengan server web dengan client lainnya maka deployment diagram akan sangat membantu dalam menjelaskan sistem yang kita buat kepada para stakeholder. Dalam literatur analisa dan disain sistem, stakeholder diartikan sebagai pihak-pihak yang berkepentingan dengan sistem yang kita buat dari pemilik perusahaan, analis sistem, programmer hingga user pengguna sistem. Model dan diagram UML yang kita buat ditujukan kepada mereka. 

9. Composite Structure Diagram

Composite structure diagram pada Unified Modeling Language (UML) adalah jenis diagram struktur statis, yang menunjukkan struktur internal kelas dan kolaborasi bahwa struktur ini memungkinkan.

Diagram ini dapat meliputi bagian internal, port melalui mana bagian berinteraksi satu sama lain atau melalui mana contoh kelas berinteraksi dengan bagian dan dengan dunia luar, dan konektor antara bagian-bagian atau port. Sebuah struktur komposit adalah seperangkat unsur yang saling berhubungan yang berkolaborasi Durasi untuk mencapai beberapa tujuan. Setiap elemen memiliki beberapa peran yang didefinisikan dalam kolaborasi.

10. Interaction Overview Diagram

Interaction Overview Diagram adalah salah satu dari tiga belas jenis diagram Unified Modeling Language (UML), yang dapat menggambarkan aliran kontrol dengan node yang dapat berisi diagram interaksi.

Interaction Overview Diagram mirip dengan diagram aktivitas baik memvisualisasikan urutan kegiatan. Perbedaannya adalah bahwa kegiatan individu dalam interaction overview diagram digambarkan sebagai frame, yang dapat berisi interaksi - atau diagram urutan. interaction/sequence diagrams yang dibangun dengan blok bangunan seperti: sequence, communication, interaction overview and timing diagram. Simpul dalam diagram menghubungkan urutan diagram, yang bisa menjadi tempat dalam urutan tertentu. Dengan elemen-elemen interaction overview diagram dapat digunakan untuk "mendekonstruksi skenario kompleks yang tidak akan membutuhkan jalan jika-maka-lain ganda untuk digambarkan sebagai sequence diagrams ".

Kecuali untuk kegiatan node elemen notasi lain untuk Interaction Overview Diagram adalah sama seperti untuk activity diagram, seperti awal, keputusan akhir,, menggabungkan, bercabang dan bergabung node. Kedua elemen baru dalam diagram interaksi ikhtisar adalah "kejadian interaksi" dan "unsur-unsur interaksi".

11. Object Diagram

Diagram objek ialah merupakan suatu diagram yang mengambarkan objek-objek dalam suatu system. Bila pada kelas diagram terdapat banyak relasi antar kelas, namun pada diagramobjek, hanya terdapat satu relasi antar kelas, yaitu asosiasi. Tidak hanya itu, pada diagram objek yang didefinisikan hanya nama objek dalam suatu kelas beserta atributnya saja, tanpa operasi yang dilakukan oleh objek tersebut. Diagram ini sering juga disebut sebagai Diagram Perintah, karena pada diagram ini perintah-perintahnya lebih ditonjolkan daripada kelasnya.

Penulisan nama pada objek diagram, bisa kita tulis nama kelasnya saja, tanpa diikuti nama objeknya. Jangan lupa, nama kelas awalnya harus ditulis dengan huruf capital.

12. Package Diagram

Package Diagram mengatur unsur-unsur sistem menjadi kelompok-kelompok terkait untuk meminimalkan ketergantungan

Simbol dan Notasi utama Diagram Package :

Paket
Gunakan folder tab untuk menggambarkan paket. Tuliskan nama paket pada tab atau di dalam folder. Serupa dengan kelas, Anda juga dapat membuat daftar atribut dari sebuah paket.

Visibilitas

Visibilitas menunjukkan siapa yang boleh mengakses informasi yang terkandung dalam sebuah paket. privavte visibilitas berarti bahwa atribut atau operasi tidak dapat diakses oleh hal di luar paket. Visibilitas publik memungkinkan atribut atau operasi untuk dilihat oleh paket-paket lain. Visibilitas Dilindungi menjadikan atribut atau operasi dapat dilihat oleh paket yang pemiliknya saja.

Dependensi
Dependensi mendefinisikan hubungan di mana perubahan satu paket akan mempengaruhi paket lain. Importing adalah jenis ketergantungan yang memberikan satu akses paket untuk isi paket lain.

13. Timing Diagram

Timing diagram dalam Unified Modeling Language 2.0 adalah suatu jenis diagram interaksi, di mana fokusnya adalah pada kendala waktu.

Timing Diagram digunakan untuk menyelidiki tingkah laku objek sepanjang periode waktu tertentu. Sebuah timing diagram merupakan berntuk khusus dari sequence diagram. Perbedaan antara timing diagram dan diagram sequence adalah sumbu dibalik sehingga waktu meningkat dari kiri ke kanan dan jalur hidup yang ditampilkan dalam ruang terpisah yang diatur secara vertikal.

                                                  

Timing diagram UML digunakan untuk menampilkan perubahan dalam keadaan atau nilai dari satu atau lebih elemen dari waktu ke waktu. Hal ini juga dapat menunjukkan interaksi antara peristiwa waktunya dan kendala waktu dan durasi yang mengaturnya.

WATERFALL PROCESS MODEL

Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. 

 Secara umum tahapan pada model waterfall dapat dilihat pada gambar berikut :



Gambar di atas adalah tahapan umum dari model proses ini. Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya.

 Berikut adalah penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman:

·         System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.

·         Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.

·         Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.

·         Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.

·         Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.

·         Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

Mengapa model ini sangat populer??? Selain karena pengaplikasian menggunakan model ini mudah, kelebihan dari model ini adalah ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di awal project, maka SE dapat berjalan dengan baik dan tanpa masalah. Meskipun seringkali kebutuhan sistem tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan sistem di awal project lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.

Meskipun demikian, karena model ini melakukan pendekatan secara urut / sequential, maka ketika suatu tahap terhambat, tahap selanjutnya tidak dapat dikerjakan dengan baik dan itu menjadi salah satu kekurangan dari model ini. 

Selain itu, ada beberapa kekurangan pengaplikasian model ini, antara lain adalah sebagai berikut:

·         Ketika problem muncul, maka proses berhenti, karena tidak dapat menuju ke tahapan selanjutnya. Bahkan jika kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul. Hal-hal seperti ini yang dapat membuang waktu pengerjaan SE.

·         Karena pendekatannya secara sequential, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya. Oleh karena itu, seringkali model ini berlangsung lama pengerjaannya.

·         Pada setiap tahap proses tentunya dipekerjakan sesuai spesialisasinya masing-masing. Oleh karena itu, ketika tahap tersebut sudah tidak dikerjakan, maka sumber dayanya juga tidak terpakai lagi. Oleh karena itu, seringkali pada model proses ini dibutuhkan seseorang yang “multi-skilled”, sehingga minimal dapat membantu pengerjaan untuk tahapan berikutnya.

tahapan-tahapan model ini sudah cukup baik dalam artian minimal untuk melakukan SE, maka harus ada tahapan-tahapan ini. Tahapan-tahapan ini jugalah yang digunakan oleh model-model yang lain pada umumnya. Ada filosofi yang mengatakan sesuatu yang sukses diciptakan pertama kali, maka akan terus dipakai di dalam pengembangannya. Hal ini juga berlaku pada waterfall model ini. Mungkin dapat dikatakan bahwa inilah standar untuk melakukan SE.

Akan tetapi, yang mungkin menjadi banyak pertimbangan mengenai penggunaan dari model ini adalah metode sequential-nya. Mungkin untuk awal-awal software diciptakan, hal ini tidak menjadi masalah, karena dengan berjalan secara berurutan, maka model ini menjadi mudah dilakukan. Sesuatu yang mudah biasanya hasilnya bagus. Oleh karena itu model ini sangat populer. Akan tetapi, seiring perkembangan software, model ini tentu tidak bisa mengikutinya. Yang menjadi kelemahan adalah pada pengerjaan secara berurutan tadi, seperti yang sudah saya utarakan sebelumnya. Kelemahan-kelemahan yang lain juga sudah saya utarakan di atas, atau bahkan masih ada yang lainnya.
Dari sini, nantinya akan dikembangkan model-model yang lain, bahkan ada tahap evolusioner dari suatu model proses untuk mengatasi kelemahan-kelemahan tadi. Meskipun secara tahapan masih menggunakan standar tahapan waterfall model. Kesimpulannya adalah ketika suatu project skalanya sedang mengarah kecil bisa menggunakan model ini. Akan tetapi kalau sudah project besar, tampaknya kesulitan jika menggunakan model ini.