Apa itu MISRA dan cara memasaknya

Mungkin, setiap pengembang program untuk mikrokontroler mungkin setidaknya pernah mendengar tentang standar pengkodean khusus yang dirancang untuk membantu meningkatkan keamanan dan portabilitas kode Anda. Salah satu standar tersebut adalah MISRA. Dalam artikel ini kita akan memeriksa secara lebih rinci apa standar ini, apa filosofinya dan bagaimana menggunakannya dalam proyek Anda.

Banyak pembaca kami telah mendengar bahwa PVS-Studio mendukung klasifikasi peringatan mereka sesuai dengan standar MISRA. Saat ini PVS-Studio mencakup lebih dari 100 aturan MISRA C: 2012 dan MISRA C ++: 2008.

Artikel ini bertujuan untuk membunuh tiga burung dengan satu batu:

1. Katakan apa MISRA untuk mereka yang tidak terbiasa dengan standar ini;
2. Ingatkan dunia yang melekat tentang apa yang kita mampu;
3. Untuk membantu lebih dalam dalam perjalanan bisnis bagi karyawan baru yang juga akan lebih jauh mengembangkan alat analisa MISRA kami;

Saya harap saya bisa membuatnya menarik. Jadi mari kita mulai!

Kisah MISRA

Sejarah MISRA dimulai sejak lama. Kemudian, pada awal 90-an, program pemerintah Inggris dengan nama indikatif "Safe IT" mengalokasikan dana untuk berbagai proyek, dengan satu atau lain cara terkait dengan keamanan sistem elektronik. Proyek MISRA (Asosiasi Keandalan Perangkat Lunak Industri Motor) sendiri didirikan untuk membuat panduan untuk mengembangkan perangkat lunak untuk mikrokontroler pada kendaraan darat - pada mobil, secara umum.

Setelah menerima dana dari negara, tim MISRA mulai bekerja, dan pada November 1994 merilis panduan pertamanya: " Pedoman pengembangan untuk perangkat lunak berbasis kendaraan ". Panduan ini belum dikaitkan dengan bahasa tertentu, tetapi harus saya akui: karya itu mengesankan dan mungkin menyangkut semua aspek yang mungkin terjadi dalam pengembangan perangkat lunak tertanam. Ngomong-ngomong, para pengembang panduan ini baru-baru ini merayakan ulang tahun ke 25 dari tanggal yang begitu penting bagi mereka.

Ketika pendanaan dari negara berakhir, anggota MISRA memutuskan untuk terus bekerja bersama secara informal - ini berlanjut hingga hari ini. Faktanya, MISRA (sebagai organisasi) adalah komunitas pemangku kepentingan dari berbagai industri manufaktur mobil dan pesawat terbang. Sekarang pihak-pihak ini adalah:

• Mobil motor Bentley
• Ford Motor Company
• Jaguar land rover
• Sistem diesel delphi
• HORIBA MIRA
• Listrik protein
• Layanan teknik Visteon
• Universitas leeds
• Ricardo uk
• ZF TRW

Pelaku pasar yang sangat kuat, bukan? Tidak mengherankan, standar terkait bahasa pertama mereka, MISRA C, telah diterima secara luas di antara para pengembang tertanam yang kritis terhadap misi. MISRA C ++ muncul sedikit kemudian. Secara bertahap, versi standar diperbarui dan disempurnakan untuk mencakup fitur-fitur baru bahasa. Pada saat penulisan ini, versi saat ini adalah MISRA C: 2012 dan MISRA C ++: 2008.

Filsafat dan Contoh Aturan

Fitur yang paling khas dari MISRA adalah perhatiannya terhadap detail dan ketelitian yang luar biasa dalam memastikan keamanan. Para penulis tidak hanya berkumpul di satu tempat semua "lubang" C dan C ++ yang muncul di benak (seperti, misalnya, penulis CERT) - mereka dengan hati-hati menyusun standar internasional bahasa-bahasa ini dan menuliskan semua cara yang mungkin dan tidak terpikirkan untuk membuat kesalahan. Dan kemudian mereka mengambil dan menambahkan aturan tentang keterbacaan kode dari atas - ini untuk membuatnya lebih sulit untuk memperkenalkan kesalahan baru ke dalam kode yang sudah bersih.

Untuk memahami tingkat keseriusan, pertimbangkan beberapa aturan yang diambil dari standar.

Di satu sisi, ada banyak aturan yang baik dan cocok yang harus selalu diikuti setiap saat, terlepas dari apa tujuan proyek Anda. Sebagian besar, mereka dirancang untuk menghilangkan perilaku yang tidak ditentukan / tidak ditentukan / tergantung implementasi. Sebagai contoh:

• Jangan gunakan nilai variabel yang tidak diinisialisasi
• Jangan gunakan pointer FILE setelah menutup aliran
• Semua fungsi non-void harus mengembalikan nilai.
• Penghitung lingkaran tidak boleh memiliki tipe titik-mengambang
• ... dll.

Di sisi lain, ada aturan, manfaat yang terletak di permukaan, tetapi yang (dari sudut pandang proyek biasa) tidak begitu berdosa untuk dilanggar:

• Jangan gunakan goto dan longjmp
• Setiap switch harus diakhiri dengan default
• Jangan menulis kode yang tidak terjangkau
• Jangan gunakan fungsi variabel
• Jangan gunakan aritmatika alamat (kecuali [] dan ++ )
• ...

Aturan seperti itu juga tidak buruk, dan dalam kombinasi dengan yang sebelumnya mereka sudah memberikan peningkatan keamanan yang nyata, tetapi apakah ini cukup untuk sistem embedded yang sangat bertanggung jawab? Mereka digunakan tidak hanya dalam industri otomotif, tetapi juga dalam pembuatan pesawat terbang, kedirgantaraan, militer, dan medis.

Kami tidak ingin, karena kesalahan perangkat lunak, beberapa mesin sinar-X menyinari pasien dengan dosis 20.000 rad , sehingga aturan "sehari-hari" yang biasa tidak lagi cukup. Yang dipertaruhkan adalah nyawa manusia dan sejumlah besar uang, dan ketelitian harus dimasukkan. Di sini aturan MISRA lainnya naik ke atas panggung:

• Sufiks 'L' dalam literal harus selalu huruf besar (huruf 'l' kecil dapat dikacaukan dengan unit)
• Jangan gunakan operator koma (meningkatkan kemungkinan melakukan kesalahan)
• Jangan gunakan rekursi (setumpuk mikrokontroler kecil dapat dengan mudah meluap)
• Badan if , else , for , while , do , statement switch harus dibungkus dengan kurung kurawal (Anda berpotensi dapat membuat kesalahan jika kode tidak disejajarkan dengan benar )
• Jangan gunakan memori dinamis (karena ada kemungkinan tidak berhasil mengalokasikannya dari tumpukan, terutama di mikrokontroler)
• ... dan banyak, banyak aturan seperti itu.

Seringkali, orang yang menemukan MISRA berpendapat bahwa filosofi standar adalah "melarang ini dan melarang ini." Sebenarnya ini memang benar, tetapi hanya sebagian saja.

Ya, standar memang memiliki banyak aturan yang serupa, tetapi tujuannya bukan untuk melarang segala sesuatu yang mungkin, tetapi untuk membuat daftar semua-semua-semua cara untuk entah bagaimana melanggar keamanan kode. Untuk sebagian besar aturan, Anda memilih untuk mengikutinya atau tidak. Saya akan menjelaskan ini secara lebih rinci.

Dalam MISRA C, aturan termasuk dalam tiga kategori utama: Mandatory, Required, and Advisory. Wajib - ini adalah aturan yang tidak boleh dilanggar dengan alasan apa pun. Misalnya, bagian ini mencakup aturan "jangan gunakan nilai variabel yang tidak diinisialisasi". Aturan yang diperlukan kurang ketat: mereka memungkinkan kemungkinan penolakan, tetapi hanya jika penyimpangan ini didokumentasikan dan dibenarkan secara tertulis. Aturan yang tersisa termasuk dalam kategori Penasihat - ini adalah aturan yang tidak perlu diikuti.

MISRA C ++ sedikit berbeda: kategori Wajib tidak ada di sana, dan sebagian besar aturan termasuk dalam kategori Wajib. Karena itu, pada kenyataannya, Anda memiliki hak untuk melanggar aturan apa pun - ingatlah untuk mendokumentasikan penyimpangan tersebut. Ada juga Dokumen kategori - ini adalah aturan wajib (penyimpangan tidak diperbolehkan), yang terkait dengan praktik umum seperti "Setiap penggunaan assembler harus didokumentasikan" atau "perpustakaan plug-in harus mematuhi MISRA C ++".

Apa lagi yang ada di sana

Faktanya, MISRA bukan hanya seperangkat aturan. Bahkan, ini adalah manual untuk menulis kode aman untuk mikrokontroler, dan karena itu penuh dengan segala macam kegunaan. Mari kita lihat secara detail.

Pertama, standar berisi deskripsi latar belakang yang agak menyeluruh: demi apa standar dibuat, mengapa C atau C ++ dipilih, kelebihan dan kekurangan bahasa ini.

Kami sangat menyadari keutamaan bahasa-bahasa ini. Ya, dan tentang kekurangannya, secara umum juga :) Apa kompleksitas tinggi, spesifikasi standar dan sintaksis yang tidak lengkap yang membuatnya sangat mudah untuk membuat kesalahan, dan kemudian mencari kesalahan untuk waktu yang lama. Misalnya, Anda dapat menulis ini tanpa sengaja:

for (int i = 0; i < n; ++i); { do_something(); } 

Namun, ada kemungkinan bahwa seseorang tidak akan melihat titik koma tambahan , kan? Anda juga dapat menulis seperti ini :

 void SpendTime(bool doWantToKillPeople) { if (doWantToKillPeople = true) { StartNuclearWar(); } else { PlayComputerGames(); } } 

Baik bahwa kasus pertama dan kedua mudah ditangkap oleh aturan MISRA (yang pertama adalah MISRA C: 13.4 / MISRA C ++: 6.2.1, yang kedua adalah MISRA C: 13.4 / MISRA C ++: 6.2.1).

Selain menjelaskan masalah, standar berisi sejumlah besar tips tentang apa yang perlu Anda ketahui sebelum Anda mulai: tentang cara mengatur proses pengembangan MISRA, tentang penggunaan analisis statis untuk memeriksa kode kepatuhan, pada dokumen mana yang perlu Anda simpan, dan bagaimana isi, dan sebagainya dan sebagainya.

Di bagian akhir juga terdapat aplikasi yang berisi: daftar pendek dan ringkasan tabel aturan, daftar kecil kerentanan C / C ++, contoh dokumentasi penyimpangan dari aturan, serta beberapa daftar periksa yang dirancang untuk membantu Anda tidak tersesat di seluruh birokrasi ini.

Seperti yang Anda lihat, MISRA bukan hanya seperangkat aturan, tetapi hampir seluruh infrastruktur untuk menulis kode aman untuk sistem tertanam.

Gunakan dalam proyek Anda

Bayangkan sebuah situasi: Anda akan menulis sebuah program untuk beberapa sistem embedded yang sangat penting dan bertanggung jawab. Atau Anda sudah memiliki program, tetapi Anda perlu "mentransfer" ke MISRA. Bagaimana cara memeriksa kode Anda untuk kepatuhan terhadap standar? Apakah Anda benar-benar harus melakukannya secara manual?

Verifikasi kode manual bukanlah tugas yang mudah dan berpotensi tidak mungkin. Tidak hanya setiap pengulas harus hati-hati melihat setiap baris kode, tetapi mereka juga harus tahu standarnya. Horor!

Oleh karena itu, pengembang MISRA sendiri disarankan untuk menggunakan analisis statis untuk menguji kode Anda. Memang, pada kenyataannya, analisis statis adalah proses peninjauan kode otomatis. Anda cukup menjalankan analisa pada program Anda dan dalam beberapa menit Anda akan menerima laporan tentang kemungkinan pelanggaran standar. Apa yang Anda butuhkan, bukan? Anda hanya perlu melihat log dan memperbaiki responsnya.

Pertanyaan berikutnya: pada titik apa Anda mulai menggunakan MISRA? Jawabannya sederhana: semakin cepat semakin baik. Idealnya, bahkan sebelum Anda mulai menulis kode, karena MISRA mengasumsikan bahwa Anda mengikuti standar selama masa pakai kode Anda.

Tentu saja, tidak selalu mungkin untuk menulis MISRA sejak awal. Sebagai contoh, sering terjadi bahwa suatu proyek telah dilaksanakan sebagian atau sepenuhnya, tetapi pelanggan berharap bahwa proyek tersebut memenuhi standar. Dalam hal ini, Anda harus melakukan refactoring menyeluruh terhadap kode yang ada.

Di sinilah perangkap muncul. Saya bahkan akan mengatakan batu bawah air muncul. Apa yang terjadi jika Anda mengambil analisa statis dan memeriksa proyek "biasa" untuk kepatuhan dengan standar MISRA? Spoiler: Anda bisa takut.

Tentu saja, contoh dalam gambar ini dilebih-lebihkan. Di sini Anda dapat melihat hasil pengecekan proyek yang cukup besar, yang sebenarnya tidak pernah terpikirkan untuk mengerjakan mikrokontroler. Namun demikian, ketika memeriksa kode yang ada, Anda mungkin melihat satu, dua, lima, atau bahkan sepuluh ribu operasi penganalisa. Dan dalam semua tumpukan ini operasi baru akan hilang yang dikeluarkan ke kode yang baru saja ditulis atau diubah.

Apa yang harus dilakukan? Apakah benar-benar perlu mengesampingkan semua hal dan duduk untuk memperbaiki semua yang lama?

Kita tahu bahwa pertama kali proyek diperiksa, banyak hal positif yang muncul cukup sering, dan telah mengembangkan solusi yang akan membantu Anda mendapatkan manfaat dari penganalisa dengan segera, tanpa menghentikan pekerjaan. Solusi ini disebut "basis penekan."

Basis penekan adalah mekanisme PVS-Studio yang memungkinkan pesan penganalisa menekan secara besar-besaran. Jika Anda memeriksa proyek untuk pertama kalinya dan menemukan beberapa ribu positif di sana, Anda cukup menambahkannya ke basis penekan, dan saat berikutnya Anda menjalankan analisa, itu akan memberi Anda nol peringatan.

Dengan demikian, Anda dapat terus menulis dan memodifikasi kode dengan cara biasa, dan pada saat yang sama Anda akan melihat peringatan hanya tentang kesalahan-kesalahan yang baru saja diperkenalkan ke dalam proyek. Pada saat yang sama, Anda akan mendapatkan manfaat maksimal dari alat analisa di sini dan sekarang, tanpa terganggu oleh kesalahan lama. Beberapa klik - dan alat analisa diimplementasikan! Anda dapat membaca petunjuk terperinci tentang ini di sini .

Anda mungkin bertanya: "Tunggu, apa yang harus dilakukan dengan tanggapan tersembunyi?" Jawabannya cukup sederhana: jangan lupa tentang mereka dan diam-diam memperbaikinya. Anda dapat, misalnya, meletakkan basis penekan dalam sistem kontrol versi dan hanya memperbolehkan komit yang tidak menambah jumlah operasi. Dengan demikian, secara bertahap, "batu bawah air" Anda cepat atau lambat akan terkuras dan tidak akan ada jejaknya.

Oke, alat analisa sudah diimplementasikan dan sekarang kami siap untuk melanjutkan. Apa yang harus dilakukan selanjutnya? Bersihkan bisnis - untuk bekerja dengan kode. Tetapi apa yang dibutuhkan untuk dapat menyatakan kepatuhan dengan standar? Bagaimana membuktikan bahwa proyek Anda sesuai dengan MISRA?

Faktanya adalah bahwa tidak ada "sertifikat" khusus yang sesuai dengan kode Anda dengan MISRA. Sesuai standar itu sendiri, pelacakan kode kepatuhan harus dilakukan oleh dua pihak: pelanggan perangkat lunak dan penyedia perangkat lunak. Pemasok mengembangkan perangkat lunak yang sesuai dengan standar dan mengisi dokumen yang diperlukan. Pelanggan, untuk bagiannya, harus memastikan bahwa data dari dokumen-dokumen ini benar.

Jika Anda sendiri adalah pelanggan dan pengembang perangkat lunak Anda sendiri, maka tanggung jawab untuk mematuhi standar hanya akan berada di pundak Anda :)

Secara umum, untuk membuktikan kesesuaian proyek Anda, Anda akan memerlukan dokumen bukti. Daftar dokumen yang harus disiapkan oleh pengembang proyek dapat beragam, tetapi MISRA menawarkan beberapa sebagai referensi. Mari kita pertimbangkan set ini lebih detail.

Untuk mengklaim kepatuhan dengan standar, Anda akan memerlukan beberapa hal:

• Sebenarnya proyek yang kodenya mematuhi aturan Wajib dan Diperlukan
• Panduan rencana penegakan
• Dokumentasi semua peringatan penyusun dan penganalisa statis
• Dokumentasi semua penyimpangan dari aturan yang Diperlukan
• Ringkasan pedoman kepatuhan

Yang pertama adalah rencana kepatuhan. Ini adalah meja Anda yang paling penting, dan akan mengirim penguji ke semua dokumen lain. Pada kolom pertama adalah daftar aturan MISRA, sisanya dicatat apakah ada penyimpangan dari aturan ini telah diidentifikasi. Tabel ini terlihat seperti ini:

Standar merekomendasikan membangun proyek Anda dengan beberapa kompiler, serta menggunakan dua atau lebih analisa statis untuk memeriksa kode Anda untuk kepatuhan. Jika kompilator atau penganalisa menghasilkan semacam peringatan yang terkait dengan aturan, Anda harus mencatat ini dalam tabel dan dokumen: mengapa operasi tidak dapat dihilangkan, apakah itu salah, dll.

Jika ada aturan yang tidak dapat diperiksa dengan penganalisa statis, maka Anda perlu melakukan prosedur peninjauan kode. Prosedur ini juga harus didokumentasikan, setelah itu tautan ke dokumentasi ini harus ditambahkan ke rencana kepatuhan.

Jika kompiler atau penganalisa statis ternyata benar, atau jika pelanggaran kode aktual ditemukan dalam proses peninjauan kode, Anda harus memperbaikinya atau mendokumentasikannya. Sekali lagi, dengan melampirkan tautan ke dokumentasi di tabel.

Dengan demikian, rencana kepatuhan adalah dokumen yang dengannya Anda dapat menemukan dokumentasi untuk setiap penyimpangan yang diidentifikasi dalam kode Anda.

Sekarang sedikit tentang dokumentasi penyimpangan dari aturan. Seperti yang telah saya sebutkan, dokumentasi semacam itu hanya diperlukan untuk aturan yang Diperlukan, karena Anda tidak dapat melanggar aturan tingkat Wajib, dan aturan Penasihat tidak dapat diikuti tanpa dokumentasi apa pun.

Jika Anda memutuskan untuk menyimpang dari aturan, maka dokumentasi harus berisi:

• Nomor Aturan Rusak
• Lokasi penyimpangan yang tepat
• Validitas penyimpangan
• Bukti bahwa penyimpangan tidak membahayakan keamanan
• Implikasi pengguna potensial

Seperti yang Anda lihat, pendekatan dokumentasi ini membuat Anda berpikir serius apakah pelanggaran itu sepadan. Hal ini dilakukan secara khusus untuk melanggar peraturan yang diperlukan tidak baik :)

Sekarang tentang ringkasan kepatuhan dengan aturan. Makalah ini mungkin yang paling mudah diisi:

Kolom pusat diisi sebelum Anda mulai bekerja dengan kode, dan kolom paling kanan adalah setelah proyek Anda siap.

Cukup masuk akal untuk mengajukan pertanyaan: mengapa Anda perlu menentukan kategori aturan, jika sudah ditentukan dalam standar itu sendiri? Faktanya adalah bahwa standar memungkinkan "peningkatan" aturan dalam kategori yang lebih ketat. Misalnya, pelanggan mungkin meminta Anda untuk memindahkan aturan Penasihat ke dalam kategori. "Peningkatan" seperti itu harus dilakukan sebelum bekerja dengan kode, dan ringkasan kepatuhan dengan aturan memungkinkan hal ini dicatat dengan jelas.

Dengan kolom terakhir, semuanya sederhana: cukup untuk hanya mencatat apakah aturan itu digunakan, dan jika demikian, maka ada penyimpangan dari itu.

Seluruh tabel ini diperlukan agar Anda dapat dengan cepat melihat prioritas apa yang dimiliki aturan dan apakah kode cocok dengan mereka. Jika tiba-tiba Anda tertarik untuk mengetahui alasan pasti penolakan, Anda selalu dapat merujuk ke rencana kepatuhan dan menemukan dokumentasi yang Anda butuhkan.

Jadi, Anda menulis kode dengan hati-hati mengikuti aturan MISRA. Anda membuat rencana kepatuhan dan mendokumentasikan semua yang dapat Anda dokumentasikan, dan mengisi ringkasan kepatuhan. Jika ini benar, maka Anda telah menerima kode yang sangat bersih, sangat mudah dibaca, dan sangat andal yang sekarang Anda benci :)

Di mana program Anda akan tinggal sekarang? Di mesin MRI? Dalam sensor kecepatan biasa atau dalam sistem autopilot dari beberapa satelit luar angkasa? Ya, Anda melewati jalur birokrasi yang serius, tapi ini sepele. Bagaimana mungkin seseorang tidak menjadi teliti ketika kehidupan manusia nyata dipertaruhkan?

Jika Anda berhasil dan berhasil mencapai kemenangan, maka saya dengan tulus mengucapkan selamat kepada Anda: Anda menulis kode aman berkualitas tinggi. Terima kasih

Masa depan standar

Akhirnya, saya ingin berbicara sedikit tentang masa depan standar.

MISRA saat ini hidup dan berkembang. Misalnya, pada awal 2019, “MISRA C: 2012 Edisi Ketiga (Revisi Pertama)” diumumkan - pembaruan dan dilengkapi dengan aturan baru 2012 standar. Pada saat yang sama, mereka mengumumkan rilis MISRA C: Amandemen 2 - C11 Core yang akan datang, standar 2012, di mana aturan akan ditambahkan yang mencakup versi pertama bahasa C pada tahun 2011 dan 2018.

Tidak diam dan MISRA C ++. Seperti yang Anda ketahui, standar MISRA C ++ terbaru kembali ke tahun 2008, jadi versi bahasa tertua yang tercakup adalah C ++ 03. Karena itu, ada standar lain, mirip dengan MISRA, dan itu disebut AUTOSAR C ++. Ini awalnya dipahami sebagai kelanjutan dari MISRA C ++ dan dimaksudkan untuk mencakup versi bahasa selanjutnya. Tidak seperti dalangnya, AUTOSAR C ++ diperbarui dua kali setahun dan saat ini mendukung C ++ 14. Peningkatan lebih lanjut direncanakan untuk C ++ 17, dan kemudian C ++ 20, dan seterusnya.

Apa yang saya mulai tentang standar lain? Faktanya adalah bahwa kurang dari setahun yang lalu, kedua organisasi mengumumkan penyatuan standar mereka menjadi satu. Sekarang MISRA C ++ dan AUTOSAR C ++ akan menjadi standar tunggal, dan sekarang mereka akan dikembangkan bersama. Saya pikir ini adalah berita bagus untuk pengembang yang menulis di bawah mikrokontroler C ++, dan tidak kurang berita bagus untuk pengembang analisis statis. Masih banyak pekerjaan favorit di depan! :)

Kesimpulan

Hari ini kami telah belajar banyak tentang MISRA: kami membaca sejarah kemunculannya, mempelajari contoh aturan dan filosofi standar, mempertimbangkan semua yang Anda butuhkan untuk menggunakan MISRA dalam proyek Anda, dan bahkan melihat sedikit ke masa depan. Saya harap Anda sekarang lebih memahami apa MISRA itu dan bagaimana cara memasaknya!

Menurut tradisi lama, saya akan meninggalkan tautan di sini ke penganalisa statis PVS-Studio kami. Ia dapat menemukan tidak hanya penyimpangan dari standar MISRA, tetapi juga sejumlah besar kesalahan dan kerentanan. Jika Anda tertarik untuk mencoba PVS-Studio sendiri, unduh versi demo dan periksa proyek Anda.

Ini menyimpulkan artikel saya. Saya berharap semua pembaca selamat Tahun Baru dan akhir pekan Tahun Baru yang bahagia!

Tautan situs

1. Georgy Gribkov - " Keamanan dengan kecepatan maksimum - cara menulis kode C / C ++ yang andal untuk sistem tertanam ."
2. PVS-Studio adalah penganalisa kode statis .
3. Kolaborasi PVS-Studio & KEIL 5 .

Jika Anda ingin berbagi artikel ini dengan audiens yang berbahasa Inggris, silakan gunakan tautan ke terjemahan: George Gribkov. Apa itu MISRA dan bagaimana cara memasaknya .