Dokumen ini membahas tentang model driven software development dengan penekanan pada penggunaan diagram UML untuk memodelkan kebutuhan perangkat lunak. Berbagai perspektif pemodelan seperti use case, activity, dan class diagram dijelaskan secara detail untuk mendukung analisis dan perancangan sistem. Selain itu, terdapat tips dan contoh dalam menyusun user story serta analisis fungsional perangkat lunak.

1. MODEL DRIVEN SOFTWARE DEVELOPMENT
Oleh: Adam Mukharil Bachtiar

2. MODEL
Artifak yang digunakan untuk mendeskripsikan
domain dari sistem yang akan dibangun,
representasi abstrak dari sistem yang akan
dibangun, sebagai bentuk dokumentasi, dan
spesifikasi untuk proses pengujian.
Inspirasi: IBM Research

3. MODEL
Domain
Modelling
Static Analysis
Code
Generation
Documentation
Refactoring or
Transformation
Automated
Testing

4. MODEL DRIVEN
SOFTWARE DEVELOPMENT
REQUIREMENTS

5. Contoh Code Generation
dari Class Diagram

6. Memodelkan perangkat lunak itu sejatinya
adalah bercerita perihal perangkat lunak
macam apa yang mau kita bangun.

7. Ruang:
Bangunkan rumah dengan dua
kamar tidur, 1 kamar mandi, 1
ruang keluarga, 1 ruang makan, 1
dapur, 1 garasi dan taman depan
serta belakang.
Posisi:
.....
Dimensi:
.....
Dan segala hal lainnya.
By Descriptive Story
By Diagram Model

8. KEBUTUHAN
PERANGKAT LUNAK
KEBUTUHAN
FUNGSIONAL
KEBUTUHAN NON
FUNGSIONAL
Fokus bercerita:
“Perangkat lunak harus bisa melayani apa?”
Fokus bercerita:
“Batasan apa dari layanan yang disediakan?”
Inspirasi: Ian Sommerville, Software Engineering 7th edition

9. Untuk memodelkan kebutuhan
perangkat lunak menggunakan
OOAD, terdapat alat bantu
yaitu UML*
*Singkatan dari Unified Modelling Language

10. Logical View Process View
Physical
View
Development
View
Use Case
View
Apa yang digambarkan UML?
Russ Miles, Learning UML 2.0

11. Use Case
View*
Mendeskripsikan fungsional sistem
yang dimodelkan dari perspektif
dunia luar sistem
* Diagram UML: Use case diagram dan Use case scenario

12. Mendeskripsikan proses-proses
yang ada di dalam sistem. Membantu
memvisualkan apa yang terjadi di
sistem kita.
Process
View*
* Diagram UML: Activity Diagram

13. Logical View*
Mendeskripsikan deskripsi abstrak
dari bagian-bagian sistem. Biasanya
digunakan untuk memodelkan
terbuat dari apa saja sistem yang
kita bangun dan bagaimana bagian-
bagian tersebut berinteraksi.
* Diagram UML: Class Diagram, Object Diagram, State Machine, dan Interaction Diagram

14. Development
View*
Mendeskripsikan bagaimana bagian-
bagian dari sistem diorganisasikan
dalam bentuk modul dan komponen.
Biasanya digunakan untuk visualisasi
layer arsitektur sistem
* Diagram UML: Package Diagram dan Component Diagram

15. Physical
View*
Mendeskripsikan bagaimana desain
dari sistem untuk kemudian dibawa
sebagai entitas dunia nyata.
* Diagram UML: Deployment Diagram

16. Urutan
Penggambaran
Model pada UML

17. Setiap diagram akan mempunyai
notation, semantic, dan stereotype
Russ Miles, Learning UML 2.0

18. Stereotype
Notation
Elemen yang membentuk modeling language
Kelas Mahasiswa memiliki dua atribut yaitu nim dan nama
serta dua method yaitu kumpulkan tugas dan lihat nilai
Semantic
Deskripsi yang menjelaskan notasi
Deskripsi yang menjelaskan
penggunaan special dari suatu notasi

19. FOKUS
PEMODELAN
PADA OOAD

20. Dalam UML, terdapat beberapa
Diagram yang secara exchangeable
dapat digunakan pada tahap Analisis
dan Perancangan Perangkat Lunak.

21. TIPS 1:
Gunakan standar baku dari
model yang digunakan
(contoh: UML 2.0)

22. https://www.omg.org/spec/UML/

23. Recommended Book for
learning UML 2.0
Learning UML 2.0 by Russ Miles and Kim Hamilton

24. Apa makna relasi <<include>>?
Apakah penggunaan <<include>>
seperti ini?

25. Digunakan untuk konsep reusable use case.
Use case yang di-include wajib dieksekusi
secara eksplisit oleh pengguna sistem.
RELASI INCLUDE
Sumber: Learning UML 2.0, Russ Miles and Kim Hamilton

26. Kasus Relasi Include

27. Karena ada langkah-langkah yang sama antara
dua use case di use case description yaitu
“Check Identity” maka use case diperbaiki
Russ Miles, Learning UML 2.0

28. Perubahan Use Case Description
Russ Miles, Learning UML 2.0

29. TIPS 2:
Bedakan fokus pemodelan
ketika menganalisis dan
merancang perangkat lunak

30. FOKUS PEMODELAN
Pada tahap analisis, fokus pemodelan adalah
perihal ”WHAT” sementara pada tahap
perancangan berkisar perihal “HOW”
Inspirasi: Software Engineering for Practitioner Approach, Roger S. Pressman

31. CLASS DIAGRAM ANALYSIS
Berfokus pada WHAT dan
PROBLEM SPACE CLASS DIAGRAM DESAIN
Berfokus pada HOW dan
SOLUTION SPACE

32. TIPS 3:
Breakdown kebutuhan
fungsional agar mudah
dimodelkan

33. Cara menyampaikan
kebutuhan fungsional ada
berbagai macam, salah
satunya menggunakan
User Story

34. As a < type of users >
I want < some goals >
So that < some reason/benefit >
Priority: < Jenis Prioritas >
Estimate: < Time needed >
USER STORY

35. Sumber: Vitality Chicago

36. Calon Use Case

37. TIPS 4:
Gunakan Tools spesifik untuk
menggambar model

38. Terdapat beberapa tools
spesifik untuk
menggambar diagram
pada UML seperti Visual
Paradigm dan Star UML.

40. TIPS 5:
Baca model dengan Mind Eyes

43. TIPS 5:
Sebuah cerita atau alur harus
mengandung alternative flow

44. Use Case Description Details Keterangan
Related Requirements Diisi dengan nomor atau kode dari kebutuhan pengguna yang dipenuhi.
Goal in Context Diisi dengan tujuan dari use case dibuat dan kenapa use case ini penting.
Preconditions Hal apa yang harus terjadi sebelum use case dieksekusi.
Successful End Condition Kondisi sistem yang harus terpenuhi jika use case berhasil dieksekusi.
Failed End Condition Kondisi sistem yang harus terpenuhi jika use case gagal dieksekusi.
Primary Actors
Aktor utama yang berpartisipasi di dalam use case. Seringkali berupa aktor yang men-trigger
atau menerima informasi secara langsing dari eksekusi use case.
Secondary Actors Aktor yang berpartisipasi tapi bukan pemain utama di dalam eksekusi use case.
Trigger Event yang di-trigger oleh aktor dalam rangka mengeksekusi use case.
Main Flow Mendeskripsikan setiap langkah penting ketika eksekusi use case secara normal.
Extensions Desripsi dari langkah-langkah alternatif yang mungkin terjadi pada langkah di main flow.
Overview Use Case Description
Russ Miles, Learning UML 2.0

45. Use case “Record Application
Failure” hanya dijalankan ketika ada
kegagalan di eksekusi use case
“Create a new Personal Wiki” atau
”Create a new Blog Account”
Russ Miles, Learning UML 2.0

46. Kasus Relasi Include

47. Kasus Relasi Extend
Di dalam use case “Create a
new Personal Wiki” juga terjadi
Russ Miles, Learning UML 2.0

49. REVIEW 1:
Sebelum use case diagram
dimodelkan, jangan bahas desain
interaksi dengan detail

50. REVIEW 2:
Terdapat beberapa kekeliruan
penggunaan notasi dan semantic
pada model

51. REVIEW 3:
Pola pikir pemodelan untuk
analisis dan desain belum
dibedakan dengan jelas

52. REVIEW 4:
Bedakan use case untuk
modelling proses bisnis manual
dengan kebutuhan fungsional

53. REVIEW 5:
Alternative flow dalam suatu
cerita di fungsional kurang
diperhatikan

54. REVIEW 6:
Bedakan model data dengan
model perangkat lunak

55. REVIEW 7:
Use case diagram itu digunakan
untuk memodelkan kebutuhan
fungsional dan bukan alur cerita

56. TERIMA KASIH
Adam Mukharil Bachtiar
https://www.linkedin.com/in/adammbachtiar/
Email: adammbachtiar@gmail.com