Tingkatkan Statechart vs. Mesin Meta State


142

Rupanya boost mengandung dua perpustakaan terpisah untuk mesin-mesin negara: Statechart dan Meta State Machine (MSM). Tagline memberikan deskripsi yang sangat mirip:

  • Boost.Statechart - Mesin negara berhingga yang rumit secara arbitrer dapat diimplementasikan dalam kode C ++ yang mudah dibaca dan dipelihara.
  • Meta State Machine - Pustaka berperforma sangat tinggi untuk mesin negara hingga UML2 ekspresif.

Apakah Anda tahu apa perbedaan utama dan apa pertimbangan dalam memilih di antara keduanya?


4
Hehe, kasus lain yang sangat menarik tetapi tidak ada yang tahu jawabannya ... :)
j_random_hacker

8
: D Pertanyaan ini adalah puncak dari pengalaman SO saya! Dapatkan jawaban dari kedua pengembang ... bisakah ini menjadi lebih baik ?! Banyak terima kasih kepada Christophe dan Andreas.
FireAphis

Pertanyaan yang sangat bagus dan Anda berhasil mendapatkan jawaban dari dua pengembang yang bersaing!
Offirmo

3
Statechart membuat Anda menempatkan fungsionalitas ke dalam konstruktor dan destruktor. Itu anti-pola, terutama dengan destruktor.
Im

2
Di Statechart, tindakan keluar dapat dimasukkan ke dalam keluar yang terpisah () pawang yang dipanggil sebelum kehancuran. Saya pikir ketentuan ini mengurangi masalah utama dengan pola anti yang disebutkan oleh Lev.
Tim Crews 4-15

Jawaban:


116

Karena tampaknya ada banyak minat, perkenankan saya memberikan pendapat saya (yang jelas-jelas bias), yang karenanya harus diambil dengan sebutir garam:

  • MSM jauh lebih cepat
  • MSM tidak memerlukan RTTI atau apapun virtual
  • MSM memiliki dukungan UML2 yang lebih lengkap (misalnya transisi internal, wilayah orthogonal yang sesuai dengan UML)
  • MSM menawarkan bahasa deskriptif (sebenarnya beberapa). Misalnya, menggunakan front-end eUML, transisi dapat digambarkan sebagai Sumber + Acara [Penjaga] / Aksi == Target
  • MSM akan membuat kompiler Anda menderita untuk mesin negara yang lebih besar, sehingga Anda akan memerlukan kompiler yang cukup baru (g ++> = 4.x, VC> = 9)

Anda dapat membuat diri Anda pendapat yang lebih baik dengan mencari komentar yang diposting selama peninjauan MSM. Subjek ini banyak dibahas dalam daftar pengembang.


2
Terima kasih banyak. Sangat menyenangkan mendengar pendapat pengembang itu sendiri! Sekarang kita hanya perlu respons Andreas Huber :)
FireAphis

16
Pilihan kecil: Dalam mode rilis, penggunaan C ++ RTTI (dynamic_cast, typeid) sangat opsional dengan Boost.Statechart.

111

Seperti yang telah disebutkan Christophe, salah satu perbedaan utama antara kedua perpustakaan adalah kinerja runtime. Walaupun MSM mungkin menawarkan yang terbaik yang bisa Anda dapatkan di sini, Statechart secara sadar memperdagangkan memori dan siklus prosesor menuju skalabilitas yang lebih baik.

Dengan Boost.Statechart Anda dapat menyebarkan tata letak (yaitu status, transisi) mesin negara Anda ke beberapa unit terjemahan (file cpp) dengan cara yang tidak dapat Anda lakukan dengan MSM. Ini memungkinkan Anda untuk membuat implementasi FSM besar lebih mudah dikelola dan mendapatkan kompilasi yang jauh lebih cepat daripada dengan MSM.

Apakah overhead kinerja Statechart dibandingkan dengan MSM akan benar-benar signifikan untuk aplikasi Anda, seringkali cukup mudah untuk dijawab ketika Anda bertanya pada diri sendiri berapa banyak acara yang harus diproses aplikasi Anda per detik.

Dengan asumsi FSM yang cukup kompleks diimplementasikan dengan Boost.Statechart, berikut adalah beberapa angka rata-rata:

  • Sebagian besar perangkat keras PC saat ini akan dengan mudah mengatasi> 100.000 peristiwa per detik
  • Bahkan perangkat keras yang sangat terbatas sumber daya akan dapat memproses beberapa ratus peristiwa per detik.

Mengenai beban CPU, jika jumlah acara untuk diproses jauh lebih rendah dari angka-angka ini, Boost.Statechart overhead dibandingkan dengan MSM hampir pasti tidak akan terlihat. Jika angkanya jauh lebih tinggi, Anda pasti lebih baik dengan MSM.

Informasi lebih mendalam tentang pengorbanan kinerja / skalabilitas dapat ditemukan di sini: http://www.boost.org/doc/libs/1_45_0/libs/statechart/doc/performance.html


9
Hai Andreas, soal penyebaran tata letak, sudah ada beberapa perbaikan. Anda sekarang dapat mengkompilasi submachine pada core yang berbeda. Itu tidak sempurna tetapi peningkatan yang nyata. Lihat svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/…
Christophe Henry

11

Saat mengkode implementasi PPP saya sendiri, saya menggunakan Statechart karena tiga alasan: 1) Statechart lebih sederhana dan memiliki dokumentasi yang lebih jelas; 2) Saya sangat tidak menyukai UML :)

Boost docs mengatakan MSM setidaknya 20 kali lebih cepat, tetapi kompilasi cukup lambat untuk FSM besar.


7
Sementara saya setuju bahwa banyak dari UML adalah pakaian baru kaisar, bagan negara adalah satu hal yang sebenarnya memiliki nilai dalam UML.
Jon Trauntvein

4
Jelas, tapi saya belajar statecharts dari matematika diskrit, bukan rekayasa perangkat lunak. Ini meninggalkan bekas :)
nyalakan

4

Beberapa waktu lalu saya mulai dengan Statechart dan pindah ke MSM karena lebih mudah digunakan bersama dengan asio dari satu utas. Saya tidak berhasil menyatukan Statechart dan kemampuan multithreading-nya dengan penggunaan saya pada asio - kemungkinan semacam pemula yang tidak memahami Statechart di pihak saya. Saya menemukan bahwa MSM lebih mudah digunakan karena tidak membahas multithreading.


1
Sebagian besar tipe statechart tidak membahas threading. Sehubungan dengan multithreading, Anda harus dapat menggunakan boost :: statechart :: state_machine seperti halnya mitra MSM. boost :: statechart :: asynchronous_state_machine dan tipe yang terkait adalah bagian opsional ketat dari perpustakaan statechart.

2

Sebagai jawaban atas keterlambatan Tim untuk berdiskusi (yang juga membahas salah satu komentar paling awal dari Lev).

Sebagai salah satu dari mereka yang berpendapat untuk keluar dari destruktor di statechart (argumen berdasarkan kasus penggunaan nyata, tentang interaksi dengan dunia nyata yaitu I / O) kembali ketika diajukan ke Boost, saya setuju ada masalah dalam menempatkan keluar logika dalam destruktor. David Abrahams secara mengejutkan membuat argumen persuasif tentang keselamatan pengecualian juga. Karena alasan itu, Statechart tidak mengharuskan Anda untuk menempatkan logika pada destruktor - tetapi memungkinkan Anda untuk - dengan saran yang biasa.

Logika yang seharusnya hanya dijalankan sebagai bagian dari transisi keluar dari keadaan (bukan penghancuran objek statechart secara keseluruhan) dapat (dan harus jika ada juga pembersihan sumber daya yang harus dilakukan) dipisahkan menjadi tindakan keluar () yang terpisah.

Untuk keadaan "tipis" tanpa keadaan aktif (sumber daya), cukup tindakan masuk / keluar untuk dilakukan, Anda dapat melakukan tindakan tersebut dalam ctor dan d'tor dan pastikan konstruktor dan destruktor tidak melempar. Tidak ada alasan bagi mereka untuk - tidak ada negara untuk melakukan RAII - tidak ada kejahatan dalam memiliki penanganan kesalahan di tempat-tempat ini menimbulkan peristiwa yang tepat. Anda mungkin masih perlu mempertimbangkan apakah Anda ingin tindakan keluar yang mengubah keadaan eksternal untuk berjalan pada kehancuran mesin negara ... dan menempatkannya dalam tindakan keluar jika Anda tidak ingin mereka terjadi dalam kasus ini ...

Statechart memodelkan aktivasi sebagai instantiasi objek, jadi jika konstruktor Anda memiliki pekerjaan / aktivasi / instantiasi nyata untuk dilakukan dan jika ia dapat gagal sehingga keadaan tidak dapat dimasukkan, Statechart mendukung itu dengan memberi Anda kemampuan untuk memetakan pengecualian terhadap suatu peristiwa. Ini ditangani dengan cara yang bekerja pada hierarki negara mencari keadaan luar yang menangani peristiwa pengecualian, analog dengan cara tumpukan akan membatalkan untuk model doa berdasarkan panggilan stack.

Ini semua didokumentasikan dengan baik - Saya sarankan Anda membaca dokumen dan mencobanya. Saya menyarankan Anda menggunakan destruktor untuk membersihkan "sumber daya perangkat lunak" dan keluar dari tindakan untuk melakukan "tindakan keluar dunia nyata".

Perlu dicatat bahwa propagasi pengecualian adalah sedikit masalah di semua lingkungan event driven, bukan hanya statechart. Cara terbaik untuk mempertimbangkan dan memasukkan kesalahan / kesalahan dalam desain statechart Anda dan jika dan hanya jika Anda tidak bisa menangani mereka dengan cara lain menggunakan pemetaan pengecualian. Setidaknya itu bekerja untuk saya - ymmmv ....


Terima kasih, saya melihat bahwa semua masalah saya cukup dibahas di bagian "Penanganan pengecualian" pada tutorial Boost :: statechart. Dalam hal ini, saya pikir komentar Lev (menyesatkan) dapat diatasi hanya dengan menunjuk ke bagian "keluar dua tahap" dari tutorial itu. Saya akan mempertimbangkan untuk menghapus jawaban saya, kecuali bahwa jawaban Anda sendiri menambahkan informasi berharga ke topik ini.
Tim Crews 4-15
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.