I am looking for a tool that can (automatically) create class diagrams like this one from Modelica code:
https://trac.modelica.org/Modelica/attachment/ticket/85/classDiagramModelicaMedia.png
I need to create a couple of such diagrams and an automated solution would help a lot!
So far, I found this article about Modelica CDV (class diagram viewer):
https://www.modelica.org/events/modelica2006/Proceedings/sessions/Session1c1.pdf
but not a ready to use tool. Any ideas?
This can be done with SystemModeler and Mathematica. The relevant function is a little bit hidden, but it's there. Here's an example:
WSMLink`Library`WSMDependencyGraph["Modelica.Mechanics.Rotational.Components.Spring"]
When hovering over the classes, the full name appears:
The object returned from the function includes a Graph, so you can operate on it with all the graph functionality in Mathematica. Also the function takes the same arguments as Graph, so you can get different graph layouts if needed.
I don't have any specific suggestions, but you might find that a tool like OpenModelica could extract and output sufficient information to construct such diagrams. It seems to have many command line switches for outputting lots of information (debugging and otherwise).
Related
A while ago during documenting legacy code I found out there is a tool for displaying call graph (call stack) of any standard program. Absurdly I wasn't aware of this tool for years :D
It gives fancy list/hierarchy of calls of the program, though it is not a call graph in a full sense, it is very helpful in some cases.
The problem is this tool is linked only to SE93 so it can be used only for transactions.
I tried to search but didn't find any similar tool for reports or function modules. Yes, I can create a tcode for report, but for function module this approach doesn't work.
If I put FM call inside report and build a graph using this tool, it wraps this call as a single unit and does not analyze deeper. And that's it
Anybody knows a workaround how we can build graph for smth besides transaction?
The cynic in me thinks RS_CALL_HIERARCHY was left to rot. Sandra is right, it definitely used to work. Once OO came to abap, interfaces and dynamic/generic code became possible. So a call heirarchy based on static code analysis was pushing proverbial up hill.
IMO the best way to solve this is a FULL trace and then to extract the data from the trace.
There are even external tool that do that.
This is of course, still limited as running a trace on every execution path can be very time consuming. Did I hear someone say small Classes please ?
Trans SAT.
Make sure teh profile you use isnt aggregating, and measure the blocks you are interested.
Now wade you way through the trace.
https://help.sap.com/doc/saphelp_ewm93/9.3/en-US/4e/c3e66b6e391014adc9fffe4e204223/content.htm?no_cache=true
Have fun :)
The call hierarchy displays also works for programs and function modules.
In my S/4HANA system, for VA01, it displays:
Clicking the hierarchy of function module CJWI_INIT displays:
I get exactly the same result by calling the function module RS_CALL_HIERARCHY this way:
The parameter OBJECT_TYPE may have these values:
P : program
FF : function module
The "call graph" is not maintained anymore since at least Basis 4.6, and it doesn't work for classes and methods.
But the tool is buggy: in some cases, a function module containing a PERFORM at the first line, it may not be displayed, whatever the call graph is launched from SE93 or directly from RS_CALL_HIERARCHY.
Currently, I am "forced" to develop my reports with SE80 / SE24, etc. and I can't use eclipse. There I've seen that if you have the "Source Code-Based" view in Z-Classes, above every method the signature is shown as a comment. See in the following picture:
Well, I know that those comments are not really in the source code, but shown anyway (generated somehow).
Do you know a way how to disable those "comments"?
I find them unnecessary and I am losing the overview over the class. And instead of a 27-row implementation part of a class I've got an 88-row-long implementation part.
These signature comments are automatically generated by the SAP GUI based class editor reached through transactions SE24 and SE80.
Use the ABAP Development Tools to avoid them.
There's no way to disable those comments. I genereally prefer the form editor when forced to use SE80, I think it gives a better overview. The best would be if you were allowed to use Eclipse, but politics can be difficult to change.
I have a large amount (about 50) of SubVIs including beyond some usage specific code a small number of GUI elements (mostly about 2: input and output).
My goal is to reuse those VIs without creating a huge mess in a new ('main') VI and collect all GUI elements on a GUI common pane a user shall finally interact with.
I tried to use the Open VI Function, 'VI Reference' and 'Run SubVi' like in the examples to create references for subpanels, but the subpanel ui is only shown when the program is run and the amount of additional blocks is mostly bigger than the code in the respective SubVI.
The SubVIs should be loaded only once to construct the main User Interface.
In addition: In this tutorial they create a subVI and recreate GUI elements that are already defined in the subVI.
I assume this behaves like passing arguments as in a text based programming languages like the snippet:
def main_vi(x, y, z): # inputs x, y, z
s = sub_vi(x, y, z)
return s # output s
Is this necessary, or can the subvi's GUI controls directly be reused from outside?
Is it possible to use the subVIs inside of an "main" VI that includes everything and maps everything to a common UI using tabs?
Or is it better to copy everything to the main VI, i.e. no code reuse at all?
Thanks in advance!
Depending on the functionality you are going for, yo may want o look into XControls. This would allow you to encapsulate your functionality into a reusable control that could be used on a main panel without making the main panel very messy.
Large UI's can be a pain (pun with pane not intended), especially if there are a lot of controls and indicators. There are some useful ways to break UIs into modular components. XControls are one of those but I don't recommend them due to their unpredictable behaviors. Instead look into working with Sub Panels. There is a great toolkit for this from a company called Moore Good Ideas (or MGI). More info can be found on their website here.
There is also a better alternative to XControls, called QControls. More info on them can be found here.
In general, though, you might want to look into a more modular framework. More info on Frameworks can be found here.
I want to find my mistake in GAMS model. I don't have any errors , but my model doesn't work well
Is there any debugging tools in GAMS ?( like debugger tools in other software, e.g MATLAB)
Best
Unfortunately, I have not come across any.
If you have no errors in GAMS, it rather points to a modelling problem rather than a GAMS one. GAMS is like any other programming/modelling software, what you put in is what you get out. However, there are some commands and some intuitive ways you can find out the problem with your model:
One common way is by using the display and $stop commands. If you have loops within your GAMS code, it is best to track the progress of the loop by displaying some key variables either to your .lst file or using put utility (also a nice tool). I use the put utility, and write the code to display key variables at each point of my code to identify where things may have gone wrong.
The $stop command terminates your GAMS code at the line in which it is written.
Hope this helps.
I need to drive a testbench with labview.
The test scenarios are written in a languages that can be automaticaly translated into labview diagrams.
Is this an API that allow to create "labview diagrams" from another software ? or with labview itself ?
I agree that LabVIEW scripting is one approach, but let me throw out another option.
If you are planning to do a one time migration from your test code to LabVIEW than scripting is great, but if you plan to regularly update your test code (because it's easier to use the "test" language than LabVIEW) than it could become quite painful to constantly perform the migration every time your test code has changed.
I've had great success with simply putting my state machine inside of a for loop and then reading in "commands" from a text file that was generated using my "test" language (see pic).
For example, to do an IV sweep my text file might say something like:
SourceV, 5
ReadI
Wait, 1
SourceV, 6
ReadI
This image is greatly simplified - I'm not using a state machine and I don't show how to use "parameters," but I can provide a more comprehensive example if needed. Again, I've had great success doing this with around 30 "commands" controlling multiple instruments and then I generated the text input using VBA or Python.
It's called LabVIEW scripting. You will need to enable an option in the VI Server page in the options dialog to see the relevant features.
A few things to note:
Scripting isn't complicated, but you do need to be aware of how LV code is built.
While scripting is public, it was initially created as an internal tool. There are still corners of it which are incomplete.
Scripting code can be tedious. If you can get away with it, try creating templates of code.
NI has something called CodeGen, which I believe are a series of functions which make some scripting easier, although I never really looked into it.