По вариантам использования.
В use case обычно отображаются цели действующего лица, т.е, то, чего действующее лицо хочет достичь при работе с системой. Деталей реализации вроде подключения к БД там быть не должно. Предположительно, у Вас вырисовывается два действующих лица
1. Пользователь
2. Программист (лучше обозвать как-нибудь по-другому, 'служба сопровождения', что ли...)
Варианты использования для Пользователя
- Добавить изображение
- Поставить контрольную точку
- Найти изображение /*скажем, по критериям поиска*/
- ....
По поводу второго действующего лица не все ясно. Будут ли некие действия, которые Ваш 'Программист' будет совершать средствами системы? Ну, архивирование какое-нибудь, либо удаление старых изображений? Если под сопровождением имеется в виду, что разработчик (он же аналитик, он же служба сопровождения, он же тестировщик в одном флаконе) залезает непосредственно в базу и ручками что-то там
правит - это на диаграмме ВИ отображать не стоит.
По классам.
Класс в нотации UML на основе приведенного кода будет выглядеть как квадратик, в котором написано MainWindow, с перечислением методов ниже. Такие детали реализации вряд ли есть смысл изображать на диаграмме классов - это если только для отчетности надо...
Скорее всего, Вам нужно выделить сущности предметной области (кстати, Вы не уточнили, что это за область) и прикинуть, как они связаны друг с другом.
Слоты и сигналы QT - технически просто методы соответствующих классов. Но поскольку они несут вполне определенную смысловую нагрузку (связь между объектами), эти классы явно должны быть соединены ассоциацией.
Т.е, рисуете в UML классы и ассоциации между ними, а на уровне кода эти ассоциации будут выражены механизмом слотов-сигналов.