atau dihasilkan dalam suatu proses rekayasa software. Artifact dapat berupa model, deskripsi atau software. ) dari sistem software,

Transkripsi

1 1

2 Unified Modelling Language (UML) adalah sebuah "bahasa" yang telah menjadi standar dalam industri untuk menentukan, visualisasi, merancang dan mendokumentasikan artifact (sepotong informasi yang digunakan atau dihasilkan dalam suatu proses rekayasa software. Artifact dapat berupa model, deskripsi atau software. ) dari sistem software, untuk memodelkan bisnis dan sistem non software lainnya. UML merupakan suatu kumpulan teknik terbaik yang telah terbukti sukses dalam memodelkan sistem yang besar dan kompleks. 2

3 Awalnya diciptakan oleh Ivar Jacobson, Grady Booch, dan Jim Rumbaugh (The Three Amigos) Dikelola oleh OMG (Object Management Group) pada tahun 1997 Tahun 2006: Lebih dari 10 juta professional IT menggunakan UML Tahun 2008: lebih dari 70% software development organization menggunakan UML Versi terbaru: 2.0 (2005) 3

4 UML digunakan untuk memodelkan sistem! (Ingat : Model dalam RPL sangat penting sebagaimana pentingnya kita memiliki blueprint untuk bangunan yang besar dan model digunakan untuk membangun komunikasi yang baik antar anggota tim). UML hanya sebagian KECIL dari proses pembuatan proyek software, terutama pada bagian requirements dan design serta dokumentasi Notasi UML membingungkan pada awalnya, namun banyak orang merasa lebih mudah memahami dibandingkan dokumen teknis Konsistensi dalam penggunaan notasi/ simbol 4

5 Menganalisa kebutuhan pengguna Diagram UML yang bisa dipakai: Use Case : menjelaskan interaksi penggunasistem Class diagram : dilihat dari perspektif konseptual Activity diagram : melihat arus proses dan bagaimana interaksi sistem dan pengguna 5

6 Pada tahap ini, diagram bisa bersifat lebih teknis, karena tidak lagi berhubungan dengan konsumen Class diagram : kelas dan hubungan antar kelas Sequence diagram : urutan kejadian dari sebuah use case Component + package diagram : organisasi paketpaket 6

7 Diagram UML yang jelas dan lengkap bisa berguna untuk memahami sistem secara umum Package diagram : road map sistem umum Class diagram : attribut dan method yang menggambarkan tentang kelas tersebut Catatan: UML BUKAN sebagai pengganti dokumentasi pada source code 7

8 Pengguna Menggambarkan kebutuhan fungsional sistem Business Analyst Memperjelas alur proses/ logika sistem System Architect Membangun arsitektur sistem secara umum Menggambarkan hubungan antar komponen Developer Mengimplementasikan rancangan menjadi code Integrator Melihat hubungan antar komponen dan menggabungkan komponen-komponen tersebut Tester/ Quality Assurance Menguji produk berdasarkan desain yang sudah dibangun 8

9 UML bersifat komersial Awalnya memang oleh Rational, tetapi sekarang sudah dibawah OMG, organisasi nirlaba UML susah/kompleks UML sangatlah luas, tidak perlu digunakan semua Tidak mungkin mengimplementasikan semua notasi untuk setiap kasus Pelajari dan gunakan sesuai kebutuhan dan target pengguna UML menghabiskan waktu Jika dibuat dengan benar, bisa memangkas waktu development dan komunikasi serta meningkatkan pemahaman, produktivitas, dan kualitas Lebih baik waktu terbuang didepan daripada terbuang di belakang, karena biayanya jauh lebih besar 9

10 Things Relationships Diagrams 10

11 Structural things classes, interfaces, collaborations, use cases, active classes, components, nodes. Behavioral things interactions, state machines. Grouping things packages. Annotational things notes. 11

12 Dependency Association Generalization Realization 12

13 Dependency Suatu hubungan semantik antara dua things dimana perubahan pada satu thing (independent) mungkin mempengaruhi semantik thing (dependent) lain. ScheduleAlgorithm RegistrationManager 13

14 Association An association is a structural relationship that specifies that objects of one thing are connected to objects of another. Hubungan struktural yang menggambarkan sehimpunan mata rantai antar objek. Bank Teller serves Customer 14

15 Aggregation An aggregation is a special form of association that specifies a whole part relationship between the aggregate (the whole) and a component (the part). Course CourseOffering 15

16 Generalization A generalization is a relationship between a general thing and a more specific kind of that thing. Sometimes it is called an ''is a kind of'' relationship. Hubungan spesialisasi dimana objek dari elemen khusus (anak) merupakanpengganti untuk objek elemen umum (induk) Employment Teller Manager 16

17 Realization A realization is a semantic relationship between classifiers, wherein, one classifier specifies a contract that another classifier guarantees to carry out. Hubungan antara antarmuka yang tersedia secara umum (interface atau use case) dengan penerapan detail dari antarmuka (class, package, atau use case realization). Billing.exe Billing System <<interface>> Register.exe 17

18 UML mendefinisikan diagram-diagram berikut ini : use case diagram class diagram behaviour diagram : -- statechart diagram -- activity diagram interaction diagram : -- sequence diagram -- collaboration diagram component diagram deployment diagram 18

19 Setiap sistem yang kompleks selalu akan menjadi lebih baik apabila didekati melalui himpunan berbagai sudut pandang yang kecil yang satu sama lain hampir saling bebas. Sudut pandang tunggal tidak mencukupi. Diagram yang berbeda-beda tersebut dapat menyatakan tingkatan yang berbeda-beda dalam proses rekayasa. Diagram-diagram tersebut dibuat agar model yang dibuat semakin mendekati realitas. 19

20 A use case diagram shows a set of use cases and actors and their relationships. Menjelaskan manfaat sistem jika dilihat menurut pandangan orang yang berada di luar sistem (actor) Use case diagram dapat digunakan selama proses analisis untuk menangkap requirement sistem Selama tahap desain, use case diagram menangkap perilaku sistem saat diimplementasikan 20

21 21

22 Membantu memvisualisasi struktur kelas-kelas dari suatu sistem. Class diagram memperlihatkan hubungan antar kelas dan penjelasan detail tiaptiap kelas di dalam model desain dari suatu sistem. Selama proses analisis, class diagram memperlihatkan aturan-aturan dan tanggungjawab entitas yang menentukan perilaku sistem. Selama tahap desain, class diagram berperan menangkap struktur dari semua kelas-kelas yang membentuk arsitektur sistem yang dibuat. 22

23 Class memiliki tiga area pokok : 1. Nama (dan stereotype) 2. Atribut 3. Metoda Atribut dan metoda dapat memiliki salah satu sifat berikut : Private, tidak dapat dipanggil dari luar class yang bersangkutan Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya Public, dapat dipanggil oleh siapa saja 23

24 24

25 Menjelaskan interaksi objek yang disusun dalam suatu urutan waktu. Diagram ini secara khusus berasosiasi dengan use case. Memperlihatkan tahap demi tahap apa yang seharusnya terjadi untuk menghasilkan sesuatu di dalam use case. Menekankan pada urutan kejadian. 25

26 26

27 Melihat pada interaksi dan hubungan terstruktur antar objek. Tipe diagram ini menekankan pada hubungan (relationship) antar objek Dalam satu collaboration diagram terdapat beberapa object, link dan message. Digunakan sebagai alat untuk menggambarkan interaksi yang mengungkapkan keputusan mengenai perilaku sistem 27

28 28

29 Memodelkan alur kerja (workflow) sebuah proses bisnis dan urutan aktifitas dalam suatu proses. Sangat mirip dengan flowchart, karena dapat memodelkan sebuah alur kerja dari satu aktifitas ke aktifitas yang lain atau dari satu aktifitas ke dalam keadaan sesaat (state). Juga berguna untuk menggambarkan perilaku paralel atau menjelakan bagaimana perilaku dalam berbagai use case berinteraksi. 29

30 30

31 Untuk memodelkan perilaku dinamis satu kelas atau objek Memperlihatkan urutan keadaan sesaat (state) yang dilalui oleh sebuah objek, kejadian yang menyebabkan sebuah transisi dari satu state atau aktifitas kepada yang lainnya, dan aksi yang menyebabkan perubahan satu state atau aktifitas. Khususnya digunakan untuk memodelkan tahaptahap diskrit dari sebuah siklus hidup objek. 31

32 32

33 Menggambarkan alokasi semua kelas dan objek ke dalam komponen-komponen dalam desain fisik perangkat lunak. Memperlihatkan pengaturan dan ketergantungan antara komponenkomponen perangkat lunak, seperti source code, binary code, dan komponen tereksekusi (executable components) 33

34 Billing.exe Register.exe Billing System Course.dll Course People.dll User Student Professor Course Course Offering 34

35 Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/ IP) dan requirement dapat juga didefinisikan dalam diagram ini. 35

36 Registration Database Library Main Building Dorm 36

37 Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul. 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. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem. Berdasarkan use case diagram, mulailah membuat activity diagram. 37

38 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. Buarlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case. 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. 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. 38

39 Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node. 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. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual Piranti lunak siap dirilis. 39

40 UML: Use Case Diagram Catatan Pelajari OOP dasar!!!! Anda tidak akan paham sebagian istilah-istilah dalam diagram UML jika Anda tidak memahami konsep dasar OOP 40