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

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

• id
• Фамилия
• Имя
• Адрес
• Телефон

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

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

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

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

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

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

Если Вы студент, разъясните преподавателю, почему Вы приняли то или другое решениею

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 нужен только для разработчиков.   

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