Класс и его атрибуты.Диаграмма классов(Прочитано 10132 раз)
Добрый вечер, уважаемые участники форума.
Занимаясь проектированием диаграммы классов я наткнулся на простецкую с первого взгляда задачку, которая к сожалению пока мною не решена.

Суть: Имеется класс Customer (Заказчик). У данного класса я определил атрибуты:
  • id
  • Фамилия
  • Имя
  • Адрес
  • Телефон

Вопрос1: нужно ли указывать в классе (как это сделал я) атрибут, под названием "id"? (или я начинаю путаться со схемой БД-где этот атрибут необходим,как правило).
Вопрос2: меня смущают атрибуты Адрес и Телефон. Мне кажется, что они - отдельные классы. Если это так, то какие отношения будут между  классами Адрес и Заказчик; Телефон и Заказчик

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



Мне кажется, это зависит от цели моделирования.

Если это уровень анализа, то, скорее всего, id за рамками модели: проектировщик разберется. Если это проектная модель, то вопрос, нужно ли выделять id как атрибут, зависит от принятой технологии (м.б., framework).

Примерно так же можно рассуждать об адресе и телефоне. В анализе - это точно атрибуты. В проекте - зависит от ситуации. Я плохо представляю себе полезность решения, когда имеются классы "человек" и "номер телефона" с множественностью "один к одному". Но, м.б. случай, что вся семья имеет один домашний телефон и адрес. А если кто-то переедет? Если семья переедет по другому адресу, то ... и т.д. Последствия разные!

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

Если Вы студент, разъясните преподавателю, почему Вы приняли то или другое решениею
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



1. ID заказчика может быть нужен как некий код, который будет известен и заказчику и пользователям системы. Это не исключает необходимости в уникальном ключе для хранения данных о заказчиках в БД.
2. Адрес и телефон скорее всего будут отдельными классами (или классом?), просто потому что у заказчика может быть больше чем один адрес (офиса, доставки, склада, юридический и пр.), и уж конечно больше чем один телефон. А как же про адрес электронной почты? А другие способы связи, типа skype, не понадобятся? Можно все эти виды контактной информации обобщить в один класс с указанием типа связи.



1. Всегда есть ID для разработчиков (присваивается автоматом счетчиками базы данных) и какой нибудь номер, который создается прикладной системой, по настройкам пользователей. Поэтому ID в диаграммах не описываем.
2. Смотря для каких целей система проектируется, но адрес чаще как отдельный класс (потому что есть всякие справочники КЛАДР). Телефон себя изжил. Используются атрибут "контакты для связи" -раб.телефон, аська, почта и т.д. 



lnew
Цитировать
В каждом отдельном случае решение может быть разным. Нельзя говорить, что что-то является правильным или неправильным!
Благодарю за очень ясный комментарий!Теперь понимаю, что все это- очень гибкая структура.

Alfia
Цитировать
Это не исключает необходимости в уникальном ключе для хранения данных о заказчиках в БД
Правильно ли я понял, что в диаграмме классов вы имеете ввиду можно как и использовать id, так и не использовать. (нужно смотреть по обстоятельствам) ?
Насчет БД, да, вы правы. ID обязательно необходимо отразить

Цитировать
А как же про адрес электронной почты? А другие способы связи, типа skype, не понадобятся?
Спасибо за данное замечание! Я совсем упустил данные атрибуты из виду.

Elf
Цитировать
1.Всегда есть ID для разработчиков (присваивается автоматом счетчиками базы данных)
Правильно ли я понял, что ID можно не отражать в диаграмме классов, т.к он будет все равно указан на этапе проектирования БД ? (то есть указание id более разумно указать именно при проектировании БД, т.о не перегружая диаграмму классов)

Цитировать
Используются атрибут "контакты для связи" -раб.телефон, аська, почта и т.д.
Вы наверное имели ввиду не атрибут, а класс "контакты для связи"? Очень ценная мысль!Большое спасибо за подсказку




Если на ID не заточен какой-нибудь прикладной функционал, то не указывайте. 



Согласна с Elf. Я это и пыталась сказать. Дмитрий, Вам надо выяснить, нужен ли для заказчика какой-то уникальный код (ID), который будет виден и использоваться пользователями системы. Например, этот код заказчика можно будет печатать на счетах фактурах рядом с названием заказчика. Наличие такого кода может облегчить поиск заказчика в системе. Если нет, то ID для этого класса указывать на диаграмме классов не нужно.



Добавлю от себя пару слов.

ID в практике использования в англоязычных странах (америке) всегда обозначало ИНДЕНТИФИКАТОР.  Идентифиактор - то, что однозначно определяет объект, сущность, вещь и т.п. Однако идентификатор может быть разным - число, строка, символ и т.п.

В реляционных БД, он обозначает первичный ключ и делает каждую запись уникальной. В объектной парадигме - это неотъемлемое свойство объекта. Каждый объект уникален. Достигается это внутренним механизмом ОС или ЯП, называется OID и подобно.

Подозреваю, что Ваш ID рудимент реляционной БД, то, что мы часто называем суррогатным ключом. В ООП для передачи того, что какой-то атрибут идентифицирует объект класса обычно используют квалификатор, который суть уникальный ключ.



Да, все правильно, есть первичный ключ ID для базы данных, есть а-ля (суррогатный и т .д.) ID для использования в качестве идентификатора в прикладной системе. Но я имела в виду, что бывает и такое что первичный ID иногда тоже могут использовать в прикладной ситеме. Например, для определения версионности записи - чем больше ID, тем выше версия записи. Это делается для сохранения истории изменения. И тогда такой первичный ключ может и нужно указывать в классах. Но опять же такой ID нужен только для разработчиков.   



Видимо у меня в голове произошло смешение классов и БД, что и запутало меня. Хотя на самом деле- это две разные плоскости
Благодарю за пояснение :)




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19