Описание каждого атрибута
В некоторых случаях к модели можно добавить дескриптивную информацию о каждом атрибуте.
Однако важнее всего выбрать для них подходящие имена, обеспечивающие максимально эффективные связи. Удачно выбранное имя полезнее массы слов. (Если возникает потребность в длинном описании атрибута, нужно найти для него более подходящее имя.)
Разумеется, можно добавить описания атрибутов с тем, чтобы более полно показать суть каждого из них.
|
#58. Стратегия "Описание атрибутов по шаблону" |
|
• Опишите каждый атрибут, используя шаблон. описание допустимые значения (область действия, предел, нумерация значений) единица измерения тип данных устойчивость требуемый (да или нет) получить/установить ограничения как получить значение по умолчанию из другого источника, когда специальное значение неизвестно применимые состояния (для атрибутов, зависящих от состояния) коды ссылок на предшествующую документацию, если такая существует |
Можно дать описание на обычном языке, формальном языке спецификации (типа Object-Z) или даже использовать синтаксис языка программирования.
Вы вполне можете выработать навык составления коротких описаний и при этом даже находить новые атрибуты и службы.
Составим описания атрибутов объекта item.
Начнем с номера и описания:
номер: уникальный идентификационный номер, который Xназначает сама
требуемый: да
описание: имя экземпляра товара (возможно, его фабричная марка)
требуемый: да
длина=20 символов
обложение налогом: указание на то, облагается товар налогом или нет
нумерация значений: да или нет
по умолчанию: да
|
#61. Стратегия "Атрибут типа да/нет" |
|
• Атрибут может иметь значения "да" или "нет". Само имя атрибута может быть значением имени другого атрибута. Пример: облагается налогом (да или нет); изменение налогового статуса (облагается налогом, освобожден от налогов, распродается). Заблаговременное добавление деталей облегчает внесение изменений в будущем. |
"Облагаемый налогом" — это атрибут типа "да/нет", т.е. он имеет значение "да" или "нет".
Рассмотрим его более подробно. "Облагаемый налогом" — это имя значения: экземпляр товара - может быть "облагаемым налогом" и "не облагаемым налогом". Использование значения в качестве имени атрибута нецелесообразно и, более того, это далеко не лучший способ действий. При получении новых значений возникает проблема — объектная модель становится излишне сложной.
Вспомните свое последнее посещение магазина. Разве все товары облагаются налогом по одной и той же ставке? Или специальные налоги относятся к конкретной категории товаров?
Некоторые категории товаров облагаются налогом, другие — нет. В действительности объекту item нужно знать свою категорию налогообложения, а не то, облагается ли он вообще налогом или нет. Такая "необходимость знать" моделируется объектной связью с категорией налогообложения.
Подробное рассмотрение каждого атрибута приносит свои плоды, а составление его описания позволяет вникнуть в его детали. После дополнительного анализа объект item можно изобразить, как показано на рис. 1.27.
Рис.1. 27. Экземпляр товара: «что я знаю»
Б. Определение обязанностей: "кого я знаю"
Объект item знает:
— UPC (ни одного, один или несколько);
— цену (ни одной, одну или несколько);
— категорию налогообложения (ни одной, одну или несколько);
— экземпляр строки продажи (ни одного, один или несколько). Объекты UPC, цены и категории налогообложения знают свои экземпляры товара. Экземпляр строки продажи знает свой экземпляр товара (рис.1. 28).
Рис.1. 28. Экземпляр товара: «что я зною, кого я знаю. что я делаю»
В. Определение обязанностей: "что я делаю".
Зачем нужна абстракция, подобная объекту item? Для ее введения есть важная причина — отражение динамики системы. Данный объект — нечто большее, чем просто носитель данных. Чтобы понять назначение этого объекта, снова применим стратегию "сделай сам".
|
#86. Стратегия "Сделай сам" |
|
• Это аспект возникающего объекта программного обеспечения: "Я знаю другие объекты, связанные с реальным объектом, абстракцией которого я являюсь". • "Сделай сам" включает в себя атрибуты и службы, работающие с ними, что приводит к ослаблению соединения (coupling) и усилению связности (cohesion). • При построении моделирующей системы объект программного обеспечения будет имитировать действия реального объекта. В большинстве систем полная имитация не производится: объекты программного обеспечения делают то, что обязана делать система по отношению к конкретному объекту. |
Пусть абстракция экземпляра товара:
— получает цену для конкретной даты;
— определяет количество экземпляров товара-
Теперь можно запросить цену. Запрею количества — тоже хороший повод инкапсулировать зависящую цену экземпляра товара.
Добавим обязанности объекта item к объектной модели (рис.1. 28).