Idealmente, el diseño del programa debe estar vinculado con la especificación de requisitos, de modo que para cada requisito haya un módulo de código, y para ese módulo de código haya una prueba que demuestre cómo cumple con el requisito. Es una especie de utopía que rara vez se logra mantener en la práctica, pero este tipo de diseño es una buena ambición de todos modos.

Entonces, en general, no es tan importante cómo documenta el diseño del programa, siempre que el diseño general quede documentado; esto es sorprendentemente raro incluso en entornos profesionales. Pero todos los detalles pedantes de UML son realmente opcionales, utilícelos donde encuentre un caso para ellos, no los use solo porque sí. Con frecuencia uso diagramas de clases UML para documentar las dependencias del código, así como gráficos de estado que son útiles para documentar el comportamiento de la aplicación. Y así sucesivamente: manténgalo amplio sin detalles de implementación.

El equivalente en C de una clase suele ser un par .h/.c con el mismo nombre, que juntos forman un "módulo" o "ADT" o como quiera llamarlo.

Debe documentar todas las dependencias de clase B de usos de clase A , así como todas las dependencias de clase B es una clase A (herencia). La herencia no es muy común en los sistemas integrados, pero la implementación de una HAL es un ejemplo típico en el que se usa. Tiene una API abstracta además de controladores específicos de hardware.

Obviamente, debe decidir desde el principio si tales abstracciones están justificadas: ¿el programa finalmente se transferirá a otra MCU o cuenta con la garantía de "duración" del proveedor de silicio de que la MCU no llegará al final de la vida útil dentro del tiempo de vida esperado del producto? Mirando el mercado de silicio completamente roto a partir de hoy, asumiría que cualquier proyecto de microcontrolador necesita ser portado muchas veces durante su vida útil.

Para modelar una descripción general de la estructura estática de una aplicación grande escrita en C, recomendaría un diagrama de paquete. Los paquetes en el diagrama representarían los subsistemas, probablemente correspondientes a la estructura de directorios de alto nivel de la aplicación. Las flechas de dependencia entre estos paquetes indicarían qué subsistema hace uso de qué otro(s) subsistema(s).

Para cada paquete de nivel superior, puede crear un diagrama de paquete separado que muestre los subsistemas/subdirectorios y sus dependencias.