ВУЗ: Пермская государственная сельскохозяйственная академия имени академика Д. Н. Прянишникова
Категория: Методичка
Дисциплина: Проектирование информационных систем
Добавлен: 18.10.2018
Просмотров: 2253
Скачиваний: 27
СОДЕРЖАНИЕ
ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
Вопрос 1. Принципы создания модели предметной области
Имена и модели: стратегия построения карт
Типичная ошибка при выделении концептуальных классов
Необходимость спецификаций или описание концептуальных классов
Когда требуются понятия-спецификации
Пример: модель предметной области POS-системы ТТ
Модели предметной области и декомпозиция
Концептуальные классы предметной области торговли
Идентификация концептуальных классов
Стратегии идентификации концептуальных классов
Использование списка категорий концептуальных классов
Определение концептуальных классов с помощью выявления существительных
Кандидатуры на роль концептуальных классов для предметной области торговли
Пример рассуждения: включать ли понятие "товарный чек" в модель
Система обозначений для ассоциаций языка UML
Поиск ассоциаций: список стандартных ассоциаций
Ассоциации с высоким приоритетом
Рекомендации по назначению ассоциаций
Несколько ассоциаций между двумя типами
Ассоциации для предметной области POS-системы ТТ
Отношения в магазине, которые должны быть учтены
Использование списка категорий ассоциаций
Модель предметной области POS-системы ТТ
Сохранение только важных ассоциаций
Модель предметной области: добавление атрибутов
Система обозначений атрибутов в языке UML
Совет разработчикам: не используйте атрибуты в качестве внешних ключей
Для ответа на этот вопрос необходимо учитывать следующие факторы.
-
Товарный чек – это своеобразный отчет о сделанной покупке. В принципе, в модель предметной области не следует включать объекты отчета, поскольку вся содержащаяся в них информация получена из других источников. Это является одной из причин исключения понятия "чек" из модели предметной области.
-
Товарный чек выполняет конкретную роль при реализации бизнес-правил: обычно он обеспечивает право на возврат товара. Этот фактор говорит в пользу включения товарного чека в модель предметной области.
Поскольку возврат товара не рассматривается на данной итерации разработки, понятие Receipt (Товарный чек) не включается в модель предметной области. Оно будет включено в модель системы на той итерации разработки, на которой будет реализовываться прецедент Возврат товара.
Вопрос 2. Модель предметной области: добавление ассоциаций и атрибутов
В процессе разработки модели предметной области необходимо идентифицировать связи (ассоциации) между концептуальными классами, удовлетворяющие информационным требованиям разрабатываемых на текущей итерации сценариев, а также выделить те из них, которые способствуют лучшему пониманию модели предметной области.
Ассоциация (association) – это связь между типами (или точнее, экземплярами типов), отражающая некоторое значимое и полезное отношение между ними (рис. 2.1).
В языке UML ассоциации описываются как "семантические взаимосвязи между двумя или несколькими классификаторами и их экземплярами".
Рисунок 2.1 – Ассоциации
Поиск ассоциаций
Заслуживающие внимания ассоциации обычно содержат знания о взаимосвязи между объектами, которые должны сохраняться в течение некоторого периода. Этот период может измеряться в миллисекундах или годах в зависимости от конкретного контекста.
Другими словами, о связи между какими объектами нужно помнить?
Например, нужно ли помнить о том, что экземпляры объекта SalesLineItem (Элемент продажи) ассоциированы с экземпляром объекта Sale (Продажа)? Очевидно да, поскольку в противном случае будет невозможно восстановить данные о продаже, распечатать товарный чек или вычислить итоговую сумму.
В модель предметной области целесообразно включать следующие ассоциации:
-
ассоциации, знания о которых нужно сохранять в течение некоторого периода (важные ассоциации);
-
ассоциации, производные от содержащихся в списке стандартных ассоциаций.
Это важный момент. Если в модели предметной области содержится N различных концептуальных классов, то между ними можно установить N*(N-1) ассоциацию, а это может быть достаточно большое число. Многие линии связей такой диаграммы будут просто вносить визуальный «шум» и ухудшать ее наглядность. Поэтому при добавлении ассоциаций нужно придерживаться принципа минимализма. Критерии необходимости ассоциаций будут предложены ниже.
Система обозначений для ассоциаций языка UML
Ассоциация обозначается проведенной между классами линией, с которой связано определенное имя. Обычно ассоциация является двунаправленной. Это означает, что от одного объекта любого типа возможен логический переход к другому объекту. Такой переход является абсолютно абстрактным. Он не определяет тип взаимосвязей между программными сущностями.
На концах линии, которая обозначает ассоциацию, могут содержаться выражения, определяющие количественную связь между экземплярами классов.
Дополнительная стрелка рядом с именем ассоциации указывает, в каком направлении нужно читать ее имя. Она не определяет направление видимости или перемещения.
Если такая стрелка отсутствует, то имена ассоциаций следует читать с использованием общепринятых соглашений, а именно – слева направо и сверху вниз. Однако в языке UML в явной форме это правило отсутствует (рис. 2.2).
Рисунок 2.2 – Система обозначения ассоциаций в языке UML
Поиск ассоциаций: список стандартных ассоциаций
Добавим ассоциации с помощью списка, представленного в табл. 2.1. В нем указаны стандартные категории, которыми обычно не следует пренебрегать. Примеры ассоциаций взяты из предметной области розничной торговли и авиалиний.
Таблица 2.1 – Список стандартных ассоциаций
Категория |
Примеры |
А является физической частью В |
Drawer-Register (Устройство печати торговых чеков-Реестр) |
А является логической частью В |
SalesLineItem-Sale (Элемент продажи-Продажа) |
А физически содержится в/на В |
Register-Store (Реестр-Магазин), item-shelf (Товар-Полка) |
А логически содержится в В |
itemDescription-Catalog (Описание товара-Каталог) |
А является описанием В |
itemDescription-item (Описание товара-Товар) |
А является элементом транзакции или отчета В |
SalesLineItem-Sale (Элемент продажи-Продажа) |
А известен/ зарегистрирован/ записан/включен в В |
Sale-Register(Продажа-Реестр) |
А является членом В |
Cashier-Store (Кассир-Магазин) |
А является организационной единицей В |
Department-Store (Отдел-Магазин) |
А использует или управляет В |
Cashier-Register (Кассир-Реестр) |
А взаимодействует с В |
Customer-Cashier (Покупатель-Кассир) |
А связан с транзакцией В |
Customer-Payment (Покупатель-Платеж) |
А является транзакцией, которая связана с другой транзакцией В |
Payment-Sale (Платеж-Продажа) |
А следует за В |
salesLineitem-SalesLineitem (Наименование товара-Следующее наименование товара) |
А является "собственностью" В |
Register-Store (Реестр-Магазин) |
А является событием, связанным с В |
Sale-customer (Продажа-Покупатель), Sale-Store (Продажа-Магазин) |
Ассоциации с высоким приоритетом
В приведенной таблице имеются категории ассоциаций с высоким приоритетом, которые чрезвычайно полезно включать в модель предметной области:
-
А является физической (physical) или логической (logical) частью В;
-
А физически или логически содержится в/на В;
-
А записан (recorded) в В.
Рекомендации по назначению ассоциаций
-
Основное внимание нужно уделить тем ассоциациям, знания о которых нужно сохранять в течение некоторого периода (важным ассоциациям).
-
Гораздо важнее определить концептуальные классы, чем выделить ассоциации.
-
Слишком большое количество ассоциаций приводит к ошибкам в модели предметной области, а не к ее упрощению. Изучение ассоциаций не должно отнимать слишком много времени и вместе с тем должно приносить максимальную пользу.
-
Следует избегать отображения избыточных или не имеющих самостоятельного значения ассоциаций.
Роли
Каждый конец ассоциации называется ролью (role). Роль дополнительно может иметь следующие характеристики: имя, кратность, направление связи.
Кратность
Кратность (multiplicity) определяет, сколько экземпляров класса А может быть ассоциировано с одним экземпляром класса В (рис. 2.3).
Рисунок 2.3 – Кратность ассоциации
Например, один экземпляр класса Store (Магазин) может быть ассоциирован с несколькими (ни с одним или с несколькими, что отображается символом *) экземплярами класса Item.
Значение кратности определяет, сколько экземпляров одного класса может быть корректно связано с экземпляром другого класса в некоторый конкретный момент, а не на всем промежутке времени.
Имена ассоциаций
Имена ассоциаций базируются на формате ИмяТипа-ГлагольнаяФраза-ИмяТипа, где глагольная фраза представляет собой последовательность, которая читается и является значимой в контексте модели.
Имена ассоциаций должны начинаться с прописной буквы, т.к. ассоциация обычно представляет классификатор связей между экземплярами. В языке UML имя классификатора начинается с прописной буквы. Для имен ассоциаций принято использовать два формата:
-
Paid-by (с дефисом)
-
PaidBy (без дефиса)
На рис. 2.4 при чтении имен ассоциаций используется направление, принятое по умолчанию, а именно – слева направо и сверху вниз. Это правило относится не только к языку UML, а является относительно стандартным.
Рисунок 2.4 – Имена ассоциаций
Несколько ассоциаций между двумя типами
Между двумя типами может быть установлено несколько ассоциаций. В рассматриваемой нами POS-системе нет соответствующего примера, однако из предметной области системы управления полетами в качестве подобного примера можно привести отношение между объектами Flight (Полет) и Airport (Аэропорт) (рис. 2.5). Ассоциации Flies-to (Летит в) и Flies-from (Летит из) являются принципиально различными и должны отображаться отдельно.
Рисунок 2.5 – Несколько ассоциаций
Ассоциации для предметной области POS-системы ТТ
Теперь приступим к добавлению ассоциаций в модель предметной области рассматриваемой POS-системы. Требуется добавить те ассоциации, которые должны сохраняться согласно определенным требованиям (например, прецедентам), или те, которые вытекают из нашего представления о предметной области. При решении новой проблемы должны быть пересмотрены и проанализированы ранее определенные стандартные категории ассоциаций, поскольку они представляют многие из актуальных ассоциаций, которые обычно следует учитывать.
Отношения в магазине, которые должны быть учтены
Важными являются следующие ассоциации. Они основываются на описанных выше прецедентах:
Register Records Sale (Register Фиксирует Sale) |
Для того чтобы получить информацию о текущей продаже, необходимо вычислить общую сумму покупки и напечатать чек |
Sale Paid-by Payment (Sale Оплачивается посредством Payment) |
Чтобы узнать, была ли оплачена покупка, необходимо сравнить внесенную сумму с общей стоимостью покупки и напечатать чек |
ProductCatalog Records ProductSpecification(ProductCatalog Записывает ProductSpecification) |
Чтобы получить спецификацию товара ProductSpecification, необходимо знать его идентификатор itemID |
Использование списка категорий ассоциаций
Проанализируем список категорий ассоциаций, основываясь на ранее идентифицированных типах и учитывая требования разрабатываемых на данной итерации прецедентов.
Категория |
Примеры |
А является физической частью В |
Register-CashDrawer |
А является логической частью В |
SalesLineItern-Sale |
А физически содержится в/на В |
Register-Store Item-Store |
А логически содержится в В |
Product Speci£ication-ProductCatalog ProductCatalog-Store |
А является описанием В |
Product Specification-1 tern |
А является элементом транзакции или отчета В |
SalesLineItern-Sale |
А известен/зарегистрирован/записан/ включен в В |
(Совершенные покупки) Sales-Store (Текущая продажа) Sale-Register |
А является членом В |
Cashier-Store |
А является организационной единицей В |
Не применяется |
А использует или управляет В |
Cashier-Register Manager-Register Manager-Cashier; однако, ВОЗМОЖНО, не применяется |
А взаимодействует с В |
Customer-Cashier (Покупатель-Кассир) |
А связан с транзакцией В |
Customer-Payment Cashier-Payment |
А является транзакцией, которая связана с другой транзакцией В |
Payment-Sale (Платеж-Продажа) |
А следует за В |
SalesLineItem-SalesLineItem |
А является "собственностью" В |
Register-Store |
Модель предметной области POS-системы ТТ
В показанной на рис. 2.6 модели предметной области представлен набор концептуальных классов и ассоциаций, являющихся кандидатами на включение в POS-приложение. Ассоциации предварительно были выбраны из списка ассоциаций-кандидатов.
Рисунок 2.6 – Фрагмент модели предметной области
Сохранение только важных ассоциаций
Ассоциации, представленные в модели предметной области на рис. 2.6, были, по существу, механически выбраны из списка ассоциаций. Однако при включении ассоциаций в модель предметной области желательно быть более избирательным. Не стоит перегружать модель предметной области ассоциациями, которые не требуются наверняка или не отражают результатов исследования предметной области.
Из приведенных выше рекомендаций по выбору ассоциаций следует, что не каждая из представленных ассоциаций является необходимой.
Ассоциация |
Описание |
Sale Entered-by Cashier (Sale Вводится Cashier) |
Требования не отражают необходимости хранить или записывать информацию о кассире. Кроме того, эта ассоциация напрямую следует из ассоциации Register used-by Cashier (Register Используется Cashier) |
Register Used-by Cashier (Register Используется Cashier) |
Требования не отражают необходимости хранить или записывать информацию о кассире |
Register Started-by Manager (Register Запускается Manager) |
Требования не отражают необходимости хранить или записывать информацию о менеджере, запустившем систему |
Sale Initiated-by Customer (Sale Инициируется Customer) |
Требования не отражают необходимости хранить или записывать информацию о текущем покупателе, инициировавшем продажу |
Store Stocks Item (Store Хранит Item) |
Требования не отражают необходимости хранить или поддерживать информацию об инвентаризации |
SalesLineItem Records-sale-of Item (SalesLineItem Записывает-информацию-о-продаже Item) |
Требования не отражают необходимости хранить или поддерживать информацию об инвентаризации |
Обратите внимание, что размещение ассоциаций по степени важности зависит от требований. Внесение в них явных изменений, таких как требование наличия на товарном чеке идентификатора кассира, приведет к необходимости хранения данных о новой связи.
Основываясь на проведенном анализе, можно сказать, что эти ассоциации можно удалить.
Модель предметной области: добавление атрибутов
Необходимо идентифицировать атрибуты концептуальных классов, которые удовлетворяют информационным требованиям разрабатываемых в текущий момент сценариев.
Атрибуты
Атрибут (attribute) – это абстрактное свойство объекта.
В модель предметной области включаются те атрибуты, для которых определены соответствующие требования (например, прецеденты) или для которых необходимо хранить определенную информацию.
Например, в товарном чеке (представляющем собой отчет о некоторой продаже) обычно указываются дата и время. Эта информация необходима менеджерам компании. Следовательно, для концептуального класса Sale (Продажа) требуются атрибуты date (дата) и time (время).