UML Activity Diagram

Langkah pertama yang HARUS dilakukan untuk memodelkan perangkat lunak adalah dengan membuat model proses bisnis. Proses bisnis yang dimaksudkan disini adalah proses yang terkait dengan urutan langkah, cara kerja atau bagaimana kita melakukan pekerjaan tertentu. Urutan langkah atau cara kerja inilah yang akan dibangun pada perangkat lunak.

Pemodelan proses bisnis dapat dibagai menjadi dua bagian. Bagian pertama disebut identifikasi problem domain. Pada bagian ini, tim pengembang bekerja sama dengan stakeholders berusaha untuk menemukan setiap permasalahan yang ada dalam proses bisnis. Proses ini dapat dilakukan dengan melalui wawancara, menyebarkan kuesioner ataupun melakukan diskusi. Setelah dilakukan identifikasi problem domain, maka dilanjutkan dengan menyimpulkan kebutuhan user/stakeholders terkait dengan perangkat lunak yang akan dibangun. Pada tahap ini, penting sekali untuk disepakati bersama kebutuhan-kebutuhan apa yang akan diselesaikan oleh perangkat lunak.

Bagian kedua pemodelan proses bisnis adalah identifikasi solution domain. Solution domain dimulai dengan mengidentifikasi features (berdasarkan needs yang ada) yang harus dibangun pada perangkat lunak. Berdasarkan features ini kemudian ditentukanlah software specification requirements yang akan dibangun.

Jika akan menggunakan UML maka kakas pemodelan yang bisa digunakan dalam pemodelan proses bisnis ini adalah Activity Diagram, Business Use-case Model, Business Object Model (BOM) dan Use-case Diagram. 

Pada bagian tulisan ini, saya akan menuliskan tentang memodelkan proses bisnis dengan Activity Diagram. Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang: awal proses, decision, akhir proses, proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu

Notasi dalam Activity Diagram

Cara menggambarkan activity diagram:

1. Menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. 

2. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.

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

4. Untuk dapat menggambarkan activity diagram dengan baik, disarankan agar membuat daftar sejumlah aktivitas beserta dengan kondisinya. Tools FDD dapat menjadi sangat berguna untuk mengecek proses-proses serta jalur aktivitas, baik dari level atas maupun level rincinya.

Tentang Activity Diagram:

Sebuah Activity diagram dalam business use-case menggambarkan workflow (aliran kerja) sebuah business use-case. Workflow dari sebuah business use-case menggambarkan apa yang harus dikerjakan bisnis tersebut untuk menghasilkan nilai tertentu untuk business actor yang bersangkutan. Activity diagram di bawah ini memodelkan alur kerja (workflow) sebuah proses bisnis dan urutan aktivitas dalam suatu proses.

Contoh pada Studi Kasus:

Pada sebuah Foodcourt. Pembeli datang ke foodcourt, menuju stand penjual makanan yang dinginkan. Pembeli memesan makanan, jika makanan tersebut ada, maka pesanan disiapkan, jika makanan tersebut tidak ada maka pembeli tidak jadi memesan makanan. Setelah memesan, petugas stand menyiapkan bon dua rangkap dan memberikan bon tersebut kepada pembeli.

Pembeli kemudian membayar makanan yang dibeli di kasir stand dengan menyerahkan bon pembelian. Kasir menghitung jumlah yang harus dibayar pembeli dan menginformasikannya ke pembeli. Pembeli menyiapkan uang dan memberikan kepada kasir. Jika ada kembalian, kasir menghitung kembalian tersebut dan memberikan kembalian beserta bukti pembayaran (struk) serta bon yang sudah ditandai lunas.

Pembeli mencari tempat duduk, penjual stand makanan memberikan makanan kepada pembeli dengan mengambil bon yang sudah ditandai lunas tersebut.

Activity Diagram Pembayaran

Activity Diagram Pemesanan

Sebuah Video Tutorial tentang Activity Diagram dapat dilihat disini:
http://www.youtube.com/watch?v=yAihwmczqsk&feature=related

UML dan Pemodelan Software

Pemodelan pada dasarnya merupakan kegiatan untuk menyederhanakan. Seperti misalnya kita ingin memahami tentang bentuk bumi yang seperti bola. Alih-alih kita melihat bumi dari luar angkasa, maka kita mengambil benda yang “menyerupai” bola, dan kemudian mulai memodelkan bumi yang sebenarnya.

Kegiatan pemodelan perangkat lunak berorientasi obyek adalah kegiatan untuk mencoba menyederhanakan perangkat lunak yang akan kita kembangkan dengan terlebih dahulu membuat model visualisasi (penggambaran model) perangkat lunak yang akan dikembangkan. Pembuatan model visualisasi perangkat lunak dilakukan dengan menggunakan kakas yang disebut Unified Modelling Language atau disingkat UML. 

Jadi, sebenarnya UML adalah:

1. sebuah "bahasa" pemodelan perangkat lunak standar yang dapat digunakan untuk melakukan spesifikasi, visualisasi, konstruksi, dan dokumentasi dari komponen-komponen perangkat lunak.
2. bahasa pemodelan visual yang notasi grafis yang ekspresif dalam arti lengkap dan mudah dipahami, baik oleh pengembang maupun user.
3. menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa berorientasi obyek seperti C++, Java, C# atau VB.NET.

Tiga hal yang harus diperhatikan agar dapat menguasai UML dengan baik, yaitu:

1. Memahami maksud dan tujuan digunakannya UML
2. Memahami apa yang akan dimodelkan dalam UML
3. Menguasai langkah-langkah pembuatan diagram UML

Ada beberapa notasi grafis dalam UML yang dapat digunakan untuk memodelkan aplikasi perangkat lunak berorientasi obyek. Notasi grafis atau disebut juga diagram tersebut memiliki bermacam-macam sudut-pandang (atau disebut perspektif) untuk menunjukkan model perangkat lunak. Diagram-diagram tersebut juga menunjukkan tingkat abstraksi pemodelan berorientasi obyek yang berbeda-beda. Berikut adalah Ringkasan Diagram UML ver 2.0 yang diambil dari buku System Analysis and Design with UML version 2; An Object-Oriented Approach,2nd Ed. By Allan Dennis, Barbara Wixon, David Tegarden. © John Wiley&Sons, 2010

Bagaimana memodelkan perangkat lunak dengan UML?

Terdapat banyak variasi dalam memodelkan perangkat lunak dengan menggunakan UML. Dibawah ini saya memberikan saran untuk memodelkan perangkat lunak dengan menggunakan UML. Tidak berarti bahwa saran saya ini adalah yang paling tepat, penyesuaian terhadap langkah-langkah pemodelan itu sangat terbuka. Masing-masing pengembang dapat menemukan "best practices"-nya sendiri. Urutan langkah yang disarankan untuk memodelkan perangkat lunak dengan menggunakan UML adalah:

1. Buatlah daftar proses business dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul. Langkah ini dapat dilakukan dengan membuat FDD (functional decomposition diagram) ataupun dengan membuat Business Use Case Model dan Business Object Model (BOM).
2. Petakan use case untuk tiap proses business 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. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem dengan mengisi use case table.
4. Berdasarkan use case table, highlight semua potensial obyek dan dari situ pilihlah obyek yang dapat dijadikan sebuah kelas. Kemudian, gambarkan high-level class digram dan detailed class diagram.
5. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Oleh karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
6. Berdasarkan use case diagram, mulailah membuat activity diagram.
7. Setelah activity diagram selesai dibuat, maka langkah selanjutnya yaitu mendefinisikan objek-objek level atas (package atau domain). Lalu 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.
8. Buatlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.
9. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
10. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan:
11. Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
12. Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.
13. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual.
14. Piranti lunak siap dirilis.

Sebuah Video Tutorial tentang Introduction to UML, bisa dilihat disini:
http://www.youtube.com/watch?v=FkRwbVUVFvE&feature=fvwrel

ERD dan Normalisasi

ERD merupakan alat bantu untuk visualisasi pemodelan data. ERD berperan penting dalam melakukan pemodelan data logis. Seperti kita kita bersama, pemodelan data logis sangat penting dalam proses perancangan basis data. ERD juga sangat membantu dalam melakukan normalisasi data.

Pemodelan logic data dikembangkan dalam beberapa tahapan sebagai berikut:

1) Context ERD atau Model Data Konteks

Model data ini digunakan untuk menentukan lingkup proyek yang tidak terlalu detail dalam membahas entitas dan aturan bisnis. Banyak hubungan  tersebut mungkin non- spesifik.

Berikut adalah sebuah contoh Context ERD yang menjelaskan mengenai sebuah proses bisnis yang melibatkan entitas-entitas seperti customer, customer order, customer transaction, product dan product_type.

2) Model Data Key-Based

Pada model data key-based, kita telah mulai menyertakan attribute data yang memiliki primary key, foreign key dan entitas asosiatif yang ada. 

Apabila terdapat 2 buah tabel yang mempunyai hubungan many-to-many, maka kedua tabel ini harus dipisahkan dengan cara menambah sebuah tabel diantaranya. Kemudian berikan relevan key di setiap tabelnya dan jangan lupa untuk mengganti notasi kardinalitas pada ketiga tabel tersebut.

Lihat pada contoh gambar diatas. 

Tabel ‘member_order’ and ‘product’ mempunyai hubungan many-to-many. Kedua tabel ini harus dipisahkan dengan menambahkan sebuah tabel dan namakan tabel tersebut ‘member_ordered_product’. Tabel baru ini berisi 2 primary keys yaitu  member_order_id (table member_order) dan product_id (table product). 

Jika ingin memudahkan pengkodean, anda dapat menambahkan sebuah primary key lainnya dan namakan key tersebut ‘member_ordered_product_id (pk)’ di mana key ini mempunyai fungsi yang sama dengan member_order_id (pk) and product_id (pk). Akan tetapi, bila hal ini dilakukan, anda harus mengganti ‘member_ordered_product_id (pk)’ menjadi ‘member_ordered_product_id (fk) dan ‘product_id (pk)’ menjadi ‘product_id (fk)’.

3) Model Data Fully-Attributed

Model data fully-attributed adalah model data logic yang menyertakan semua atribut deskriptif secara menyeluruh.

Lihat pada Gambar dibawah

4) Normalized Data Model

Normalised data model adalah model data logis yang telah melalui proses normalisasi. Pada dasarnya normalisasi adalah suatu teknik pengorganisasian data ke dalam tabel-tabel untuk memenuhi kebutuhan pengguna. Tujuannya untuk mernghilangkan kerangkapan data, mengurangi kompleksitas data dan mempermudah modifikasi data.

Secara singkat tahapan Normalisasi adalah sebagai berikut:

1. Bentuk Normal Tahap Pertama (1st Normal Form)

Pada bentuk ini, semua elemen yang berulang pada suatu entitas      dihapuskan. Dalam 1st Normal Form tidak ada elemen data yang muncul beberapa kali untuk satu entitas tertentu.

2. Bentuk Normal Tahap Kedua (2nd Normal Form)

Dalam bentuk ini pastikan bahwa atribut descriptor bergantung pada seluruh composite key untuk identifikasi.

3. Bentuk Normal Tahap Ketiga (3rd Normal Form)

Dipastikan bahwa nilai atribut tidak bergantung pada nilai atribut lain dalam entitas yang sama.

Pada contoh gambar kita sebelumnya, semua atribut yang ada pada table-tabel di atas sudah normal, maka dari itu tidak perlu dilakukan normalisasi. Jika dalam situasi yang berbeda di mana harus dilakukan normalisasi terhadap tabel-tabel tertentu, pergunakanlah aturan normalisasi dengan benar. Setelah dilakukan normalisasi, maka gabungkan kembali tabel yang sudah dinormalisasi dengan tabel lainnya. 

5) Physical Database Schema

Untuk menggambarkan bagian ini, maka harus mengambil gabungan tabel yang sudah dinormalisasi sebelumnya. Kemudian tambahkan data type dan data length pada setiap atribut yang ada pada tabel-tabel tersebut. Apabila ada batasan-batasan yang harus diketahui, maka hal ini harus dideskripsikan secara singkat pada skema basis.
Lihat contohnya pada Gambar dibawah ini:

Semua Gambar diambil dari buku teks System Analysis and Design for the Global Enterprise - Bentley & Whitten, 7th ed, 2007

Data Flow Diagram

Pemodelan sistem informasi sering dilakukan dengan menggunakan DFD (Data Flow Diagram). Sebelum berkembang pemodelan berorientasi obyek yang menggunakan UML, maka tools DFD sangat sering digunakan. Dalam hubungan dengan metodologi pengembangan sistem informasi maka DFD sering digunakan pada metode Waterfall.
O’brien (1999) menjelaskan bahwa DFD merupakan diagram yang mendemonstrasikan cara data diproses oleh system . Bocij, Chaffey, Greasley, dan Hickie (2003) menjelaskan  diagram konteks merupakan pola penggambaran yang berfungsi untuk memperlihatkan interaksi sistem informasi tersebut dan lingkungan di mana sistem tersebut ditempatkan.
Simbol-simbol yang digunakan dalam DFD menurut DeMarco dan Yourdon, adalah sebagai berikut:

Gambar Simbol-Simbol DFD

Sumber:  Bentley & Whitten, System Analysis and Design for the Global Enterprise 7th ed, 2007

Penjelasan simbol-simbol tersebut dikutip dari McLeod (2001):
1) Arus Data (Data Flow) merupakan kumpulan elemen-elemn data, yang berhubungan secara logis yang bergerak dari satu titik atau process ke titik atau proses lain. Tanda panah menyatakan arah hubungan antar elemen data tersebut
2) Entitas Eksternal (External Entity(, yakni entitas yang berada diluar sistem, tetapi bisa memberikan masukan bagi sistem dan menerima keluaran dari sistem.
3) Proses (Process), adalah sesuatu yang mengubah masukan menjadi keluaran. Tiap proses memiliki satu atau lebih data masukan dan menghasilkan satu atau lebih data keluaran.
4) Penyimpanan Data (Data Storage). Dalam istilah DFD, data store adalah merupakan suatu tempat penyimpanan data.

Berikut adalah aturan mengenai penggambaran Diagram Konteks dan DFD level-n:
Aturan Diagram Konteks:
1. Gunakan satu simbol proses
2. Berikan nama atau label pada simbol proses tersebut untuk menggambarkan seluruh sistem.
3. Tidak menomori simbol proses tersebut.
4. Menyertakan semua extenal entity dari sistem.
5. Menunujukkan semua data flow antara teminator dan sistem.

Aturan Diagram Gambar-n
Diagram gambar-n mendokumentasikan satu proses DFD secara lebih tinggi. Huruf n menggambarkan jumlah proses pada tingkat selanjutnya yang lebih tinggi yang sedang didokumentasikan.
Tahapan Pembuatan DFD
1. Beri label tiap arus data (data flow) dengan nama yang unik.
2. Jaga agar nama arus data tetap dari satu tingkat ke tingkat lain.
3. Tunjukkan penempatan yang tepat bagi catatan-catatan yang dihapuskan dari penyimpanan data.
4. Saat mendokumentasikan program komputer jangan menyertakan proses membaca dan menulis.
5. Hindari proses membaca saja (read-only process).
6. Proses membaca saja diijinkan jika waktu berfungsi sebagai pemicu

Aturan Penggambaran DFD

Berikut saya berikan contoh langkah-langkah untuk menggambar DFD:
1) Menggambar Functional decomposition diagram (FDD)
2) Menggambar Context DFD (Level 0)
3) Menggambar DFD Level 1
4) Menggambar DFD Level 2 … Level n (Event diagrams)
Contoh kasus adalah sebuh Proses Sales Processing!

Gambar FDD

Gambar Context Diagram

Gambar DFD Level 1

Gambar DFD Level 2

Sebuah contoh lainnya tentag Pemodelan menggunakan DFD dapat dilihat disini ....

Eliminasi Gauss

Praktikum Metode Numerik
Modul 5 Metode Eliminasu Gauss
BAB I
TUJUAN DAN DASAR TEORI

I.1. Tujuan
1) Menguasai metode eliminasi gauss yang digunakan dalam komputasi numerik
2) Memahami algoritma pemrograman untuk merancang program metode eliminasi gauss yang ada dalam komputasi numerik
3) Menerapkan algoritma untuk perancangan dan pembuatan program metode eliminasi gauss.

II.2. Dasar Teori
Berikut ini dipaparkan metode 2 langkah dalam menyelesaikan persamaan dengan Gaussian Eliminasi.

Langkah ke-1:
Melakukan proses triangulasi = mengubah matriks A menjadi matriks segitiga (hal ini akan mengubah matriks B)

Langkah ke-2:
Melakukan substitusi mundur, yaitu: menghitung x mengikuti urutan terbalik, dari yang terakhir (Xn ) sampai yang pertama (X1 )

Modul selengkapnya dapat diunduh disini