Cyclic "dependency" can be. Why not? Because they are not dependencies
, but associations
with visible navigability. But you have some problems here.
Reservation should better have navigation to Member. Backward it could be, too. But Reservation should have Member instance as attribute. It is more simple way.
Also Rental is a class representation of association between DVD and Customer. And should have their instances as attributes. Again, back navigation IS possible, but do you need it? Maybe.
Another problem:
- Title-DVD aggregation has correct direction, but it should be Composite, for there are no DVD without Title.
Testing: You can do unit tests, isolating classes from other ones by mocking first. After debugging that start to replace mocks with real classes. After that try unit tests without mocking, then normal auto tests, with automatic input/output/comparing.
As for code engineering, download VP UML enterprise "for testing version" and/or Enterprise Architect of Sparx, eval professional version. They both can do code engineering in C++.