Model UML pada Rational Unified Process

Presentasi berjudul: "Model UML pada Rational Unified Process"— Transcript presentasi:

1 Model UML pada Rational Unified Process

2 Pendahuluan Rational Unified Process merupakan hasil kerja awal :
Ivar Jacobson, Grady Booch, James Rumbaugh “Three Amigos” Konsep utama Model Workflows dan workers Phasa dan iterasi

3 Software Engineering Process

4 Iterative and Incremental
Bertahap Iterative pada setiap tahap Rencanakan secara bertahap Spesifikasi, desain dan implementasi bertahap Integrasi, test dan running setiap iterasi bertahap Evaluasi dan ulangi (iterasi), sesuai keperluan Transformasikan bag. kecil kebutuhan pengguna menjadi bag. kecil software Proyek-mini: satu langkah pada setiap waktu Pada setiap tahap terdapat perencanaan, aturan dsb Perbaikan awal dengan membangun pengetahuan(mengurangi resiko) fungsionalitas yang dibutuhkan dan kelangsungan teknis. Perbaikan selanjutnya membangun fungsionalitas produk. Risk-Driven Setiap iterasi menambah perbaikan dan mengurangi resiko

5 Feature-feature RUP Use-Case Driven
Berbasis kebutuhan dan berfokus pada pengembangan Architecture-Centric Struktur over-arching; dasar dari desain Iterative and Incremental Bertahap, pertumbuhan dikontrol melalui “mini-projects” Setiap langka mencerminkan kebutuhan dan resiko saat ini

6 Feature-feature RUP Rational Unified Process terdiri dari :
Workflow yang menghasilkan model: requirements, analysis, design/deployment, implementation, test Workers yang mengimplementasikan workflow : user, manager, analis, architect, designer, tester, dsb. Phasa development dan iterasi: inception, elaboration, construction, transition Aktivitas dalam iterasi: perencanaan, eksekusi workflow , evaluasi

7 Rational Unified Process

8 Phasa-phasa RUP Empat Phasa Inception
Membuat proses bisnis, umur sistem Mendefinisikan tujuan daur hidup Elaboration Membuat kelayakan dan batasan : keuangan, jadual, teknis dsb. Mendefinisikan arsitektur daur hidup Construction Membangun sistem Mendefinisikan kemampuan operasional awal Transition Menyerahkan fungsionalitas sistem lengkap ke pengguna Menyerahkan rilis produk

9 Waktu dan Unified Process
Pada Unifies Process, waktu mengalir melalui phasa-phasa, increment dan iterasi, tidak melalui workflow tradisional : requirementsdesignimplementation  test Phasa Waktu diantara dua milestones utama – titik-titik dimana manajemen memutuskan apakah untuk memproses pengembangan dan menyetujui jangkauan, anggaran dan jadual untuk phasa selanjutnya Iterasi Sebuah “proyek-mini” that typically crosses all five workflows (disciplines) Output adalah rilis (internal atau external) Mungkin terdapat beberapa peningkatan Increment Bagian kecil dan dapat diatur oleh sistem – sebuah bangunan Biasanya perbedaan fungsionalitas ditambahkan pada hasil increment sebelumnya

10 Phases and Iterations Phasa-phasa ( dalam waktu )
Inception Elaboration Construction Transition Banyak iterasi per phasa Manajemen resiko Selesaikan masalah sulit lebih dahulu Setiap workflow (requirement, analisa, desain, implementasi, test) dilakukan pada setiap iterasi

11 Phasa Inception Inception: membuat proses bisnis Jangkauan, batasan
Kandidat arsitektur ( meyakinkan, layak) Resiko kritis Prototype proof-of-concept ( sistem dapat memuaskan kebutuhan pengguna ) Antar muka Algoritma kunci throw-away Perkiraan pengembangan kebutuhan sumber ( bukan RUP )

12 Phasa Elaboration Elaboration: “do-ability” Berbasis arsitektural
Meliputi fungsionalitas utama Use case untuk 80%an fungsionalitas Menentukan level kualitas (misalnya reliability, performansi) Resiko utama ditransformasikan ke aktivitas yang dapat dihargai dan dijadualkan Penawaran kebutuhan sumber Jadual, staff, harga

13 Phasa Construction Construction: membangun kemampuan operasional awal
Semua use case ditemukan, digambarkan dan direalisasikan ( dipetakan ke model desain ) Menyelesaikan analisa ( menyisakan 50%an ) Menyelesaikan desain, implementasi dan test ( menyisakan 90%an ) Mempertahankan integritas arsitektural Memonitor dan mengurangi resiko

14 Phasa Transition Transition: berpindah ke lingkungan pengguna
Persiapan situs (secara fisik) Perubahan lingkungan operasional (hardware, sistem operasi, protokol komunikasi, shared components, dsb.) Lengkapi manual dan rilis dokumen lainnya Configure software to specific user environment Konfigurasi software untuk lingkungan pengguna tertentu Perbaikan kekurangan dari feedback test beta Modifikasi software sesuai keperluan

15 Kesimpulan Workflow Requirements Analysis Design Implementation Test
Feature lists Domain models Use cases Customer language External view Unambiguous models Consistent use cases Developer language Internal view Sets solution architecture Conceptual Informal models Few abstractions, subsystems, interfaces Physical Technologies and “-ilities” Many abstractions, subsystems, interfaces Detailed Formal Implement details (source, scripts, binaries, executables, etc.) Distribute executable components across computing nodes Unit test Test cases, procedures, components Integration and system tests Feed results back into process

16 Kebutuhan Resource needs
Resources Waktu 5% 20% 65% 10% Inception Elaboration 30% Construction 50% Transition Lebih banyak usaha up-front untuk proyek yang sulit

17 Setiap tahap menghasilkan kumpulan model tertentu

18 Multiple, sudut pandang konsisten pada model dasar
Model-model UML Multiple, sudut pandang konsisten pada model dasar Use Case Diagram Class Diagram Behavior Diagrams Statechart Diagram Activity Diagram Interaction Diagrams Collaboration Diagram Sequence Diagram Implementation Diagrams Component Diagram Deployment Diagram Diagrams Model

19 4+1 View Arsitektur Software
System Assembly Configuration Management Vocabulary Functionality Design View Implementation View Use Case View Behavior Process View Deployment View System Topology Distribution Delivery Installation Performance Scalability Throughput logical physical

20 Artifacts Dokumen produk Dokumen proses Dokumen proyek ( organisasi )

21 Essential Software Process
Transformasi model aplikasi konseptual menjadi model solusi detail Domain Aplikasi Model Konseptual Transformasi Domain Implementasi Model Formal

22 Output Proses adalah Model Produk
Analisa Application Objects Rekayasa Framework Solusi Model Desain Middleware Model Implementasi Distributed Platform Ekseskusi solusi

23 Aktivitas RUP dan Workers (Roles)
Analisa

24 Aktivitas RUP dan Workers (Roles) (2)
Desain

25 Aktivitas RUP dan Workers (Roles) (3)
Implementasi

26 Aktivitas RUP dan Workers (Roles) (4)
Test

27 Requirements

28 Requirements Activitas Artifact Daftar kandidat requirements
Daftar feature Memahami konteks sistem Model bisnis/domain Memahami requirements fungsionalitas Use-case model Memahami requirements kualitas dan bisnis Supplementary requirements

29 Tujuan aktivitas requirements
Mengarahkan development agar sesuai dengan sistem Tugas lainnya agar fokus dalam pembangunan sistem yang benar Membatasi apa yang boleh dan tidak dilakukan sistem Persetujuan diantara customer ( termasuk user ) dan organisasi pengembangan Dalam bahasa customer/user Tugas-tugas Daftar kandidat requirements Memahami konteks sistem Memahami requirements fungsionalitas Memahami requirements non fungsionalitas Validasi requirements

30 Dokumen requirements customer detail
Starting points Samar Sangat detail Pernyataan Visi Dokumen requirements customer detail System Requirements Domain object model Similar systems Business model

31 Analysis

32 Requirements dan analysis
Use Case Model Analysis Model Bahasa customer External view sistem Functionalitas sistem Terstruktur oleh use cases Kontrak diantara customer dan developer Redundansi, inkonsistensi Bahasa developer Internal view sistem Bagaimana merealisasikan functionalitas sistem Terstruktur oleh class-class dan package- package Sketsa realisasi fungsi; first-cut design Tidak boleh terdapat redundansi atau inkonsistensi

33 Model Analysis Analisa class-class dan/atau subsystems
Fokus pada fungsional (vs. non-fungsional) requirement Konseptual, granularity yang besar Model desain akan mempunyai ~5 kali lebih elemen model Minimal interface operasi Definisi responsibilities (textual) instead Atribute pada high level Relasi konseptual boundary (interaksi dengan actor), control (koordinasi, sequencing, transaksi) atau entity (long-lived real-life object atau event) class-class Boundary Entity Control

34 Model Analysis (2) Use case realizations
Kolaborasi yang menggambarkan bagaimana sebuah use case direalisasikan dan digambarkan dalam interaksi object-object Deskripsi tekstual flow events, class diagram, interaction diagram, special requirements Analysis Package mengorganisasikan analysis classes, use-case realizations dan analysis packages lainnya Pemisahan urusan analisis Berdasar masalah requirement domain fungsional, bukan domain solusi Model Arsitektur View “significant” dari model analysis

35 Model Analysis Berpengaruh pada Desain
Mempertahankan struktur ketika membahas requirements non-fungsional dan batasaan implementasi Packages  Subsystems Class-class analysis adalah spesifikasi dari class-class desain Entity classes  databases Boundary classes  User Interface or communications Use-case realizations Spesifikasi lebih detail dari use cases Mengidentifikasikan flow proses di desain View arsitektur akan menemukan multiple view dari model desain

36 Desain

37 Aktivitas Desain Menentukan bentuk sistem arsitektur yang memenuhi semua requirements Memahami isu pada requirements non-fungsional dan batasan teknologi Mengidentitaskan subsystem ( semua struktur, requirement, interface, class-class) yang membolehkan implementasi konkuren Membuat abstraksi yang tak terlihat pada implementasi sistem Implementasi menambah isi ke arsitektur yang stabil Menyediakan visualisasi implementasi

38 4+1 View Arsitektur dan model-model yang mendefinsikan view yang ada
Analysis Implementasi Logical View Functionality Implementation View Software management Use Case View Understandability Usability Requirements Process View Performance, scalability, throughput Deployment View System topology, delivery, installation, communication Desain Desain

39 Artifacts Model Desain
Desain Class-class Desain Subsystems Desain Use-Case Realization Class Diagrams Interaction Diagrams Desain Flow of Events Implementasi Requirements Interface Model Deployment Model Process Architecture Views Model Desain

40 Aktivitas Desain Workflow dan Worker
Arsitektural Architect Desain sebuah Use Case Use-Case Engineer Desain sebuah Class Desain sebuah Subsystem Component Engineer

41 Implementasi

42 Tugas-tugas Implementasi
Implementasi desain dalam komponen-komponen source code, script, binary, executable, dsb. Sempurnakan arsitektur Rencanakan integrasi sistem pada setiap iterasi incremental : kecil dan langkah yang teratur Distribusi sistem : petakan komponen ke node-node Implementasi class-class desain dan subsystem Komponen-komponen unit testing Integrasi komponen-komponen ( kompile dan link ke dalam satu atau lebih executable ) untuk integrasi dan testing sistem

43 Artifact Model Implementasi Descripsi Arsitektur
Komponen Implementasi Subsystem Interface Descripsi Arsitektur View Implementasi dari arsitektur Rencana pembangunan Integrasi Urutan pembangunan dalam sebuah iterasi Fungsionalitas dalam setiap pembangunan Catatan : jaga model saat ini melalui round-trip engineering Model desain menjamin visualisasi model implementasi

44 Implementasi Aktivitas Workflow dan Workers
Arsitektural Architect Integrasi Sistem System Integrator Implementasi sebuah Class Component Engineer Lakukan sebuah Unit Test Implementasi sebuah Subsystem

45 4+1 View Arsitektur dan model-model yang mendefinsikan view yang ada
Analysis Implementation Logical View Functionality Implementation View Software management Use Case View Understandability Usability Requirements Process View Performance, scalability, throughput Deployment View System topology, delivery, installation, communication Design Design

46 Testing

47 Aktivitas Testing Verifikasi hasil dari implementasi dengan testing setiap pembangunan Rencanakan test pada setiap iterasi Test integrasi untuk setiap pembangunan dalam iterasi Test sistem untuk akhir iterasi Test desain dan implementasi dengan membuat Kasus-kasus test untuk menentukan apa yang akan ditest Prosedur-prosedur test yang menentukan bagaimana melakukan test Komponen test executable untuk mengotomasi test Lakukan test dam secara sistematis menangani hasil test Pembangunan yang cacat dikirim ke workflow yang lain (misalnya desain dan implementasi) untuk perbaikan kecacatan

48 Testing pada daur hidup software
Pada umumnya, dimanapun ada hasil implementasi , terdapat sebuah test Test pada setiap pembangunan Phasa Inception : perencanaan test awal, test prototype Phasa Elaboration : test dasar arsitektural Phasa Construction : testing pada setiap pembangunan Phasa Transition : re-test perbaikan dan test regresi Test Regresi tests: dalam pembagunan baru, lakukan test ulang dari pembangunan lama untuk meyakinakan tidak ada kesalahan dalam pembangunan baru Menyusun model test Membuat kasus-kasu test yang baru untuk setiap pembangunan Perbaiki kasus-kasus test lama menjadi test regresi Pindahkan testing, prosedur dan komponen test kuno yang berhubungan

49 Artifact Artifacts model testing Artifact lainnya Kasus-kasus testing
Prosedur testing Komponen-kompenen testing Testing subsystem packages untuk model test yang kompleks Testing package subs Artifact lainnya Rencana Test Cacat Evaluasi Test