Thiết kế phần mềm nhúng

11

Tôi đang bắt đầu lập trình phần mềm nhúng bằng RTOS và vì tôi đã là nhà phát triển cho các ứng dụng máy tính để bàn, tôi cứ tự hỏi làm thế nào để mô hình hóa phần mềm nhúng bằng sơ đồ UML, như Sơ đồ hoạt động, Sơ đồ tuần tự, Các trường hợp sử dụng, v.v.

Phần mềm nhúng có được thiết kế bằng UML không, giống như cách các ứng dụng trên máy tính để bàn? Đó là lựa chọn tốt nhất hay có một lựa chọn tốt hơn? Tôi có thể có một số ví dụ?

Có một công cụ cụ thể làm điều này?

embedded software

— Cassio
nguồn

8

Hoàn toàn không có gì cụ thể về các ứng dụng nhúng. Điều đặc biệt là các ứng dụng bị hạn chế tài nguyên , phổ biến nhất trong số các hạn chế đó là các hạn chế về thời gian, ví dụ như các yêu cầu thời gian thực cứng. Nếu bạn cho chúng tôi biết thêm về các yêu cầu cho ứng dụng của bạn, chúng tôi có thể sẽ cho bạn một câu trả lời cụ thể.

— Wouter van Ooijen

3

Tôi hoàn toàn đồng ý với ý kiến của @ Wouter về các ứng dụng bị hạn chế tài nguyên, nhưng tôi tin rằng có những sắc thái thiết kế cụ thể liên quan đến việc sử dụng RTOS so với môi trường phát triển máy tính để bàn được lên lịch mềm trong đó chặn cuộc gọi là một thông lệ được chấp nhận.

— HikeOnPast

1

Cẩn thận với các hệ thống nhúng áp đảo. Xem thêm "Máy nướng bánh mì của nhà vua" ee.ryerson.ca/~elf/hack/ktoast.html

— drxzcl

2

@drxzcl - Không đồng ý. Thứ nhất, tôi không nghĩ bạn có thể chăm sóc quá nhiều khi thiết kế phần mềm đủ điều kiện không gian . Thứ hai, cách tiếp cận của Kỹ sư với Máy nướng bánh mì King là lý do rất nhiều bánh mì bị đốt cháy. Hầu hết các lò nướng bánh quá đơn giản cho những gì thực sự là một công việc không tầm thường.

— Rocketmagnet

1

@Cassio: Tôi với Wouter về điều này. Bạn phải tự mình phân tích vấn đề, và sau đó vạch ra những phần quan trọng bằng cách sử dụng bất kỳ hệ thống nào bạn cho là phù hợp. Vấn đề với việc chọn một đại diện trước khi phân tích vấn đề là bạn gặp khó khăn khi nhìn vấn đề theo một cách nhất định. UML là một đại diện có nguồn gốc từ phần mềm doanh nghiệp và bạn không muốn bị lôi cuốn vào việc thiết kế phần mềm nhúng như phần mềm doanh nghiệp.

— drxzcl

8

Có các phần mở rộng thời gian thực cho UML đã được phổ biến bởi một công ty có tên thoát khỏi tôi vào lúc này. Tôi nhớ làm một bài báo về nó vài năm trước. Bruce Powell Doulass đã viết một vài cuốn sách về chủ đề mô hình hóa các hệ thống nhúng bằng UML, nhưng công ty của ông không phải là cuốn sách tôi nghĩ đến.

Điều đó nói rằng, để lặp lại Wouter, không có gì đặc biệt về phần mềm nhúng mỗi se. Tôi viết phần mềm nhúng mỗi ngày cho một hệ thống chạy trên bộ xử lý lớp Pentium; UML là khá áp dụng. Ngoài ra, hãy nhớ rằng nhiều khía cạnh của phần mềm điều khiển đã được thêm vào UML theo thời gian: có cú pháp chỉ định các sự kiện đồng bộ hoặc không đồng bộ cùng với thời gian phản hồi trong Biểu đồ tuần tự, hành vi loại Petri có thể được tìm thấy trong Biểu đồ hoạt động, hành vi mô hình Statecharts thậm chí còn tốt hơn hơn sơ đồ nhà nước có thể, vv

OTOH, rất nhiều người thích mô hình hóa phần mềm nhúng bằng cách sử dụng khái niệm Structured Design và Dataflow. Đó là tất cả về loại hệ thống bạn đang thiết kế và những gì hoạt động tốt nhất.

— lyndon
nguồn

Cảm ơn @lyndon. Nhưng làm thế nào để bạn mô hình hóa phần mềm nhúng hàng ngày? Bạn có nghĩ rằng Sơ đồ hoạt động, Máy trạng thái và Sơ đồ trình tự sẽ thực hiện thủ thuật không? Tôi thực sự đang tìm kiếm khái niệm về những gì cần thiết kế, sau đó các sơ đồ sẽ được thực hiện để chèn vào Tài liệu thiết kế, nếu có một cho các hệ thống nhúng.

— Cassio

Các cấu trúc thường xuyên nhất mà tôi thấy là sơ đồ trạng thái / statecharts và sơ đồ tuần tự để sử dụng hàng ngày. Tôi thành thật nghĩ rằng chúng ta có thể sử dụng nhiều hơn từ sơ đồ Class, nhưng tôi thấy rằng mọi người có xu hướng chỉ tạo ra những "vật thể thần" đồ sộ. Oh: công ty tôi đã nghĩ đến là Artisan Software. Liên kết này có thể là thông tin: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

— lyndon

5

Khi chuyển sang RTOS, chúng tôi thường xử lý một ứng dụng có nhiều nhiệm vụ đồng thời cần được lên lịch tối ưu để mỗi người trong số họ đáp ứng thời hạn đúng hạn hoặc chia sẻ tài nguyên một cách an toàn. Khung RTOS mà bạn chọn thực hiện một trình lập lịch tác vụ và công việc của bạn (thông thường) là viết các tác vụ riêng lẻ này với một tập các thuộc tính nhất định (thời gian, mức độ ưu tiên, v.v.) và sau đó chuyển giao cho trình lập lịch biểu. Vì vậy, đối với tài liệu, cách tiếp cận tôi sẽ làm là ghi chép lại từng nhiệm vụ một cách cẩn thận.

Hầu hết các phần mềm nhúng và, theo như tôi biết, hầu hết các RTOS không được viết bằng ngôn ngữ hướng đối tượng và do đó có thể không được hưởng lợi từ rất nhiều thứ hướng đến như sơ đồ lớp chẳng hạn.

Tuy nhiên, khi ghi lại các nhiệm vụ RTOS của bạn, bất kỳ sơ đồ nào mô tả tốt nhiệm vụ sẽ là một lợi ích lớn. Tôi sẽ tưởng tượng một sơ đồ trình tự cho mỗi nhiệm vụ có thể rất hữu ích chẳng hạn. Cùng với đó, bạn có thể chỉ định các yêu cầu cứng của nó như thời gian / tần suất, mức độ ưu tiên, mọi tài nguyên được chia sẻ mà nó có thể sử dụng, yêu cầu trước khi thực hiện, v.v. Ngoài ra, giá trị có thể là ghi lại cách bạn đã định cấu hình RTOS và có lẽ là trạng thái máy thuật toán lập lịch của nó.

Thực hiện bất kỳ lời khuyên nào theo cách bạn muốn, tôi đã không gặp rắc rối với công cụ RTOS kể từ thời đại học và chưa bao giờ thực sự "ghi chép" lại công việc.

— Jon L
nguồn

Cảm ơn @JonL. Vì vậy, để có một Tài liệu thiết kế đẹp, tôi chỉ cần thiết kế các nhiệm vụ liên quan đến ứng dụng của mình? Ngoài ra, tôi không rành lắm về thuật toán lập lịch, tôi không bao giờ phải đối phó với nó. Tôi đang sử dụng RTEMS.

— Cassio

@Cassio, tôi không bảo bạn làm cái này hay cái khác, điều đó thực sự tùy thuộc vào bạn. Chỉ cần cố gắng làm những gì cần thiết. Nếu bạn không quen thuộc với RTOS của mình, tôi nghĩ chỉ cần bắt đầu với nó trước và cách bạn nên sử dụng nó sẽ là một nơi tốt để bắt đầu. Sau đó, bạn có thể bắt đầu thiết kế các nhiệm vụ của bạn xung quanh nó.

— Jon L

Có, tôi vẫn đang làm quen với các tính năng RTOS. Và cảm ơn cho cách tiếp cận được đề xuất! Sẽ làm điều đó! Và như tôi đã nói trước đây, tôi chưa quen với phần mềm nhúng, tôi không thực sự chắc chắn những gì cần thiết. Sẽ thật tuyệt nếu có Tài liệu thiết kế hoặc Kiến trúc phần mềm nhúng. Bạn sẽ có một trong những?

— Cassio

"Hầu hết các RTOS không được viết bằng ngôn ngữ hướng đối tượng" Thật vậy. Nhưng đối với một khóa học về mô hình hóa và triển khai thời gian thực, chúng tôi sử dụng một RTOS đơn giản (không ưu tiên) trong C ++.

— Wouter van Ooijen

5

Mô hình là tất cả về

biết khía cạnh nào là khó khăn và phức tạp trong ứng dụng của bạn,
tìm một công cụ mô hình / ngôn ngữ / trừu tượng / quy ước / ký hiệu phù hợp với khía cạnh đó
thiết kế khía cạnh đó

Do đó không có công cụ mô hình / phương pháp tiếp cận / vv nào phù hợp cho mọi tình huống. Một vệ tinh có thể sẽ là một hệ thống đa tác vụ thời gian thực, có thể có nhiều hơn một bộ xử lý. Sơ đồ cấu trúc nhiệm vụ, STD và sơ đồ trình tự có thể hữu ích (chỉ để đặt tên một vài). Nếu dự án được thực hiện trong C, một sơ đồ lớp sẽ ít hữu ích hơn (nếu nó trở nên rất hữu ích, sự lựa chọn cho C có lẽ đã sai). Tôi không thích UseCase và một vệ tinh không có người dùng. Các trường hợp sử dụng là thích hợp nhất trong trường hợp bạn muốn thảo luận các yêu cầu cho hệ thống của mình với người dùng không có kỹ thuật. Nếu đó là tình huống bạn đang ở trong một dự án vệ tinh thì có gì đó không ổn.

— Đồ trang sức van Ooijen
nguồn

Cảm ơn @Wouter. Bạn đã giới thiệu một khái niệm mới cho tôi: Sơ đồ cấu trúc nhiệm vụ, thật tuyệt! Vì vậy, nó là trong C. Bạn sẽ có gì cho một tài liệu với tất cả các yêu cầu, nếu không phải là UseCase?

— Cassio

IMO bạn cần một danh sách các yêu cầu có thể nhận dạng, nhiều hoặc ít hơn, nếu chỉ để dựa trên các trường hợp thử nghiệm của bạn. Đối với tôi UseCase chỉ là một phương pháp để đi đến một danh sách như vậy. Một phương pháp tốt, trong một số trường hợp.

— Wouter van Ooijen

1

Tôi chưa thiết kế bất cứ thứ gì đủ không gian. Nhưng tôi đã làm việc cho một nhà thầu phụ hàng không vũ trụ của Bộ Quốc phòng (DoD) và rất nhiều thiết kế của tôi đã đủ điều kiện bay. Họ yêu cầu rất nhiều tài liệu về thiết kế của bạn và cung cấp Mô tả Mục dữ liệu (DID) chi tiết chính xác những gì họ muốn xem.

Bạn có thể sử dụng Tìm kiếm nhanh DoD ASSIST để xem tất cả các DID cho các tài liệu có thể được yêu cầu nếu bạn nhập "phần mềm" vào trường "Word (s) In Title" và nhấp vào Gửi. (Tôi thấy buồn cười khi một trang web DoD đưa ra cảnh báo bảo mật chứng chỉ, nhưng tôi đảm bảo với bạn rằng nó an toàn).

Vì bạn hỏi cụ thể về Tài liệu thiết kế, đây là DID Mô tả thiết kế phần mềm (SDD). Họ nhấn mạnh việc sử dụng các từ để mô tả từng phần của thiết kế. Nhưng nếu việc sử dụng UML, Sơ đồ trạng thái, sơ đồ khối, mã giả, v.v., có thể nâng cao sự hiểu biết về thiết kế, thì tất nhiên họ muốn bạn đưa nó vào.

Phương pháp mô hình nào bạn chọn, như những người khác đã nêu, phụ thuộc vào bạn thiết kế. Nhưng tôi nghĩ rằng việc nhìn thấy DID cho phần mềm hàng không vũ trụ có thể giúp bạn viết Tài liệu thiết kế vì dự án của bạn có liên quan đến không gian.

— nhúng.kyle
nguồn