views:

794

answers:

3

UML is most commonly used for modelling system by using C++. In my projects C is the implementation language. I am looking for resources on UML strategies which are applicable for C. I want to use UML during design and represent the different aspects of the system.

+4  A: 

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.

monksy
C is not a "functional" programming language. I believe the term that was sought is "procedural".
coobird
You're right about that, I was thinking ... functions but not classes = functional... but by the strictest definition it is functional ... it works :P
monksy
I agree that UML isn't well suited for C, given that UML was derived from Object Oriented school of thought. But you *can* hack together a minimal relationship-based, watered down Object-like construct in C using structs containing function pointers... though inheritance and polymorphism are not as simple. Either way, UML is not so useful in C
Sam Post
c is a multi-paradigm language, and fp is easily attained in c by simply structuring your functions to be side-effect free.
John Weldon
@sam: Thats why I suggested the diagrams that are more big picture approach rather than class diagrams and the like.
monksy
If you think of C modules as singleton classes, you can definitely use class diagrams. When these C modules use the notion of "handle" in their APIs to allow functions to work on difference instances of "objects", then you get full-fledged classes.
Emile Cormier
+3  A: 

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.

jdehaan
Its not an obstacle for clean design... but you aren't going to have the level of abstraction, and component design as you would with an OOP language. That is the reason why OOPs was created.
monksy
OOP can also be done in C: GTK is a good example for it. It makes a heavy use of macros, ok, but syntactically it is quite clean. I agree that other languages integrate it better into their syntax and the code looks maybe a bit cleaner but with C you can reach the same goals. Abstraction is in the design, the code just reflects it more or less well.
jdehaan
+3  A: 

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.

Emile Cormier