Вопрос о типе отношения диаграммы классов UML
-
03-07-2019 - |
Вопрос
У меня есть класс данных со следующими методами:
- ExecuteUDIQuery(строковый запрос)
- ExecuteSelectQuery(строковый запрос)
- ExecuteSP(строка anme, параметры string[,])
У меня есть много классов, которые используют класс data.Теперь я хочу создать диаграмму классов, но я не знаю, какую связь имеют классы с классом данных.Является ли это составным?Это 1: 1 или ..?
Примером класса, который использует класс data, является класс Staff.Этот класс имеет метод Load(), который загрузит объект staff с идентификатором staff member.Этот метод содержит запрос, который передается методу ExecuteSelectQuery(строковый запрос) класса Data.
Редактировать:Класс данных не является статическим.Однако у меня есть свои сомнения.На самом деле я не знаю, что делать.Дело в том, что единственное, что он делает, - это выполняет запросы и возвращает результаты.
Решение
Я бы предположил, что это использование отношения зависимости.
Видишь здесь для краткого описания.
Другие советы
Я бы запросил именование ваших классов.имя класса обычно должно быть существительным в единственном числе.Примеры;
- Окно
- Человек
- Транзакция
Данные - это множественное число, и в любом случае я думаю, что это должна быть база данных.
Аналогично для Staff - еще раз множественное число, я думаю, это должно быть MemberOfStaff.Если, конечно, это не список сотрудников, и в этом случае я бы назвал его чем-то вроде Отдела, Проекта или дивизиона - независимо от того, что указывает ваша проблемная область.
Вы обнаружите, что придумать хорошие названия для классов удивительно сложно, но это того стоит.
Разница между агрегациями, композитами и отношениями 1 на 1 немного расплывчата и несколько произвольна.
Я использую агрегацию (open diamond), если один класс владеет другим классом (отвечает за жизненный цикл.
Я использую отношения 1 на 1 во всех остальных случаях.
Создается ли экземпляр класса классами, которые его используют, или методы являются статическими?Если они статичны, я бы представил это как неквалифицированную зависимость (пунктирная стрелка, указывающая от классов, использующих класс data, к классу data)
Если классы, использующие класс data, создадут свой собственный частный экземпляр этого класса, это будет композиция 1: 1 (при условии, что жизненный цикл экземпляра класса data привязан к использующему его объекту)
Я не могу воздержаться от комментариев по вашему общему дизайну, я бы попытался перенести метод Load из класса Staff, чтобы этот класс не зависел напрямую от класса Data.
В рамках вашего существующего дизайна я бы предложил следующее:Если класс staff содержит переменную экземпляра класса data, то это ассоциация.Если класс данных создается только для извлечения экземпляра, это просто зависимость заданного типа, как говорит @toolkit.
Недостаточно данных.
Дайте нам какие-нибудь конспекты занятий или что-то в этом роде.Из того, что я вижу, я бы на самом деле не назвал это классом данных (это больше похоже на data аксессуар) что звучит именно так мог бы быть синглтоном (много: 1, агрегация или ассоциация), или, если создан экземпляр, это будет компонент 1: 1.
Теперь я хочу создать диаграмму классов, но я не знаю, какую связь имеют классы с классом данных.
Мы тоже - вы описали только класс данных, но не сказали, как Персонал получает Данные, которые он использует.
Если Staff относится к одному или нескольким экземплярам класса data, то либо существует связь между Staff и Data, либо Staff имеет атрибут типа Data (если данные имеют семантику значения).
Если на экземпляры Данных ссылаются несколько экземпляров Staff, и их жизненные циклы зависят от того, ссылаются ли на них экземпляры Staff, то это может быть показано как отношение агрегирования.Если экземпляры данных не являются общими для экземпляров Staff и их жизненные циклы зависят от наличия ссылок, то это может быть показано как отношение состава.
Если X не сохраняет экземпляры данных, которые он использует, тогда уместна связь использования.
Зависимость и использование - это два самых слабых вида "соединителей".Вы могли бы рассмотреть стереотипы, ключевые слова для уточнения отношений.Вы можете обнаружить, что стереотипы создания экземпляра, вызова, отправки работают.Без дополнительной информации, хотя правильным ответом, по-видимому, является использование.