Let me guess: this is a program
- only for academic purposes, which will probably have a restricted life time
- in the range of 2K lines of code up to 20K at most
- with just one developer (you)?
Then using the restricted "amount of OOP" you already did ("abstracting some datastructures into classes") is probably what makes sense most. You can introduce some more classes to group some modules together, but if there is just one "main module" which requires five lists, stacks and sets, make those member variables of the corresponding class and consider them as global in the scope of that module, that's fine.
OOP is not an end in itself, it is a means to an end. It is for building larger software, isolating blocks from each other, keeping software maintainable and evolvable even when it grows over a longer period of time, and aims for a long-term scalable development process. Your kind of program does not seem to fit into that picture. If there is only one main algorithm inside, there is most probably just one "main module" required, and the program is simply too small to use more. So use from OOP what's useful for your case, and forget about the rest.
Said that, even in a relatively small optimization program as you scetched it, there will usually be three layers at minimum:
- a data layer (you will most probably need a specialized graph structure, maybe with some general, basic operations for graphs)
- a "business logic" layer (your main algorithm)
- a user interface layer (either a command line interface, or maybe a simple GUI)
I would recommend to keep these separated, and use OO means like classes and objects to separate them. This will usually make it easier to add automated tests to this system, which might be considered as a fourth layer, and a fourth opportunity to use classes and objects.
With growing program size, I can envision that you find more opportunities for using classes and objects:
- different algorithms: give each one a class of its own
- exchangeable algorithms with the same input and output: define a common interface, derive each algorithm class from it
- shared code and infrastructure for the different algorithms: refactor those to the data layer, if possible, or into helper classes
- algorithms which are similar to a larger extent, except one inner part, which behaves differently: make use of the strategy pattern to encapsulate and exchange that inner part
But if you are currently not at that point, don't try to force more "OO" into your program than necessary.
Regarding the "name question": I don't think there is a special one, "small program with restricted life time" is the only name which comes into my mind.