создание UML-диаграмм?

[dsp]

Привет. Нужна консультация по созданию use case и class diagram.

Как в UML обозначаются сигналы и слоты?

[Авварон]

Никак, умл про них не в курсе.
Рисуй двунавправленную ассоциацию

[dsp]

Дополню свой вопрос

Делаю программу для создания виртуального тура.

Подробности:

1) Есть программа, выводящая изображение, взятое из базы данных (SQLite).При этом используется OpenGL для создания фигуры на которую накладывается в виде текстуры взятое изображение.
2) Пользователь может добавлять изображения в базу данных.
3) Между изображениями есть переходы (в виде стрелок). Можно переходить из одной сцены в другую.
4) Имеются контрольные точки, которые позволяют перемещаться к нужной сцене не проходя до нее последовательно весь путь.

Нужно составить  use case диаграмму, диаграмму классов.
С UML раньше не имел дело, но теперь понадобилось.

Я попробовал сделать use case диаграмму (посмотрите пожалуйста):



Собираюсь делать диаграмму классов.

Пусть есть такой код, на его примере не могли бы вы мне показать, как будет выглядить диаграмма классов. По аналогии я сделаю остальное.

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)));
}

...

Спасибо.

[Denjs]

Как в UML обозначаются сигналы и слоты?

вообще по логике вещей - связь типа "сигнал-слот" должна отображаться на диаграмме объектов (Object diagram).
Но фишка в том, что стандартные элементы диаграммы объектов для этого плохо подходят.

Вам необходимо _расширить_ нотацию. т.е. вместо того, чем рисуются объекты, нам надо рисовать что-то более нам подходящее, и отражающее суть связи. Не всякий редактор на это способен, и не все человеки признают вашу диаграмму UML-ной (многие знают про UML но редкие знают что UML _предназначен_ быть расширямым - т.е. вы под каждый нужный вам случай можете создать ваше маленькое расширение -  ваш собственныый вариант нотации.)

Я рисовал вместо объекты элементами используемыми для отображения классов, а "ассоцияциями" отражал связи. Рисовалось это в DIA элементами диаграммы классов. но вам нужно понимать, что это именно объекты, а не классы(!). Это диаграмма объектов!

[dsp]

Denjs, спасибо за картинку: в интернетах вообще нет картинок-примеров UML диаграмм для Qt.

[Denjs]

Код:

С UML раньше не имел дело, но теперь понадобилось.

"UseCase диаграмма" которую вы рисуете - это не "UsaCase"!
в первую очередь когда вы рисуете "UseCase диаграмму" - вы должны понимать что Usecase отраженный на диаграмме в виде овалов - это последовательность шагов, описанная в виде текста. Вариант взаимодействия системы и внешней сушности. Из данного описания, по шагам - вы и должны уже выделять классы и сущности, поддерживающие ваши "прецеденты использования".

Без текстового описапания - т.е. без наличия самих прецедентов - диаграмма прецедентов есть штука бессмысленная, и не нужная.

Диаграмма прецедентов - это не более чем иллюстрация, задача которой помочь человеку сориентироваться в тех 50 листах сценариев, к которым данная диаграмма прилагается.

В качестве примера - вот вам краткое описание прецедента (это бриф-дескипшин, от которого системный аналитик начнет прорабатывать более детальное описание.

КП.08.1 (UC.009.2) КП: получение оффлайн транзакций АРМ КО.

АРМ КО передает на сервер транзакции (по одной), которые были проведены в
режиме отсутствия связи с КП.
КП принимает операцию, сопоставляя её по идентификаторам. Если КП не находит сопоставления, то предлагается следующая схема
идентификации: У транзакции заполняются идентификатор КП или идентификатор АРМ КО, в зависимости от места создания транзакции. При загрузке транзакции на КП заполняется идентификатор КП, если он не заполнен.
Идентификатор АРМ КО может быть пустым, если транзакция создавалась на КП.

Собственно вы должны разбить все взаимодейтсвие вашей программы с внешним миром на некоторые (относительно независимые) участки, каждый из которых имеет некую конечную полезность для актора, который использует ваш прецедент.

Как только вы это сделаете, под каждый участок взаимодействия вы опишите структуру классов, которая необходима для данного участка, а потом сведете все в общую диаграмму классов.


PS: Это вопросы касающиеся постановки функциональных требований и проектирования системам вообще, а не "конкретно UML" или "диаграммы классов".

[dsp]

Из данного описания, по шагам - вы и должны уже выделять классы и сущности, поддерживающие ваши "прецеденты использования".

Программа уже написана (нужно, конечно, было делать наоборот...). Я нарисовал use case исходя из того, что пользователю(актерам) досупно и как происходит взаимодействие. Видимо, я что-то недопонял.

[Denjs]

Из данного описания, по шагам - вы и должны уже выделять классы и сущности, поддерживающие ваши "прецеденты использования".

Программа уже написана (нужно, конечно, было делать наоборот...). Я нарисовал use case исходя из того, что пользователю(актерам) досупно и как происходит взаимодействие. Видимо, я что-то недопонял.

Сильно сомневаюсь, что вы программировали где-то такую вещь как "сопровождение системы". Хотя если вы можете описать в виде сценария это - то сделайте.
Сопровождение системы - это не очень похоже на "функциональное требование к программе". А значит весьма маловероятно что это прецедент.
Прецедент - это инструмент описания функциональных требований. (и весьма хороший замечу вам)



Так если у вас есть написанная программа - в чем проблема нарисовать её фактическую структуру классов? тут нет совершено никакой разницы на чем у вас программа - на голом С++ или на С++\Qt.
Если конечно вы при создании программы применяли ООП ))))

Единственная раница (ну между "голым С++ или на С++\Qt") - это то, что голый С++ вы можете засунуть в анализатор и он вам сам сделает диаграмму классов ( тот же Rational Rose так может, может DIA с некоторыми плагинами), а на Qt-шных директивах метакомпилятора - егойный парсер сломается и ничего вы из попытки сделать диаграмму автоматически не получите.

[dsp]

Да я с отношениями пока что не разобрался.

Например, вот это что за отношение и как это рисовать?

Код:

class QToolBar;

class MainWindow : public QMainWindow
{
    Q_OBJECT

public:
    MainWindow();

private:
    QToolBar *toolBar;  
};

[Denjs]

Да я с отношениями пока что не разобрался.

Например, вот это что за отношение?

Код:

...

отношение чего к чему? тут 3 класса задействовано.

MainWindow наследуется от QMainWindow

QToolBar - не понятно сразу - он или "агрегирован" в MainWindow или (скажем так) "находится в состоянии композиции в класс MainWindow" - смотря что вы с ним делаете когда вы уничтожаете MainWindow. (см http://ru.wikipedia.org/wiki/Агрегирование_(программирование) - там есть примеры прямо с кодом.)

[dsp]

Что касается QToolBar, то ничего особенного с ним не делаю. Создаю как обычно, добавляю кнопочки, все...

отношение класса
MainWindow и QMainWindow понятно (наследование)

class QToolBar с классом MainWindow, видимо, агрегация.. Хотя, читая вики "Если контейнер будет уничтожен, то и включенный объект тоже будет уничтожен." можно сделать вывод, что это композиция.

 Стыдно мне чего-то стало, не знаю такой ерунды х(

[Авварон]

Никогда не мог запомнить разницу между аггрегацией и композицией. Вообще, в случае Qt тут подход спорный, я бы различал их по указателю/по значению независимо от времени жизни объекта, тк диаграмма вообще показывает взаимоотношение классов и не то, кто за чью удаление отвечает.
Т.е. всё-таки аггрегация в случае QToolBar*

[dsp]

Прочитал, что агрегация - это более слабая форма композиции.

Одним из признаков агрегации - использование указателя.

Свойства композиции:
1 Части в отношении композиции существуют, пока существует целое. Целое отвечает за создание и уничтожение своих частей.
2 Часть в каждый момент может принадлежать только одному целому.
3 Только один класс может представлять целое.

[dsp]

если следовать логие "Если контейнер будет уничтожен, то и включенный объект тоже будет уничтожен", то в Qt одна композиция...?

[Denjs]

Что касается QToolBar, то ничего особенного с ним не делаю. Создаю как обычно, добавляю кнопочки, все...
...
class QToolBar с классом MainWindow, видимо, агрегация.. Хотя, читая вики "Если контейнер будет уничтожен, то и включенный объект тоже будет уничтожен." можно сделать вывод, что это композиция.

т.е. вы отображаете объект класса QToolBar на виджете класса MainWindow? значит это композиция. Потому что для того, что бы быть отображенным - QToolBar должен сделать MainWindow своим родителем. А это уже означает, что QToolBar будет автоматически уничтожен при уничтожении MainWindow. Родительский объект при уничтожении автоматически уничтожает все дочерние объекты (правило для всех QObject-наследованных классов).

Никогда не мог запомнить разницу между аггрегацией и композицией. Вообще, в случае Qt тут подход спорный, я бы различал их по указателю/по значению независимо от времени жизни объекта, тк диаграмма вообще показывает взаимоотношение классов и не то, кто за чью удаление отвечает.

это именно отношения классов, а не способ связи (по указателю/по значению).
отношения - это как сильный/слабый способ связи (?). По ссылке он как правило "слабый" (агрегация) но если "включаемый" объект не может существовать (именно логически) без "основного" - то это "композиция". Рассматриваете это правило как одно из тех, что определяет логическую целостность системы. особенно "ярко" это видно случае с записями в БД

т.е. например "факультет" не имеет смысла вне рамок какого-либо "института". ==> при уничтожении "института" - мы должны уничтожить и все "факультеты" (т.к. композиция). А вот "профессора" без "факультетов" - вполне себе существуют. При упразднении "факультета" - уничтожать записи о "профессорах" нет смысла (т.к. агрегирование).

если следовать логие "Если контейнер будет уничтожен, то и включенный объект тоже будет уничтожен", то в Qt одна композиция...?

нет, может быть и так, и так - смотря по логике работы вашей программы.

 Qt - это C++. тут может быть и то, и другое. Наличие в классе ссылки на другой класс - это ещё не означает что кто-то будет объект по ссылке уничтожать.
т.е. ещё раз посмотрите и найдите разницу между примером "Агрегация" и вторым примером "композиция" в википедии. И там и там - объект по ссылке. но во втором случае он уничтожается (то что это явно прописано в деструкторе - это только один из возможных примеров), а в первом - нет.