การออกแบบซอฟต์แวร์ฝังตัว

11

ฉันเริ่มต้นในการเขียนโปรแกรมซอฟต์แวร์แบบฝังตัวโดยใช้ RTOS และเนื่องจากฉันเป็นผู้พัฒนาแอพพลิเคชั่นเดสก์ท็อปอยู่แล้วฉันก็ยังสงสัยว่ามันจะเป็นอย่างไรกับซอฟต์แวร์ฝังตัวโดยใช้แผนภาพ UML เช่น Activity Diagrams Sequence Diagrams

ซอฟต์แวร์แบบฝังตัวได้รับการออกแบบโดยใช้ UML เหมือนกับแอปพลิเคชันเดสก์ท็อปหรือไม่ มันเป็นตัวเลือกที่ดีที่สุดหรือมีทางเลือกที่ดีกว่า ฉันขอตัวอย่างได้ไหม

มีเครื่องมือเฉพาะที่ทำสิ่งนี้หรือไม่?

embedded software

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

8

ไม่มีอะไรเฉพาะเจาะจงเกี่ยวกับแอปพลิเคชันแบบฝัง สิ่งที่พิเศษคือแอปพลิเคชั่นที่มีการ จำกัด ทรัพยากรส่วนใหญ่ของข้อ จำกัด ดังกล่าวคือข้อ จำกัด ด้านเวลา หากคุณบอกเราเพิ่มเติมเกี่ยวกับข้อกำหนดสำหรับใบสมัครของคุณเราอาจจะเป็นคำตอบสำหรับคุณ

— Wouter van Ooijen

3

ฉันเห็นด้วยทั้งหมดกับความคิดเห็นของ @ Wouter เกี่ยวกับแอปพลิเคชั่นที่ จำกัด ทรัพยากร แต่ฉันเชื่อว่ามีความแตกต่างในการออกแบบเฉพาะที่เกี่ยวข้องกับการใช้ RTOS กับสภาพแวดล้อมการพัฒนาเดสก์ท็อปที่มีกำหนดเวลานุ่มนวล

— HikeOnPast

1

ระวังระบบฝังตัวที่มีการ overengineering ดูได้ที่ "The King's Toaster" ee.ryerson.ca/~elf/hack/ktoast.html

— drxzcl

2

@drxzcl - ไม่เห็นด้วย ประการแรกฉันไม่คิดว่าคุณจะใส่ใจมากเกินไปเมื่อออกแบบซอฟต์แวร์ที่มีคุณสมบัติเหมาะสมกับพื้นที่ ประการที่สองวิธีการของวิศวกรในการใช้เครื่องปิ้งขนมปังของ King คือเหตุผลที่ขนมปังถูกเผาไหม้จำนวนมาก เครื่องปิ้งขนมปังส่วนใหญ่นั้นง่ายเกินไปสำหรับสิ่งที่เป็นงานที่ไม่สำคัญ

— Rocketmagnet

1

@Cassio: ฉันกับ Wouter ในนี้ คุณต้องวิเคราะห์ปัญหาด้วยตัวเองแล้วทำแผนที่ส่วนสำคัญโดยใช้ระบบที่คุณคิดว่าเหมาะสม ปัญหาเกี่ยวกับการเลือกการแสดงก่อนที่จะวิเคราะห์ปัญหาคือคุณติดขัดในการเห็นปัญหาในลักษณะที่แน่นอน UML เป็นตัวแทนที่มีรากฐานมาจากซอฟต์แวร์ระดับองค์กรและคุณไม่ต้องการล่อลวงในการออกแบบซอฟต์แวร์ฝังตัวเช่นซอฟต์แวร์ระดับองค์กร

— drxzcl

8

มีส่วนขยายแบบเรียลไทม์ถึง UML ที่ บริษัท ได้รับความนิยมในขณะนี้ ฉันจำได้ว่าทำกระดาษกับมันเมื่อหลายปีก่อน Bruce Powell Douglass เขียนหนังสือสองสามเล่มเกี่ยวกับการสร้างแบบจำลองระบบฝังตัวโดยใช้ UML แต่ บริษัท ของเขาไม่ใช่คนที่ฉันคิด

ที่กล่าวว่าเพื่อสะท้อน Wouter ไม่มีอะไรพิเศษเกี่ยวกับซอฟต์แวร์ฝังตัวต่อ ฉันเขียนซอฟต์แวร์ฝังตัวทุกวันสำหรับระบบที่ทำงานบนโปรเซสเซอร์ Pentium ระดับ; UML นั้นใช้ได้จริง นอกจากนี้โปรดจำไว้ว่ามีการเพิ่มซอฟต์แวร์ควบคุมหลายแง่มุมใน UML เมื่อเวลาผ่านไป: มีไวยากรณ์สำหรับการระบุเหตุการณ์แบบซิงโครนัสหรือแบบอะซิงโครนัสพร้อมกับเวลาตอบสนองในลำดับแผนภาพพฤติกรรมประเภทสุทธิ Petri กว่าไดอะแกรมของรัฐสามารถเป็นต้น

OTOH ผู้คนจำนวนมากชอบที่จะสร้างโมเดลซอฟต์แวร์ฝังตัวโดยใช้ Structured Design และแนวคิดของ Dataflow มันเกี่ยวกับประเภทของระบบที่คุณกำลังออกแบบและสิ่งที่ดีที่สุด

— ลินดอน
แหล่งที่มา

ขอบคุณ @lyndon แต่คุณจะสร้างแบบจำลองซอฟต์แวร์ฝังตัวทุกวันได้อย่างไร คุณคิดว่าแผนภาพกิจกรรมเครื่องสถานะและแผนภาพลำดับจะทำเคล็ดลับหรือไม่ ฉันกำลังมองหาแนวคิดของสิ่งที่จะออกแบบจริง ๆ แล้วอะไรคือแผนงานที่จะแทรกลงในเอกสารการออกแบบถ้ามันมีระบบฝังตัวอยู่

— Cassio

โครงสร้างที่ฉันพบบ่อยที่สุดคือไดอะแกรมสถานะ / สเตจแผนภูมิและแผนภาพลำดับสำหรับการใช้งานแบบวันต่อวัน ฉันคิดว่าจริงๆแล้วเราสามารถใช้ประโยชน์จากไดอะแกรมของชั้นเรียนได้มากขึ้น แต่ฉันพบว่าผู้คนมีแนวโน้มที่จะสร้าง "เทพเจ้าวัตถุ" ขนาดใหญ่ โอ้: บริษัท ที่ฉันคิดว่าเป็น Artisan Software ลิงค์นี้อาจมีข้อมูล: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

— lyndon

5

เมื่อหันไปใช้ RTOS เรามักจะจัดการกับแอปพลิเคชันที่มีงานหลายอย่างพร้อมกันที่จำเป็นต้องมีการจัดตารางเวลาให้เหมาะสมเพื่อให้พวกเขาแต่ละคนตรงตามกำหนดเวลาตรงเวลาหรือแบ่งปันทรัพยากรอย่างปลอดภัย กรอบงาน RTOS ที่คุณเลือกใช้ตัวกำหนดตารางเวลางานและงานของคุณ (โดยทั่วไป) คือการเขียนแต่ละงานเหล่านี้ด้วยชุดของคุณสมบัติ (รอบระยะเวลาลำดับความสำคัญ ฯลฯ ) แล้วส่งไปยังตัวกำหนดตารางเวลา ดังนั้นสำหรับเอกสารแนวทางที่ฉันจะทำก็คือจัดทำเอกสารแต่ละงานอย่างรอบคอบ

ซอฟต์แวร์ฝังตัวส่วนใหญ่และเท่าที่ฉันรู้ RTOS ส่วนใหญ่ไม่ได้เขียนด้วยภาษาเชิงวัตถุและอาจไม่ได้รับประโยชน์จากสิ่งต่าง ๆ มากมายที่มุ่งเน้นไปที่เช่นแผนภาพระดับ

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

ใช้คำแนะนำใด ๆ นี้ แต่คุณชอบฉันไม่ได้ยุ่งกับ RTOS สิ่งตั้งแต่วันที่วิทยาลัยของฉันและไม่เคย "บันทึก" งาน

— จอนแอล
แหล่งที่มา

ขอบคุณ @JonL ดังนั้นเพื่อให้มีเอกสารการออกแบบที่ดีฉันแค่ต้องการออกแบบงานที่เกี่ยวข้องในใบสมัครของฉัน นอกจากนี้ฉันไม่คุ้นเคยกับอัลกอริทึมการตั้งเวลาฉันไม่ต้องจัดการกับมัน ฉันใช้ RTEMS

— Cassio

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

— Jon L

ใช่ฉันยังคงคุ้นเคยกับคุณสมบัติ RTOS และขอบคุณสำหรับแนวทางที่แนะนำ! จะทำมัน! และอย่างที่ฉันบอกไปก่อนหน้านี้ฉันยังใหม่กับซอฟต์แวร์ฝังตัวฉันไม่แน่ใจว่าจำเป็นจริงๆ มันจะดีถ้ามีสถาปัตยกรรมซอฟต์แวร์แบบฝังตัวหรือเอกสารการออกแบบ คุณจะมีหนึ่งในนั้นหรือไม่

— Cassio

"RTOS ส่วนใหญ่ไม่ได้เขียนด้วยภาษาเชิงวัตถุ" แน่นอน แต่สำหรับหลักสูตรในการสร้างแบบจำลองเรียลไทม์และการใช้งานเราใช้ RTOS แบบง่าย ๆ

— Wouter van Ooijen

5

การสร้างแบบจำลองเป็นเรื่องเกี่ยวกับ

การรู้ว่าสิ่งใดยากและซับซ้อนในแอปพลิเคชันของคุณ
การหาเครื่องมือสร้างแบบจำลอง / ภาษา / นามธรรม / การประชุม / สัญกรณ์ที่เหมาะสมสำหรับด้านนั้น
ออกแบบว่าด้านนั้น

ดังนั้นจึงไม่มีเครื่องมือสร้างแบบจำลอง / วิธี / ฯลฯ ที่เหมาะสมสำหรับทุกสถานการณ์ ดาวเทียมน่าจะเป็นระบบมัลติทาสกิ้งตามเวลาจริงซึ่งอาจมีโปรเซสเซอร์มากกว่าหนึ่งตัว ไดอะแกรมโครงสร้างงาน, STDs และไดอะแกรมลำดับอาจเป็นประโยชน์ (เพียงเพื่อตั้งชื่อไม่กี่) ถ้าโครงการทำในคลาส C ไดอะแกรมจะเป็น likley น้อยกว่าที่จะเป็นประโยชน์ (ถ้าปรากฎว่าเป็นประโยชน์อย่างมากตัวเลือกสำหรับ C อาจผิด) ฉันไม่ชอบ UseCases มากและดาวเทียม an-sich ไม่มีผู้ใช้ กรณีการใช้มีความเหมาะสมที่สุดในสถานการณ์ที่คุณต้องการหารือเกี่ยวกับข้อกำหนดสำหรับระบบของคุณกับผู้ใช้ที่ไม่ใช่ด้านเทคนิค หากนั่นคือสถานการณ์ที่คุณกำลังอยู่ในโครงการดาวเทียมมีบางอย่างผิดพลาด

— Wouter van Ooijen
แหล่งที่มา

ขอบคุณ @Wouter คุณได้แนะนำแนวคิดใหม่สำหรับฉัน: โครงสร้างงานดีมาก! ดังนั้นมันอยู่ใน C คุณจะได้อะไรสำหรับเอกสารที่มีข้อกำหนดทั้งหมดถ้าไม่ใช่ UseCases

— Cassio

IMO คุณต้องการรายการข้อกำหนดการออกใช้เดี่ยวที่ระบุได้มากขึ้นหรือน้อยลงหากใช้เพื่อทดสอบกรณีของคุณเท่านั้น สำหรับฉัน UseCases เป็นเพียงวิธีการในการเข้าถึงรายการดังกล่าว วิธีการที่ดีในบางกรณี

— Wouter van Ooijen

1

ฉันไม่ได้ออกแบบสิ่งใดที่มีคุณสมบัติเหมาะสมกับพื้นที่ แต่ฉันได้ทำงานให้กับผู้รับเหมาช่วงการบินและอวกาศกระทรวงกลาโหม (DoD) และงานออกแบบของฉันจำนวนมากมีคุณสมบัติในการบิน พวกเขาต้องการเอกสารจำนวนมากเกี่ยวกับการออกแบบของคุณและให้คำอธิบายรายการข้อมูล (DIDs) ซึ่งมีรายละเอียดที่ชัดเจนว่าพวกเขาต้องการดูอะไร

คุณสามารถใช้การค้นหาด่วนของ DoD Assistเพื่อดู DID ทั้งหมดสำหรับเอกสารที่อาจจำเป็นหากคุณพิมพ์ "ซอฟต์แวร์" ลงในฟิลด์ "คำในชื่อเรื่อง" และคลิกส่ง (ฉันคิดว่ามันตลกที่ไซต์กระทรวงแจ้งเตือนเรื่องความปลอดภัยของใบรับรอง แต่ฉันรับรองว่าปลอดภัยแล้ว)

เมื่อคุณถามเฉพาะเกี่ยวกับเอกสารการออกแบบนี่คือคำอธิบายการออกแบบซอฟต์แวร์ (SDD) DID พวกเขาเน้นการใช้คำเพื่ออธิบายแต่ละส่วนของการออกแบบ แต่ถ้าใช้ UML, แผนภาพสถานะ, ผังงาน, รหัสหลอก, ฯลฯ สามารถเพิ่มความเข้าใจในการออกแบบได้แน่นอนพวกเขาต้องการให้คุณรวมมันไว้ด้วย

วิธีการสร้างแบบจำลองใดที่คุณเลือกตามที่คนอื่น ๆ ระบุไว้ขึ้นอยู่กับการออกแบบ แต่ฉันคิดว่าการเห็น DID สำหรับซอฟต์แวร์การบินและอวกาศอาจช่วยให้คุณเขียนเอกสารการออกแบบของคุณเนื่องจากโครงการของคุณเกี่ยวข้องกับพื้นที่

— embedded.kyle
แหล่งที่มา