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

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

СОДЕРЖАНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роли

Кратность

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

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

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

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

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

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

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

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

Атрибуты

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

Типы данных

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

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

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

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

Для ответа на этот вопрос необходимо учитывать следующие факторы.

  • Товарный чек – это своеобразный отчет о сделанной покупке. В принципе, в модель предметной области не следует включать объекты отчета, по­скольку вся содержащаяся в них информация получена из других источни­ков. Это является одной из причин исключения понятия "чек" из модели предметной области.

  • Товарный чек выполняет конкретную роль при реализации бизнес-правил: обычно он обеспечивает право на возврат товара. Этот фактор говорит в пользу включения товарного чека в модель предметной области.

Поскольку возврат товара не рассматривается на данной итерации разра­ботки, понятие 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 (время).

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