Merancang Perangkat Lunak Tertanam

11

Saya mulai dalam pemrograman perangkat lunak tertanam menggunakan RTOS dan, karena saya sudah menjadi pengembang untuk aplikasi desktop, saya terus bertanya-tanya bagaimana rasanya memodelkan perangkat lunak tertanam menggunakan diagram UML, seperti Activity Diagram, Sequence Diagram, Use Cases, dll.

Apakah perangkat lunak tertanam dirancang menggunakan UML, seperti halnya aplikasi desktop? Apakah ini pilihan terbaik atau ada yang lebih baik? Bisakah saya memiliki beberapa contoh?

Apakah ada alat khusus yang melakukan ini?

embedded software

— Cassio
sumber

8

Sama sekali tidak ada yang spesifik tentang aplikasi yang disematkan. Apa yang istimewa adalah aplikasi terbatas sumber daya, pembatasan yang paling umum adalah pembatasan waktu, misalnya persyaratan waktu nyata. Jika Anda memberi tahu kami lebih lanjut tentang persyaratan untuk aplikasi Anda, kami mungkin akan memberi Anda jawaban spesifik.

— Wouter van Ooijen

3

Saya sepenuhnya setuju dengan komentar @ Wouter tentang aplikasi yang dibatasi sumber daya, tetapi saya percaya bahwa ada nuansa desain khusus yang terkait dengan penggunaan RTOS vs. lingkungan pengembangan desktop terjadwal lunak di mana memblokir panggilan adalah praktik yang diterima.

— HikeOnPast

1

Waspadalah terhadap overengineering sistem embedded. Lihat juga "The King's Toaster" ee.ryerson.ca/~elf/hack/ktoast.html

— drxzcl

2

@drxzcl - Tidak setuju. Pertama, saya pikir Anda tidak bisa terlalu berhati-hati ketika merancang perangkat lunak yang memenuhi syarat . Kedua, pendekatan Insinyur terhadap Pemanggang Roti Raja adalah alasan mengapa begitu banyak roti terbakar. Sebagian besar pemanggang roti terlalu sederhana untuk apa yang sebenarnya merupakan pekerjaan non-sepele.

— Rocketmagnet

1

@Cassio: Saya bersama Wouter untuk yang satu ini. Anda harus menganalisis sendiri masalahnya, dan kemudian memetakan bagian-bagian penting menggunakan sistem apa pun yang Anda anggap tepat. Masalah dengan memilih representasi sebelum menganalisis masalah adalah Anda terjebak melihat masalah dengan cara tertentu. UML adalah representasi yang berakar pada perangkat lunak perusahaan, dan Anda tidak ingin terpikat untuk merancang perangkat lunak tertanam seperti perangkat lunak perusahaan.

— drxzcl

8

Ada ekstensi Waktu Nyata ke UML yang dipopulerkan oleh perusahaan yang namanya luput dari saya saat ini. Saya ingat pernah menulis makalah tentang itu beberapa tahun yang lalu. Bruce Powell Douglass menulis beberapa buku tentang masalah pemodelan sistem embedded menggunakan UML, tetapi perusahaannya bukan yang saya pikirkan.

Yang mengatakan, untuk menggemakan Wouter, tidak ada yang istimewa tentang perangkat lunak tertanam per se. Saya menulis perangkat lunak tertanam setiap hari untuk sebuah sistem yang berjalan pada prosesor kelas Pentium; UML cukup berlaku. Juga, ingatlah bahwa banyak aspek perangkat lunak kontrol telah ditambahkan ke UML dari waktu ke waktu: ada sintaks untuk menentukan peristiwa sinkron atau asinkron bersamaan dengan waktu respons dalam Diagram Urutan, perilaku tipe Petri net dapat ditemukan dalam Activity Diagram, perilaku model Statecharts bahkan lebih baik daripada Diagram Negara, dll.

OTOH, banyak orang lebih suka memodelkan perangkat lunak tertanam menggunakan konsep Desain Terstruktur dan Dataflow. Ini semua tentang jenis sistem yang Anda rancang dan apa yang paling berhasil.

— lyndon
sumber

Terima kasih @lyndon. Tetapi bagaimana Anda memodelkan perangkat lunak tertanam setiap hari? Apakah Anda berpikir bahwa Diagram Kegiatan, Mesin Negara, dan Diagram Urutan, akan berhasil? Saya sebenarnya mencari konsep apa yang harus dirancang, lalu apa skema yang harus dilakukan untuk dimasukkan ke Dokumen Desain, jika ada satu untuk sistem embedded.

— Cassio

Konstruksi yang paling sering saya lihat adalah State diagram / statecharts dan Sequence diagram untuk penggunaan sehari-hari. Jujur saya pikir kita bisa lebih banyak menggunakan diagram Kelas, tetapi saya menemukan bahwa orang-orang memiliki kecenderungan untuk hanya membuat "objek dewa" yang besar. Oh: perusahaan yang saya pikirkan adalah Artisan Software. Tautan ini mungkin informatif: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

— lyndon

5

Saat beralih ke RTOS, kami biasanya berurusan dengan aplikasi yang memiliki banyak tugas bersamaan yang harus dijadwalkan secara optimal agar masing-masing memenuhi tenggat waktu tepat waktu atau berbagi sumber daya dengan aman. Kerangka kerja RTOS yang Anda pilih mengimplementasikan penjadwal tugas, dan tugas Anda (biasanya) adalah menulis tugas-tugas individual ini dengan serangkaian properti tertentu (periode, prioritas, dll.) Dan kemudian menyerahkannya ke penjadwal. Jadi untuk dokumentasi, pendekatan yang akan saya ambil adalah mendokumentasikan setiap tugas dengan hati-hati.

Sebagian besar perangkat lunak tertanam dan, sejauh yang saya tahu, sebagian besar RTOS tidak ditulis dalam bahasa berorientasi objek dan dengan demikian mungkin tidak mendapat manfaat dari banyak hal yang diarahkan seperti diagram kelas misalnya.

Ketika mendokumentasikan tugas RTOS Anda, diagram apa pun yang menggambarkan tugas dengan baik akan bermanfaat. Saya akan membayangkan diagram urutan untuk setiap tugas bisa sangat membantu misalnya. Bersamaan dengan itu Anda dapat menentukan persyaratan sulitnya seperti periode / frekuensi, prioritas, sumber daya bersama apa pun yang dapat digunakan, persyaratan pra-emption, dll. Juga nilainya dapat mendokumentasikan bagaimana Anda mengkonfigurasi RTOS dan mungkin sebuah negara- mesin algoritma penjadwalannya.

Ikuti saran ini sesuka Anda, saya belum pernah mengacaukan hal-hal RTOS sejak saya masih kuliah, dan tidak pernah benar-benar "mendokumentasikan" pekerjaan itu.

— Jon L
sumber

Terima kasih @JonL. Jadi, untuk memiliki Dokumen Desain yang bagus, saya hanya perlu merancang tugas-tugas yang terlibat dalam aplikasi saya? Juga, saya tidak terlalu terbiasa dengan algoritma penjadwalan, saya tidak pernah harus menghadapinya. Saya menggunakan RTEMS.

— Cassio

@Cassio, saya tidak mengatakan kepada Anda untuk melakukan satu atau lain hal, itu benar-benar terserah Anda. Coba lakukan apa yang perlu. Jika Anda tidak terbiasa dengan RTOS Anda, saya pikir baru saja memulainya terlebih dahulu dan bagaimana Anda seharusnya menggunakannya akan menjadi tempat yang baik untuk memulai. Kemudian Anda dapat mulai merancang tugas-tugas Anda di sekitarnya.

— Jon L

Ya, saya masih terbiasa dengan fitur RTOS. Dan terima kasih atas pendekatan yang disarankan! Akan melakukannya! Dan seperti yang saya katakan sebelumnya, saya baru mengenal perangkat lunak tertanam, saya tidak begitu yakin apa yang diperlukan. Alangkah baiknya memiliki Arsitektur Perangkat Lunak Tertanam atau Dokumen Desain. Apakah Anda memiliki salah satunya?

— Cassio

"Kebanyakan RTOS tidak ditulis dalam bahasa berorientasi objek" Memang. Tetapi untuk kursus dalam pemodelan dan implementasi real-time kami menggunakan RTOS (non-preemptive) sederhana dalam C ++.

— Wouter van Ooijen

5

Pemodelan adalah semua tentang

mengetahui aspek apa yang sulit dan rumit dalam aplikasi Anda,
menemukan alat pemodelan / bahasa / abstraksi / konvensi / notasi yang sesuai untuk aspek tersebut
merancang aspek itu

Karenanya tidak ada alat pemodelan / pendekatan / dll yang sesuai untuk semua situasi. Satelit mungkin akan menjadi sistem multi-tasking waktu-nyata, mungkin dengan lebih dari satu prosesor. Diagram struktur tugas, STD, dan diagram urutan mungkin berguna (hanya untuk beberapa nama). Jika proyek dilakukan dalam C diagram kelas kurang likley menjadi berguna (jika ternyata sangat berguna, pilihan untuk C mungkin salah). Saya tidak terlalu menyukai UseCases, dan satelit an-sich tidak memiliki pengguna. Kasus penggunaan paling tepat dalam situasi di mana Anda ingin mendiskusikan persyaratan untuk sistem Anda dengan pengguna non-teknis. Jika itu adalah situasi dimana Anda berada dalam proyek satelit, ada yang tidak beres.

— Wouter van Ooijen
sumber

Terima kasih @Wouter. Anda telah memperkenalkan konsep baru untuk saya: Diagram Struktur Tugas, bagus! Jadi, itu dalam C. Apa yang akan Anda miliki untuk dokumen dengan semua persyaratan, jika tidak UseCases?

— Cassio

IMO Anda memerlukan daftar persyaratan yang dapat diidentifikasikan, kurang lebih sekali pakai, jika hanya dijadikan dasar pada kasus uji Anda. Bagi saya UseCases hanyalah metode untuk sampai ke daftar seperti itu. Metode yang baik, dalam beberapa kasus.

— Wouter van Ooijen

1

Saya belum merancang apa pun yang memenuhi syarat ruang. Tetapi saya telah bekerja untuk subkontraktor aerospace Departemen Pertahanan (DoD) dan banyak desain saya yang berkualitas penerbangan. Mereka membutuhkan banyak dokumentasi tentang desain Anda dan memberikan Deskripsi Item Data (DID) yang merinci apa yang ingin mereka lihat.

Anda dapat menggunakan Pencarian Cepat DoD ASSIST untuk melihat semua DID untuk dokumen yang mungkin diperlukan jika Anda mengetik "perangkat lunak" di bidang "Word (s) Dalam Judul" dan klik Kirim. (Saya merasa lucu bahwa situs DoD melempar peringatan keamanan sertifikat, tapi saya yakinkan Anda, itu aman).

Karena Anda bertanya secara spesifik tentang Dokumen Desain, di sini adalah Deskripsi Desain Perangkat Lunak (SDD) DID. Mereka menekankan penggunaan kata-kata untuk menggambarkan setiap bagian dari desain. Tetapi jika penggunaan UML, State Diagram, flowchart, pseudo-code, dll., Dapat meningkatkan pemahaman desain, maka mereka tentu saja ingin Anda memasukkannya.

Metode pemodelan mana yang Anda pilih, seperti yang dinyatakan orang lain, tergantung pada desain Anda. Tetapi saya berpikir bahwa melihat DID untuk perangkat lunak kedirgantaraan mungkin membantu Anda menulis Dokumen Desain Anda karena proyek Anda terkait dengan ruang.

— tertanam.kyle
sumber