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.

Terdapat beberapa hal penting yang harus diketahui, yaitu ;

Activity mengambarkan sebuah pekerjaan atau tugas dalam workflow

Pada UML, activity digambarkan dengan simbol kotak

Start state dengan tegas menunjukan dimulainya suatu workflow pada sebuah activity diagram

Hanya ada satu start state dalam sebuah workflow

Pada UML, start state digambarkan dengan simbol lingkaran yang solid

End state menggambarkan akhir atau terminal dari pada sebuah activity diagram

Bisa terdapat lebih dari satu end state pada sebuah activity diagram

Pada UML, end state digambarkan dengan simbol sebuah bull’s eye

State transition menunjukan kegiatan apa berikutnya setelah suatu kegiatan sebelumnya

Pada UML, state transition digambarkan oleh sebuah solid line dengan panah

Decision adalah suatu titik atau point pada activity diagram yang mengindikasikan suatu kondisi dimana ada kemungkinan perbedaan transisi

Pada UML, decision digambarkan dengan sebuah simbol diamond

Swimlanes

Obyek swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

Mulailah dengan node awal untuk titik awal.

Tambahkan partisi jika relevan untuk analisis yang dibuat.

Tambahkan aksi untuk setiap langkah utama dari use case.

Tambahkan alur dari setiap aksi ke aksi lain, keputusan atau node akhir. Setiap aksi hanya mendapat satu alur masuk dan satu alur keluar menuju ke forks, joins, decisions, dan merges.

Tambahkan decisions jika alur dipecah menjadi beberapa pilihan. Jangan lupa untuk menggabungkan kembali dengan merge.

Tambahkan forks dan joins jika aktivitas akan dilakukan secara paralel.

Contoh Activity Diagram

Studi kasus : Penarikan Uang dari Account Bank Melalui ATM

Sumber : http://dewadirga.blogspot.com/2011/09/tentang-activity-diagram.html

USE CASE

Pengertian USE CASE

       Use Case merupakan sebuah teknik yang digunakan dalam pengembangan sebuah software atau sistem informasi untuk menangkap kebutuhan fungsional dari sistem yang bersangkutan, Use Case menjelaskan interaksi yang terjadi antara ‘aktor’ – inisiator dari interaksi sistem itu sendiri dengan sistem yang ada, sebuah Use Case direpresentasikan dengan urutan langkah yang sederhana.


Deskripsi singkat tentang USE CASE

Perilaku sistem adalah bagaimana sistem beraksi dan bereaksi. Perilaku ini merupakan aktifitas sistem yang bisa dilihat dari luar dan bisa diuji.
Perilaku sistem ini dicapture di dalam USE CASE. USE CASE sendiri mendeskripsikan sistem, lingkungan sistem, serta hubungan antara sistem dengan lingkungannya.
Deskripsi dari sekumpulan aksi sekuensial yang ditampilkan sistem yang menghasilkan yang tampak dari nilai ke actor khusus. Use Case digunakan untuk menyusun behavioral things dalam sebuah model. Use case direalisasikan dengan sebuah collaboration. Secara gambar, sebuah use case digambarkan dengan sebuah ellips dengan garis penuh, biasanya termasuk hanya namanya, seperti gambar berikut :

Representasi atau model yang digunakan dalam Rekayasa Perangkat Lunak untuk menggambarkan fungsional requirement suatu sistem.
Sekelompok skenario pengguna yang menggambarkan alur penggunaan sistem.
Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang atau piranti yang berinteraksi dengan perangkat lunak dalam berbagai cara.
Suatu Use Case adalah suatu sekuensial aksi yang dilakukan oleh sistem, yang akan secara bersama-sama, memproduksi hasil yang dibutuhkan oleh pengguna sistem. Use Case mendefinisikan alur proses sepanjang sistem berbasis pada kegunaan sebagaimana yang biasa dilakukan (secara manual).

Contoh sederhana:
Konsumen pesan tiket pesawat 

Contoh lebih lengkap:
Use Case pada Sistem Rumah Sakit

Kegunaan Use Case adalah untuk menspesifikasikan konteks sistem, menggambarkan kebutuhan sistem, memvalidasikan arsitektur sistem, menjalankan implementasi dan meng-generate test case.

Include
Keterhubungan secara include antar use case menunjukkan bahwa use case asal secara eksplisit memasukkan perilaku dari use case lain yang ditunjuk oleh use case tersebut. Included use case tidak pernah berdiri sendiri, tetapi hanya merupakan bagian dari beberapa use case yang lebih besar yang diikutinya. Keterhubungan use case secara include pada dasarnya merupakan sebuah contoh dari pendelegasian - sekumpulan dari tanggung jawab sebuah sistem diambil dan ditangkap di dalam satu tempat (included use case) - kemudian bagian lainnya dari sistem (use case yang lain) memasukkan kumpulan tanggung jawab yang baru setiap saat mereka memerlukan fungsi-fungsi use case tersebut.

Extend
Keterhubungan use case secara extend menunjukkan bahwa use case yang ditunjuk merupakan perluasan perilaku dari use case asal. Use case asal dapat berdiri sendiri, tetapi untuk kondisi tertentu perilaku use case tersebut dapat diperluas oleh perilaku dari use case lain. Hubungan perluasan digunakan untuk memodelkan bagian dari use case yang dapat dilihat oleh user sebagai perilaku yang dapat dipilih dari sistem. Hubungan perluasan juga dapat digunakan untuk memodelkan sub aliran yang terpisah-pisah yang hanya dapat dijalankan dalam kondisi tertentu. Pada akhirnya, hubungan perluasan use case untuk memodelkan beberapa aliran yang dapat dimasukkan dalam titik tertentu.

RANCANGAN ENTITAS TABEL PROGRAM

Pada Kesempatan kali ini saya akan melanjutkan pembahasan tentang rancangan data tabel yang akan di gunakan dalam aplikasi pemninajam dvd. Sebelum masuk dalam perangan table apa yang kita butuhkan marilah kita flashback kebelakang melihat proses atau skema dari proses peminjaman dvd tersebut. Berikut aluratau proses bisnis untuk aplikasi ini.
“pelanggan datang kemudian melihat-lihat daftar film dvd yang tersedia atau yang terupdate,setelah pelanggan menemukan dvd yang akan dipinjam pelanggan menuju ke operator toko untuk proses peminjaman,setelah berhadapan dengan operator toko pelanggan akan ditanyakan oleh operator film apa yang akan di pinjam,pelanggan menyebutkan nama film ,lalu operator mencari filmnya kemudian operator menanyakan kembali kepada pelanggan sudah punya kartu membernya belum ?,jika belum pelanggan diwajibkan untuk registrasi terlebih dahulu,jika sudah maka langsung diproses ke pembayaran, operator akan bertanya berapa hari akan meminjam dvd film tersebut, setelah operator mendapatkan jawabnnya,lalu operator memberitahu nominal biaya yang harus dikeluarkan sesuai dengan lama peminjaman,kemudian pelanggan membayarnya ,operator memberikan dvdnya, pelanggan keluar toko dengan membawa dvd hasil peminjamannya. Kemudian operator membuat laporan peminjaman dan laporan diberikan kepada pemilik toko”
Dari cerita diatas dapat kita gambarkan dalam model sketsa agar lebih terbuka atau lebih ringkas sehingga kita dapat mengetahui lebih jelas berikut model sketsanya :



Pada  saat ini setelah melihat model sketsa saya baru menyimpulkan bahwa aplikasi ini membutuhkan 6 tabel sebagai database penunjang aplikasi yaitu :
Tabel Login
Tabel DVD
Tabel Anggota
Tabel Peminjaman
Tabel Pendaftaran
Tabel Laporan

 berikut entitas-entitas pada setiap tabel 

Entity Relationship Diagram (ERD)

Entity Relationship Diagram (ERD)

adalah sebuah konsep yang mendeskripsikan hubungan antara penyimpanan dan didasarkan pada persepsi dari sebuah dunia nyata yang terdiri dari sekumpulan objek, disebut entiti & relasi diantar objek-objek tersebut. Atau juga bisa disebut suatu model jaringan (network) yang menggunakan susunan data yang disimpan dari sistem secara abstrak.

Fungsi dari penggambaran ERD adalah:

·      Untuk memodelkan struktur data dan hubungan antar data

·      Model dapat diuji dengan mengabaikan proses yang dilakukan

·      Menjelaskan hubungan antar data dalam basis data berdasarkan objek-objek dasar data  yang mempunyai hubungan antar relasi

·      mendokumentasikan data-data yang ada dengan cara mengidentifikasi tiap jenis entitas dan hubungannya.

A. Entitas

Entitas digunakan untuk menerapkan integritas pada tingkat Entity (Tabel), agar setiap Instances (Record/Baris) pada suatu Entity bersifat Unique yang disebut sebagai Primary Key sehingga dapat dibedakan antara yang satu dengan yang lainnya.

Contohnya :

Semua Leptop, atau Leptop saja dengan entitas Asus, Toshiba, Acer.

Semua Mobil, atau Mobil apa saja, dengan entitas mobil Baleno, Terano dan lain-lain

Semua Mahasiswa, atau Mahasiswa saja dengan entitas Budi, Andi dan lain-lain.

B.     Relasi

Relasi digunakan utk menghubungkan beberapa tabel, sehingga data–data yang disimpan dalam tabel tetap normal.

C.    Atribut

Setiap Entitas pasti memiliki Atribut yang mendeskripsikan karakteristik dari Entitas tersebut. Penentuan/pemilihan atribut-atribut yang relevan bagi sebuah entitas merupakan hal penting lainnya dalam pembentukan model data. Penetapan atribut bagi sebuah entitas umumnya memang didasarkan pada fakta yang ada, tetapi tidak selalu seperti itu. Istilah atribut sebenarnya identik dengan pemakaian kolom data.

D.    Garis

Kita langsung ambil saja contoh pada simbol garis ini. Pada diagram E-R dibawah terdiri dari 2 entitas, customer dan loan, dan satu relasi borrower. Atribut dari customer adalah nama, ktp, jalan, kota. Atribut untuk loan adalah no_pinjaman, jml_pinjaman. Hubungan entity customer ke loan adalah banyak ke banyak.

contoh kardinalitas dalam Diagram E-R !

  

Kardinalitas pemetaan atau rasio kardinalitas menunjukkan jumlah entitas yang dapat dihubungkan ke satu entity lain dengan suatu relasi.

Kardinalitas pemetaan meliputi :

1. Hubungan satu ke satu (one to one), yaitu satu entity dalam A dihubungkan dengan maksimum satu entity dalam B.

Contoh : mahasiswa dengan kelas, satu mahasiswa hanya boleh mempunyai satu kelas.

2.   Hubungan satu ke banyak (one to many)

Yaitu satu entity dalam A dihubungkan dengan sejumlah entity dalam B. Satu entity dalam B dihubungkan dengan maksimum satu entity dalam A.

Contoh : orang tua dengan anak, satu orang tua boleh memiliki banyak anak.

3.   Hubungan banyak ke satu (many to one)

Yaitu satu entity dalam A dihubungkan dengan maksimum satu entity dalam B. Satu entity dalam B dapat dihubungkan dengan sejumlah entity dalam A.

Contoh : anak dengan orang tua, sejumlah anak hanya bisa dimiliki satu orang tua.

4.   Hubungan banyak ke banyak (many to many).

Satu entity dalam A dihubungkan dengan sejumlah entity dalam B, dan satu entity dalam B dihubungkan dengan sejumlah entity dalam A.

Contoh : matakuliah dengan mahasiswa, banyak mata kuliah dapat dimiliki banyak mahasiswa.

Weak Entity

Definisi:

Weak Entity: suatu entity dimana keberadaan dari entity tersebut tergantung dari keberadaan entity lain

Entity yang merupakan induknya disebut Identifying Owner dan relationship-nya

Disebut Identifyimg Relationship

Weak Entity Selalu mempunyai Total Participation Constraint dengan Identifying Owner

Contoh Weak Entity:

1. Entity

2. Weak Entity

3. Relationship

4. Identifying Relationship

5. Atribut

6. Atribut Primary Key

7. Atribut Multivalue

8. Atribut Composite

9. Atribut Derifatif

DFD Level 1

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

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

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



sumber: 
http://7enius.wordpress.com/2012/03/11/pengertian-fungsi-dan-contoh-dari-data-flow-diagramdfd/

Diagram Konteks (context diagram)

Pengertian diagram kontek adalah suatu diagram alir yang tingkat tinggi yang menggambarkan seluruh jaringan, masukan dan keluaran. sistem yang dimaksud adalah untuk menggambarkan sistem yang sedang berjalan. mengidentifikasikan awal dan akhir data awal dan akhir yang masuk dan keluaran sistem.

Diagram ini merupakan gambaran umum sistem yang nantinya akan kita buat. secara uraian mah dapat dikatakan bahwa diagram kontek itu berisi siapa saja yang memberikan data (inputan) kesimstem serta kepada siapa data informasi yang harus dihasilkan sistem.

jadi dalam diagram ini yang dibutuhkan adalah : 

1. siapa saja pihak yang akan memberikan data ke sistem.

2. Data apa saja yang diberikannya kesistem

3. kepada siapa sistem harus memberikan informasi atau laporan 

4. apa saja isi atau jenis laporan yang harus dihasilkan sistem.

kata siapa diatas dilambangkan dengan kotak persegi atau disebut dengan terminator, dan kata "apa" diatas dilambangkan dengan aliran data, dan kata sistem dilambangkan dengan lingkaran atau disebut dengan proses.

3 Buah Model Pengembangan Perangkat Lunak

Linear sequential model (classic life cycle / model cycle) 

  Model yang paling luas dipakai dan tertua. Mengusulkan suatu pendekatan sekuensial dan sistematis pada pengembangan PL. Meliputi aktivitas-aktivitas :

 
• System / information engineering (rekayasa dan pemodelan sistem) : menyangkut pengumpulan kebutuhan (requirement gathering) pada level sistem dengan sejumlah kecil analisis serta top desain.
 
• Analisis : kebutuhan PL, proses requirement gathering diintesifkan dan difokuskan, khususnya pada PL. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan sistem maupun PL didokumentasikan dan direview bersama user.
 
• Desain : fokus pada 4 hal : desain database, arsitektur PL, interface, dan algoritma prosedural. Proses desain menerjemahkan kebutuhan ke dalam representasi PL sebelum dimulai coding.
 
• Coding : menerjemahkan desain ke dalam bahasa yang dimengerti mesin.
 
• Testing : fokus pada :
 
   
• Logika internal PL : memastikan bahwa semua statement telah diuji
   
• Fungsi eksternal : mengarahkan testing untuk menemukan kesalahan-kesalahan dan memastikan bahwa input yang diberikan akan menghasilkan output sesuai yang diinginkan.       
 

Kelemahan model :

• Meskipun mengakomodasi iterasi, model linier melakukannya secara tidak langsung sehingga perubahan-perubahan dapat menyebabkan keraguan saat tim proyek berjalan
     
• Jika user sulit menyatakan semua kebutuhannya secara explisit, model ini sulit mengakomodasi ketidakpastian itu
     
• User harus bersabar karena hasil baru bisa dinikmati setelah testing (akhir waktu). Jika ada kesalahan besar yang tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka.
     
• Pengembang sering melakukan penundaan yang tidak perlu. Anggota tim harus menunggu anggota tim lain selesai mengerjakan tugasnya yang mempunyai keterkaitan dan ketergantungan tinggi.
   
 

  Meski memiliki kelemahan, model ini masih lebih baik daripada pendekatan yang sembrono / sembarangan.  
Contoh : model Waterfall terdiri dari fase investigasi -> analisis -> desain -> implementasi (coding) -> testing -> maintenance. 

 Prototyping Model   
  Berfungsi sebagai mekanisme pendefinisian kebutuhan. Pertama, developer menggali semua kebutuhan user secara cepat kemudian membangun prototipe yang sesuai dengan yang diinginkan dengan cepat pula dan ditunjukkan ke user, baru dibuat PL yang sesungguhnya berdasarkan komentar user terhadap prototipe. 
  Kelebihan model : user dapat langsung melihat wujud PL yang akan dibangun meskipun sederhana dan dari sana dapat digali kebutuhan yang lebih dalam sebagai bahan penyusunan PL berikutnya. 
    
    
  Masalah yg muncul : 

• User merasa prototipe merupakan PL yang sesungguhnya, padahal ketika membuat prototipe belum disertakan kualitas PL secara keseluruhan / kemampuan pemeliharaan untuk jangka panjang
 
• Developer sering membuat kompromi-kompromi implementasi untuk membuat prototipe bekerja dengan cepat sehingga akan ditemui ketidakcocokan pada prototipe ketika prototipe dibangun dengan bahasa yang sederhana
 
• Program dibuat ulang / prototipe selalu baru

  Contoh : model Iterative : investigasi -> membuat PL -> testing / deliver ke user dengan program prototipe.

 Rapid Application Development (RAD) Model   
  Model proses perkembangan PL sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Menekankan perkembangan komponen program yang bisa dipakai lagi sehingga mendasari konsep Object-Oriented.  
  Fase2 pendekatan RAD :  
  • Bussines modeling 
  • Data modeling 
  • Proses modeling 
  • Application generation : RAD mengasumsikan pemakaian teknik 4G (generasi keempat). Selain menciptakan PL dengan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program atau menciptakan komponen yang bias dipakai lagi. 
  • Testing and Turn Over : karena menekankan pada reusability, banyak komponen program yang telah diuji sehingga mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji dan semua interface harus dilatih secara penuh.

source : http://cumadaniel.blogspot.com/2012/01/model-pengembangan-perangkat-lunak.html

Pengertian Rekayasa Perangkat Lunak

Nama: Angga Khoirul Hadi M

Nim: TI 111032

Politeknik Tedc Bandung

Rekayasa perangkat lunak (RPL, atau dalam bahasa inggris : Software Engineering atau SE) adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembanganan perangkat lunak dan manajemen kualitas.

          IEEE Computer Society mendefinisikan rekayasa perangkat lunak sebagai penerapan suatu pendekatan yang sistematis, disiplin dan terkuantifikasi atas pengembangan, penggunaan dan pemeliharaan perangkat lunak, serta studi atas pendekatan-pendekatan ini, yaitu penerapan pendekatan engineering atas perangkat lunak

http://id.wikipedia.org/wiki/Rekayasa_perangkat_lunak