Файл: Лаб. занятие № 6+.doc

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

Вопрос 1. Принципы создания модели предметной области

Имена и модели: стратегия построения карт

Типичная ошибка при выделении концептуальных классов

Необходимость спецификаций или описание концептуальных классов

Когда требуются понятия-спецификации

Пример: модель предметной области POS-системы ТТ

Концептуальные классы

Модели предметной области и декомпозиция

Концептуальные классы предметной области торговли

Идентификация концептуальных классов

Стратегии идентификации концептуальных классов

Использование списка категорий концептуальных классов

Определение концептуальных классов с помощью выявления существительных

Кандидатуры на роль концептуальных классов для предметной области торговли

Пример рассуждения: включать ли понятие "товарный чек" в модель

Поиск ассоциаций

Система обозначений для ассоциаций языка UML

Поиск ассоциаций: список стандартных ассоциаций

Ассоциации с высоким приоритетом

Рекомендации по назначению ассоциаций

Роли

Кратность

Имена ассоциаций

Несколько ассоциаций между двумя типами

Ассоциации для предметной области POS-системы ТТ

Отношения в магазине, которые должны быть учтены

Использование списка категорий ассоциаций

Модель предметной области POS-системы ТТ

Сохранение только важных ассоциаций

Модель предметной области: добавление атрибутов

Атрибуты

Система обозначений атрибутов в языке UML

Типы данных

Непримитивные типы классов

Совет разработчикам: не используйте атрибуты в качестве внешних ключей

Моделирование атрибутов Quantity и Unit

Атрибуты модели предметной области системы ТТ

Атрибуты помещаются во второй раздел условного обозначения класса (рис. 2.7). Дополнительно может быть указан также тип атрибута.

Рисунок 2.7 – Класс и его атрибуты

Корректные типы атрибутов

Некоторые сущности гораздо удобнее представлять не в виде атрибутов, а в фор­ме ассоциаций. Изучению корректных атрибутов и посвящен данный подвопрос.

Атрибуты должны быть простыми

Типы большинства простых атрибутов зачастую рассматриваются как при­митивные типы данных. Обычно тип атрибута не должен быть сложным поняти­ем предметной области, таким как Sale (Продажа). На­пример, атрибут currentRegister класса Cashier (Кассир) лучше не использо­вать (рис. 2.8), поскольку он имеет тип Register, не являющийся простым типом атрибута (таким, как Number (Число) или String (Строка)). Если объект Cashier использует объект Register, то лучше всего выразить этот факт с по­мощью ассоциации, а не атрибута.

В модели предметной области атрибуты должны быть простыми атрибутами (simple attributes) или простыми типами данных (data types).

К стандартным типам атрибутов относятся Boolean, Date, Number, String(Text), Time.

Другими стандартными типами являются следующие: Address (адрес), Color (цвет), Geometries (Point, Rectangle) (геометрические фигуры: точка, прямо­угольник), Phone Number (номер телефона), Social Security Number (номер страхового полиса), Universal Product Code (UPC) (универсальный код товара), SKU, ZIP или postal code (почтовый индекс), перечисляемые типы.

Рисунок 2.8 – Связь с помощью ассоциаций, а не атрибутов

Как видно из приведенного примера, стандартной ошибкой является моде­лирование сложного понятия предметной области в форме атрибута. Другими словами, аэропорт назначения на самом деле является не простой, а сложной сущностью с территорией, протянувшейся на многие километры. Таким образом, объект Flight (Полет) должен быть связан с объектом Airport (Аэропорт) с помощью ассоциации, а не атрибута (рис. 2.9).

Связывайте концептуальные классы с использованием ассоциаций, а не атрибутов.

Рисунок 2.9 – Пример представления сложных по­нятий предметной области в виде ассоциации, а не атрибутов

Типы данных

Атрибутами должны быть данные простых типов (или в терминах UML ти­пов данных – data types), для которых совершенно незначимой является уни­кальная тождественность (в контексте модели или системы).

Например, обычно не существует различия между:

  • отдельными экземплярами числа 5 (тип Number);

  • отдельными экземплярами строк 'cat' (тип String);

  • отдельными объектами PhoneNumber, содержащими один и тот же номер телефона;

  • отдельными объектами Address, содержащими один и тот же адрес.

Однако существенными являются различия между двумя отдельными объ­ектами Person (Человек), даже если в обоих объектах содержится имя "Jill Smith", поскольку два экземпляра могут представлять отдельных людей с одним и тем же именем.

В терминах программных систем существует несколько случаев, когда нет необходимости сравнивать адреса памяти экземпляров объектов Number, String, PhoneNumber или Address, достаточно лишь выполнить сравнение их значений. Однако для того чтобы различить объекты Person, даже если они имеют одина­ковые значения атрибутов, все же придется сравнить адреса памяти, поскольку в данном случае важна их уникальность.


Таким образом, все простые типы (числа, строки) считаются типами данных UML, однако не все типы данных являются простыми. Например, PhoneNumber (Номер телефона) – это не простой (или не примитивный) тип данных.

Данные простых типов называются также объектами значений (value objects).

Сущность данных простых типов трудноуловима. Для стандартной провер­ки "простоты" руководствуйтесь следующим правилом: если атрибут можно рас­сматривать как число, строку, логическое значение, дату или время (и т.д.), то следует оставить его в качестве атрибута; в противном случае его нужно пред­ставить отдельным концептуальным классом.

Если у вас имеются какие-либо сомнения, то лучше создайте отдельный кон­цептуальный класс, а не атрибут.

Непримитивные типы классов

Тип атрибута может рассматриваться как непримитивный класс в его собствен­ном значении в модели предметной области.

Например, в POS-системе имеется универсальный идентификатор товара. Обычно он рассматривается как простое число. Что же должно быть представлено как непримитивный класс? Руково­дствуйтесь следующими рекомендациями.

Тип данных, изначально считающийся примитивным (такой, как число или стро­ка), может быть представлен в виде непримитивного класса в следующих случаях:

  • Если он составлен из отдельных частей;

  • Номер телефона, имя человека;

  • Если с этим типом обычно ассоциируются операции, такие как синтакси­ческий анализ и проверка;

  • Номер страхового полиса;

  • Он содержит другие атрибуты;

  • Для льготной цены могут устанавливаться сроки действия (начало и конец);

  • Если этот тип используется для задания количества с единицами измерения;

  • Стоимость товара измеряется в некоторых единицах;

  • Это абстракция одного или нескольких типов;

  • Идентификатор товара – это некое обобщение типов UPC (Universal Product Code) и EAN (European Article Number).

Применение этих рекомендаций к атрибутам модели предметной области POS-системы приведет к формулировке следующих идей:

  • Идентификатор товара – это абстракция, построенная на основе различных стандартных схем кодирования, включая UPC-A, UPC-E и семейство схем EAN. Эти схемы кодирования могут использоваться при подсчете контрольной суммы или иметь другие атрибуты (например, код изготовителя, товара, страны). Сле­довательно, это должен быть непримитивный класс ItemID.

  • Атрибуты price (цена) и amount (сумма) должны иметь тип Quantity (Количество) или Money (Валюта), поскольку они представляют собой коли­чество, выраженное в денежных единицах.

  • Атрибут address (адрес) должен относиться к непримитивному типу Ad­dress, поскольку в нем имеются отдельные разделы.

Классы ItemID, Address и Quantity относятся к данным простых типов (уникальная тождественность является несущественной), так что их без проблем можно помещать в раздел атрибутов, а не связывать с использованием ассоциаций.


Совет разработчикам: не используйте атрибуты в качестве внешних ключей

Атрибуты не должны использоваться для связи концептуальных классов в моде­ли предметной области. Наиболее распространенным нарушением этого принци­па является добавление некоторой разновидности атрибута внешнего ключа (foreign key attribute), что обычно происходит при разработке реляционных баз данных. Например, на рис. 2.10 атрибут currentRegisterNumber использовать нежелательно, поскольку его назначением является связывание объекта Cashier с объектом Register. Объекты Cashier и Register лучше связать с помощью ассоциации, а не атрибута внешнего ключа. Не лишним будет повторить еще раз: связывайте типы с помощью ассоциаций, а не атрибутов.

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


Рисунок 2.10 – Не используйте атрибуты в качестве внешних ключей

Моделирование атрибутов Quantity и Unit

Большинство количественных сущностей нельзя представить в виде числовых типов данных. Например, цена или скорость. С этими количественны­ми сущностями связаны определенные единицы измерения, необходимые для поддержки функций конвертирования. Программная система ТТ предна­значена для использования в различных странах, поэтому она должна поддер­живать различные типы валют.

Решение заключается в создании отдельного концептуального класса Quantity (Количество), с которым будет ассоциировать­ся класс Unit (Единица измерения). Поскольку количество рассматривается в качестве типа данных, соответствующий атрибут можно поместить в раздел атрибутов, как показано на рис. 2.11. Обычно количество измеряют в некоторых единицах. Деньги – это количество, единицей измерения которого служит тип валюты. Вес – это количество, измеряемое в килограммах или фунтах.

Рисунок 2.11 – Моделирование количества

Атрибуты модели предметной области системы ТТ

Теперь необходимо сформировать список атрибутов для отображения требо­ваний данной итерации или список атрибутов для сценариев прецедента Оформление продажи.

Таблица 2.2 – Список атрибутов для прецедента

Sale (Продажа)


date (дата), time (время). Товарный чек представляет собой распечатанные на бумаге данные о продаже. Как правило, на не также указываются дата и время продажи


Payment (Платеж)


amount (сумма). Если нужно определить, достаточную ли сумму заплатил покупатель, и вычислить разность между этой суммой и стоимостью покупок, необходи­мо иметь атрибут amount (известный также как "предложенная сумма")


Product Specification (Спецификация товара)


description (описание). Оказывается полезным, если описание товара нужно отобразить на экране или распечатать на товарном чеке

id (идентификатор товара). Если необходимо про­смотреть данные объекта ProductSpecification, соответствующего введенному значению кода

itemID, то эту связь можно обеспечить с помощью данного атрибута

price (цена). Необходим для вычисления итоговой суммы и отображения цены единицы товара


SalesLineItem (Элемент продажи)


quantity (количество). Требуется для записи введен­ного количества товаров, если покупатель приобретает несколько единиц одного и того же товара (например, пять коробок конфет)


Store (Магазин)

address (адрес), name (название). На товарном чеке требуется указывать название и адрес магазина




Тогда модель предметной области с атрибутами будет иметь вид согласно рис. 2.13 и 2.14.

Рисунок 2.13 – Модель предметной области с атрибутами


Рисунок 2.14 – Фрагмент модели предметной области


Задание на самостоятельную работу (для выбранной темы индивидуального проекта):

  1. построить модель предметной области.




















































1 Прецеденты — это важные артефакты этапа анализа требований, но на самом деле они не являются объектно-ориентированными. Они концентрируют внимание разработ­чиков на процессах, происходящих в предметной области.

19