Pattern Software Design - Tugas Personal ke-1 Week 2

Individual Assignment Pattern Software Design


Soal Teori

1. Apa yang dimaksud dengan komplektifitas dalam perangkat lunak?

Kompleksitas perangkat lunak merupakan indikator kerumitan dalam memahami, memelihara, memodifikasi dan menggunakan kembali perangkat lunak. Jika nilai kompleksitas tinggi maka developer akan kesulitan dalam memahami perangkat lunak pada tahap pemeliharaan maupun jika akan melakukan perubahan. Oleh karena itu kompleksitas perangkat lunak perlu dipantau untuk menetapkan kualitas dan kehandalan perangkat lunak tersebut menggunakan software metric.

Kompleksitas adalah suatu indikator antar hubungan di dalam suatu proyek, program, atau portofolio yang memengaruhi cara bagaimana hubungan ini akan dikelola dan keahlian yang dibutuhkan untuk mengelolanya.

 

2. DDD menangani tantangan untuk memahami domain masalah dan menciptakan solusi yang dapat dipelihara yang berguna untuk memecahkan masalah di dalamnya. Ini mencapai ini dengan memanfaatkan sejumlah pola strategis dan taktis, apakah itu pola Strategis DDD?

Pola strategic DDD menawarkan problem domain dan membentuk arsitektur dari sebuah aplikasi. Pola strategis DDD :

  • Menyaring Domain Masalah untuk Mengungkap Apa yang Penting Domain inti adalah kekuatan pendorong di belakang produk yang sedang dikembangkan. Menemukan domain inti membantu tim memahami mengapa mereka memproduksi perangkat lunak dan apa artinya perangkat lunak tersebut agar berhasil bagi bisnis.

  • Membuat Model untuk Memecahkan Masalah Domain Model perangkat lunak dibangun untuk setiap subdomain untuk menangani masalah domain. Model ini bukanlah model kehidupan nyata tetapi lebih merupakan abstraksi yang dibangun untuk memenuhi persyaratan kasus penggunaan bisnis dengan tetap mempertahankan aturan dan logika domain bisnis.

  • Menggunakan Bahasa Bersama untuk Mengaktifkan Kolaborasi Pemodelan Model dibangun melalui kolaborasi pakar domain dan tim pengembangan. Komunikasi dicapai dengan menggunakan bahasa yang dikenal sebagai ubiquitous language (UL) untuk menghubungkan model perangkat lunak secara efisien dan efektif ke model analisis konseptual.

  • Memisahkan Model dari Ambiguitas dan Korupsi Model yang lebih besar dapat dipecah menjadi model yang lebih kecil dan didefinisikan dalam konteks terbatas yang terpisah di mana terdapat ambiguitas dalam terminologi atau di mana beberapa tim bekerja untuk mengurangi kompleksitas. Model diisolasi dari kode infrastruktur untuk menghindari kerumitan yang tidak disengaja dari penggabungan konsep teknis dan bisnis

  • Memahami Hubungan antar Konteks DDD memahami kebutuhan untuk memastikan bahwa tim dan bisnis memahami dengan jelas bagaimana model dan konteks terpisah bekerja sama untuk memecahkan masalah domain yang tersebar di seluruh subdomain. Peta konteks membantu memahami gambaran yang lebih besar. Mereka memungkinkan tim untuk memahami model apa yang ada, untuk apa mereka bertanggung jawab, dan di mana batasan penerapannya.

 

3. Jelaskan perbedaan antara sistem yang dibangun dengan structured analysis and design (analisa dan perancangan terstruktur) dengan sistem yang dibangun dengan object-oriented analysis and design?

Perancangan Terstruktur (Structured Analysis and Design / SSAD) adalah aktivitas mentransformasikan suatu hasil analisis ke dalam suatu perencanaan untuk dapat diimplementasikan ( diotomasikan).

Kelebihan

  • Milestone diperlihatkan dengan jelas yang memudahkan dalam manajemen proyek.

  • SSAD merupakan pendekatan visual, ini membuat metode ini mudah dimengerti oleh pengguna atau programmer.

  • Penggunaan analisis grafis dan tool seperti DFD menjadikan SSAD menjadikan bagus untuk digunakan.

  • SSAD merupakan metode yang diketahui secara umum pada berbagai industri.

Kekurangan

  • SSAD berorientasi utama pada proses, sehingga mengabaikan kebutuhan non-fungsional.

  • Sedikit sekali manajemen langsung terkait dengan SSAD.

  • Prinsip dasar SSAD merupakan pengembangan non-iterative (waterfall), akan tetapi kebutuhan akan berubah pada setiap proses.

Perancangan Berbasis Objek (Object-oriented Analysis and Design / OOAD) adalah suatu teknik atau cara pendekatan baru dalam melihat permasalahan dan sistem (sistem perangkat lunak. Sistem informasi, atau sistem lainnya).

Kelebihan

  • Dibandingkan dengan metode SSAD, OOAD lebih mudah digunakan dalam pembangunan sistem.

  • Dibandingkan dengan SSAD, waktu pengembangan, level organisasi, ketangguhan,dan penggunaan kembali (reuse) kode program lebih tinggi dibandingkan dengan metode OOAD (Sommerville, 2000).

  • Tidak ada pemisahan antara fase desain dan analisis, sehingga meningkatkan komunikasi antara user dan developer dari awal hingga akhir pembangunan sistem.

  • Analis dan programmer tidak dibatasi dengan batasan implementasi sistem, jadi desain dapat diformulasikan yang dapat dikonfirmasi dengan berbagai lingkungan eksekusi.

Kekurangan

  • Pada awal desain OOAD, sistem mungkin akan sangat simple.

  • Pada OOAD lebih fokus pada coding dibandingkan dengan SSAD.

  • Pada OOAD tidak menekankan pada kinerja team seperti pada SSAD.

 

4. Apa yang dimaksud dengan design pattern? dan keuntungan yang didapatkan dalam mengimplementasikan design pattern ?

Design pattern adalah suatu metode untuk membantu menyelesaikan permasalahan- permasalahan yang umumnya berulang atau memiliki pola dalam pengembangan software.

Kelebihannya dapat membantu mempercepat pengembangan suatu software karena pola-pola yang dijelaskan di dalam Design Pattern merupakan paradigma-paradigma yang telah teruji kegunaannya.

Dengan menggunakan Design Pattern ini dapat membantu menyelesaikan sebuah masalah, juga membuat komunikasi menjadi lebih efektif, dan programmer dapat melakukan re-usability projek lebih mudah.

 

5. Apa yang disebut dengan hal dibawah ini :

  • Bounded Context

    merupakan sebuah pendekatan yang memisahkan model besar kedalam konteks kecil secara eksplisit dan hubungan antara keduanya. Dengan Bounded Context, tidak perlu khawatir atas perbedaan kosakata atau perbedaan konsep keilmuan yang dipakai dalam pengembangan software.

  • Ubiquitous Language yaitu bahasa yang dipilih/dibuat oleh semua orang yang terlibat pada project seperti Tim pengembang dan domain expert akan bekerja sama untuk menentukan bahasa yang nantinya akan digunakan pada program. Dan pada akhirnya domain expert juga dapat mengerti kode yang tim pengembang tulis.

  • Core domain

    adalah subdomain terpenting dalam sebuah bisnis dan bisa membuat berbeda dari yang lain. Jika tidak ada core domain maka suatu bisnis tidak dapat berhasil.

  • Domain expert

    adalah orang ahli yang memiliki pengetahuan khusus , pendapat, pengalaman dan metode, serta kemampuan untuk pengaplikasian keahlian tersebut guna menyelesaikan masalah.

  • Business drivens

    adalah metodologi untuk mengembangkan solusi TI yang secara langsung memenuhi persyaratan bisnis .

 

Soal kasus

Buatlah artikel mengenai domain design pattern. Artikel terdiri dari 1 halaman A4 dengan line spasing “single”. Referensi dapat menggunakan (jurnal, proceeding, buku, blog).

Desain Domain-Driven (DDD) adalah pendekatan untuk pengembangan perangkat lunak yang memungkinkan tim untuk secara efektif mengelola konstruksi dan pemeliharaan perangkat lunak untuk domain masalah yang kompleks. DDD adalah filosofi pengembangan yang didefinisikan oleh Eric Evans.

Dalam pengembangan software, terdapat tantangan yaitu customer tidak benar- benar mengetahui apa dia butuhkan. Berdasarkan penelitian yang dipublikasikan oleh Compustat pada tahun 2014, industri software memegang posisi ketiga urutan ketidakpastian. Terlepas dari metodologi atau kerangka yang digunakan, kita melihat masalah ketidakpastian dari sisi miskomunikasi. DDD menyediakan tools untuk menghindari miskomunikasi antara tim bisnis dan tim developer software, yaitu Ubiquitous Language.

Ubiquitous Language merupakan sebuah bahasa yang sama dalam satu tim, dibuat oleh programmer, bisnis, product owner, dan tester. Ubiquitous Language merupakan istilah yang diciptakan oleh Eric Evans untuk membangun bahasa yang umum dan kaku antara tim developer dan user.

DDD memberikan beberapa panduan yang jelas tentang bagaimana objek Anda harus berinteraksi, dan membantu Anda membagi objek Anda ke dalam kategori berikut:

  • Objek nilai, yang mewakili nilai yang mungkin memiliki sub-bagian (misalnya, tanggal mungkin memiliki hari, bulan, dan tahun).

  • Entitas, yang merupakan objek dengan identitas . Misalnya, setiap objek Pelanggan memiliki identitasnya sendiri, jadi kami tahu bahwa dua pelanggan dengan nama yang sama bukan pelanggan yang sama.

  • Akar agregat adalah objek yang memiliki objek lain. Ini adalah konsep yang kompleks dan bekerja atas dasar bahwa ada beberapa objek yang tidak masuk akal kecuali mereka memiliki pemilik. Misalnya, objek 'Jalur Pesanan' tidak masuk akal tanpa 'Pesanan' menjadi milik, jadi kami mengatakan bahwa Pesanan adalah akar agregat, dan objek Baris Pesanan hanya dapat dimanipulasi melalui metode di objek Pesanan.

DDD juga merekomendasikan beberapa pola:

  • Repositori , pola untuk kegigihan (menyimpan dan memuat data Anda, biasanya ke/dari database).

  • Pabrik , pola untuk pembuatan objek.

  • Layanan, pola untuk membuat objek yang memanipulasi objek domain utama

  • Anda tanpa menjadi bagian dari domain itu sendiri

 

Referensi

Evans, Eric. 2003. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison Wesley

Fowler, Martin. 2006. Ubiquitous Language. https://martinfowler.com/bliki/UbiquitousLanguage.html

Bagikan postingan ini

Penulis
Dikhi Martin

Dikhi MartinSoftware Engineer