Use Case Diagram

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang

ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case

merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya. 

Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu. Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem.

Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.

Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.

Activity Diagram

Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.

Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.

Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.

Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk

menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.

Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

• Diawali dengan initial node
• Fill Order dan Send Invoice terjadi secara bersamaan
• Urutan menjadi tidak relevan antara 2 proses tadi
• Digunakan untuk concurrent algorithm atau threads
• Jika terdapat paralelism, diperlukan sinkronisasi
• Order tidak akan ditutup sampai barang dikirim dan pembayaran diterima
• Digunakan operasi join
• Diakhiri dengan activity final

Permodelan Bisnis

Secara formal, didefinisikan sebagai segala teknik pemodelan yang digunakan untuk mengambarkan model sebuah bisnis. Pemodelan Bisnis dapat digunakan untuk meninjau, meningkatkan, dan membuat sebuah bisnis.Dengan dilakukannya pemodelan bisnis diharapkan kita:

• Memahami struktur dan dinamika organisasi
• Memahami masalah-masalah dalam mencapai target organisasi dan menemukan potensi untuk kemajuan organisasi.
• Yakin bahwa para customer, end user, dan developer mempunyai sebuah pemahaman yang benar mengenai organisasi.
• Dapat menurunkan/mendapatkan kebutuhan perangkat lunak yang akan kita buat yang diperlukan untuk mendukung pencapaian target organisasi.

Kapan membutuhkan Pemodelan Bisnis?

• Jika kelompok kerja merupakan kelompok baru dalam organisasi
• Jika organisasi mengalami re-engineering proses bisnis/ bermaksud menjalankan re-engineering proses bisnis
• Jika kita akan membangun perangkat lunak yang akan dipergunakan oleh porsi yang significant dari organisasi
• Jika terdapat aliran kerja yang kompleks dan besar yang tidak didokumentasikan
• Jika kita merupakan konsultan organisasi yang belum pernah bekerja sama

Kapan tidak memerlukan Pemodelan Bisnis?

• Jika kita telah memahami struktur, tujuan, visi dan stakeholder dari organisasi
• Jika kita membangun perangkat lunak yang akan dipergunakan hanya oleh bagian kecil dari organisasi dan tidak akan menimbulkan efek pada keseluruhan bisnis
• Jika aliran kerja organisasi telah jelas dan didokumentasikan dengan baik
• Jika tidak terdapat banyak waktu (tapi tidak boleh dijadikan alasan).

Elemen-elemen pemodelan bisnis:

• Business use-case model, dengan elemen-elemen: Business Actor dan Business Use-case, serta Activity Diagram untuk menjelaskan model business use-case. Berikut gambaran Business Use-case Diagram [Activity Diagram dapat dilihat di sini].

• Business objek model, dengan elemen-elemen: Business Worker (Pekerja Bisnis), Business Entity (Entitas Bisnis)

Business Object Model: Menggambarkan realisasi business use-case. Mengenali semua orang yang bekerja dan benda yang terlibat dalam bisnis dan bagaimana satu sama lain berhubungan

Business Use-case Model: Merupakan model yang menggambarkan proses bisnis dari sebuah bisnis atau organisasi dan interaksi proses tersebut dengan pihak luar, seperti para customer dan partner. Diperlukan untuk memperjelas konteks bisnis dari perangkat lunak yang akan dibuat, bersifat optional. Diilustrasikan dalam satu atau beberapa business use-case diagram

UML Diagram

Unifed Modeling Language adalah seperangkat aturan dan notasi untuk spesifikasi sistem perangkat lunak, dikelola dan dibuat oleh Object Management Group. notasi ini menyediakan satu set elemen grafis untuk pemodelan sistem.

Beberapa diagram dari UML adalah:

1. Use Case Diagram

alat komunikasi tingkat tinggi untuk mewakili persyaratan sistem. Diagram menunjukkan interaksi antara pengguna dan entitas eksternal lainnya dengan sistem yang sedang dikembangkan.

2. Activity Diagram

Menangkap alur dari sebuah sistem, termasuk tindakan utama dan poin keputusan. Diagram ini berguna untuk mendokumentasikan proses bisnis.

3. Class Diagram

Class diagram menggambarkan struktur statis dari kelas dalam sistem anda dan menggambarkan atribut, operasi dan hubungan antara kelas.

4. Squence Diagram

Squence diagram secara khusus menjabarkan sebuah Use Case. Diagram ini menunjukkan sejumlah objek dan pesan yang melewati suatu objek.

5. Component Diagram

Komponen diagram digunakan untuk menggambarkan bagaimana komponen suatu sistem yang terhubung bersama di tingkat yang lebih tinggi dari abstraksi dari diagram kelas. Sebuah komponen bisa dimodelkan oleh salah satu atau lebih kelas.

6. Deployment Diagram

Adalah model arsitektur runtime dari sistem dalam pengaturan dunia nyata. Mereka menunjukkan entitas bagaimana perangkat lunak diterapkan ke perangkat fisik.

7. State Machine Diagram Digunakan untuk menggambarkan status transisi dari objek tunggal dalam menanggapi peristiwa.

8. Interaction Overview Diagrams

Merupakan pencangkokan dari Activity Diagram dan Squence Diagram. Disini berupa squence diagram yang dipecah menggunakan notasi activity diagram untuk menunjukkan aliran kontrol

9. Communications Diagram

Mendeskripsikan kumpulan objek yang berinteraksi untuk menjalankan suatu tingkah laku dalam sistem.

RPL (Rekayasa Perangkat Lunak)

Rekayasa perangkat lunak telah berkembang sejak pertama kali ddiciptakan pada tahun 1940-an hingga kini. Focus utama pengembangannya adalah untuk mengembangkan praktek dan teknologi untuk meningkatkan produktivitas para praktisi pengembang perangkat lunak dan kualitas aplikasi yang dapat digunakan oleh pemakai.

Fase Rekayasa Perangkat Lunak:

1. Analisa

2. Perancangan / Design

3. Pengembangan / Development

4. Testing

5. Implementasi / Deployment

6. Maintenance

Tujuan Rekayasa Perangkat Lunak

1. Meningkatkan keakuratan, performance & efficiency produk secara keseluruhan dalam pengembangan.

2. Menerapkan metodologi yang terdefinisi dengan baik untuk resolusi software.

3. Melengkapi secara rasional konflik-konflik dan dokumentasi.

UML (Unified Modelling Language)

UML adalah sebuah "bahasa" yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.

Dengan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun. Tetapi karena UML juga menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa-bahasa berorientasi objek seperti C++, Java, C# atau VB.NET. Walau demikian, UML tetap dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C.

Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax/semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering).

Langkah-Langkah Penggunaan UML

Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:

1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul.

2. Petakan use case untuk tiap business process untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.

3. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.

4. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem.

5. Berdasarkan use case diagram, mulailah membuat activity diagram.

6. Definisikan objek-objek level atas (package atau domain) dan buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.

7. Buarlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.

8. Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau domain dipecah menjadi hirarki class lengkap dengan atribut dan metodanya. Akan lebih baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi dengan class lain.

9. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.

10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.

11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :
• Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
• Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.

12. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual.

13. Piranti lunak siap dirilis.

Database Connectivity

Database Connectivity

1. Koneksi database

adalah sebuah fasilitas dalam ilmu komputer yang memungkinkan perangkat lunak client untuk berkomunikasi dengan perangkat lunak database server. Sambungan diperlukan untuk mengirimkan perintah dan menerima jawaban.

Hal yang harus diperhatikan dalam Koneksi Database:

• Knowing the business, not only technology 
• Centralized or Distributed 
• Thin client or fat client 
• Database gateway 
• Network Trafic 
• Webbase or dekstop:

             * Need provider?
             * Availability?

             * Red use down time

2. Elemen – elemen dalam Database Connectivity

Database adalah repositori dimana data disimpan untuk perusahaan. Java EE mengakses aplikasi database relasional melalui API JDBC. Untuk prosedur administrasi. JDBC Connection Pool adalah sekelompok koneksi dapat digunakan kembali untuk database tertentu untuk prosedur administrasi.

3. Pooling Connection

Koneksi database yang terbatas dan mahal dapat memakan waktu yang tidak proposional dan lama untuk menciptakan relatif terhadap operasi yang dilakukan pada mereka. Hal ini sangat tidak efisien untuk sebuah aplikasi untuk membuat menutup koneksi database jika perlu untuk memperbaharui database.

4. ODBC (Open Database Connectivity)

Sebuah standar terbuka untuk konektivitas antar mesin basis data. Standar ini menyediakan API yang dapat digunakan untuk menjalankan dan mengoneksikan sebuah aplikasi dengan sbeuah sistem managemen basis data (SMBD). Pada Desainer ODBC membuatnya dengan tujuan agar ODBC terbebas dari penggunaan bahasa pemrograman tertentu, sistem manajemen basis data tertentu, dan sistem operasi tertentu.

5. Komponen utama ODBC

• ODBC API : Sekumpulan panggilan fungsi kode – kode kesalahan dan sintaksis SQL yang mendefinisikan bagaimana data dalam sebuah DBMS diakses. 
• Driver basis data ODBC : driver yang mampu memproses panggilan fungsi ODBC untuk sebuah DBMS tertentu. 
• ODBC Driver Manager : yang bertugas untuk memuat driver basis data ODBC yang dibutuhkan oleh aplikasi. 

6. Jadi kesimpulannya terdapat beberapa hal yang penting yang harus diperhatikan, yaitu :

• Knowing the business, not only technology [fokus terhadap pemahaman tentang bisnis] 
• Centralized or distributed [memperhitungkan apakah menggunakan databse terpusat atau terdistribusi] 
• Thin client fat client [melihat apakah client yang di layani dalam kapasitas kecil atau besar] 
• Database gateway [melihat hubungan – hubungan (connect) dan pembatasanannya] 
• Network trafic [kemampuan atau kinerja dalam trafic network] 
• Database design [bagaimana disain dari database tersebut]