Форум Сообщества Аналитиков
Общий раздел => Примеры => Задачи студентов => Тема начата: idsp от 19 Июня 2011, 20:13:51
-
Привет. Делаю программу для создания виртуального тура.
Подробности:
1) Есть программа, выводящая изображение, взятое из базы данных (SQLite).При этом используется OpenGL для создания фигуры на которую накладывается в виде текстуры взятое изображение.
2) Пользователь может добавлять изображения в базу данных.
3) Между изображениями есть переходы (в виде стрелок). Можно переходить из одной сцены в другую.
4) Имеются контрольные точки, которые позволяют перемещаться к нужной сцене не проходя до нее последовательно весь путь.
Нужно составить use case диаграмму, диаграмму классов.
С UML раньше не имел дело, но теперь понадобилось.
Я попробовал сделать use case диаграмму (посмотрите пожалуйста):
(http://s43.radikal.ru/i100/1106/8a/b0d63b66f812t.jpg) (http://radikal.ru/F/s43.radikal.ru/i100/1106/8a/b0d63b66f812.png.html)
Собираюсь делать диаграмму классов. Программу писал на Qt (C++)
Пусть есть такой код, на его примере не могли бы вы мне показать, как будет выглядить диаграмма классов. Просто я незнаю, как в UML представить signals и slots Qt.
mainwindow.h
#include <QMainWindow>
class Scene3D;
class dbViewer;
class QListWidget;
class QToolBar;
class QAction;
class QTableWidget;
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
MainWindow();
private slots:
void aboutSlot();
void checkPhotoSlot();
void informationSlot();
private:
void createToolBar();
void createActions();
void createStatusBar();
void createCheckPointList();
void createTableWidget();
enum { COLUMN = 2 };
QTableWidget *checkpointTable;
QAction *exitAction;
QAction *aboutAction;
QAction *nextPhotoAction;
QAction *previousPhotoAction;
QAction *checkerAction;
QAction *informationAction;
QToolBar *toolBar;
Scene3D *view3D;
dbViewer *viewChecker;
};
mainwindow.cpp
#include <QtGui>
#include "mainwindow.h"
#include "dbViewer.h"
#include "scene3D.h"
#include "helpBrowser.h"
MainWindow::MainWindow()
{
QTextCodec::setCodecForCStrings(QTextCodec::codecForLocale());
view3D = new Scene3D;
viewChecker = new dbViewer;
setCentralWidget(view3D);
setContextMenuPolicy(Qt::NoContextMenu);
setGeometry(100, 100, 800, 600);
createActions();
createToolBar();
createStatusBar();
createCheckPointList();
connect(checkpointTable, SIGNAL(cellDoubleClicked(int,int)), view3D, SLOT(getPhoto(int,int)));
}
...
Спасибо.
-
ДВИ никуда не годится. Почему - слишком долго объяснять. Почитайте хотя бы наш FAQ на сайте.
А какие сложности в представлении ДКлассов? Сигнал - тот же класс со стереотипом "signal". А что такое слот?
-
По вариантам использования.
В use case обычно отображаются цели действующего лица, т.е, то, чего действующее лицо хочет достичь при работе с системой. Деталей реализации вроде подключения к БД там быть не должно. Предположительно, у Вас вырисовывается два действующих лица
1. Пользователь
2. Программист (лучше обозвать как-нибудь по-другому, 'служба сопровождения', что ли...)
Варианты использования для Пользователя
- Добавить изображение
- Поставить контрольную точку
- Найти изображение /*скажем, по критериям поиска*/
- ....
По поводу второго действующего лица не все ясно. Будут ли некие действия, которые Ваш 'Программист' будет совершать средствами системы? Ну, архивирование какое-нибудь, либо удаление старых изображений? Если под сопровождением имеется в виду, что разработчик (он же аналитик, он же служба сопровождения, он же тестировщик в одном флаконе) залезает непосредственно в базу и ручками что-то там
правит - это на диаграмме ВИ отображать не стоит.
По классам.
Класс в нотации UML на основе приведенного кода будет выглядеть как квадратик, в котором написано MainWindow, с перечислением методов ниже. Такие детали реализации вряд ли есть смысл изображать на диаграмме классов - это если только для отчетности надо...
Скорее всего, Вам нужно выделить сущности предметной области (кстати, Вы не уточнили, что это за область) и прикинуть, как они связаны друг с другом.
Слоты и сигналы QT - технически просто методы соответствующих классов. Но поскольку они несут вполне определенную смысловую нагрузку (связь между объектами), эти классы явно должны быть соединены ассоциацией.
Т.е, рисуете в UML классы и ассоциации между ними, а на уровне кода эти ассоциации будут выражены механизмом слотов-сигналов.
-
Тут как раз недавно делал диаграмму классов на основе кода (Visual Paradigm делает это автоматически)
он мне вроде как в местах типа
QAction *aboutAction;
нарисовал на ДК отношение containment(на конце линии кружочек с крестиком внутри)