Those units wouldn't exist within the same class if they weren't related to each other. By grouping them into their classes visually, we can take advantage of that relationship to make our diagrams more easily.
Usually, it saves us trouble later on. Things that are related to each other at one level are often part of the same thing at a higher level.
In testing, as in chemistry, it's important to change only one thing at a time. If we pull together more than two things in a single step, we've changed more than one thing, and so we can lose track of where any problems we find came from.
The ones in the smallest circles, especially if they don't have any lines pointing from themselves to other circles.
Start from the smallest circles involving that code, and build up step by step until you're ready to integrate it with your earlier code.
When we were doing unit testing, even other instances of the same class were mocked; we were concerned that this code did what it was supposed to, without involving anything else. Now that we're doing integration testing, we need to test that instances of the same class interact correctly with each other, or with themselves when they're allowed to retain state from one operation to the next. The two kinds of tests cover different things, so it makes sense that we would need both.
A system test is the final stage of integration testing. It's a test that involves the whole code base.