Salinan dari Catatan Anaperancis Rama.docx.pdf

Behavioral Modeling A. Intro Behavioral model Model yang mempresentasikan perilaku internal sistem Gambaran proses dinamis dalam sistem informasi Menunjukkan objek pada domain yang sama saling berkolaborasi dan mendukung setiap use case Kalo...

Behavioral Modeling A. Intro Behavioral model Model yang mempresentasikan perilaku internal sistem Gambaran proses dinamis dalam sistem informasi Menunjukkan objek pada domain yang sama saling berkolaborasi dan mendukung setiap use case Kalo fungsional: menggambarkan behaviour dari sistem Kalo struktural: mewakili objek serta hubungan diantaranya Kalo Behavioral: tampilan internal proses bisnis (internal dynamic aspects + internal behavior or dynamic view) Saat analisis Behavioral model: menjelaskan logika internal dalam bisnis tanpa melihat cara sistem diimplementasi Saat Design and implementation: detail desain dari operasi akan ditentukan, termasuk objek dalam data base dan komponen user interface Behavioural model: ○ Analis melihat masalah sebagai kesatuan use case (functional model) dan didukung oleh collaborating object (structural model) ○ Bagaimana objek berinteraksi dan berkolaborasi mendukung use case ○ Internal view proses bisnis melalui use case ○ Proses iteratif, sehingga bisa mengubah model yang sudah ada B. Tipe-tipe Behavioral Model Interaction Diagram ○ Diagram menampilkan detail proses bisnis dari use case ○ Menunjukkan cara aktor dan objek berkolaborasi untuk menciptakan fungsionalitas pada use case ○ Memperbolehkan analis membuat distribusi behaviour sistem melewati aktor dan objek yang ada dalam sistem ○ Bentuknya: Sequence diagram (message sequence) Communication diagram (message flow) Behavioral State Machine ○ Menampilkan perubahan status pada data C. Interaction Diagram Perbedaan dengan class diagram Class Diagram Interaction Diagram Mendeskripsikan struktur Mendeskripsikan behaviour Fokus pada class level Fokus pada object level (instance nya class) D. Sequence Diagram Diagram yang mengilustrasikan objek dan pesan yang melewatinya dari waktu ke waktu di sebuah use case Urutan aktivitas dapat terlihat dengan jelas Time-based ordering, sangat membantu membuat mengerti real-time specification dan use case yang kompleks Cocok menggambarkan flow of control berdasarkan urutan waktu Merepresentasikan model dinamis yang menunjukkan secara eksplisit sequence dari message Biasanya menunjukkan seluruh skenario yang memungkinkan untuk use case, tetapi biasanya dibuat single scenario untuk satu use case Sangat implementation specific karena sering melibatkan objek database dan komponen user interface yang spesifik sebagai objek Menjelaskan seluruh skenario dalam 1 use case Komponen: 1. Aktor dan Object Diletakkan dibagian atas Pihak eksternal Kalau bukan manusia, pakainya persegi panjang Actor dan object memiliki format penulisan yang berbeda ○ Actor = aPatient, aReceptionist ○ Object = aPatient : Patient, aPatient : UnpaidBill Metaclass, kelas di atas Class, memungkinkan untuk membuat suatu class baru Bisa ada objek abstrak (misal -> x : List) 2. Lifeline dan Object Destruction Lifeline, garis putus2 vertikal, untuk actor dan object  Object Destruction ○ Objek dihancurkan (misal: cart) ○ tanda X yang diletakkan di akhir lifeline Jika objek masih terus ada di dalam sistem setelah ia digunakan, lifeline harus sampai bawah 3. Execution Occurrence Periode waktu object menangani pesan (aktivasi) Box yang memanjang di atas lifeline 4. Message Komunikasi antar object Mentrigger suatu aktivitas Operation Call Message ○ Garis yang menghubungkan dua object ○ Tanda panah terisi penuh ○ Urutan pesan dari atas ke bawah Return Message ○ Garis putus2 dengan anak panah bentuk outline ○ Informasi yang dikembalikan, ditulis di atas label panah ○ Tidak perlu dituliskan jika sudah jelas ○ Dituliskan pada akhir activation bar ○ Optional, kalau void gak usah Jika return message tidak digambarkan, message yang dikirimkan harus dilengkapi dengan return variable (kayak yang dilingkari hijau) Jika return message digambarkan, tuliskan return variable di atas return message tsb (kayak yang dilingkari merah) Synchronous Message ○ Tanda panah tertutup, ada isinya  ○ Pengirim akan menunggu hingga penerima selesai memproses, baru melanjutkannya ○ Asynchronous Message ○ Tanda panah terbuka ○ Pengirim tidak perlu menunggu penerima selesai ○ 5. Self delegation Object bisa mengirim pesan ke dirinya sendiri Misal: make lunch 6. Create of Instance: Object membuat object lainnya Anak panah diarahkan ke object bukan ke lifeline 7. Guard Condition Test yang harus dilewati untuk sebuah pesan dapat dikirimkan 8. Frames (konteks) If & else Alt = alternative (mutually exclusive - dua pilihan) Loop = Loop Opt = optional (if satu pilihan) Par = parallel (dieksekusi secara paralel) Region = region (critical region yang hanya satu thread bisa dijalankan) Kalau sequence diagram fokus pada satu skenario, condition jarang untuk digunakan di single sequence diagram Frames dapat dibuat nested Guideline Sequence ○ Penulisan dari kiri ke kanan, atas ke bawah ○ Gunakan nama yang sama untuk aktor/object yang menunjukkan pada hal yang sama Contoh: customer berinteraksi dengan sistem dan sistem menyimpan informasi tentang customer ○ Objek atau aktor yang menginisiasi skenario terletak di kiri atas ○ Object yang jenisnya sama perlu diberi nama Contoh: A : Parent dan B : Parent ○ Tampilkan return value jika diperlukan saja  ○ Berikan nama messages dan return value di deket panah agar lebih mudah terbaca Langkah-langkah Membuat Sequence 1. Menentukan konteks (keseluruhan sistem / 1 use case / 1 scenario dalam use case) 2. Identifikasi aktor dan objek 3. Berikan life line untuk masing-masing 4. Tambahkan message 5. Tambahkan execution occurrence pada setiap object lifeline 6. Validasi sequence diagram yang sudah dibuat E. Communication Diagram Dapat menampilkan aspek dinamis dari sistem berbasis objek ○ Menunjukkan bagaimana member dari kumpulan objek berkolaborasi mewujudkan use case atau use case scenario ○ Menunjukkan kolaborasi (CRC Card), terlihat ketergantungan antar objek Menampilkan pesan dari objek ke objek pada use case tertentu Lebih ke arah message passing relationship, ketimbang agregasi dan generalisasi Cocok menggambarkan message flow dan process pattern, ketimbang time ordering Komponen: ○ Actor dan Object Sama dengan sequence diagram Menunjukkan alur penyampaian pesan (message passing) Tidak eksplisit, apakah object sedang dihapus atau dibuat Ketika message untuk menghapus (delete/remove/destroy) dikirimkan ke suatu objek, maka objek tsb akan hilang  Ketika pesan create atau new message dikirimkan maka objek tsb akan muncul ○ Association dan Messages Association: pakai garis tanpa tanda panah Messages: sequence number + label dari association + panah ○ Guard Condition Conditional condition Ditulis di antara sequence number dan messages ○ Frame Menunjukkan konteks dari communication diagram ○ Sequence number Urutan dari aktivitas yang dilakukan. Bisa modelan sub sub nomor juga (1.1.2 / 2.1 /..) Langkah-langkah Membuat Communication Diagram: 1. Tentukan konteks 2. Identifikasi aktor dan objek 3. Tentukan asosiasi atau hubungan antar objek 4. Tambahkan messages, sequence number, tanda panah, dan yang lainnya 5. Validasi Guidelines Communication Diagram 1. Jangan gunakan untuk memodelkan process flow (ini pakai activity diagram aja). communication diagram cocok untuk menjelaskan message flow (hubungan 1 object dengan object lain) 2. Jangan gunakan untuk menampilkan urutan pesan (lebih cocok sequence diagram) 3. Dapat disederhanakan apabila terlalu complex dengan packages, yaitu beberapa object dikelompokkan berdasarkan pesan yang dikirimkan/diterima dari object lainnya Example of Message 1. Message to “self” / “this” 2. Message Instance Creation  Guard Condition 1. Conditional Message Syntax: Seq. Number [ variable = value ] : message() Contoh: 1 [color = red]: calculate() 2. Mutually exclusive condition 1a [test1] 1b [not test1] Jadi make a sama b, kayak sub number (cabang) 3. Loop Syntax: Seq. Number * [ i := 1..N ]: message() * wajib pake [...] gak wajib pake Contoh: 1 * [i = 1..n] : st= getSubTotal() F. Sequence VS Communication Diagram Sequence Diagram Communication Diagram Menekankan urutan waktu pengiriman Menekankan flow dari aliran pesan dari pesan (time ordering) berbagai objek Bisa ada/tidak ada return message Tidak akan menampilkan return message  Asosiasi antar objek tidak tergambar Asosiasi antar objek tergambar jelas (garisnya ada anak panah) (tidak memiliki anak panah pada garis) Memperlihatkan dengan eksplisit objek Tidak eksplisit terlihat, kalau fungsi yang akan dihapus delete maka menunjukan objek yang ada di parameter dihapus, misal delete(cashier) G. Behavioral State Machine (BSM) Model dinamis yang menunjukkan perubahan states pada satu objek Tidak digunakan pada setiap objek, hanya digunakan pada objek yang kompleks Komponen: 1. State - Ditentukan oleh nilai atribut dan hubungannya dengan objek lain - Tapi, tidak semua atribut bisa membawa perubahan - Atribut misalnya lokasi geografis, jadi nanti perlakuannya berbeda 2. An Event  - Sesuatu yang dapat mengubah nilai yang mendeskripsikan objek 3. A transition - Relasi yang merepresentasikan pergerakan objek dari satu state ke state yang lain - Beberapa memiliki guard condition (boolean) 4. Action - Sesuatu yang atomik (tidak bisa didekomposisi lagi), - Tidak bisa diinterupsi - Memerlukan zero time - Berasosiasi dengan transisi 5. Activity - Berlawanan dengan action - Bukan atomik, masih bisa didekomposisi, dan berada pada seluruh periode proses hingga selesai - Bisa dimulai atau di stop oleh action Contoh: H. Guidelines Behavioural State Machine 1. Buat untuk objek yang kompleks, yang memiliki perubahan behavior setelah statusnya berubah 2. Gunaakan prinsip left to right dan top to bottom 3. Pastikan nama statenya simple, intuitif, jelas, dan mendeskripsikan 4. Hindari blackhole dan miracle state 5. Pastikan setiap guard condition mutually exclusive 6. Setiap transisi pastikan terdapat message dan operation, kalau tidak objek tidak akan berubah  I. Langkah-langkah Membuat BSM 1. Tentukan dulu konteksnya. Konteks dari BSM biasanya adalah sebuah class, tapi konteks dapat berupa kumpulan class, sub system, atau keseluruhan sistem. 2. Identifikasi status objek yang sudah dipilih, dari awal hingga akhir. Dibuat berdasarkan normal flow dari uc description. 3. Mulai mengurutkan status objek tersebut dan mulai membuat layout diagram. 4. Identifikasi transisi di antara setiap objek dan tambahkan event, action, dan guard condition. 5. Lakukan validasi terhadap diagram yang telah dibuat. J. CRUDE analysis Menggunakan CRUDE matrix Setiap cellnya merepresentasikan interaksi antar instance pada class Bisa saja memunculkan perubahan baru, sehingga harus mengelola yang sebelum-sebelumnya Berguna sebagai ○ system-wide representation (pembeda dari interaction diagram dan BSM) ○ Way to partially validate interaksi antar objek di object oriented system Pastikan: ○ Setiap objek yang sifatnya sementara harus memiliki operasi D (delete) ○ Setiap objek yang memiliki nilai historical dan ingin disimpan jangan diberikan operasi U (update) atau D (delete) K. Verifying and Validating Behavioural Model 1. Setiap aktor dan objek pada sequence diagram harus juga ada di communication diagram (vice versa) 2. Jika terdapat message di sequence diagram, maka juga harus ada asosiasi pada communication diagram (vice versa) 3. Setiap message pada sequence diagram, maka juga harus ada sebagai message di asosiasi pada communication diagram (vice versa) 4. Jika ada guard condition di sequence diagram, harus ada dan ekuivalen di communication diagram (vice versa) 5. Urutan sequence number harus sesuai antara sequence dan behavioural 6. Setiap transisi pada BSM, harus berasosiasi dengan message di sequence dan communication diagram, dan harus termasuk ke dalam CRUD matrix 7. Jika ada CUD, maka harus juga berasosiasi dengan transisi di BSM sebagai representasi instance yang menerima class Process & Data Modeling A. Process Model Cara untuk merepresentasikan bisnis proses dalam perusahaan Bagaimana sistem bisnis dapat beroperasi  Mengilustrasikan aktivitas yang dilaksanakan, dan bagaimana data dapat berjalan di atasnya Ada as-is dan to-be system Bagian dari structured system analysis dan design techniques Data flow diagramming: ○ Merupakan bagian dari cara kita membuat process model ○ Teknik membuat diagram untuk proses bisnis dan data yang melewatinya ○ Erat dengan use case ○ Lebih ke arah apa yang dilakukan sistem, bukan bagaimana cara melakukannya B. Jenis Process Model 1. Logical Mendeskripsikan proses yang ada tanpa menjelaskan bagaimana proses tersebut dibuat Dijalankan pada fase analisis 2. Physical Menyediakan informasi yang dibutuhkan untuk membangun sistem Dijalan pada fase desain C. Data flow diagram (DFD) Use case (Requirements definition dan description) menjadi referensi yang fundamental dan utama untuk membuat DFD Proses bisnis kadang terlalu kompleks sehingga perlu dibuatkan beberapa DFD Verify pembuatan dengan user validation / walkthrough atau role play process Terdapat hierarki: ○ Hierarki pertama menyediakan ringkasan dari sistem secara overall ○ Level berikutnya menjelaskan detailnya ○ Makanya timbul konsep dekomposisi untuk proses bisnis yang akan direpresentasikan Relasi: ○ Context diagram Diagram pertama dalam pembuatan DFD Menjelaskan data flow diagram atau representasi dari proses bisnis Entire system dan environment Hanya ada satu buah proses (overall business process) Bisa ada external entity Tidak memiliki data store Setiap process model punya 1 context diagram ○ Level 0 DFD Seluruh proses utama (major) pada level utama  Bisa dibilang ini diagram DFD level pertama Memperlihatkan seluruh proses high level dan hubungannya Seluruh process model hanya memiliki 1 level 0 diagram ○ Level 1 DFD menjelaskan salah satu proses pada level 0 dan memiliki proses yang lebih detail Kita membuat detail dari setiap major process di level 0 ○ Level 2 DFD detailing lagi level 1 DFD Tidak perlu semua yang ada di level 1 dijelaskan pada level 2, yang dibutuhkan saja ○ Alternative Data Flow Muncul ketika proses menghasilkan beberapa data flow dengan kondisi yang berbeda Notasi: Nama Harus ada Penjelasan Simbol (Gane and Sarson) Process Number Bisa manual atau Nama (Verb-Noun computerized {Get patient information}->harus Melaksanakan proses unik) bisnis yang spesifik. Deskripsi Minimal 1 input dan 1 Hindari penggunaan kata output 'dan' pada proses. Data Flow Nama (Noun) Merepresentasikan data ->unik tunggal (patient name), Deskripsi atau logical collection data 1 atau lebih koneksi (new appointment) ke proses Sifatnya 1 arah Data Store Identification Koleksi data yang -Number disimpan. Ada starting Nama (Noun) point dari data model. Deskripsi Minimal 1 input dan Ada principal link antara output process model dengan data model. External Nama (Nouns) Bisa person, organisasi, Entity Deskripsi dan sistem (pihak eksternal tapi memiliki hubungan) Berkorespondensi dengan primary actor di use case Menyediakan data atau  menerima data dari sistem. Decomposition ○ Proses mendetailkan proses bisnis menjadi level yang lebih detail ○ Child merupakan penjelasan lebih detail dari parent Balancing ○ Perlu memastikan informasi yang di present secara akurat direpresentasikan kembali pada level-level berikutnya ○ Penjelasan pada child harus relevan dengan level diatasnya D. Creating Data Flow Diagram Nama use case bisa menjadi proses dalam DFD Input dan output bisa menjadi data flow Data input dan output yang kecil bisa dijadikan satu ke single flow 1. Bangun context diagram - Satu buah proses besar dari SI - Setiap process models punya satu context diagram - Cari seluruh input dan output (dari use case yang ada) - Hubungan eksternal ke dalam proses - Umumnya tidak memiliki data stores 2. Buat DFD Fragment - Masing-masing use case besar di convert ke 1 DFD fragment - Urutan nomornya sama kayak di use case number - Proses di ubah ke kata kerja - Sudut pandangnya dari dalam organisasi yang menjalankan proses - Data store biasanya ada di bawah process (use case) - Setiap use case jadi satu fragment 3. Membuat diagram level 0 - Menggabungkan semua fragment - Menunjukkan major high level process dan hubungannya - Setiap process model hanya punya 1 level 0 DFD - Penomoran ngikutin aturan dari atas, kiri, kanan, bawah - Menyembunyikan kompleksitas sistem - Ada sekitar 3 sampai 7 proses 4. Membuat diagram level 1 - Hasil dekomposisi level 0 DFD - Mendetailkan DFD, masing-masing use case diambil langkahnya lalu dibuatkan diagram 5. Membuat diagram level 2 - Memilih proses dari level 1 yang dianggap masih perlu untuk di detailkan  6. Validasi DFD dengan user untuk memastikan kelengkapan dan ketepatan DFD yang sudah dibuat. E. Illegal Process Spontaneous Generation (miracle) ○ Proses tidak memiliki input Black Hole ○ Proses tidak memiliki output Gray Hole ○ Proses tidak memiliki pasangan input dan output yang sesuai F. Illegal Data Flow - Semuanya harus melalui proses G. Data Model Bentuk formal untuk merepresentasikan data yang digunakan dan dihasilkan oleh sistem  Harus seimbang dengan process models sebelumnya Jenis-jenisnya: ○ Logical data model Menunjukkan data tanpa mengindikasi bagaimana cara menyimpan, membuat, atau memanipulasinya Fokus menyocok diagram dengan kebutuhan real bisnis dari sistem ○ Physical data model Menunjukkan data yang akan disimpan di database H. ERD Gambaran bagaimana informasi tercipta, tersimpan, dan digunakan oleh sistem Bisa digunakan untuk menunjukkan business rules (constrain) Komponen: 1. Entity - Orang, tempat, event, atau benda - Namanya harus singular dan dituliskan dengan huruf kapital - Harus muncul beberapa kali, misalnya ketika seseorang hanya memiliki satu rumah maka rumah tersebut bukan entity. - Jika hanya single instance (yang menurunkan class) tidak perlu dijadikan entity 2. Attribute - Kata benda - Harus digunakan oleh minimal satu proses bisnis - Identifier: kayak unique key, bisa satu (single) bisa lebih dari satu (Concatenated). Tapi tidak wajib ada sampai design phase 3. Relationship - Asosiasi di antara entity - Menggunakan kata kerja aktif  4. Cardinality - Seberapa banyak jumlah instance dari satu entity bisa berhubungan dengan instance di entity lain 5. Modality - Terkait apakah boleh atau tidaknya instance dari child entity ada tanpa berhubgnan dengan parent - Not null: harus ada agar valid - Null: tidak perlu ada untuk valid 6. Identifier - Bisa hasil dari gabungan dua atribut maupun hanya satu atribut User Interface Design A. Design Tujuan: ○ Menentukan bagaimana cara membuat sistem ○ Aktivitas utama adalah mengembangkan representasi analisis ke representasi design ○ Membuat blueprint sistem yang bisa diimplementasi Fokus pada cara membangun sistem ○ Menentukan bagaimana data disimpan ○ Arsitektur fisik ○ Rancangan user interface Lebih ke arah nonfunctional requirement Analisis dan desain sangat erat, jadi mampu mengubah model analisis yang telah dibuat sebelumnya Tahapan: 1. Verifikasi dan validasi model analisis 2. Kembangkan analisis model ke desain model 3. Buat packages dan utilisasi package diagram 4. Pilih strategi desain B. Hindari Classic Design 1. Reducing design time: desain sering dikorbankan waktunya untuk mengerjakan hal yang lain 2. Feature creep: jika ada penambahan fitur yang tidak vital, oper ke versi yang nantinya 3. Silver bullet syndrome: tidak ada tool yang ampuh untuk mengetasi semua masalah 4. Switching tools midproject: jangan mengganti tools jika dirasa tidak bermanfaat C. Verifikasi dan Validasi Model Analisis Memastikan konsistensi model fungsional, struktural, dan behavioral Disebut juga balancing ○ Balancing Fungsional - Struktural  [Act Diagram, UC Diagram, UC Description ↔ Class Diagram] Pastikan setiap class pada class diagram dan CRC card harus berasosiasi minimal dengan satu use case (vice versa) Setiap aktivitas pada activity diagram dan event di use case description mempunyai relasi minimal satu dengan CRC dan operasi dengan class diagram (vice versa) Objek node di activity diagram harus berasosiasi dengan instance dari sebuah class di class diagram dan CRC card atau atribut di class / CRC Card Setiap atribut dan relasi yang ada di CRC card harus berelasi dengan subjek atau objek dari event di use case description Memastikan activity diagram, use case diagram, use case description sesuai dengan class diagram Pastikan setiap class pada class diagram terhubung minimal dengan satu use case Activity pada activity diagram harus berkorelasi dengan event pada use case description dan operation pada class diagram Objek node pada activity diagram berhubungan dengan atribut pada class diagram ○ Balancing Fungsional - Behavioral [Act Diagram, UC Diagram, UC Description ↔ Seq./Communication Diagram, CRUDE Matrix, BSM]  Memastikan setiap sequence dan communication diagram terhubung dengan use case di use case diagram dan use case description Aktor di sequence diagram, communication diagram, dan CRUDE matrix terasosiasi dengan actor di use case diagram / use case description (vice versa) …. Memastikan setiap sequence dan communication diagram terhubung dengan use case, termasuk aktor-aktornya Message dalam sequence diagram, harus terhubung dengan transition pada behavioral state machine Entri pada CRUDE matrix harus sesuai dengan activity diagram dan event pada use case Semua objek yang kompleks harus memiliki behavioral state machine ○ Balancing Structural - Behavioral [Class Diagram ↔ Seq./Communication Diagram, CRUDE Matrix, BSM] Pastikan setiap object pada Crude matrix, behavioral state machine (BSM), dan sequence diagram berasosiasi dengan object pada class diagram Message pada sequence diagram punya korelasi dengan operation pada class diagram Transisi pada BSM juga punya korelasi dengan operation pada class diagram State pada BSM harus sesuai dengan nilai atribut pada object di class diagram D. Mengubah model analisis ke model desain  Evolve the analysis models into design models Bukan berarti analis harus membuat pemodelan baru, namun memberikan detail tambahan informasi untuk model analisis yang sudah ada. Analis harus memastikan sistem memenuhi kebutuhan non functional requirement serta merancang kebutuhan lain seperti: ○ System performance ○ System environment issues ○ User interface ○ Database ○ Distributed or centralized processing Sistem harus maintainable dan affordable, serta efisien dan efektif E. Membuat package diagram Mengelompokkan beberapa komponen sistem yang saling terhubung atau memiliki kesamaan (konsep folder pada komputer) Packages digunakan untuk mengelompokkan class atau use case Tujuan: membuat representasi model yang lebih sederhana / mengurangi kompleksitas model Syntax F. Menentukan strategi design Jenis: 1. Custom development Pengembangan sistem yang dilakukan sendiri mulai dari awal hingga akhir 2. Purchase Packaged Software Membeli software yang sudah jadi dan telah beredar ke Oracle, Microsoft 3. Hire External vendor (outsource) Membuat sistem dari awal oleh pihak eksternal Kriteria pemilihan G. User interface Interface design menentukan bagaimana sistem berinteraksi dengan entitas di luar sistem Terdapat dua interface: ○ System interface, menjelaskan bagaimana sistem akan berhubungan dengan sistem yang lainnya ○ User interface, menjelaskan bagaimana sistem akan berinteraksi dengan penggunanya/eksternal (kita fokus disini) Tujuan perancangan UI: menyediakan interface yang enak dipandang dan mudah digunakan Masalah utama dalam perancangan UI → cara menggunakan ruang/space secara efektif. Analis harus bisa menyeimbangkan kebutuhan terhadap interface yang sederhana & mudah digunakan dengan kebutuhan untuk menyajikan informasi di banyak halaman, yang justru bisa mengurangi kesederhanaan interface. Prinsip-prinsip yang harus diikuti: 1. Layout Pengaturan item pada layar pengguna Item yang mirip akan disatukan pada area yang sama Tiga area: ○ Navigation area → menu2 yang dapat digunakan ○ Report and forms area → menampilkan informasi utama & dapat digunakan user untuk memasukkan informasi ke dalam sistem ○ Status area → info apa yang sedang dilakukan user Area dan informasi harus meminimalkan gerakan dari user: ○ Gunakan konsep kiri-kanan, atas-bawah ○ Menampilkan informasi berdasarkan kronologi ○ Least-to-most-specific (umum ke spesifik) ○ Most to least frequent (paling sering muncul) Pastikan untuk setiap area hal-hal ini konsisten: ○ Ukuran ○ Bentuk ○ Tempat untuk meng-input data ○ Tempat untuk menampilkan laporan/informasi  Contoh: 2. Content Awareness Seluruh interface harus memiliki judul User harus mengetahui sedang berada di mana dan cara menuju lokasi tertentu (breath crum) Input field harus menyebutkan jenis informasi yang harus dimasukkan Setiap action/area harus bisa dibedakan dengan jelas 3. Aesthetics Menarik dan menyenangkan untuk dilihat Biasanya desain yang bersifat simpel dan minimalis lebih diutamakan Hindari menampilkan terlalu banyak informasi Pemilihan, ukuran, kapital pada font Bedakan font untuk mencetak dengan menampilkan laporan Gunakan warna dan pola yang cocok 4. User Experience Ease of learning ○ Relevan dengan sistem untuk jumlah user yang besar Ease of use ○ Penting untuk sistem yang terspesialisasi Ease of learning and use of use are related ○ Complementary: membawa pada keputusan desain yang serupa antara novice dan expert user ○ Conflicting: adanya perbedaan kebutuhan yang kontras antara novice dengan expert, sehingga harus memilih 5. Consistency Memprediksi apa yang akan terjadi, jika pengguna berinteraksi dengan sistem Diterapkan pada: ○ Navigasi control ○ Terminologi (penggunaan istilah) ○ Template form atau report  6. Minimal User Effort User mengeluarkan upaya seminim mungkin untuk menyelesaikan suatu task Three clicks rule (maksimal 3 klik) H. Navigation Design Perpindahan antar screen User dapat memasukkan perintah dan informasi ke dalam sistem serta dapat melihat kembali informasi yang ada di dalam sistem Menyediakan pesan jika action pengguna berhasil atau tidak Tujuan: membuat sistem yang simple dan mudah, kalau bisa pengguna tidak sadar kalau ada navigasi Asumsinya: ○ User belum membaca manual book ○ User belum mengikuti training ○ User tidak memiliki bantuan dari eksternal Prinsip Dasar (Krug's Guiding Principle): ○ Menghindari kesalahan Memberi label pada perintah Membatasi pilihan Jangan menampilkan perintah yang tidak dapat digunakan Konfirmasi permintaan pengguna yang penting ○ Memudahkan perbaikan dari kesalahan (undo, redo) ○ Menggunakan tata bahasa yang konsisten Pendekatan untuk menentukan command / perintah (Types of Navigation Control): ○ Language Command language (UNIX, SQL) Natural language (Google, Microsoft office assistant, Siri) ○ Menu Ada list menu pilihan Berasal dari form yang berbeda (menu bars, popup, dropdown) ○ Direct manipulation Interaksi langsung pada objek di layer (drag and drop) Misalnya mengubah ukuran object pada powerpoint (pinch) Message ○ Cara sistem merespon user ○ Memberitahukan status interaksi ○ Jenis-jenis: Error message Confirmation message Delay message (sistem sedang berproses, loading) Help message (tambahan informasi akan sistem) Acknowledgement message (misal notif telah berhasil) I. Input Design Layar yang digunakan untuk memasukkan data Mendapatkan informasi akurat dan sederhana Tipe data: ○ Structured: tanggal, nama, produk ○ Unstructured: komentar, description Tipe input: ○ Free form control: Data item Text Number Password ○ Selection boxes Check boxes Radio button On screen list box Drop down list box Combo boxes Slider Input validation (minimal ada 1 untuk sistem) ○ Completeness check, setiap data telah diinput ○ Format check, data sudah sesuai jenisnya ○ Range check, data masuk ke dalam range ○ Digit check, memeriksa digit tertentu ○ Consistency check, konsistensi data dengan database ○ Database check, membandingkan data yang diinput dengan yang ada Prinsip ○ Online vs batch processing Online processing setiap input dimasukkan satu persatu ke dalam database saat transaksi berjalan (misal booking pesawat). Batch processing, input dikumpulkan terlebih dahulu kemudian dimasukkan ke database dalam satu batch, master file tidak diperbarui secara real-time. ○ Capture data at its source Meminimalkan input manual Contoh teknologi: Barcode reader Optical character recognition Magnetic stripe reader (kartu atm) Smart card RFID ○ Minimize keystroke Minimalkan penekanan tombol  Hindari permintaan informasi jika bisa didapatkan dari sumber yang lain Caranya: Look Up Dropdown list Default values J. Output design Prinsip dasar: ○ Understand report usage Real time: report dengan data yang akurat dan real time Batch report: informasi yang bersifat historis, ada informasi tambahan summary, total, rata-rata, dll. ○ Manage information load Menyediakan informasi yang hanya dibutuhkan Tempatkan informasi yang paling penting di atas ○ Minimize bias Entri di awal pasti perhatiannya lebih besar Tentukan urutan yang tepat dalam penampilan entri Sorting Tipe output 1. Detail report Informasi detail dari data yang diminta 2. Summary report Rangkuman dari informasi 3. Turnaround document Dapat digunakan kembali untuk input pada proses selanjutnya 4. Graphs Diagram untuk mempermudah perbandingan data 5. Batch report Bisa menunjukkan histori dalam bulan, jam, hari Menyediakan tambahan informasi di luar reported information seperti total summaries dan historical averages Physical Architecture A. Introduction Menentukan bagaimana sistem akan didistribusikan pada komputer-komputer Hardware dan software apa saja yang kana digunakan Dipengaruhi juga oleh non functional requirement B. Architecture design process 1. Analis harus memahami software dan hardware 2. Memilih alternatif terbaik sesuai kebutuhan sistem Kriteria: ○ Biaya akuisisi ○ Biaya pengembangan  ○ Kemudahan pengembangan ○ Kemampuan interface ○ Control dan security ○ Skalabilitas C. Architectural Component 1. Software (sistem yang berperan) - Data storage Setiap program perlu memiliki data agar bisa disimpan dan diambil kembali Data tersebut adalah data yang didokumentasikan pada structural modeling (CRC card dan class diagram) Berasosiasi dengan objek yang terletak pada manajemen layer - Data access logic Logika yang diperlukan untuk mengakses data Query data base SQL - Application logic Logika untuk menjalankan fungsi aplikasi Logika diambil dari model fungsional (activity diagram, use case, behavioural modeling) - Presentation logic Logika untuk menyajikan informasi kepada pengguna dan menerima input Sering disebut user interface 2. Hardware (perangkat keras) - client: Perangkat input atau output yang digunakan oleh user Contoh: laptop, cell phone, terminal atm, PDA, dll - Server Komponen komputer yang lebih beras Menyimpan perangkat lunak dan keras yang dapat diakses siapapun yang memiliki izin contoh : mainframe, minicomputer (multi user memiliki lebih dari satu terminal pada cpu, power dan kecepatan lebih besar), microcomputer (single user computer, PC, ada microprocessor) - Network Menghubungkan komputer Variasi kecepatan D. Tipe Architecture 1. Server based architecture Server menjalankan seluruh fungsinya (4) Client bisa membuat user mengirim atau menerima pesan namun tidak melakukan pemrosesan Semua software aplikasi disimpan di satu komputer Setiap data juga disimpan pada satu komputer Kontrol terpusat pada satu server (kelebihan beban)  Biaya server sangat besar 2. Client based architecture Pc client dan komputer server berada pada jaringam yang sama Client bertanggung jawab akan data access, application, presentation logic Server: hanya menyimpan data Namun: circuit jaringan bisa mengalami benn yang besar, seluruh data pada server harus dikirim ke client untuk diproses (beban) 3. Client server architecture Client: application logic, presentation logic Server: data storage, data access logic Thin client (client hanya melakukan presentation logic) Thick client (presentation + application logic) Keuntungan: ○ Scalable (mudah menambahkan / mengurangi kapasitas penyimpanan dan pemrosesan server) ○ Biaya upgrade bisa bertahap ○ Dapat menundukan jenis client dan server yang berbeda-beda (middleware) ○ Jaringan lebih dapat diandalkan ○ Tidak berpusat pada satu titik Kekurangan: ○ Lebih kompleks ○ Biaya kepemilikan menjadi lebih besar 4. Two tiered (Thick client server architecture) E. Pemilihan tipe server