Postingan

Sequence Diagram

-
  Josua Siregar_11321012_D3TI Sequence Diagram Interaction diagram Serangkaian diagram yang menggambarkan perilaku dinamis dari berorientasi objek sistem. Satu set pesan yang dipertukarkan di antara satu set objek dalam konteks untuk mencapai suatu tujuan. Sering digunakan untuk memodelkan cara usecase direalisasikan melalui urutan pesan antar objek. Tujuan dari diagram Interaksi adalah untuk: - Model interaksi antar objek - Membantu dalam memahami bagaimana sebuah sistem (usecase) benar-benar bekerja - Verifikasi bahwa deskripsi usecase dapat didukung oleh yang ada kelas - Mengidentifikasi tanggung jawab/operasi dan menugaskannya ke kelas UML Diagram Kolaborasi Menekankan hubungan struktural antar objek diagram urutan subjek subjek ini  Alat untuk Diagram Urutan - Star UML - Draw.IO (Konsep MVC menggunakan model, penampil dan simbol pengontrol di alat ini) Pandangan Pertama pada Diagram Urutan Menggambarkan bagaimana objek berinteraksi satu sama lain. Menekankan urutan waktu pesan. Da
Posting Komentar
Baca selengkapnya

Activity Diagram

-
  Josua Siregar_11321012_D3TI Activity Diagram Activity diagram menunjukkan aliran tindakan dalam suatu aktivitas sering digunakan untuk memodelkan proses bisnis (alur kerja) Sering digunakan untuk memodelkan aliran (tindakan) dalam kasus penggunaan Terkadang digunakan, seperti diagram alur, untuk memodelkan logika internal suatu operasi. Elemen Diagram Aktivitas : Alur Aksi, Aktivitas, dan Kontrol.  Action: Adalah perilaku sederhana yang tidak dapat terurai diberi label dengan namanya. Activity: Digunakan untuk mewakili serangkaian tindakan diberi label dengan namanya. Control flow: Menunjukkan urutan eksekusi. Elements of an Activity Diagram: Initial and Final Node Initial node: Menggambarkan awal dari serangkaian tindakan atau kegiatan. Final node: Digunakan untuk menghentikan semua aliran kontrol dan aliran objek dalam suatu aktivitas (atau tindakan). Elements of an Activity Diagram: An Object Node and Object Flow Object node: Digunakan untuk merepresentasikan sebuah objek yang ter
Posting Komentar
Baca selengkapnya

Usecase diagram & usecase scenario

-
Gambar
  Josua SIregar_11321012_D3TI Usecase diagram & Usecase scenario Mengapa Usecase? Dalam perangkat lunak ada beberapa cara pendekatan model Dua cara yang paling umum adalah dari perspektif algoritmik dan dari perspektif berorientasi objek. Dalam pandangan tradisional pengembangan perangkat lunak membutuhkan perspektif algoritmik, blok pembangun utama dari perangkat lunak adalah prosedur atau fungsi. Saat kebutuhan berubah dan sistem berkembang, sistem dibangun dengan fokus algoritmik ternyata sangat sulit untuk dipertahankan. Dalam Operspektif blok bangunan utama jatuh sistem perangkat lunak adalah objek atau kelas. PEMODELAN OBJEKTORORIENT Pemodelan berorientasi objek muncul antara pertengahan 1970-an dan akhir 1980-an. UML awalnya dimotivasi oleh keinginan untuk menstandarisasi sistem notasi yang berbeda dan pendekatan untuk desain perangkat lunak yang dikembangkan oleh Grady Booch,Ivar Jacobson and James Rumbaughat, Rasional Perangkat lunak pada tahun 1994–1995. UML adalah bahasa
Posting Komentar
Baca selengkapnya

Design Principle

-
Josua Siregar_11321012_D3TI   Design Principle Merancang dengan metodologi apapun, baik berorientasi objek atau tidak, harus dimulai dengan membuat deskripsi sistem yang jelas, yaitu deskripsi pengguna, komponen/modul sistem dan interaksi antar komponen, dan input yang diperlukan, serta output yang dihasilkan oleh sistem. Deskripsi umum sistem sebaiknya ditulis dalam narasi yang jelas, disertai ilustrasi yang sesuai, dan fokusnya adalah pada kepentingan stakeholder (bukan pada software). Merancang sistem biasanya dilakukan bukan dengan memandang “objek” atau kelas, tapi fokus ke stakeholder, kepentingan, kebutuhan mereka dan interaksi antar komponen sistem maupun sistem tersebut dengan dunia luar. Dengan perkataan lain, fokus ke : “tujuan” (goal) Perancang sistem harus memperhatikan kepentingan berbagai stakeholder:  a. End user  b. Manager  c. Para Eksekutif  d. Administrator  e. Teknisi penginstalasi Perancang software, fokus agar kualitas teknikal dari software yang akan dihasilkan
Posting Komentar
Baca selengkapnya

Requirement Engineering

-
Gambar
  Josua Siregar_11321012_D3TI Requirement Engineering REQUIREMENT Persyaratan untuk sebuah sistem adalah: Deskripsi tentang apa yang harus dilakukan sistem Layanan yang diberikannya dan batasan operasinya Persyaratan ini mencerminkan kebutuhan pelanggan untuk sistem yang melayani tujuan tertentu tujuan seperti mengendalikan perangkat, menempatkan pesanan, atau mencari informasi. Proses menemukan, menganalisis, mendokumentasikan, dan memeriksanya layanan dan kendala disebut rekayasa persyaratan (RE). ( Sommerville, Software Engineering 9th Edition ) 1. Requirement Contoh dari sistem manajemen pasien perawatan kesehatan mental (MHC-PMS) ini menunjukkan bagaimana persyaratan pengguna dapat diperluas menjadi beberapa persyaratan sistem. 1.1. USER REQUIREMENT AND SYSTEM REQUIREMENT Perbedaan PERSYARATAN PENGGUNA DAN KEBUTUHAN SISTEM 'persyaratan pengguna/( user requirement )' berarti persyaratan abstrak tingkat tinggi 'persyaratan sistem/( system requirement )' berarti deskr
Posting Komentar
Baca selengkapnya