materi kuliah it505 - 1b (rup-uml)
DESCRIPTION
aaaaTRANSCRIPT
Materi 1b Kuliah IT-505 PSBO
©Ayi Purbasari, S.T., M.T. @Unpas – 2010/2011
(Rational) Unified Process-(R)UP
04/19/23 -ap- 3
Unified Process
• Unified Process adalah proses pembangunan perangkat lunak. Proses pembangunan perangkat lunak, secara umum dapat dinyatakan sebagai proses untuk mengubah kebutuhan pengguna menjadi sebuah sistem perangkat lunak.
• Proses pembangunan perangkat lunak harus mendefinisikan Siapa harus mengerjakan Apa, Kapan dan Bagaimana dalam membangun produk perangkat lunak.
• Proses yang baik haruslah dapat menjamin dihasilkannya perangkat lunak yang berkualitas baik, yaitu perangkat lunak yang memenuhi kebutuhan penggunanya, yang dihasilkan pada jadwal yang telah ditetapkan, dan dengan biaya yang telah direncanakan.
04/19/23 -ap- 4
Unified Process
• Unified Process menerapkan enam prinsip pembangunan perangkat lunak yang didefinisikan berdasarkan pendekatan pembangunan perangkat lunak yang terbukti secara komersial, yang apabila diterapkan dapat memecahkan masalah yang umum muncul dalam pembangunanperangkat lunak (best practices), yaitu:– Membangun secara iteratif– Mengelola kebutuhan (requirements)– Menggunakan component architectures– Memodelkan perangkat lunak secara visual– Melakukan verifikasi kualitas– Mengendalikan perubahan.
• diformalkan ke dalam sekumpulan prosedur detil yang lengkap
04/19/23 -ap- 5
Gambaran RUP
Business Modeling
Requirements
Analysis & Design
Workflows Inception
Elaboration
PhasesConstruction Transitio
n
Implementation
Test
DeploymentConfiguration &
Change Management
Project Management
Environment
Iterations
Initial E # 1
E # 2
C # 1
C # 2
C # n
T #1
T #2
Co
nte
nt
04/19/23 -ap- 6
RUP vs Waterfall
Risk
Transition
Inception
Elaboration
Construction
PreliminaryIteration
Architect.Iteration
Architect.Iteration
Devel. Iteration
Devel. Iteration
Devel. Iteration
TransitionIteration
TransitionIteration
Post-deployment
Waterfall
Time
04/19/23 -ap- 7
Gambaran RUP
• Proses pengembangan pada RUP dinyatakan dalam dua dimensi, atau dua sumbu – sumbu horizontal (sumbu x) merepresentasi
waktu dan menunjukkan aspek dinamis dari proses, yaitu siklus, tahap, iterasi, dan milestone.
– sumbu vertikal (sumbu y) merepresentasikan aspek statis dari proses, yaitu aktivitas, artifak, pelaksana kerja (worker) dan aliran kerja (workflow).
04/19/23 -ap- 8
Aliran Kerja RUP
• Ada dua jenis aliran kerja (workflow) pada RUP, yaitu aliran kerja utama dan aliran kerja pendukung.
• Aliran Kerja Utama:– Pemodelan bisnis (business modeling)
• Mendeskripsikan struktur dan proses-proses bisnis organisasi.
– Kebutuhan (requirements)• Mendefinisikan kebutuhan perangkat lunak dengan
menggunakan metode use case.
04/19/23 -ap- 9
Aliran Kerja RUP
– Analisis dan perancangan (analysis and design)• Mendeskripsikan berbagai arsitektur perangkat lunak
dari berbagai sudut pandang.
– Implementasi (implementation)• Menulis kode-kode program, menguji, dan
mengintegrasikan unit-unit programnya.
– Pengujian (testing)• Mendeskripsikan kasus uji, prosedur, dan alat ukur
pengujian.
– Deployment• Menangani konfigurasi sistem yang akan diserahkan.
04/19/23 -ap- 10
Aliran Kerja RUP
• Aliran Kerja Pendukung:– Manajemen konfigurasi dan perubahan
(configuration and change management)• Mengendalikan perubahan dan memelihara artifak-
artifak proyek.
– Manajemen proyek (project management)• Mendeskripsikan berbagai strategi pekerjaan dengan
proses yang berulang.
– Lingkungan (environment)• Menangani infrastruktur yang dibutuhkan untuk
mengembangkan sistem.
04/19/23 -ap- 11
Fase pada R(UP)
• Unified Process terdiri dari empat fase, yaitu:– Fase Inception– Fase Elaboration– Fase Construction– Fase Transition
• Setiap fase dapat dilaksanakan dalam satu atau lebih iterasi yang jumlahnya mungkin berbeda untuk setiap fasenya.
• Setiap iterasi menghasilkan suatu release yang semakin lama akan semakin mendekati aplikasi final.
• Release internal digunakan untuk kepentingan internal, sedangkat release eksternal diberikan kepada pihak pemesan (pengguna).
04/19/23 -ap- 12
Fase pada (R)UP
• Permulaan (inception)– Tahap inception fokus pada penentuan
manfaat perangkat lunak yang harus dihasilkan, penetapan proses-proses bisnis (business case), dan perencanaan proyek.
• Pemerincian (elaboration)– Tahap untuk menentukan use case (set of
activities) dari perangkat lunak berikut rancangan arsitekturnya.
04/19/23 -ap- 13
Fase pada (R)UP
• Konstruksi (construction)– Membangun produk perangkat lunak secara
lengkap yang siap diserahkan kepada pemakai.
• Transisi (transition)– Menyerahkan perangkat lunak kepada
pemakai, mengujinya di tempat pemakai, dan memperbaiki masalah-masalah yang muncul saat dan setelah pengujian.
04/19/23 -ap- 14
Inception – Fase untuk mendefinisikan lingkup proyek
• Pada fase ini dilakukan penjajakan apakah proyek perangkat lunak dapat dilangsungkan atau tidak.
• Pertimbangan dapat didasarkan pada faktor ekonomi.
• Pada fase ini dihasilkan gambaran perangkat lunak yang akan dibangun, yang didefinisikan sebagai lingkup proyek, dengan melakukan identifikasi actor dan use case yang paling esensial (biasanya mencapai 20% dari model yang lengkap).
• Selain itu, dibuat perencanaan bisnis yang menentukan sumberdaya yang dibutuhkan untuk proyek ini.
04/19/23 -ap- 15
Inception – Fase untuk mendefinisikan lingkup proyek
• Artifak yang dihasilkan pada fase ini adalah:– Business model.– Business case.– Daftar fitur– Use case diagram dan use case scenario tahap
awal yang telah diberi prioritas.– Deskripsi arsitektur dokumen.– Prototipe user interface.– Risk list.
04/19/23 -ap- 16
Inception – Fase untuk mendefinisikan lingkup proyek
• Prototipe yang dihasilkan pada umumnya berupa throw-away prototype, sementara deskripsi arsitektur merupakan dasar untuk aktivitas selanjutnya.
• Beberapa kesalahan yang biasa timbul pada fase inception adalah:– Memakan waktu berminggu-minggu– Adanya usaha untuk mendefinisikan seluruh kebutuhan
perangkat lunak– Estimasi dan rencana yang ada diharapkan tidak akan
berubah hingga akhir proyek– Deskripsi arsitektur perangkat lunak yang lengkap– Tidak adanya business case.– Semua use case dituliskan secara detail.– Tidak ada use case yang dituliskan secara detail.
04/19/23 -ap- 17
Inception – Fase untuk mendefinisikan lingkup proyek
• Kriteria evaluasi pada fase ini meliputi: kesepakatan stakeholder atas lingkup proyek dan perkiraan biaya dan jadwal, kemudahan pemahaman spesifikasi kebutuhan dengan munculnya use case urtama pada model, perkiraan biaya/jadwal, prioritas, resiko, dan proses pembangunan perangkat lunak yang akan digunakan, kedalaman prototipe arsitektur yang dibuat, pengeluaran nyata vs rencana pengeluaran.
04/19/23 -ap- 18
Elaboration
• Fase untuk merencanakan proyek, membuat spesifikasi kemampuan utama, dan membuat baseline architecture
• Fokus dari fase ini adalah menentukan apakah pembangunan perangkat lunak sanggup dilakukan oleh pengembang.
• Hal ini didasarkan pada gambaran arsitektur perangkat lunak yang sudah lebih detail.
• Pada tahap ini dapat dilakukan tawar menawar mengenai jadwal, jumlah pegawai, dan biaya yang akan dikeluarkan.
• Tujuan akhir yang ingin dicapai pada fase ini adalah terciptanya suatu arsitektur perangkat lunak yang telah stabil.
04/19/23 -ap- 19
Elaboration
• Artifak yang dihasilkan pada fase ini adalah:– Business model yang telah direvisi.– Use case diagram dan use case scenario yang
lengkap.– Sequence diagram.– Class diagram.– Conding standard dan naming convention.– Detailed user interface.– Skeleton code.– Preliminary user manual.– Updated risk list.
04/19/23 -ap- 20
Elaboration
• Pada tahap ini deskripsi arsitektur dititikberatkan pada paket analisis, yang belum spesifik terhadap bahasa pemrograman.
• Tetapi di sisi lain, paket desain (sudah spesifik terhadap bahasa pemrograman) juga sudah didefinisikan untuk keperluan pembangunan skeleton code awal.
04/19/23 -ap- 21
Elaboration
• Beberapa kesalahan yang mungkin timbul pada fase elaboration adalah:
1. Memakan waktu lebih dari beberapa bulan.2. Hanya terdapat satu kali iterasi3. Hampir seluruh spesifikasi kebutuhan
didefinisikan sebelum elaboration.4. Elemen dengan resiko tinggi tidak
ditangani.5. Tidak ada kode program yang dihasilkan.
04/19/23 -ap- 22
Elaboration
6. Adanya usaha untuk melakukan seluruh desain sebelum programming. Seharusnya dilakukan secara iteratif.
7. Tidak adanya keterlibatan user.8. Deskripsi arsitektur telah dianggap selesai
sebelum programming.9. Programming dilakukan hanya untuk
membuktikan bahwa hasil perancangan dapat diimplementasikan. Seharusnya kode program yang dihasilkan berupa kode program yang secara terus menerus dikembangkan hingga dihasilkan produk jadi.
04/19/23 -ap- 23
Elaboration
• Kriteria evaluasi pada fase ini meliputi:stabilitas model produk dan arsitektur, resolusi untuk resiko utama, keberterimaan (acceptance) stakeholder terhadap model produk dan rencana proyek, level pengeluaran.
04/19/23 -ap- 24
Construction
• Fase untuk membangun produk• Pada fase ini dilakukan implementasi kode
program sesuai hasil perancangan sebelumnya.
• Milestones yang terdapat pada fase ini berupa kode program yang sudah dapat menjalankan fungsi-fungsi tertentu.
• Produk perangkat lunak dibangun secara incremental dalam beberapa iterasi hingga dihasilkan beta release.
04/19/23 -ap- 25
Construction
• Artifak yang dihasilkan pada fase ini adalah:– Kode program.– Updated use case diagram and use case
scenario.– Updated class diagram.– Updated sequence diagram.– User manual untuk versi beta.
• Kriteria evaluasi pada fase ini meliputi: stabilitas dan kematangan release produk, kesiapan stakeholders untuk fase keempat, dan level pengeluaran.
04/19/23 -ap- 26
Transition
• Fase untuk masa transisi pada saat penerapan produk di lingkungan pengguna
• Pada fase ini, secara keseluruhan pembangunan perangkat lunak telah selesai.
• Fase ini diawali dengan beta release. • Pada fase ini, produk perangkat lunak akan
diserahkan kepada pengguna untuk mulai digunakan.
• Untuk mendukung operasional perangkat lunak, dapat dilakukan pelatihan untuk pengguna.
04/19/23 -ap- 27
Transition
• Artifak yang dihasilkan pada fase ini adalah:– Kode program yang telah dapat
diimplementasikan pada lingkungan pengguna.– Use case diagram, use case scenario,
sequence diagram, dan class diagram yang sesuai dengan kode program versi akhir.
– Installation wizard.– User manual.– Training material.
04/19/23 -ap- 28
Transition
• Di akhir fase ini, dibuat keputusan apakah produk akan di-release atau tidak berdasarkan level kepuasan pengguna pada fase keempat ini.
• Apabila ada kekurangan, dapat diinisiasi siklus berikutnya untuk meningkatkan kemampuan produk.
04/19/23 -ap- 29
Pelaksanaan Aktivitas Unified Process
• Bobot pekerjaan di setiap fase berbeda-beda. Berikut adalah perkiraan kasar mengenai bobot pekerjaan di setiap fase:– Fase insepsi(15%)– Fase elaborasi(35%)– Fase konstruksi(35%)– Fase Transisi(15%)
UML
04/19/23 -ap- 31
Tujuan
• Mengetahui sejarah UML• Mengetahui diagram UML dan notasi
dasarnya • Dapat menjelaskan arti dari elemen UML • Dapat menjelaskan arti dari sebuah diagram
UML• Mengetahui kapan memilih dan
menggunakan diagram UML• Dapat mengaplikasikan diagram UML pada
proyek perangkat lunak
04/19/23 -ap- 32
UML .. (1)
• Oktober 1994, ketika James Rumbaugh - OMT (Object Modeling Technique) bergabung dengan Grady Booch - the Booch Unified Method.
• Akhir 1995 Ivar Jacobson, OOSE (Object-Oriented Software Engineering)
• Draft metoda UML versi 0.8, Oktober 1995.• Juli 1996 muncul versi 0.9, versi 0.91 pada
bulan Oktober. • Juli 1997, Object Management Group
(OMG) merepresentasikan UML versi 1.0
04/19/23 -ap- 33
UML .. (2)
04/19/23 -ap- 34
UML .. (3)
04/19/23 -ap- 35
UML .. (4)
• UML: Unified Modeling Language bahasa atau alat bantu untuk menentukan, visualisasi, kontruksi dan mendokumentasikan artifacts[1] dari sistem software.
• UML:notasi diagramatik untuk pemodelan sistem yang menggunakan konsep pendekatan berorientasi objek [1] Artifact adalah sepotong informasi yang digunakan untuk dihasilkan dalam suatu proses rekayasa software. Artifact dapat berupa model, deskripsi atau software.
04/19/23 -ap- 36
UML .. (5)
• UML:bahasa standard untuk pengembangan sebuah software bagaimana membuat dan membentuk model-model, tetapi tidak menyampaikan apa dan kapan model yang seharusnya dibuat
• Bahasa model adalah sebuah bahasa yang mempunyai kosakata dan konsep tatanan/aturan penulisan serta secara fisik mempresentasikan dari sebuah sistem.
04/19/23 -ap- 37
Bahasa Pemodelan UML .. (1)
• Use Case Modeling teknik analisis kebutuhan untuk mendefinisikan aturan-aturan dan proses-proses bisnis, serta bagaimana bentuk dukungan sistem aplikasi untuk proses-proses tersebut.
• Class and Object Modeling teknik untuk memodelkan kelas-kelas dan objek-objek dari aplikasi serta arsitektur aplikasi
04/19/23 -ap- 38
Bahasa Pemodelan UML .. (2)
• Component Modeling teknik pemodelan unit-unit fisik dari kode sumber dan executable units menjadi sebuah aplikasi
• Distribution and Deployment Modeling teknik pemodelan bagaimana aplikasi dipetakan ke jaringan penyebaran terdistribusi (distributed deployment network)
04/19/23 -ap- 39
Model Konseptual UML .. (1)
• Adalah model yang mengabstraksikan komponen-komponen yang menyusun UML:
• Blok pembangun (building blocks), merupakan kosakata yang menjelaskan bagaimana semantik dan sintaks dari setiap bagian-bagian model UML. Terdapat tiga kategori, yaitu:– Benda/things adalah abstraksi yang pertama
dalam sebuah model, mencakup structural things, behavioral things, grouping things dan notational things
04/19/23 -ap- 40
Model Konseptual UML .. (2)
– Hubungan/relationship ialah sebagai alat komunikasi dari benda-benda, mencakup ketergantungan (dependency), asosiasi (association), generalisasi (generalization) dan realisasi (realization).
– Diagram sebagai kumpulan/group dari benda-benda/things, yang menggambarkan permasalahan maupun solusi dari permasalahan suatu model. Secara umum, UML mempunyai tujuh diagram, yaitu use-case, class, object, state, sequence, collaboration, component dan deployment diagram
04/19/23 -ap- 41
Model Konseptual UML .. (3)
• Aturan (rules), menunjukkan bagaimana building block dirangkai/diletakkan bersama-sama untuk membangun model. UML mempunyai aturan-aturan semantik untuk:– Nama, aturan penamaan untuk things,
hubungan antar abstraksi dan diagram– Ruang lingkup, konteks yang memberikan
arti spesifik dari sebuah nama.
04/19/23 -ap- 42
Model Konseptual UML .. (4)
– Visibility, aturan yang dapat menunjukan bagaimana nama dapat dilihat dan digunakan oleh elemen lain.
– Integritas, aturan yang menunjukkan bagaimana hubungan antar elemen yang konsisten dan tepat.
– Eksekusi, aturan yang menunjukkan apa artinya untuk menjalankan atau mensimulasikan model dinamis
04/19/23 -ap- 43
Model Konseptual UML .. (5)
• Mekanisme umum (common mechanism), mencakup:– Spesifikasi, penjelasan rinci dari suatu model atau
elemen model– Dandanan (adornment), notasi yang menyediakan
representasi visual dari aspek-aspek penting lainnya.
– Pembagian secara umum (common division), pembagian antara kelas dan objek serta pemisahan antara antarmuka dan implementasi.
– Mekanisme pengembangan (extensibility mechanism), mekanisme untuk mengembangkan model yang ada
04/19/23 -ap- 44
Diagram UML
• Diagram adalah representasi grafis dari sekumpulan elemen. Secara umum, beberapa diagram yang digunakan oleh UML adalah:
• Diagram kelas (class diagram), mengambarkan keberadaan dari kelas-kelas dan hubungannya dengan logical view dari sebuah sistem
04/19/23 -ap- 45
Class Diagram
Kelas/ObjekAtribut
Operasi/Metode()Kelas/Objek
Atribut
Operasi/Metode()Kelas/Objek
Atribut
Operasi/Metode()
04/19/23 -ap- 46
Use Case Diagram .. (1)
• Diagram use case (use case diagram), menggambarkan use case dari sistem dan aktor-aktor[1] yang terlibat [1] Aktor adalah seseorang atau sesuatu yang berorientasi dengan sistem atau yang menggunakan sistem tersebut.
• Berinteraksi dengan sistem artinya bahwa aktor mengirimkan atau menerima pesan ke atau dari sistem, atau bertukar informasi dengan sistem.
04/19/23 -ap- 47
Use Case Diagram .. (2)
• Dapat dikatakan bahwa aktor mempunyai use case, sedangkan use case menyatakan fungsi lengkap yang dimiliki oleh aktor.
• Sebuah use case harus menyampaikan sesuatu nilai ke aktor yang diinginkan dari sistem
• Diagram use case terdiri dari kumpulan graf aktor, himpunan use case yang berada di dalam batas sistem. Komunikasi antar aktor dengan use case dan generalisasi antar use case
04/19/23 -ap- 48
Use Case Diagram .. (3)
UseCase 1
(from Use Case View )
Aktor
Use Case 2
04/19/23 -ap- 49
Use Case Diagram .. (4)
Nama Elemen Notasi
Use Case
Aktor
Relasi Include<<Include>>
Relasi Extend<<Extend>>
NamaUse Case
04/19/23 -ap- 50
Collaboration Diagram .. (1)
• Diagram kolaborasi (collaboration diagram), digunakan untuk menyatakan skenario yang memperlihatkan pesan yang mengalir di dalam diagram objek. Pesan yang mengalir tersebut mungkin merupakan pemanggilan prosedur atau asynchronous link
04/19/23 -ap- 51
Collaboration Diagram .. (2)
: Aktor
Objek 1 Objek 2
Objek 3 :kelas
1: event 2: operasi ke-1
3: operasi ke-2 (parameter list)
4: operasi ke-3 (parameter list) 5: operasi ke-4 (parameter list)
04/19/23 -ap- 52
Sequence Diagram .. (1)
• Diagram sekuen (Sequence diagram), menunjukkan kerja sama yang dinamis antar objek, aspek terpenting dalam diagram ini adalah untuk menunjukan deretan pesan yang dikirimkan diantara objek ha1 ini juga menunjukan interaksi antar objek
04/19/23 -ap- 53
Sequence Diagram .. (2)
: Aktor
Objek 1 Objek 2 Objek 3
proses ke-1
proses ke-2
proses ke-3
04/19/23 -ap- 54
Statechart Diagram .. (1)
• Diagram statechart ( Statechart diagram), menggambarkan state space dari konteks yang diberikan, kejadian yang menyebabkan transisi dari state satu ke lainnya, dan aksi yang dihasilkan
04/19/23 -ap- 55
Statechart Diagram .. (2)
NewStateState 1 State 2
State 3stop
04/19/23 -ap- 56
Component Diagram .. (1)
• Diagram komponen (component diagram), menunjukan kode dalam hubungannya dengan komponen kode. – Sebuah komponen dapat menjadi sumber kode
komponen, dapat berupa komponen binary ataupun komponen executable.
– Sebuah komponen mengandung informasi tentang logical class yag diimplementasikan.
– Jadi diagram komponen adalah pemetaan dari logical view ke component view, ketergantungan antara komponen dapat ditunjukan, sehingga akan membuat lebih mudah untuk menganalisa dalam sebuah komponen
04/19/23 -ap- 57
Component Diagram .. (2)
komponen 1
komponen 2
04/19/23 -ap- 58
Deployment Diagram .. (1)
• Deployment diagram, menunjukan arsitektur dari perangkat keras dan perangkat lunak dalam sistem serta deployment view yang menggambarkan arsitektur fisik aktual dari sebuah sistem.
04/19/23 -ap- 59
Deployment Diagram .. (2)
node 1 node 2
link name