√ Pemodelan Analisis Dalam Rekayasa Perangkat Lunak Lengkap

Pondoksalam – Pemodelan Analisis Dalam Rekayasa Perangkat Lunak – Di dalam Rekayasa ada beberapa hal yang sangat penting adalam menganalisa pemodelan, diantaranya analisis kebutuhan, analisis model, penjelasannya sebagai berikut :

Download Pemodelan Analisis

Analisis Kebutuhan

Pemodelan Analisis – Need Assessment (analisis kebutuhan) merupakan suatu cara / metode untuk dapat mengetahui perbedaan antara kondisi yang diinginkan ataupun seharusnya atau diharapkan dengan kondisi yang ada (what is). Kondisi yang diinginkan seringkali disebut dengan sebutan kondisi ideal, sedangkan kondisi yang ada, seringkali disebut dengan sebuthan kondisi riil atau kondisi nyata.

Terdapat beberapa hal yang melekat pada pengertian pemodelan analisis (need assessment) ini

1. need assessment ialah suatu proses yang artinya terdapat rangkaian kegiatan di dalam pelaksanaan need assessment. Need assessement ini bukanlah suatu hasil, namun tetapi merupakan aktivitas tertentu di dalam upaya mengambil suatu keputusan tertentu.
2. kebutuhan itu sendiri pada hakikatnya merupakan kesenjangan dianatara harapan dan kenyataan. Dengan hal demikian maka, need assessment adalah suatu kegiatan dalam mengumpulkan informasi mengenai kesenjangan yang seharusnya dimilikidengan apa yang telah dimiliki.

Rekayasa dimulai dengan suaru rangkaian tugas pemodelan yang membawa keopada suatu spesifikasi lengkap dari persyaratan represntasi dan representasi desain yang komprehensif bagi perangkat lunak yang dibangun.

Model Analisis yang sebenarnya merupakan serangkaian model , merupakan serangkaian teknis yang pertama dari sistem.

Saat ini terdapat 2 yang mendominasi landskap pemodelan analisis

1. Analisis terstruktur merupakanmetode pemodelan klasik, analisis terstruktur ini merupakan aktivitas pembangunan model
2. Analisis berorientasi Objek .

Elemen Model Analisis

Model analisis harus dapat mencapai 3 sasaran utama, diantaranya :

1. Untuk menggambarkanapa yang dibutuhkan oleh pelanggan.
2. Untuk membangun dasasr bagi pembuatan desain perangkat lunak
3. Untuk membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.

Pada inti model terdapat kamus data (data dictionary)- penyimpan yang berisi deskripsi dari semua objek data yang dikonsumsi / diproduksi oleh perangkat lunak . Terdapat 3 hal yang megelilingi inti ini diantaranya :

1. Entity relationship diagram (ERD) merupakan notasi yang digunakan untuk melakukan aktivitas pemodelan data.
2. Data flow Diagram (DFD) melayani 2 tujuan
   1. Untuk memberikan indikasi mengenai bagaimana data ditransformasikan pada saat data bergerak melalui system,.
   2. Untuk menggambarkan fungsi-fungsi(dan sub fungsi) yang mentransformasikanaliran data.
3. State-transition diagram (STD) menunjukan bagaiaman system bertingkah laku sebagai akibat dari kejadian eksternal. Untuk melakukannya, STD menunjukkan berbagai model tingkah laku yang disebut dengan STATE system dan cara dimana transisi dibuat dari STATE satu ke STATE yang lain . STD Berfungsi sebagi dasar bagi pemodelan tingkah laku . Aspek control dari perangkat lunak diisikan dalam spesifikasi kontrol/Control Specification (SCPEC).

1. Pemodelan Data

Metode pemodelan data menggunakan ERD (Entity Relationship Diagram ). Pada konteks analisis terstruktur, ERD Menetapkan semua data yang dimasukkan, disimpan, ditransformasi, dan diproduksi pada suatu aplikasi.

ERD hanya berfokus pada data (sehingga memuaskan prinsip pertama analisis operasional) dengan menunjukan “jaringan data” yang ada untuk suatu system yang berikan. ERD sangat berguna bagi aplikasi dimana data dan hubungannya mengatur data yang kompleks.

2. Objek Data dan Atribut

Objek data merupakan represntasi dari hamper semua informasi gabungan yang harus di pahami oleh perangkat lunak. Dengan informasi gabungan maka kita mengartikan sesuatu yang memiliki sejumlah sifat atas atribut yang berbeda.

Objek data dapat berupa entitas eksternal suatu benda (laporan), peristiwa atau event, peran, unit organisasional, tempat, atau suatu yang strukutur (file)

Sedangkan, Atribut menentukan property suatu objek data dan mengambil salah satu dari 3 karakteristik yang berbeda , atribut dapat digunakan untuk ,

• 1. Menanami sebuah contoh dari objek data
• 2. Menggambarkan contoh
• 3. membuat referensi ke contoh yang lain pada table yang lain,

“note” Satu atribut / lebih harus didefinisikan sebagai sebuah pengidentifikasi – dimana atribut pengidentifikasian akan menjadi “kunci” ketika kita ingin menemukan sebuah contoh dari objek data.

Analisis Model

1. Scenario Based Modeling

Model ini merupakan model yang bergantung pada permasalahan yang sekuensial dan
terfokus pada proses.

Element Scenario-Based Modeling

1. Use cases – text
2. Use case diagrams
3. Activity diagrams
4. Swim lane diagrams

Karakteristik Scenario-Based Modeling

1. 1. Permasalahan terbagi-bagi menjadi tahapan-tahapan proses.  Tahapan dan proses selajutnya dapat dianalisis menjadi use case yang sesuai.
   2. saling berkaitan antara proses yang satu dan proses lainnya. Keruntutan proses tidak sepenuhnya diperlukan, namun hal ini penting agar diagram-diagram dapat dibuat dengan mudah.
   3. Interaksinya lebih banyak dengan user. Interaksi terhadap user menentukan bagaimana proses akan terbentuk.
   4. Tidak terlalu tersebar pada entitas-entitas atau objek. Entitas-entitas yang variatif menyebabkan model semakin kompleks bila diselesaikan menjadi proses-proses.

2. Usecase Diagram

Usecase diagram adalah diagram usecase yang digunakan untuk menggambarkan secara ringkas siapa yang menggunakan sistem dan apa saja yang bisa dilakukannya. Diagram usecase tidak menjelaskan secara detail tentang penggunaan usecase, namun hanya memberi gambaran singkat hubungan antara usecase, aktor, dan sistem.

Alternative Actions

1. Dapatkah aktor mengambil beberapa tindakan lain pada saat ini?
2. Apakah mungkin bahwa aktor akan menghadapi beberapa kondisi kesalahan pada saat ini?
3. Apakah mungkin bahwa aktor akan menghadapi perilaku dipanggil oleh beberapa acara di luar kendali aktor?

3. Activity diagram

Activity diagrams adalah sesuatu yang menggambarkan berbagai alir kegiatan/aktivitas pada sistem yang sedang dirancang, bagaimana masing-masing alur berawal, decision yang mungkin akan terjadi, dan bagaimana akan berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.

4. Swimlane Diagram

Swimlane adalah elemen visual yang digunakan dalam diagram alir proses yang menggambarkan siapa bekerja pada subset tertentu dari sebuah proses. Swimlane tersebut diatur baik horisontal maupun vertikal dan digunakan untuk mengelompokkan sub-proses sesuai dengan tanggung jawab mereka.

5. Flow-Oriented Modeling

Data Flow Diagram (DFD) merupakan alat yang digunakan untuk melihat input-proses-output dari sebuah sistem. Aliran data objek yang masuk ke dalam perangkat lunak, diubah oleh elemen-elemen pemroses, kemudian hasil dari objek data mengalir keluar dari perangkat lunak.

Objek data direpresentasikan dengan  panah berlabel dan transformasinya direpresentasikan dengan lingkaran (sering juga disebut bubble). DFD ini direpresentasikan dengan pola hirarkis. Model aliran data pertama (disebut juga DFD level 0 atau context diagram)  merepresentasikan keseluruhan sistem. DFD level selanjutnya menjelaskan context diagram, bertambah detil di setiap level berikutnya.

Tujuan dari data flow diagram ini adalah untuk menyediakan jembatan semantik antara pengguna dan developer. Artinya, diagram alir yang disajikan harus dimengerti oleh baik pihak awam (pengguna), namun tetap informatif bagi pihak developer.

Karakteristik domain yang cocok dalam penerapan flow-oriented

Untuk kasus perangkat lunak yang terdapat aliran data di dalamnya, bisa dimodelkan dengan flow-oriented ini.

1. Model ini menitikberatkan pada sudut pandang masuknya data, pemrosesan data, dan keluaran data hasil proses perangkat lunak.
2. Masalah yang digambarkan data flow diagram ini bersifat umum-khusus, yaitu menerangkan perangkat lunak secara umum, kemudian dicarikan detil untuk setiap level berikutnya.
3. Melibatkan tempat penyimpanan data (basis data)
4. Melibatkan entitas luar sistem yang mengirimkan data kepada sistem, juga entitas yang menerima sistem dari perangkat lunak yang dibuat. Contoh kasus yang sering diungkapkan sebagai contoh untuk model ini adalah Safe-Home security yang disajikan dalam buku yang ditulis oleh Pressmann halaman 227-228.

Guidelines (Pedoman)

1. Menggambarkan sistem sebagai gelembung tunggal di tingkat 0.
2. Hati-hati mencatat input primer dan output.
3. Sempurnakan dengan mengisolasi proses kandidat dan terkait data mereka objek dan menyimpan data.
4. Label semua elemen dengan nama-nama bermakna.
5. Mempertahankan kesesuaian informasi antara tingkat.
6. Sempurnakan satu gelembung pada suatu waktu.

6. Data Flow Diagram

Data Flow Diagram (DFD) adalah suatu diagram yang menggunakan notasi-notasi untuk bisa menggambarkan suatu arus dari data pada sistem, yang penggunaannya sangat membantu untuk dapat memahami sistem dengan menggunakan logika, tersruktur serta jelas. DFD ini sangat mirip dengan Flowchart.

7. Grammatical Parse

1. Fungsi keamanan SafeHome memungkinkan pemilik rumah untuk mengkonfigurasi sistem keamanan ketika diinstal, memonitor semua sensor yang terhubung ke sistem keamanan, dan berinteraksi dengan pemilik rumah melalui Internet, PC, atau panel kontrol.
2. Selama instalasi, PC SafeHome digunakan untuk program dan mengkonfigurasi sistem. Setiap sensor diberikan sebuah nomor dan jenis, password master diprogram untuk mempersenjatai dan melucuti sistem, dan nomor telepon (s) adalah masukan untuk panggilan ketika peristiwa terjadi sensor.
3. Ketika acara sensor diakui, perangkat lunak memanggil alarm terdengar melekat pada sistem. Setelah waktu penundaan yang ditentukan oleh pemilik rumah selama kegiatan konfigurasi sistem, perangkat lunak memanggil nomor telepon dari layanan monitoring, menyediakan informasi tentang lokasi, melaporkan sifat dari peristiwa yang telah terdeteksi. Nomor telepon akan redialed setiap 20 detik sampai sambungan telepon diperoleh.
4. Pemilik rumah menerima informasi keamanan melalui panel kontrol, PC, atau browser, secara kolektif disebut interface. Antarmuka menampilkan pesan yang meminta dan sistem informasi status pada panel kontrol, PC, atau jendela browser. Interaksi pemilik rumah mengambil bentuk berikut.

8. Control Flow Diagram

Diagram alir kontrol ( CFD ) adalah suatu diagram untuk menggambarkan aliran kontrol dari suatu proses bisnis , proses atau program.

Diagram aliran kontrol dikembangkan pada tahun 1950 , dan secara luas digunakan dalam berbagai disiplin ilmu teknik . Mereka adalah salah satu metodologi pemodelan proses bisnis klasik , bersama dengan flow chart , data flow diagram , diagram blok aliran fungsional , grafik Gantt , diagram PERT , dan IDEF .

9. Class-Based Modeling (Kelas Berbasis Modeling)

Terdiri dari element:

1. Class
2. Operation
3. Agregat
4. Association dan Dependencies
5. Package

Cocok untuk :

1. Terdapat objek yang dapat diidentifikasi, diklasifikasi, dan didefinisikan.
2. Terdapat banyak objek
3. Dari objek-objek bisa dibentuk kelas-kelas.
4. Terdapat hubungan antara satu kelas dengan kelas yang lainnya (bisa merupakan turunan atau menggunakan kelas lainnya)

Identifying Analysis Classes

1. Eksternal entitas yang menghasilkan atau mengkonsumsi informasi.
2. Hal-hal yang merupakan bagian dari domain informasi Kejadian atau peristiwa.
3. Peran yang dimainkan oleh orang-orang yang berinteraksi dengan sistem.Organisasi unit.
4. Tempat yang menetapkan konteks.

Struktur yang mendefinisikan kelas obyek (Class Selection Criteria)

1. saldo informasi
2. dibutuhkan layanan
3. Beberapa atribut
4. umum atribut
5. umum operasi
6. persyaratan penting

Identifying Classes

10. Class Diagram

11. CRC Modeling (Cyclic Redundancy Check)

Adapun tujuan yang diharapkan dari penggunaan CRC Model ini adalah kebutuhan pemakai dapat diketahui secara tepat atau dengan kata lain dapat menjembatani antara pengembang dan pemakai.

Secara garis besar tahapan dalam membuat suatu CRC Model yang biasa disebut sebagai CRC Session dibagi menjadi tiga yaitu sebelum pelaksanaan scenario, pada saat pelaksanaan scenario dan setelah pelaksanaan scenario.

Pada intinya langkah-langkah yang harus dilakukan dalam membuat CRC Model adalah menentukan class, responsibility, collaborator, use-case, menggambarkan CRC Cards yang digunakan bcserta dengan penggambaran CRC Model dan Collaborator.

Class Responsibilities (Tanggung Jawab)

1. Mendistribusikan intelijen sistem di kelas.
2. Nyatakan setiap tanggung jawab sebagai umum mungkin.
3. Masukan informasi dan perilaku yang berkaitan dengan itu di kelas yang sama.
4. Melokalisasi informasi tentang satu hal daripada mendistribusikannya di beberapa kelas.
5. Berbagi tanggung jawab antara kelas terkait, jika sesuai.

Download Pemodelan Analisis

Sekian dan Terimakasih sudah membaca Pemodelan Analisis semoga bermanfaat untuk anda ,Pemodelan Analisis – Rekayasa Perangkat Lunak

Referensi : Rekayasa perangkat lunak Pendekatan praktisi Buku 1 , Roger  Pressman , Ph .D. BAB 12 PEMODELAN ANALISIS