Modelling a function with EA

[Propad]

Hello,

I'm bit puzzled by the fact, that I see no clean way to model a simple function (not bound to a class, but residing in a C or Python module/source file).

My task includes a number of tasks, among others: a clean modeling of existing libraries, both in C and Python.

Much of the code there is implemented as simple functions. Now I want to put  those functions in a package (corresponding to C source files, or modules), I see no way to do that in an unambiguous manner.

I've also tried to see how EA handles imported Python and C-source files. Fact is, no functionas are imported. Typedefs, enummerations and namespaces (from C++) are imported just fine.

So I'm wondering what would be the clean way to do this.
Ma best guess by now is to inreoduce some streotypes: C_source_file, C_header_file, Python_module etc., then attach Operations and Attributes to instances of classes with those stereotypes.

Any hints?

Thanks in advance,
Propad

[Eve]

It's difficult because UML doesn't actually allow for modelling operations that don't belong to a class.  (As it is for object oriented modelling)  For your C files, try importing as C instead of C++.  Other than that, adding a stereotyped class is probably the best way to go.

[sargasso]

..might be tricky, but ...
It would be nice to be able to model these beasts as components that just expose a bunch of (public) methods -- regardless of their internal structure.
Youn can do it manually, maybe a Suggestion to enable some type of RE on them???
bruce

[Propad]

Hello Simon, Bruce,
first ofall, thanks for the answers!
Other than that, this is frustrating...
The wannabe modelling language for the 21st century ignores 80% of the codebase of the 20th century, and a whole bunch of living languages, including C, which is still THE language of  embedded systems... Ugly. Oh please don't take my rant too seriously. I'm just a frustrated purist ;-).
A nice day to everybody,
Nenad

[thomaskilian]

And unfortunately it does also not RE Assembler, Cobol and Fortran

Don't take this as insult, but C is an Assembler, probably a good macro assembler, but not a programming language. Just that millions of C-programmers think so, it is not right.