เพิ่ม Statechart กับ Meta State Machine

142

เพิ่มชัดเจนมีสองห้องสมุดแยกต่างหากสำหรับเครื่องรัฐ: StatechartและMeta State Machine (MSM) สโลแกนให้คำอธิบายที่คล้ายกันมาก:

Boost.Statechart - เครื่องสถานะ จำกัด ที่ซับซ้อนโดยพลการสามารถนำไปใช้ในรหัส C ++ ที่อ่านได้ง่ายและบำรุงรักษาได้
Meta State Machine - ห้องสมุดที่มีประสิทธิภาพสูงสำหรับเครื่องจักรสถานะ จำกัด UML2 ที่แสดงออกได้

คุณรู้หรือไม่ว่าอะไรคือความแตกต่างที่สำคัญและสิ่งที่ต้องพิจารณาในการเลือกระหว่างสองอย่างนี้คืออะไร?

— FireAphis
แหล่งที่มา

4

Hehe อีกกรณีที่น่าสนใจ แต่ไม่มีใครรู้คำตอบ ... :)

— j_random_hacker

8

: D คำถามนี้เป็นจุดสุดยอดของประสบการณ์ SO ของฉัน! รับคำตอบจากนักพัฒนาทั้งสอง ... มันจะดีขึ้นกว่านี้ไหม! ขอบคุณมากสำหรับ Christophe และ Andreas

— FireAphis

คำถามยอดเยี่ยมและคุณได้รับคำตอบของผู้พัฒนาที่แข่งขันกันสองคน!

— Offirmo

3

Statechart ทำให้คุณใส่ฟังก์ชันการทำงานลงในตัวสร้างและตัวทำลาย นั่นเป็นรูปแบบการต่อต้านโดยเฉพาะกับผู้ทำลายล้าง

— เลฟ

2

ใน Statechart การดำเนินการ exit สามารถวางใน handler exit () แยกที่เรียกว่าก่อนการทำลาย ฉันคิดว่าบทบัญญัตินี้ช่วยบรรเทาปัญหาหลักด้วยรูปแบบการต่อต้านที่เลฟกล่าวถึง

— ทิมลูกเรือส์

116

เนื่องจากดูเหมือนว่าจะมีความสนใจมากโปรดอนุญาตให้ฉันแสดงความเห็นของฉัน (ลำเอียง) ซึ่งควรนำมาด้วยเม็ดเกลือ:

ชายรักชายนั้นเร็วขึ้นมาก
ชายรักชายไม่จำเป็นต้องมี RTTI หรืออะไรเสมือน
MSM มีการสนับสนุน UML2 ที่สมบูรณ์มากขึ้น (ตัวอย่างเช่นการเปลี่ยนภายใน, ภูมิภาคที่สอดคล้องกับมุมฉาก UML)
MSM เสนอภาษาบรรยาย (จริง ๆ แล้วมีหลายภาษา) ตัวอย่างเช่นการใช้ eUML front-end การเปลี่ยนแปลงสามารถอธิบายได้ว่าเป็นแหล่งที่มา + เหตุการณ์ [ยาม] / การกระทำ == เป้าหมาย
MSM จะทำให้คอมไพเลอร์ของคุณต้องทนทุกข์ทรมานกับเครื่องจักรขนาดใหญ่ดังนั้นคุณจะต้องใช้คอมไพเลอร์เมื่อไม่นานมานี้ (g ++> = 4.x, VC> = 9)

คุณสามารถทำให้ตัวเองมีความคิดเห็นที่ดีขึ้นโดยการมองหาความคิดเห็นที่โพสต์ระหว่างการตรวจสอบของ MSM หัวข้อนี้มีการพูดคุยกันมากในรายการผู้พัฒนา

— Christophe Henry
แหล่งที่มา

2

ขอบคุณมาก. ยินดีที่ได้ทราบความคิดเห็นของนักพัฒนาซอฟต์แวร์เอง! ตอนนี้เราต้องการการตอบสนองของ Andreas Huber :)

— FireAphis

16

เล็กน้อย nit-pick: ในโหมด release, การใช้ C ++ RTTI (dynamic_cast, typeid) เป็นทางเลือกอย่างเคร่งครัดกับ Boost.Statechart

111

ดังที่ Christophe ได้กล่าวไปแล้วหนึ่งในข้อแตกต่างที่สำคัญระหว่างสองไลบรารีคือประสิทธิภาพรันไทม์ ในขณะที่ MSM อาจเสนอสิ่งที่ดีที่สุดที่คุณจะได้รับจากที่นี่ Statechart ทำการซื้อขายหน่วยความจำและรอบการประมวลผลอย่างมีสติเพื่อปรับขนาดได้ดีขึ้น

ด้วย Boost.Statechart คุณสามารถกระจายเลย์เอาต์ (เช่นสถานะช่วงการเปลี่ยนภาพ) ของเครื่องสถานะของคุณผ่านหน่วยแปลหลายไฟล์ (ไฟล์ cpp) ในแบบที่คุณไม่สามารถทำได้ด้วย MSM สิ่งนี้ช่วยให้คุณสามารถทำให้การใช้ FSM ขนาดใหญ่สามารถบำรุงรักษาได้มากขึ้นและรวบรวมได้เร็วกว่า MSM

ค่าใช้จ่ายในการปฏิบัติงานของ Statechart เปรียบเทียบกับ MSM หรือไม่นั้นสำคัญสำหรับแอปพลิเคชันของคุณซึ่งมักจะตอบคำถามได้ง่ายเมื่อคุณถามตัวเองว่ามีเหตุการณ์จำนวนเท่าใดที่แอปของคุณจะต้องดำเนินการต่อวินาที

สมมติว่า FSM ที่ซับซ้อนในระดับปานกลางมีการใช้งานกับ Boost.Statechart ต่อไปนี้เป็นหมายเลข ballpark บางส่วน:

ฮาร์ดแวร์พีซีในปัจจุบันส่วนใหญ่สามารถรับมือกับ> 100'000 เหตุการณ์ต่อวินาทีได้อย่างง่ายดาย
แม้มากฮาร์ดแวร์มีทรัพยากร จำกัด จะสามารถที่จะดำเนินการไม่กี่ร้อยเหตุการณ์ต่อวินาที

เกี่ยวกับการโหลดซีพียูถ้าจำนวนของเหตุการณ์ที่จะประมวลผลต่ำกว่าตัวเลขเหล่านี้มาก Boost.Statechart ค่าใช้จ่ายเมื่อเปรียบเทียบกับ MSM จะแทบไม่สังเกตเห็นแน่นอน ถ้าจำนวนนั้นสูงกว่านี้คุณก็จะดีขึ้นด้วย MSM

ข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับการแลกเปลี่ยนประสิทธิภาพ / ความยืดหยุ่นสามารถดูได้ที่นี่: http://www.boost.org/doc/libs/1_45_0/libs/statechart/doc/performance.html

9

สวัสดี Andreas เกี่ยวกับการแพร่กระจายของรูปแบบมีการปรับปรุงบางอย่าง ตอนนี้คุณสามารถรวบรวม submachines ใน cores ต่างกัน มันไม่สมบูรณ์แบบ แต่เป็นการปรับปรุงที่เห็นได้ชัดเจน ดูsvn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/…

— Christophe Henry

11

ในขณะที่การเข้ารหัสการใช้ PPP ของฉันเองฉันใช้ Statechart ด้วยเหตุผลสามประการ: 1) Statechart นั้นง่ายกว่าและมีเอกสารที่ชัดเจนกว่า; 2) ฉันไม่ชอบ UML จริงๆ :)

Boost docs บอกว่า MSM นั้นเร็วกว่าอย่างน้อย 20 เท่า แต่การรวบรวม FSM นั้นค่อนข้างช้า

— เปลวไฟ
แหล่งที่มา

7

ในขณะที่ฉันยอมรับว่า UML ส่วนใหญ่เป็นเสื้อผ้าใหม่ของจักรพรรดิแผนภูมิของรัฐเป็นสิ่งหนึ่งที่จริง ๆ แล้วมีคุณค่าใน UML

— Jon Trauntvein

4

แน่นอน แต่ฉันเรียนรู้สถานะจากคณิตศาสตร์ไม่ต่อเนื่องไม่ใช่วิศวกรรมซอฟต์แวร์ นี่เป็นเครื่องหมาย :)

— เปลวไฟ

4

เมื่อหลายปีก่อนฉันเริ่มต้นด้วย Statechart และย้ายไปที่ MSM เพราะมันง่ายกว่าที่จะใช้ร่วมกับ asio จากเธรดเดียว ฉันไม่ได้จัดการกับเครือข่าย Statechart และความสามารถในการทำงานแบบมัลติเธรดกับการใช้ asio ของฉัน - มันเป็นไปได้ที่จะมีความเข้าใจในมือใหม่ของ Statechart ในส่วนของฉัน ฉันพบว่า MSM นั้นใช้ง่ายกว่าเพราะไม่ได้ใช้มัลติเธรด

— กรรมแมงมุม
แหล่งที่มา

1

ประเภทแผนภูมิรัฐส่วนใหญ่ไม่ได้อยู่ที่การทำเกลียว สำหรับ multithreading คุณควรใช้ boost :: statechart :: state_machine เหมือนกับ MSM boost :: statechart :: asynchronous_state_machine และประเภทที่เกี่ยวข้องเป็นส่วนเสริมของไลบรารี statechart

2

ในการตอบคำถามสุดท้ายของทิมในการอภิปราย (ซึ่งยังกล่าวถึงหนึ่งในความคิดเห็นแรกสุดจากเลฟด้วย)

ในฐานะที่เป็นหนึ่งในผู้ที่แย้งสำหรับการแยกออกจาก destructors ใน statechart (อาร์กิวเมนต์ตามกรณีการใช้งานจริงเกี่ยวกับการมีปฏิสัมพันธ์กับโลกแห่งความเป็นจริงเช่น I / O) ย้อนกลับไปเมื่อมันถูกส่งไปยัง Boost ฉันเห็นด้วย ตรรกะใน destructors เดวิดอับราฮัมทำข้อโต้แย้งโน้มน้าวใจอย่างไม่น่าเชื่อเกี่ยวกับข้อยกเว้นด้านความปลอดภัยเช่นกัน ด้วยเหตุผลเหล่านั้น Statechart ไม่ต้องการให้คุณใส่ตรรกะใน destructors - แต่ช่วยให้คุณ - ด้วยคำแนะนำปกติ

ตรรกะที่ควรเรียกใช้เป็นส่วนหนึ่งของการเปลี่ยนแปลงจากสถานะ (ไม่ใช่การทำลายวัตถุ statechart โดยรวม) สามารถ (และควรถ้ามีทรัพยากรการล้างข้อมูลที่ต้องทำ) แยกออกเป็นการกระทำแยกต่างหาก ()

สำหรับสถานะ "thin" ที่ไม่มีสถานะแอ็คทีฟ (ทรัพยากร) เพียงแค่การเข้า / ออกเพื่อดำเนินการคุณสามารถทำการกระทำเหล่านั้นใน ctor และ d'tor และตรวจสอบให้แน่ใจว่าคอนสตรัคและ destructor ไม่ได้โยน ไม่มีเหตุผลที่พวกเขาจะ - ไม่มีรัฐใดที่ต้องปฏิบัติตาม RAII - ไม่มีความชั่วร้ายใด ๆ ในการจัดการข้อผิดพลาดในสถานที่เหล่านี้ทำให้เกิดเหตุการณ์ที่เหมาะสม คุณยังอาจต้องพิจารณาว่าคุณต้องการให้การกระทำออกจากนั้นเปลี่ยนสถานะภายนอกให้ทำงานโดยการทำลายเครื่องของรัฐแม้ว่า ... และทำให้พวกเขาออกจากการกระทำหากคุณไม่ต้องการให้เกิดการกระทำในกรณีนี้ ...

การเปิดใช้งานโมเดล Statechart เป็นการสร้างอินสแตนซ์ของวัตถุดังนั้นหากตัวสร้างของคุณมีการทำงานจริง / การเปิดใช้งาน / การสร้างอินสแตนซ์ที่ต้องทำและหากสามารถล้มเหลวได้เช่นนั้น เหตุการณ์ สิ่งนี้ได้รับการจัดการในวิธีที่ทำงานลำดับชั้นของรัฐที่กำลังมองหาสถานะภายนอกที่จัดการกับเหตุการณ์ข้อยกเว้นคล้ายกับวิธีที่สแต็กจะคลายสำหรับรูปแบบการเรียกตามสแต็กการโทร

เอกสารนี้เป็นเอกสารที่ดี - ฉันขอแนะนำให้คุณอ่านเอกสารและลองทำดู ฉันขอแนะนำให้คุณใช้ destructors เพื่อล้าง "ทรัพยากรซอฟต์แวร์" และออกจากการกระทำเพื่อดำเนินการ "การกระทำออกจริง"

เป็นที่น่าสังเกตว่าการเผยแพร่ข้อยกเว้นนั้นเป็นปัญหาเล็กน้อยในทุกสภาพแวดล้อมที่ขับเคลื่อนด้วยเหตุการณ์ไม่ใช่เพียงแค่แผนที่สถานะ ที่ดีที่สุดคือให้เหตุผลและรวมถึงข้อบกพร่อง / ข้อผิดพลาดในการออกแบบ statechart ของคุณและถ้าหากคุณไม่สามารถจัดการกับพวกเขาอีกวิธีหนึ่งที่จะยกเว้นการทำแผนที่ อย่างน้อยก็ใช้ได้กับฉัน - ymmmv ....

— da77a
แหล่งที่มา

ขอบคุณฉันเห็นว่าทุกข้อกังวลของฉันได้รับการแก้ไขอย่างเพียงพอในส่วน "การจัดการข้อยกเว้น" ของบทช่วยสอน :: Boostchartchart ในกรณีนั้นฉันคิดว่าข้อคิดเห็นของ Lev สามารถทำให้เข้าใจผิดได้ง่าย ๆ เพียงชี้ไปที่ส่วน "ทางออกสองขั้นตอน" ของบทช่วยสอนนั้น ฉันจะพิจารณาลบคำตอบของฉันยกเว้นว่าคำตอบของคุณเองจะเพิ่มข้อมูลที่มีค่าในหัวข้อนี้

— ทิมลูกเรือส์