#47 Assertions and Design by Contract, Part-1
HTML-код
- Опубликовано: 2 мар 2023
- In this lesson, you'll learn about software assertions and, more formally, the Design by Contract methodology in the context of embedded programming. This is part-1 of the two-part series on this subject.
Contents with Timestamps:
-------------------------
1:25 What are software assertions?
1:46 Standard assertions in C
3:07 Demonstration of standard assertions on a desktop
4:37 Disabling standard assertions
5:49 Software Errors
6:38 Exceptional Conditions
7:17 Attempts to "handle" Errors as Exceptional Conditions
7:24 "Defensive Programming"
8:36 Fallacities of "Defensive Programming"
9:20 Design by Contract method
10:00 What assertions are NOT
11:02 The true purpose of assertions
11:24 Priorities for dealing with errors
11:49 Assertion handler as the last line of defense
12:00 Assertions as fuses
End Notes:
----------
Companion web page to this video course
www.state-machine.com/video-c...
Project download for this lesson:
www.state-machine.com/course/...
GitHub repository for projects for this video course:
github.com/QuantumLeaps/moder...
Transcript of this lesson:
www.state-machine.com/course/...
References resources:
---------------------
Key Concepts: Design by Contract
www.state-machine.com/dbc
Bertrand Meyer, “Applying Design by Contract”, IEEE Computer, 1992
www.state-machine.com/doc/May...
Miro Samek, “An Exception or a Bug?”, C/C++ Users Journal, June 2003
www.state-machine.com/doc/Sam...
Quantum Leaps, Design By Contract (DBC) for Embedded C and C++, GitHub
github.com/QuantumLeaps/DBC-f...
Music credits:
--------------
The background music comes from:
www.bensound.com/royalty-free... 
Наука
Hey Miro! I'm starting my first firmware engineering job in 3 days and I wanted to thank you for all your help in making it possible! Keep up the good work!
Congratulations on your new job, and best of luck! I'm glad to hear that this course was helpful :-) --MMS
Can't wait for the next episode!
The next episode ("Assertions and DBC, Part-2") will be coming up much sooner than my usual 3-month release cycle. Stay tuned! --MMS
In AUTOSAR we call this DET 😊
Hi Moro, is the assertion a right methodology in a code that is going to be compiled as a binary library and its functions are going to be called by a client code?
Yes, assertions (especially the precondition assertions) are *especially* valuable in library code! This is because every non-trivial library can be used incorrectly, and assertions formally specify and automatically enforce the "contracts" between the library and the client code. In my experience with the QP/C and QP/C++ frameworks, the assertions are there primarily to catch problems in the *client code*. I will talk about the impact of assertions in Part-2 on the subject. Stay tuned! --MMS
thanks for the video it was very help full, this looks very simular to the unit testing, w hat the different between the two (expect that unit testing run off target)
The purpose of assertions is to provide self-checks in the code. The purpose of software tracing is simply to report what is going on, without checking for correctness. But I can see how these two concepts can be conflated and confused because standard assertions print a message, so in a sense, they produce a "trace". In the next lesson, you will see embedded assertions that don't necessarily print anything, yet they are still valuable to perform "damage control" and eventually reset the system. I hope this will help you see the difference. Stay tuned! --MMS
Hello! I am a big fan of your content, very goog job explaining the concepts. Unfortunately, the version of the software you are using: IAR Embedded Workbench is not available to download.. which toolset can I install to follow your tutorials? I already have the board... thank you in advance!
I'm glad to hear that you like the content. Regarding the IAR EWAR, I was still able to download and install it (EWARM 9.32). It is also still possible to register the free size-limited (but time-unlimited) license. But IAR has been used only up to lesson #18. After that, lessons #19-20 used the Ecliplse-based Code Composer Studio (with GNU-ARM). And finally, starting from lesson #21 (released over 5 years ago), this course has been using the ARM-KEIL MDK (uVision IDE). --MMS
Hi Miro, thanks for your knowledge that you shared with us.
And, do you have a plan to share about autosar, automotive ?
I don't work in automotive, so I can't lecture about AUTOSAR. But I am planning to talk about a specific type of real-time kernel that is virtually unknown outside the automotive sector (OSEK/VDX kernel, CC2 compliance class). Such a preemptive kernel is ideal for executing state machines (active objects). --MMS
@@StateMachineCOM can you recommend us sources for learn AUTOSAR. Tbh, I find it difficult to learn.
@@albertoramirezdiaz8323 As I said, luckily I don't work in automotive. But AUTOSAR seems overblown, like many other heavyweight methodologies. One cynical opinion about AUTOSAR that I remember is still available on Reddit: www.reddit.com/r/embedded/comments/leq366/comment/gmiq6d0
First one.
Lots of words, just to present assert()
If you think that this video lesson is just about the assert() macro, you probably missed the point. Assertions are simple to implement, but it is a mistake to think that the *use* of assertions is simple. If this was the case, you'd see many more assertions in the embedded codebase. Instead, you still see a lot of "defensive programming", which is an anti-pattern. This lesson attempts to educate the viewers about assertions by showing the correct mental models of assertions (e.g., Design by Contract, assertions as fuses, etc.) and the proper ways of applying assertions (to avert errors and NOT to handle exceptional conditions). The next lesson will be more specific to embedded programming. Stay tuned! --MMS
@@StateMachineCOM you could have mentionned BUG() in the linux kernel. I'm well aware of what you're saying, the theory that you describe is mere "intellectual masturbation" to me, if you may.