UML for C programming language [closed]

Answer 1

The problem with C is that it is more of a procedural programming language. Its harder to get the fine grained design with a C application. If you are working with C you may want to stick with sequence diagrams, and component diagrams, as that they describe and overview of what is going on rather than a graph of dependencies and interaction.

Answer 2

An object oriented design is independent of the language and you can of course design your system using UML. Some tools like Rhapsody will also allow code generation and round-tripping, we use for some special projects where C++ is not an option. If you want to write your code by hand use some naming convention like Subsystem_Module_Class_Method to name your functions in an object oriented way and use a .c file per class. Using C is not an obstacle against having a clean design.

Answer 3

I don't know of any existing resources that discuss using UML specifically for C. As others have mentioned, UML is language-agnostic.

Keep in mind that with UML, you can have a model for the problem domain, and another for the implementation. Try not to model the problem domain in terms of C, but rather as high-level OO. Once you understand the problem domain adequately enough, you can begin modeling an implementation.

For modeling procedural-style C implementations, the following diagrams could be useful:

• Class diagram:
  • Show C module APIs
  • Show C module relationships (mostly dependencies for non-OO)
  • Show structures and enumerations (using < < stereotype> >)
• Package diagram: Show contents (modules) of libraries, and the dependency relationships between libraries
• Activity diagram: Flowcharting non-trivial algorithms
• Sequence/collaboration diagram: Show how events/messages between modules/entities/inputs/outputs occur in time
• Statechart diagram: For state machines, of course!

Expanding on class diagrams, you can "abuse" them in the following way for procedural-style C:

• Global extern functions -> public methods
• Local static functions -> private methods
• Global extern variables -> public members
• Local static variables -> private members
• Structs -> class with "struct" stereotype
• #define constants -> class with "enumeration" stereotype

Experiment, and you'll find your own conventions for abusing UML.