Static Analysis for SAP2000 API

For background, SAP2000 is a structural analysis software used in industry a lot and it has an API in several languages that seems to talk to a SAP2000 executable. It be used to create structural models as an alternative (though I think infrequently used) to the GUI.I started using the SAP2000 API for modeling a complex structure and I found it very helpful. I could have a record of everything that made the model, loop through repetitions in the structure, quickly update it with different parameters, and have calculations for the structure's geometry in the code directly. However, while there is good documentation, I found a big source of friction was that python (the language I'm using) couldn't do a static analysis with that documentation. (I can't see the component classes and methods of a component class, nor the arguments of a method in the IDE itself like most libraries). This means I have to search the documentation separately, copy over the method I want (often there's 3 or 4 layers of component classes), and count the arguments to check what they each refer to (there's often many arguments, some irrelevant). Then to review the arguments I passed I have to either wrap the call in a function I wrote, add a comment or just remember it. If this friction was removed, I think using the API would be faster and more robust than using the GUI in general.

Could there be a way to get static analysis of the classes and methods?

One approach I thought of is parsing through the documentation (a chm file) to get name, description and arguments of each method. Then I would generate python classes with an identical composition hierarchy who have methods that just call an API method with an identical name. It would then appear identical to calling the API method directly but static analysis would come with it. It sounds like a crazy idea to me (writing code to write code and wrapping an API in essentially another API), but I think it should work.

Would there be a better and simpler way of doing it? Are there issues with the way I'm proposing? Might there already be a way of getting static analysis?

Thanks!

I don't understand the term "static analysis" in the way you are using it. To me static analysis is performed by tools like pylint and I don't think that is what you want.

person123 said:

Then I would generate python classes with an identical composition hierarchy who have methods that just call an API method with an identical name. It would then appear identical to calling the API method directly but static analysis would come with it. It sounds like a crazy idea to me (writing code to write code and wrapping an API in essentially another API), but I think it should work.

No, it's not a crazy idea, that's exactly what you (or someone else) needs to do (if it has not been done already by the vendor or someone else).

pbuk said:

I don't understand the term "static analysis" in the way you are using it. To me static analysis is performed by tools like pylint and I don't think that is what you want.

Thank you!

Yes, I'm probably not using the term static analysis correctly. What I want to see are the list of component classes and methods of a class, and the arguments of a method, you often see in IDEs. Would they just be called tooltips instead? (I was calling it static analysis because it tells you things about your program without running it).

pbuk said:

No, it's not a crazy idea, that's exactly what you (or someone else) needs to do (if it has not been done already by the vendor or someone else).

Sounds good, I think I'll look around a bit more to see if it's been done, and if not, I'll do it myself. I've never really done anything like it and it felt like a strange approach, so it's very good to know it's fairly standard. (I'm not contacting CSI directly since I only have a work account and I'm not sure if I can use it to ask about things only tangentially related to my job).

Update:

I added the tooltips with the method I described, with a demo attached. The documentation isn't perfect -- small format mistakes prevented me from constructing about 10% of the methods, and you can even see typos in the demo (e.g. SapMdel instead of SapModel). I could fix these issues manually though.