Bab 11 Desain Level Komponen
Tujuan Pembelajaran Umum Menjelaskan Perangkat Lunak Sebagai Proses Tujuan Pembelajaran Khusus Mampu Mengidentifikasikan desain level komponen
Apa itu Desain Level Komponen ? • • •
Adalah satu set lengkap komponen perangkat lunak didefinisikan selama desain arsitektur Tetapi struktur data internal dan proses rinci setiap komponen tidak terwakili pada tingkat abstraksi yang tertutup dengan kode Desain level komponen mendefinisikan struktur data, algoritma, karakteristik antarmuka, dan mekanisme komunikasi yang dialokasikan untuk masing-masing komponen
Apakah komponen •
• •
OMG Unified Modeling Language Specification [OMG01] mendefinisikan komponen sebagai o ―… a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.‖ Pandangan OO : Sebuah komponen terdiri dari sekumpulan class2x yang berkolaborasi Pandangan Konvensional: logika, struktur data internal yang dibutuhkan untuk mengimplementasi logika proses dan sebuah interface yang memungkinkan komponen untuk dipanggil sehingga data dapat dimasukkan ke dalamnya.
Komponen OO
a n a l y si s c l a ss Pri n t Jo b n u m b e rOf Pa g e s n u m b e rOf Si d e s p a p e rTy p e m agnif ic at ion p ro d u c t i o n Fe a t u re s d e si g n c o m p o n e n t c o m p u t e Jo b Co st( ) p a ssJo b t o Pri n t e r( )
c o m p u t e Jo b
Pri n t Jo b
i n i t i a t e Jo b
< < in t er f ace> > co m p u t eJo b comput ePageCost ( ) comput ePaper Cost ( ) comput ePr odCost ( ) comput eTot alJobCost ( )
elaborat ed design class Print J ob number Of Pages number Of Sides paper Type paper Weight paper Size paper Color magnif icat ion color Requir ement s pr oduct ionFeat ur es
< < in t er f ace> > in it iat eJo b buildWor kOr der ( ) checkPr ior it y ( ) passJobt o Pr oduct ion( )
collat ionOpt ions bindingOpt ions cover St ock bleed pr ior it y t ot alJobCost WOnumber comput ePageCost ( ) comput ePaper Cost ( ) comput ePr odCost ( ) comput eTot alJobCost ( ) buildWor kOr der ( ) checkPr ior it y ( ) passJobt o Pr oduct ion( )
Gambar 11.1. : Komponen OO
Gambar 11.2. : Class elaboration Prinsip-prinsip desain The Open-Closed Principle (OCP). “sebuah modul[komponen] harus terbuka untuk ekstensi, namun tertutup untuk modifikasi. The Liskov Substitution Principle (LSP). “Subclass harus dapat disubstitusi oleh basis class nya. Dependency Inversion Principle (DIP). “Tergantung pada abstraksi, tidak tergantung pada konkret.” The Interface Segregation Principle (ISP). “banyak interface spesifik client lebih baik daripada satu interface general purpose.
The Release Reuse Equivalency Principle (REP). “Bagian-bagian kecil yang dapat digunakan kembali adalah bagian-bagian kecil yang akan direlease.” The Common Closure Principle (CCP). “Class2x yang berubah bersama-sama adalah milik bersama.” \The Common Reuse Principle (CRP). “Class2x yang tidak digunakan kembali bersama-sama tidak dikelompokkan bersama.” Panduan Desain Komponen o Konvensi penyebutan nama harus ditentukan untuk komponen2x yang menjadi bagian dari model arsitektur dan kemudian disempurnakan dan diuraikan sebagai bagian dari model level komponen Interfaces o Interface menyediakan informasi penting mengenai komunikasi dan kolaborasi (yang akan membantuk kita mendapatkan OCP) Dependencies dan Inheritance o Adalah ide yang bagus untuk membuat model dependency dari kiri ke kanan dan intheritance dari bawah ke atas. Prinsip-prinsip desain 1. 2. 3. 4. 5.
Design by Contract Open-Closed Principle Subtype Substitution Depend on Abstractions Interface Segregation
Desain dengan kontrak Hubungan antara kelas dan klien dapat dilihat sebagai perjanjian formal, mengekspresikan hak dan kewajiban masing-masing pihak. Pertimbangkan operasi daftar berikut:
Barang publik menghapus (int index) membutuhkan (requirement) indeks tertentu dalam jangkauan (0 < = index <size ()) memastikan (ensures) elemen pada posisi tertentu dalam daftar ini dihapus, elemen berikutnya yang digeser ke kiri (1 dikurangi dari indeks mereka), dan unsur yang dihapus dikembalikan
Prinsip Open-Clouse Bahwa perangkat lunak terbuka untuk dijalankan dan tertutup untuk dimodifikasi
Gambar 11.3. : Prinsip Open Close Substitutability Subclass harus disubstitusikan untuk kelas dasar
Gambar 11.4. : Substitutability Ketergantungan Inversi (Dependent inversion) Tergantung pada abstraksi. Jangan tergantung pada konkret.
Gambar 11.5. : Dependent Inversion Antarmuka Segregasi (Segregasion Interface) Banyak antarmuka client-spesifik lebih baik dari pada tujuan umum antarmuka
Gambar 11.6. : Client Spesifik Kohesi Pandangan konvensional: Sebuah modul tunggal OO view: cohesion menyatakan bahwa sebuah komponen atau class melakukan enkapsulasi hanya atribut2x dan operasi2x yang punya kaitan erat dengan yang satu yang lain dan dengan class atau komponen itu sendiri. Level kohesi
Fungsional Lapisan/Layer Komunikasi Sekuensial Prosedural Temporal utility
Fungsi Kohesi Biasanya berlaku untuk operasi. Terjadi ketika sebuah modul melakukan satu dan hanya satu perhitungan dan kemudian mengembalikan hasilnya.
Gambar 11.7. : Pandangan Kohesi Kombinasi Operasi Layer Kohesi Berlaku untuk paket, komponen, dan kelas. Terjadi ketika lapisan yang lebih tinggi dapat mengakses lapisan bawah, namun lapisan bawah tidak mengakses lapisan yang lebih tinggi.
Gambar 11.8. : Layar Kohesi Kohesi Komunikasi (Communicacioneal Cohesi) Semua operasi yang mengakses data yang sama yang didefinisikan dalam satu kelas.
Secara umum, kelas tersebut hanya berfokus pada data yang dimaksud, mengakses dan menyimpannya. Contoh: Sebuah class StudentRecord yang menambahkan, menghapus, update, dan mengakses berbagai bidang rekor mahasiswa untuk komponen klie
Coupling Pandangan Konvensional: Derajat dimana sebuah komponen terhubung dengan komponen lain dan dengan dunia eksternal Pandangan OO : Pengukuran kualitatif terhadap derajat dimana class2x saling terkait satu dengan yang lain Level coupling Content Common Control Stamp Data Routine call Type use Inclusion or import External Konten Coupling Terjadi ketika salah satu komponen "diam-diam memodifikasi data yang internal untuk komponen lain" Melanggar menyembunyikan informasi Apa yang salah di sini? Contoh Content Coupling Apa yang salah disini ? public class StudentRecord { private String name; private int[ ] quizScores; public String getName() { return name; } public int getQuizScore(int n) { return quizScores[n]; } public int[ ] getAllQuizScores() { return quizScores; } ….
Gambar 11.9. Coding Coupling
Common Coupling Terjadi ketika sejumlah komponen semua menggunakan variabel global.
Gambar 11.10. : Common Coupling Routine Coupling Beberapa jenis kopling terjadi secara rutin dalam pemrograman berorientasi obyek
Gambar 11.11. : Routine Coupling
Desain Level Komponen (Componen Level Design) Identifikasi kelas desain dalam domain masalah Identifikasi kelas desain infrastruktur Kelas desain yang rumit Jelaskan sumber data persisten Perinci representasi perilaku Teliti diagram deployment Refactor merancang dan mempertimbangkan alternative Langkah 1-2 (Mengidentifikasi Kelas) Kebanyakan kelas dari masalah domain adalah kelas analisis dibuat sebagai bagian dari model analisis Kelas-kelas desain infrastruktur diperkenalkan sebagai komponen selama desain arsitektur Langkah 3 (Class Elaborasi) a) Tentukan rincian pesan ketika kelas atau komponen berkolaborasi b) Identifikasi interface yang tepat untuk setiap komponen c) Atribut rumit dan menentukan struktur data yang dibutuhkan untuk menerapkannya d) Jelaskan aliran pengolahan dalam setiap operasi secara rinci Langkah 3a (Collaboration Detail) Pesan dapat diuraikan dengan memperluas sintaks mereka dengan cara berikut: [guard condition] sequence expression (return value) := message name (argument list)
Gambar 11.12. : Detail Collaboration Langkah 3b (Aprropriate Interface) Pressman berpendapat bahwa antarmuka PrintJob "initiateJob" dalam slide 5 tidak menunjukkan kohesi cukup karena ia melakukan tiga subfunctions berbeda. Dia menyarankan refactoring ini.
Gambar 11.13. : Proses Refactor Langkah 3c (Ellaborate Attribute) Analisis class biasanya hanya akan mencantumkan nama atribut umum (ex. paperType). Daftar semua atribut selama desain komponen. UML sintaks: name : type-expression = initial-value { property string } Misalnya, paperType dapat dipecah menjadi berat, ukuran, dan warna. Berat atribut akan: paperType-weight: string = ―A‖ { contains 1 of 4 values – A, B, C, or D } Lang\kah 3D (Describe Processing Flow)
Gambar 11.14. : Activity diagram for computePaperCost( ) Langkah 4 (Persistent Data)
Jelaskan sumber data persisten (database dan file) dan mengidentifikasi kelas yang diperlukan untuk mengelola mereka.
Langkah 5 (Ellaborate Behaviour) Hal ini kadang-kadang diperlukan untuk model perilaku dari kelas desain. Transisi dari negara ke negara memiliki bentuk: Event-name (parameter-list) [guard-condition] / action expression
Gambar 11.15. : Elaborate Diagram Langkah 6 (Elab Deployment)
Gambar 11.16 : eLab Deployment Langkah 7 (Redesign/Reconsider
Pertama Model Level Komponen yang Anda buat tidak akan selengkap, konsisten, atau akurat sebagai iterasi n Anda berlaku untuk model. Para desainer terbaik akan mempertimbangkan banyak solusi desain alternatif sebelum menetap pada model desain akhir. Tugas Buatleh solusi permasalah bisnis dengan dukungan system informasi Buat Model Analisis dari SRS yang anda buat sebelumnya. Model analisis berisi diagram : Use Case Diagram ERD (pendekatan konvensional) DFD (pendekatan konvensional) Activity/Sequence Diagram (Pendekatan OO) Class Diagram (Pendekatan OO) Buat Model Desain dari model analisis yang anda buat Rancangan User Interface Dinilai dari keterpaduan, kelengkapan, dan alur logika Kompleksitas dapat meningkatkan penilaian Dikumpulkan ketika ujian akhir semester Kelas A disampul mika warna merah Kelas B disampul mika warna biru Kelas C disampul mika warna hijau
Bab 12 Desain User Interfasi (UID)
Tujuan Pembelajaran Umum Mendeskripsikan Perangkat Lunak Praktis Tujuan Pembelajaran Khusus Mampu Mengidentifikasikan desain user interface
Desain interface
Mudah dipelajari (easy to learn) Mudah digunakan (easy to use) Mudah dimengerti (easy to understand)
Kesalahan desain secara umum disebabkan : Tidak konsisten Terlalu banyak mengingat Tidak ada panduan Tidak ada sensitivitas Respon buruk Arcane/unfriendly Petunjuk emas pada saat anda melakukan desain user interface adalah Tempatkan user dalam kontrol Kurangi beban memori user Buat interface konsisten Tempatkan user dalam control Tentukan mode interaksi dalam sebuah cara dimana tidak memaksa user untuk melakukan aksi yang tidak perlu atau tidak dikehendaki. Menyediakan interaksi yang fleksibel. Memungkinkan interaksi user untuk diinterupsi dan dibatalkan (undo). Mempersingkat interaksi sesuai dengan tingkat penguasaan dan memungkinkan interaksi dikustomisasi. Sembunyikan hal-hal teknis dari user. Desain interaksi langsung dengan objek yang tampak di layar. Kurangi beban memori user
Kurangi permintaan memori ‗short-term‘. Buat default yang bermakna. Tentukan shortcut yang intuitif. Layout visual dari interface harus berdasal metafora dunia nyata. Buka informasi dengan pola progresif.
Buat interface yang konsisten adalah Memungkinkan user untuk mengambil langkah yang ada menjadi konteks yang berarti. Kelola konsistensi dalam keluarga aplikasi. Jika model interaktif yang lalu telah memenuhi harapan user, jangan membuat perubahan kecuali ada alasan yang cukup kuat. Model Desain User Intergface User model — profil semua user pada sistem Design model — realisasi desain dari model user Mental model (system perception) — gambaran mental user terhadap apakah interface tersebut Implementation model — ―look and feel‖ interface dipasangkan dengan informasi pendukung yang menggambarkan syntax dan semantik interface Proses UID
Gambar 12.1. : Proses UID Analisis Interface Analisis interface berarti pemahaman terhadap : (1) orang2x (end-users) yang akan berinteraksi dengan sistem melalui interface; (2) tugas2x yang harus dilakukan end-users untuk menyelesaikan pekerjaan mereka, (3) isi yang harus dipresentasikan sebagai bagian dari interface (4) lingkungan dimana tugas2x ini dilakukan Analisis User 1. Apakah pengguna profesional terlatih, teknisi, administrasi, atau pekerja manufaktur?
2. Apa tingkat pendidikan formal yang rata-rata pengguna miliki? 3. Apakah pengguna mampu belajar dari bahan tertulis atau mereka telah menyatakan keinginan untuk pelatihan kelas? 4. Apakah pengguna ahli juru ketik atau keyboard fobia? 5. Berapa kisaran usia masyarakat pengguna? 6. Apakah pengguna diwakili didominasi oleh salah satu jenis kelamin? 7. Bagaimana pengguna kompensasi untuk pekerjaan yang mereka lakukan? 8. Apakah pengguna bekerja jam kantor normal atau mereka bekerja sampai pekerjaan dilakukan? 9. Apakah perangkat lunak menjadi bagian integral dari pengguna bekerja lakukan atau akan digunakan hanya sesekali? 10. Apa bahasa lisan utama antara pengguna? 11. Apa konsekuensi jika pengguna membuat kesalahan menggunakan sistem? 12. Ahli pengguna dalam materi pelajaran yang ditangani oleh sistem? 13. Apakah pengguna ingin tahu tentang teknologi duduk di belakang antarmuka? Swimlane Diagram p at ien t
p h armacist
r e q u e st s t h at a p r e scr ip t io n b e r e f ille d
d e t e r m in e s st at u s o f p r e scr ip t io n
no ref ills remaining ref ills remaining
ch e cks in v e n t o r y f o r r e f ill o r alt e r n at iv e
p h ysician
ch e cks p at ie n t r e co r d s
approv es ref ill
ref ill not allowed
e v alu at e s alt e r n at iv e m e d icat io n r e ce iv e s o u t o f st o ck n o t if icat io n
out of st ock alt ernat iv e available in st ock
r e ce iv e s t im e / d at e t o p ick u p
p icks u p p r e scr ip t io n
none
f ills p r e scr ip t io n
r e ce iv e s r e q u e st t o co n t act p h y sician
Fig u re 1 2 .2 Sw imlan e d iag ram fo r p rescrip t io n refill fu n ct io n
Gambar 12.2. Swimlame Diagram Analisis Display Content Berbagai jenis data yang ditugaskan ke lokasi geografis pada layar yang konsisten (misalnya, foto selalu muncul di sudut kanan atas)? Dapatkah pengguna menyesuaikan lokasi layar untuk konten?
Apakah tepat identifikasi pada layar ditugaskan untuk semua konten? Jika laporan besar yang akan disajikan, bagaimana seharusnya itu dipartisi untuk mempermudah pemahaman? Apakah mekanisme akan tersedia untuk bergerak langsung ke ringkasan informasi data untuk koleksi data yang besar.? Akan output grafis ditingkatkan agar sesuai dalam batas-batas perangkat display yang digunakan? Bagaimana mewarnai yang akan digunakan untuk meningkatkan pemahaman? Bagaimana pesan kesalahan dan peringatan yang akan disajikan kepada pengguna?
Langkah-langkah desain interface
Menggunakan informasi yang dikembangkan selama analisis antarmuka (SEPA, Bagian 12.3), mendefinisikan objek antarmuka dan tindakan (operasi). Tentukan kejadian (tindakan pengguna) yang akan menyebabkan keadaan antarmuka pengguna untuk mengubah. Model perilaku ini. Menggambarkan setiap negara antarmuka seperti itu benar-benar akan melihat ke pengguna akhir. Menunjukkan bagaimana pengguna menafsirkan keadaan sistem dari informasi yang diberikan melalui antarmuka.
Desain pola interface Pola yang tersedia untuk User interface yang lengkap Layout halaman Bentuk dan masukan tabel Manipulasi data langsung Navigasi Mencari Elemen halaman e-Commerce Isu-isu perancangan Waktu tanggap (Response time) Fasilitas bantuan (Help facilities) Menghandel kesalahan (Error handling) Menu dan label perintah (Menu and command labeling) Akses aplikasi (Application accessibility) Internasionalisasi (Internationalization) Siklus Evaluasi Perancangan
Gambar 12.3. : Design Evaluation Cycle
