Начал разбираться с UML.
Возникло несколько вопросов (прошу прощения за большой объем, я привел
описание того, что я пытаюсь сделать и хочу уточнить, правильно ли я делаю):
1. Как показать на диаграмме классов связь документа со справочником?
(чувствую, что правильно нарисовать диаграмму мне мешает привычка
мыслить в категориях реляционных БД. Хотя ООП я применяю в приложениях
достаточно часто, но вот UML как-то еще ни использовал).
Рисую класс "Документ", класс "Справочник". От документа к справочнику
рисую однонаправленную ассоциацию, устанавливаю кратность 1 к 1.
В результате в коде класса "Документ" появится переменная типа "Справочник".
В БД, соответственно, будут две таблицы, связанные как "master-detail".
Правильно, или что-то не так? Каким стереотипом можно обозначить эту ассоциацию?
2. Для связи классов "Документ" и "Деталь документа" создаю два класса (правильно?
детали же представляют собой отдельный класс? а если надо, например,
хранить комментарии к документу со временем их добавления и автором — для
такого комментария тоже нужен отдельный класс?), от документа к детали рисую
двунаправленную ассоциацию агрегации, со стороны документа ставлю кратность 1,
со стороны детали — 0..n. Для этой ассоциации можно использовать
стереотип "include"? Или нет? Как в Rose указать, что эта агрегация — композит?
3. У документа есть некий статус, который последовательно изменяется во времени.
Надо отслеживать, кто, когда и какой статус установил.
В реляционной модели я бы сделал связь многие-ко-многим между возможными
видами состояний (справочник) и документом, в таблице связи фиксировал бы время
и ссылку на пользователя.
На диаграмме классов мне надо тоже создать класс "Состояние документа" и
в нем все это хранить? Если да, то от класса "Документ" к классу "Состояние документа"
рисуем двунаправленную ассоциацию агрегации, со стороны документа ставим
кратность = 1, со стороны класса состояния документа — 1..n (статус должен быть всегда).
От класса "Состояние документа" к классу "Вид состояния" (справочнику)
рисуем однонаправленную ассоциацию с кратностью 1 к 1. Так или нет?
Каким стереотипом можно обозначить эти ассоциации?
4. Есть два класса, один из которых является "коллектором" для другого класса,
например, "Проект" является коллектором объектов класса "Задание", т.е.
он умеет их создавать/удалять/находить и т.п.
Связь между ними показываю двунаправленной ассоциацией (чтобы и из
"проекта" получить доступ к "заданиям", и наоборот, из "задания" выйти на "проект".
Для "проекта" устанавливаю кратность 1, для "задания" — 0..n. Это правильно
или здесь нужна зависимость, а не ассоциация?
Каким стереотипом можно обозначить эту ассоциацию?
5. Если я правильно понял, конструкторы и деструкторы в классах определять не надо,
создаются автоматически? А если надо создать объект какого-то класса
с инициализацией каких-то его атрибутов? Можно использовать конструктор
с параметрами или надо инициализировать атрибуты после создания вызовом
отдельного метода?
6. Как то случайно изменил Language одного из классов на "Java".
Как поменять его на "Analysis"?
Это правильно?
7. Как смоделировать объекты БД, соответствующие полученной диаграмме классов?
Только вручную, самому определить сущности (таблицы) БД для каждого класса?
Где построить эту модель (обычно пользуюсь Power Designer'ом).
8. Есть ли какие-то Add-In'ы или что-то еще для поддержки в Rose C#?
Пара вопросов по реализации:
9. Как попроще осуществлять взаимодействие полученных классов с объектами
реляционной БД? Это OO-DB-mapping? Если можно, ссылки на примеры.
10. Как осуществлять взаимодействие полученных классов с пользовательским
интерфейсом? Если можно, ссылки на примеры.
Здравствуйте, vladimir_v_l, Вы писали: __>1. Как показать на диаграмме классов связь документа со справочником? __> (чувствую, что правильно нарисовать диаграмму мне мешает привычка __> мыслить в категориях реляционных БД. Хотя ООП я применяю в приложениях __> достаточно часто, но вот UML как-то еще ни использовал). __> Рисую класс "Документ", класс "Справочник". От документа к справочнику __> рисую однонаправленную ассоциацию, устанавливаю кратность 1 к 1.
Отношение Документ — справочник всегда имеет мощность один — ко многим (с вариациями на обязательность поля 0..1 to 0..n или 1 to 1..n). __>2. Для связи классов "Документ" и "Деталь документа" создаю два класса (правильно? __> детали же представляют собой отдельный класс?
а что такое "Деталь документа"? Атрибуты класса в модели могут быть только примитивных типов. Если тип атрибута — другой класс то тут уже должна быть ассоциация или агрегация. __> а если надо, например, __> хранить комментарии к документу со временем их добавления и автором — для __> такого комментария тоже нужен отдельный класс?), от документа к детали рисую __> двунаправленную ассоциацию агрегации, со стороны документа ставлю кратность 1, __> со стороны детали — 0..n.
Так не может быть. если с одной строны мощность 1 то с другой 1..n __> стереотип "include"? Или нет? Как в Rose указать, что эта агрегация — композит?
Для агрегации в розе рисуют связь в обратном направлении чем для ассоциации, т. е. от дочернего элемента к агрегирующему.
Затем на вкладке "Role A detail" отмечаешь "Aggregate" и "By value" — вот тебе и композит.
__>3. У документа есть некий статус, который последовательно изменяется во времени. __> Надо отслеживать, кто, когда и какой статус установил. __> В реляционной модели я бы сделал связь многие-ко-многим между возможными __> видами состояний (справочник) и документом, в таблице связи фиксировал бы время __> и ссылку на пользователя. __> На диаграмме классов мне надо тоже создать класс "Состояние документа" и __> в нем все это хранить? Если да, то от класса "Документ" к классу "Состояние документа" __> рисуем двунаправленную ассоциацию агрегации, со стороны документа ставим __> кратность = 1, со стороны класса состояния документа — 1..n (статус должен быть всегда). __> От класса "Состояние документа" к классу "Вид состояния" (справочнику) __> рисуем однонаправленную ассоциацию с кратностью 1 к 1. Так или нет?
1 к 1..n __> Каким стереотипом можно обозначить эти ассоциации?
зачем тебе тут стереотип?
__>4. Есть два класса, один из которых является "коллектором" для другого класса, __> например, "Проект" является коллектором объектов класса "Задание", т.е. __> он умеет их создавать/удалять/находить и т.п. __> Связь между ними показываю двунаправленной ассоциацией (чтобы и из __> "проекта" получить доступ к "заданиям", и наоборот, из "задания" выйти на "проект". __> Для "проекта" устанавливаю кратность 1, для "задания" — 0..n. Это правильно __> или здесь нужна зависимость, а не ассоциация? __> Каким стереотипом можно обозначить эту ассоциацию?
Тут действительно скорее не ассоциация а зависимость (dependency — пунктирная линия)
__>> Рисую класс "Документ", класс "Справочник". От документа к справочнику __>> рисую однонаправленную ассоциацию, устанавливаю кратность 1 к 1. S>Отношение Документ — справочник всегда имеет мощность один — ко многим (с вариациями на обязательность поля 0..1 to 0..n или 1 to 1..n).
Это безусловно так в реляционной модели. Но я прочитал, что в UML кратность показывает, сколько
объектов одного класса связано с одним объектом другого класса. Если так, то выходит 1 к 1?
Или я все-таки неправильно понимаю, что такое кратность в UML?
Еще, к этой ассоциации подходит стереотип вроде "ссылается на" и как обозначить по-английски —
reference to или как?
__>>2. Для связи классов "Документ" и "Деталь документа" создаю два класса (правильно? __>> детали же представляют собой отдельный класс? S>а что такое "Деталь документа"? Атрибуты класса в модели могут быть только примитивных типов. Если тип атрибута — другой класс то тут уже должна быть ассоциация или агрегация.
Деталь здесь — по сути запись, допустим — операция, дата, автор.
То есть все же нужен второй класс, так?
Хочу уточнить — получается для не простых типов — массивов, записей и т.п. в UML
создаем вспомогательный класс, да?
__>> а если надо, например, __>> хранить комментарии к документу со временем их добавления и автором — для __>> такого комментария тоже нужен отдельный класс?), от документа к детали рисую __>> двунаправленную ассоциацию агрегации, со стороны документа ставлю кратность 1, __>> со стороны детали — 0..n. S>Так не может быть. если с одной строны мощность 1 то с другой 1..n
Почему? Например, есть документ (кратность 1). Но к нему еще нет вышеобозначенного
комментария (кратность 0). Опять путаю?
__>> стереотип "include"? Или нет? Как в Rose указать, что эта агрегация — композит? S>Для агрегации в розе рисуют связь в обратном направлении чем для ассоциации, т. е. от дочернего элемента к агрегирующему. S>Затем на вкладке "Role A detail" отмечаешь "Aggregate" и "By value" — вот тебе и композит.
Да, "By value" работает. А если связь рисовать от дочернего класса — ромбик появляется у дочернего,
а не у родительского класса (и в коде же переменная появится в дочернем классе?).
Вроде должно быть наоборот?
__>>3. У документа есть некий статус, который последовательно изменяется во времени. __>> Надо отслеживать, кто, когда и какой статус установил. __>> В реляционной модели я бы сделал связь многие-ко-многим между возможными __>> видами состояний (справочник) и документом, в таблице связи фиксировал бы время __>> и ссылку на пользователя. __>> На диаграмме классов мне надо тоже создать класс "Состояние документа" и __>> в нем все это хранить? Если да, то от класса "Документ" к классу "Состояние документа" __>> рисуем двунаправленную ассоциацию агрегации, со стороны документа ставим __>> кратность = 1, со стороны класса состояния документа — 1..n (статус должен быть всегда). __>> От класса "Состояние документа" к классу "Вид состояния" (справочнику) __>> рисуем однонаправленную ассоциацию с кратностью 1 к 1. Так или нет? S>1 к 1..n __>> Каким стереотипом можно обозначить эти ассоциации? S>зачем тебе тут стереотип?
Стереотип же просто уточняет, что я имею в виду, рисуя ту или иную ассоциацию,
например "включает", "имеет", "обслуживает" и т.п. Вот я и хотел на диаграмме уточнить.
Но не знаю, какой глагол тут подходит?
__>>4. Есть два класса, один из которых является "коллектором" для другого класса, __>> например, "Проект" является коллектором объектов класса "Задание", т.е. __>> он умеет их создавать/удалять/находить и т.п. __>> Связь между ними показываю двунаправленной ассоциацией (чтобы и из __>> "проекта" получить доступ к "заданиям", и наоборот, из "задания" выйти на "проект". __>> Для "проекта" устанавливаю кратность 1, для "задания" — 0..n. Это правильно __>> или здесь нужна зависимость, а не ассоциация? __>> Каким стереотипом можно обозначить эту ассоциацию? S>Тут действительно скорее не ассоциация а зависимость (dependency — пунктирная линия)
Хотя Буч пишет, что "Чаще всего зависимости применяются при работе с классами, чтобы отразить
в сигнатуре операции тот факт, что один класс использует другой в качестве аргумента",
"Если объекты одного класса должны будут взаимодействовать с объектами другого иначе,
чем в качестве параметров операции, следует определить между этими классами ассоциацию",
и здесь, как я думаю, все же именно этот вариант — т.е. "задание" для "проекта" — не просто
параметр в операциях, а класс, с которым он взаимодействует, возможен переход
от задания к проекту и от проекта к заданию и т.п. Выходит здесь — ассоциация?
Спасибо за ответ, а что можно сказать по остальным пунктам?
Здравствуйте, vladimir_v_l, Вы писали:
__>>> Рисую класс "Документ", класс "Справочник". От документа к справочнику __>>> рисую однонаправленную ассоциацию, устанавливаю кратность 1 к 1. S>>Отношение Документ — справочник всегда имеет мощность один — ко многим (с вариациями на обязательность поля 0..1 to 0..n или 1 to 1..n).
Извиняюсь. Наврал. Правильно будет Документ 0..n -> 0..1 Cправочник Либо Документ 1..n -> 1 Справочник __>Это безусловно так в реляционной модели. Но я прочитал, что в UML кратность показывает, сколько __>объектов одного класса связано с одним объектом другого класса. Если так, то выходит 1 к 1? __>Или я все-таки неправильно понимаю, что такое кратность в UML? __>Еще, к этой ассоциации подходит стереотип вроде "ссылается на" и как обозначить по-английски - __>reference to или как?
Подписи на связях обычно рисуют на ER (Entity relation) диаграмах. На диаграммах классов обычно их не используют
__>>>2. Для связи классов "Документ" и "Деталь документа" создаю два класса (правильно? __>>> детали же представляют собой отдельный класс? S>>а что такое "Деталь документа"? Атрибуты класса в модели могут быть только примитивных типов. Если тип атрибута — другой класс то тут уже должна быть ассоциация или агрегация. __>Деталь здесь — по сути запись, допустим — операция, дата, автор. __>То есть все же нужен второй класс, так?
Так __>Хочу уточнить — получается для не простых типов — массивов, записей и т.п. в UML
Массив можно отобразить мощностью связи. __>создаем вспомогательный класс, да?
__>>> а если надо, например, __>>> хранить комментарии к документу со временем их добавления и автором — для __>>> такого комментария тоже нужен отдельный класс?), от документа к детали рисую __>>> двунаправленную ассоциацию агрегации, со стороны документа ставлю кратность 1, __>>> со стороны детали — 0..n. S>>Так не может быть. если с одной строны мощность 1 то с другой 1..n __>Почему? Например, есть документ (кратность 1). Но к нему еще нет вышеобозначенного __>комментария (кратность 0). Опять путаю?
значит 0..1 к 0..n __>>> стереотип "include"? Или нет? Как в Rose указать, что эта агрегация — композит? S>>Для агрегации в розе рисуют связь в обратном направлении чем для ассоциации, т. е. от дочернего элемента к агрегирующему. S>>Затем на вкладке "Role A detail" отмечаешь "Aggregate" и "By value" — вот тебе и композит. __>Да, "By value" работает. А если связь рисовать от дочернего класса — ромбик появляется у дочернего, __>а не у родительского класса (и в коде же переменная появится в дочернем классе?). __>Вроде должно быть наоборот?
Ромбик у родительского (агрегирующего) класса. Будь внимателен. Рисуем от дочернего к родителю, и не путаем роль A и B __>>>3. У документа есть некий статус, который последовательно изменяется во времени. __>>> Надо отслеживать, кто, когда и какой статус установил. __>>> В реляционной модели я бы сделал связь многие-ко-многим между возможными __>>> видами состояний (справочник) и документом, в таблице связи фиксировал бы время __>>> и ссылку на пользователя. __>>> На диаграмме классов мне надо тоже создать класс "Состояние документа" и __>>> в нем все это хранить? Если да, то от класса "Документ" к классу "Состояние документа" __>>> рисуем двунаправленную ассоциацию агрегации, со стороны документа ставим __>>> кратность = 1, со стороны класса состояния документа — 1..n (статус должен быть всегда). __>>> От класса "Состояние документа" к классу "Вид состояния" (справочнику) __>>> рисуем однонаправленную ассоциацию с кратностью 1 к 1. Так или нет? S>>1 к 1..n __>>> Каким стереотипом можно обозначить эти ассоциации? S>>зачем тебе тут стереотип? __>Стереотип же просто уточняет, что я имею в виду, рисуя ту или иную ассоциацию, __>например "включает", "имеет", "обслуживает" и т.п. Вот я и хотел на диаграмме уточнить. __>Но не знаю, какой глагол тут подходит?
да любой подсунь. "хранит" например __>>>4. Есть два класса, один из которых является "коллектором" для другого класса, __>>> например, "Проект" является коллектором объектов класса "Задание", т.е. __>>> он умеет их создавать/удалять/находить и т.п. __>>> Связь между ними показываю двунаправленной ассоциацией (чтобы и из __>>> "проекта" получить доступ к "заданиям", и наоборот, из "задания" выйти на "проект". __>>> Для "проекта" устанавливаю кратность 1, для "задания" — 0..n. Это правильно __>>> или здесь нужна зависимость, а не ассоциация? __>>> Каким стереотипом можно обозначить эту ассоциацию? S>>Тут действительно скорее не ассоциация а зависимость (dependency — пунктирная линия) __>Хотя Буч пишет, что "Чаще всего зависимости применяются при работе с классами, чтобы отразить __>в сигнатуре операции тот факт, что один класс использует другой в качестве аргумента", __>"Если объекты одного класса должны будут взаимодействовать с объектами другого иначе, __>чем в качестве параметров операции, следует определить между этими классами ассоциацию", __>и здесь, как я думаю, все же именно этот вариант — т.е. "задание" для "проекта" — не просто __>параметр в операциях, а класс, с которым он взаимодействует, возможен переход __>от задания к проекту и от проекта к заданию и т.п. Выходит здесь — ассоциация?
Ну ты же сначала написал "создавать/удалять/находить", я решил что "проект" это фабрика для "заданий", а для таких — связь dependency
__>Спасибо за ответ, а что можно сказать по остальным пунктам?
Ничего не скажу. Я не никогда использовал розу для генерации кода или DDL поэтому ничего присоветовать не могу.
__>>Хочу уточнить — получается для не простых типов — массивов, записей и т.п. в UML S>Массив можно отобразить мощностью связи. __>>создаем вспомогательный класс, да?
Имеется в виду, что просто атрибут у класса типа массив (равно как и запись, record в ЯВУ) в UML не создать,
надо создавать класс (ну а на связи уже указывать соответствующую кратность), так?
S>>>Для агрегации в розе рисуют связь в обратном направлении чем для ассоциации, т. е. от дочернего элемента к агрегирующему. S>>>Затем на вкладке "Role A detail" отмечаешь "Aggregate" и "By value" — вот тебе и композит. __>>Да, "By value" работает. А если связь рисовать от дочернего класса — ромбик появляется у дочернего, __>>а не у родительского класса (и в коде же переменная появится в дочернем классе?). __>>Вроде должно быть наоборот? S>Ромбик у родительского (агрегирующего) класса. Будь внимателен. Рисуем от дочернего к родителю, и не путаем роль A и B
Так я так и пробую — от дочернего к родительскому, но Роза рисует ромбик у дочернего класса!
А если рисую от родительского — ромбик у него, и в нем же будет переменная, ссылающаяся на дочерний класс.
__>>и здесь, как я думаю, все же именно этот вариант — т.е. "задание" для "проекта" — не просто __>>параметр в операциях, а класс, с которым он взаимодействует, возможен переход __>>от задания к проекту и от проекта к заданию и т.п. Выходит здесь — ассоциация? S>Ну ты же сначала написал "создавать/удалять/находить", я решил что "проект" это фабрика для "заданий", а для таких — связь dependency
Так, теперь я уже запутался.
Допустим, есть список проектов. Пользователь выбирает один из них
(экземпляр класса "проект"), отображается список заданий по нему.
Доступны операции "создать задание", "изменить задание", "удалить задание".
Если выбрать, например, "создать задание", открывается соответствующий экранный интерфейс
для ввода его реквизитов (соответственно создается экземпляр класса "задание"), после завершения
ввода этот экземпляр добавляется в общий список заданий экземпляра "проект".
При удалении из списка — удаляется.
Но я предполагаю, что будут и другие операции, когда надо будет
из задания выходить на проект и из проекта — в конкретное задание.
Т.е. тут как бы и фабрика, и как бы и в какой-то мере "равноправные" классы.
Значит, используем все же не зависимость, а ассоциацию. Я прав?
А по ноликам-единичкам кратности почитаю еще. Что-то стал запутываться.
Хотя в БД прекрасно со связями управляюсь и не испытываю никакого дискомфорта
P.S. Кто знает, как в Розе поменять тип класса с Java на класс по-умолчанию (Analysis)?
Случайно поменял на Java, а как и где — не заметил. Не перерисовывать же заново.
Хотя один класс конечно не проблема перерисовать, а если в нем будет куча атрибутов
и операций — это же не рационально?!
