Uml Class Diagram C++ Struct

dealing with c++ struct in UML

"How do we deal with the C++ struct in UML class diagrams?" - Scroll a little above halfway down this link.

Specifically structs behave like Classes in UML but all of their members are public.

"...if this struct has a pointer to the struct type itself, what is the relationship between the struct and it self?" - Self referential. It has a pointer to itself. Answered here.

Google searching is a brilliant thing :). Hope this answers your question. If you have any more, just drop a comment.

UML Diagrams with C

1. Yes, you can use UML to describe programs in any language.

2. When an object (structure, w/e ) has it's lifecycle tight coupled with another object is Composition , not Aggregation

3. What you described is neither Composition nor Aggregation. The lifecycle of a particular structure/buffer that's only valid through a certain code segment can be better represented through a Sequence diagram (get buffer , release buffer calls should be shown in the diagram)

4. You will have allot of Composition and Aggregation in C. Think about POD structs. Some of them reference other POD structs inside them. If the reference comes with memory ownership it's Composition (eg :pointer which needs to be released). If the reference doesn't come with memory ownership it's Aggregation (eg : pointer which you don't have to release when releasing the structure).

how to generate UML class diagram from C++

Some remarks :

• cat and dog are C++ struct => their members are public, not private
• you missed to indicate the types of name, id, owner and age
• you used associations navigable in the two directions, but a cat and a dog do not know the corresponding Pet
• the association end must be named (cats / dogs), and it is useless to also show them through attributes

So, also adding the modifiers I speak about in the comments of your question :

(I use cat/dog rather than Cat/Dog to follow the C++ code, but to use Cat/Dog is better)

UML for C programming language

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.

Which UML diagram should be used for a Software overview which will be written in C for microcontrollers?

Ideally the program design should be tied up with your requirement specification, so that for each requirement there is a code module, and for that code module there is a test demonstrating how it lives up the requirement. It's kind of an utopia that one rarely manages to uphold in practice, but this kind of design is a good ambition anyway.

Then generally, it is not as important how you document the program design, as long as the overall design gets at all documented - this is surprisingly rare even in professional settings. But all the pedantic details of UML are really optional, use them where you find a case for them, don't use them just for the sake of it. I frequently use UML class diagrams to document code dependencies, as well as state charts which are useful for documenting application behavior. And so on - keep it broad without implementation-details.

The C equivalent of a class is typically a .h/.c pair with the same name, together forming a "module" or "ADT" or whatever you wish to call it.

You need to document all class A uses class B dependencies, as well as all class B is a class A dependencies (inheritance). Inheritance isn't very common in embedded systems, but implementing a HAL is a typical example where it is used. You have an abstract API on top of hardware-specific drivers.

Obviously you need to decide early on if such abstractions are justified - will the program eventually get ported to another MCU or do you count on the silicon vendor's "longlivety" assurance that the MCU will not go End of Life within the expected product life time? Looking at the completely broken silicon market as of today, I would assume that any microcontroller project needs to get ported plenty of times during its life time.

---

Related Topics