Содержание:

Введение

Актуальность темы исследования. Моделирование предметной области является основой статической части модели UML. Построение модели предметной области начинается с выяв­ления абстракций, существующих в реальном мире, то есть тех основных концептуальных объектов, которые встречаются в системе. При проектиро­вании объектно-ориентированного программного обеспечения вы стреми­тесь структурировать программу так, чтобы в центре оказались именно эти объекты из пространства задачи. Это делается потому, что требования к про­грамме меняются намного быстрее, чем реальный мир. Основой объектного моделирования вообще и статического моделирования в частности как раз и является создание модели этих абстракций из предметной области.

Обоснование теоретической и практической важности выбранной для исследования проблемы. Возможно, у вас возник вопрос, почему данная глава предшествует об­суждению прецедентов. Дело в том, что, приступая к их записи, мы не собирались излагать прецеденты с чисто пользовательской точки зре­ния. Вместо этого мы будем формулировать их в контексте объектной мо­дели. Это позволит связать статические и динамические части модели, что очень важно, если мы хотим заниматься проектированием на базе анализа прецедентов. Модель предметной области представляет словарь терминов, которым авторы прецедентов могут пользоваться на более поздних этапах.

Цель исследования – разработка моделирование предметной области «Учет товаров» с помощью UML.

Задачи исследования:

1. Провести описание предметной области
2. Проанализировать средства для моделирования бизнес-процессов

3. Разработать мероприятия по улучшению бизнес-процессов.

ГЛАВА 1. МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Описание предметной области. Постановка задачи

При моделировании предметной области мы будем следовать методи­ке ОМТ (Object Modeling Technique), которой свойственна направлен­ность изнутри наружу. Это означает, что мы начинаем с ключевых объек­тов в системе, а затем движемся наружу, изучая, с какими еще объектами они взаимодействуют. Таким образом, при выявлении прецедентов или динамической части системы мы продвигаемся снаружи внутрь, а при соз­дании статической модели - изнутри наружу. Секрет в том, чтобы, двигаясь одновременно в обоих направлениях, встретиться посередине, не оставив никакого разрыва. Когда речь пойдет об анализе пригодности и диаграммах последовательности, мы увидим, как это делается. А пока запомните, что моделирование предметной области и статическое моделирование - это взгляд на систему изнутри наружу^[1].

Рисунок 1. Процесс ICONIX

На рисунке 1 показано, какое место моделирование предметной области за­нимает в общей картине процесса ICONIX.

1.2 Выбор средства для моделирования бизнес-процессов

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

Лучшими источниками классов, по-видимому, являются высокоуров­невое описание задачи, низкоуровневые требования и экспертная оценка задачи. Начните с выписывания максимально возможного числа предло­жений из этих источников (не забывая и о других, например о литературе по маркетингу), а затем обведите или подчеркните все существительные и именные группы. Шансы на то, что таким образом вы найдете почти все Важные доменные объекты (классы), весьма велики^[2].

По мере уточнения этого перечня должно происходить следующее:

• имена существительные и именные группы становятся объектами и атрибутами;
• глаголы и глагольные группы становятся операциями и ассоциациями;
• родительный падеж показывает, что имя существительное должно быть атрибутом, а не объектом.

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

При построении диаграмм классов вы можете также принять предва­рительные решения об обобщениях (отношениях вида «является»). Если необходимо заниматься этим на ранней стадии проекта, можете построить даже несколько уровней обобщения. Ищите такие предложения в описа­нии задачи, которое содержит слова «является» или «представляет разно­видность». Этап моделирования предметной области - также подходящие момент для принятия решений об агрегировании (отношении вида «име­ет») классов.

В итоге модель предметной области, дополненная ассоциациями (статическими отношениями между парами классов), должна адекватно описывать аспекты задачи, не зависящие от времени (статические), и в этом напоминать диаграммы сущность – связь, применяемые в моделировании данных.

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

1.3 Моделирование бизнес-процессов «как есть»

Используйте отношения обобщение (generalization, is-a, «является») и агрегацию (aggregation, has-a, «имеет») для того, чтобы показать, как объекты соотносятся друг с другом^[3].

Например, Книга имеет Отзыв на книгу. Cчет на оплату и Банковская карта являются Способами оплаты.

Рисунок 2

Желательно размещать отношения слева направо и сверху вниз, как обычный текст. Это улучшит читаемость диаграмм.

1. Первоначальный набросок модели должен быть построен не больше, чем за пару часов.

Этот набросок все равно не будет идеальным и будет многократно изменен на следующих этапах, поэтому много времени на этом этапе тратить не стоит. Вся рассматриваемая методология основана на том, что модель предметной области неполна и требует постоянного уточнения. Для этого существуют специальные приемы.

Однако на этом этапе выявляются 80% всех понятий предметной области.

1. Нужно выделить ключевые абстракции и привязать к ним объекты предметной области.

Если ориентироваться на абстракции, то можно подготовиться к возможным изменениям в требованиях, которые обязательно произойдут, а когда это случится, модель сможет быть адаптирована к изменениям.

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

1. Нельзя путать объект (который является экземпляром сущности) с таблицей базы данных (в которой содержатся набор описаний экземпляров).

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

1. Нужно использовать модель предметной области как словарь проекта.

В этом словаре необходимо найти и исключить различные названия одних и тех же понятий.

1. Модель предметной области нужно построить до составления вариантов использования, чтобы избежать дублирования понятий.

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

1. Окончательная диаграмма классов может быть не похожа на диаграмму модели предметной области, хотя соответствие должно быть.

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

1. В модель предметной области нельзя помещать название экранов пользовательского интерфейса или другие классы, относящиеся к пользовательскому интерфейсу.

Если нарушить это правило, то модель сразу же переполнится разнообразными понятиями, не относящимися непосредственно к делу.

ГЛАВА 2. ИНТЕРНЕТ-МАГАЗИН ПО ПРОДАЖЕ КНИГ. ПОСТРОЕНИЕ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ В ПЕРВОМ ПРИБЛИЖЕНИИ НА ОСНОВЕ ТРЕБОВАНИЙ

2.1 Предлагаемые мероприятия по улучшению бизнес-процессов

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

Например, выделим сущности предметной области из следующих требований^[4].

1. Интернет-магазин должен иметь веб-интерфейс, но он должен иметь возможность подключения через другие интерфейсы (веб-сервисы и т.п.)
2. Интернет-магазин предназначен для продажи книг, с оплатой заказов через интернет.
3. Пользователь должен иметь возможность добавить книги в онлайн корзину, после чего произвести оплату.
   1. Пользователь может убрать предметы из корзины.
4. Пользователь должен иметь возможность вести списки желаемых покупок, т.е. книг, которые он хочет купить позже.
5. Пользователь должен иметь возможность отменить заказ до того, как он отправлен по почте.
6. Пользователь должен иметь возможность оплатить заказ кредитной картой или по счету на оплату.
7. Должна быть возможность вернуть книги.
8. Интернет-магазин должен встраиваться на сайты партнеров в виде мини-каталога, который составляется по основному каталогу, хранящемуся в центральной базе данных.
   1. Мини-каталог должен быть построен на основе XML для того, чтобы была возможность передавать его между системами.
   2. Система доставки по почте должна работать через почтового оператора.
9. Пользователь должен иметь возможность создать учетную запись клиента, чтобы система запоминала данные пользователя (имя, адрес, данные банковской карты и т.д.) и восстанавливала их при входе.
   1. Система должна вести основной список учетных записей в центральной базе данных.
   2. При входе пользователя его пароль должен сверяться с паролем в основном списке паролей, сохраненным в базе данных.
10. Пользователь должен иметь возможность искать книги различными способами поиска – по заголовку, по автору, ключевому слову или категории и после поиска просматривать детальное описание книги.
11. Пользователь должен иметь возможность оставлять отзывы на понравившиеся книги. Оставленные отзывы должны появляться в детальном описании книги. Отзыв должен включать выставленный клиентом рейтинг (1-5), который должен показываться вместе с заголовком книги в списке книг.
    1. Отзывы на книгу должны модерироваться, т.е. им должен присваиваться статус Ok кем-то из администраторов прежде, чем они появятся на сайте.
    2. Длинные отзывы должны обрезаться при выводе детального описания книги. Клиент может щелкнуть по отзыву, чтобы просмотреть полный отзыв на отдельной странице.
12. Должна быть возможность размещения администраторами редакторских отзывов. Они также должны появляться на странице с детальным описанием книги.
13. Интернет-магазин должен позволять сторонним продавцам (например, магазинам подержанных книг) добавлять свои каталоги книг в основной каталог книг, так чтобы книги этих продавцов присутствовали в результатах поиска.
14. Интернет-магазин должен быть масштабируем со следующими требованиями:
    1. Должна быть возможность управлять до 100 тыс. учетных записей пользователей за первые 6 месяцев работы и затем до 1 млн. пользователей.
    2. Должна быть возможность обслуживать одновременно 1000 посетителей (до 10000 тысяч после 6 месяцев)
    3. Система должна обслуживать 100 поисковых запросов в минуту (1 тыс./мин. после 6 месяцев)
    4. Система должна обслуживать 100 покупок в час (1 тыс./час после 6 мес.)

Эти требования – богатый источник для классов предметной области. Выделим существительные (в единственном числе) и связанные с ними слова.

Таблица 1

Автор	Корзина	Продавец
База данных	Кредитная карта	Редакторский отзыв
Детальное описание книги	Мини-каталог	Результат поиска
Заголовок	Оплата	Рейтинг
Заказ	Основной каталог	Система доставки по почте
Интернет	Основной каталог книг	Список желаемых покупок
Интернет-магазин	Основной список учетных записей	Список книг
Каталог книг	Отзыв	Список учетных записей
Категория	Отзыв на книгу	Способ поиска
Клиент	Партнер	Счет на оплату
Ключевое слово	Пользователь	Учетная запись клиента
Книга	Предмет	Учетная запись пользователя

В этом списке встречаются повторы, однако, их удаление – следующая задача. Некоторые из них не входят в предметную область, некоторые – только кажутся существительными.

Клиент и Учетная запись пользователя являются разными вещами. Данные учетной записи хранятся в базе данных, Клиент – это участник взаимодействия с системой (актер).

Клиент и Продавец – также участники и должны быть размещены на диаграммах вариантов использования.

Учетная запись клиента и учетная запись пользователя являются повторами. Оставим Учетную запись клиента.

Список учетных записей и Основной список учетных записей являются повторами. Оставим второй.

Отзыв на книгу и Отзыв означают одно и то же. Оставим Отзыв на книгу.

На термин Каталог у нас следующие кандидаты: Каталог книг, Список книг, Мини-каталог, Основной каталог книг. Каталог и список являются разными понятиями, поэтому если возникают сомнения, то нужно уточнять у заказчика^[5].

Понятия Основной каталог книг и Каталог книг дублируются. Основной каталог является противоположностью Мини-каталогу, поэтому их мы оставим. Список книг может описывать различные списки книг, поэтому мы пока его оставим, но вернемся к нему позже.

Из пары Основной каталог и Основной каталог книг оставим последнее, как более детально описывающее смысл.

Интернет – слишком общее понятие и ничего по существу к модели не добавляет.

Понятие Пароль – слишком маленькое, чтобы быть объектом и должно соответствовать элементу интерфейса, поэтому мы убираем его из модели. То же относится к Заголовку и Ключевому слову.

Еще повтор – это Книга и Детальное описание книги. Оставим Книгу, так как это более краткое название без потери смысла.

Слово Предмет слишком нечеткое, тем не менее, оно важно для нас, когда мы рассматриваем нечто, что пользователь может поместить в корзину. Мы его переименуем в Элемент (Line Item) и оставим в модели.

Магазин книг тоже слишком общее понятие.

В итоге, у нас остаются:

Таблица 2

Автор	Оплата	Система доставки по почте
База данных	Основной каталог книг	Список желаемых покупок
Заказ	Основной список учетных записей	Список книг
Категория	Отзыв на книгу	Способ поиска
Книга	Партнер	Счет на оплату
Корзина	Редакторский отзыв	Учетная запись клиента
Кредитная карта	Результат поиска	Элемент
Мини-каталог	Рейтинг

2.2 Моделирование бизнес-процессов «как должно быть»

На следующей диаграмме мы свяжем эти понятия вместе с помощью отношения has-a (агрегации). Понятно, что Элемент являются частью Корзины, но можно ли то же самое сказать об Оплате, которая является частью Заказа? Т.е. между ними скорее есть отношение принадлежности (агрегации), но не композиции.

В первом приближении модель предметной области выглядит так:

Рисунок 3. Черновая модель предметной области

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

Пусть в процессе анализа мы выделили два дополнительных объекта: История заказа и Диспетчер заказа. Этих понятий в требованиях не было, но из опыта можно сказать, что они должны присутствовать в хорошем интернет магазине. Обновленная диаграмма показана на рисунке 4, на котором новые классы показаны красным цветом.

Рисунок 4. Обновленная диаграмма

На этой же диаграмме отображены сущности, связанные с доставкой заказа и его отслеживанием (диспетчер).

Система доставки по почте пусть пока остается на диаграмме. Мы должны решить, является ли это понятие частью нашей системы или внешней системой. Внешние сущности должны быть изображены как участники взаимодействия (актеры).

Мы убрали Оплата, так как на самом деле это глагол, а не существительное, а также убрали Автора, так как это просто атрибут Книги.

Была некоторая неоднозначность с Основным каталогом книг. Мы убрали связь между Книгой и Основным каталогом книг и вместо этого добавили класс Каталог книг и присоединили Книгу к нему. Этим мы разрешили путаницу в отношениях. Мы решили, что Книга принадлежит Каталогу книг, а Каталог книг принадлежит Основному каталогу книг (то есть он у нас теперь каталог каталогов). Правда, у нас еще есть Мини-каталог. Яснее всего будет, если Книга будет принадлежать Каталогу книг, а различные разновидности каталогов мы введем с помощью обобщения ,которое мы осудим в следующем разделе.

Интернет-магазин по продаже книг. Построение отношений обобщения.

Отношение обобщения является обычным таксономическим отношением между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком).

В моделируемой предметной области Каталог книг является хорошей кандидатурой для базового класса, потому что Мини-каталог и Основной каталог книг являются разновидностями (kind of) Каталога книг.

Более детально исследовав требования к книжному Интернет магазину, мы увидим, что у нас имеется достаточно большое количество различных списков: Список желаемых покупок, Список рекомендаций, Связанные по тематике книги, Результаты поиска и так далее. Фактически все это просто списки книг и они могли бы (по крайней мере, концептуально) иметь общий родительский класс - Список книг (рисунок 5)

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

Новые классы (Связанные по тематике книги, Список рекомендаций, а Список желаемых покупок, Результаты поиска) наследуют все атрибуты и операции определяемые в классе Список книг.

Поэтому можно сказать, что Книга принадлежит Списку книг, а Список желаемых покупок, Список рекомендаций, Связанные по тематике книги, Результаты поиска являются разновидностью Списка книг.

При выявлении отношений мы обнаружили несколько новых классов. Они показаны красным. Кроме того, мы ввели новый класс Способ оплаты, который отделил Банковскую карту и Счет на оплату от Заказа. Диаграмма, на которую мы ввели отношения обобщения, показана на рисунке 6 .

Рисунок 6. Модель предметной области после ввода отношений обобщения

Таким образом, на данном этапе мы проделали работу, место которой в общем процессе можно показать с помощью диаграммы деятельности (Activity diagram). Диаграмма деятельности представлена на рисунке 7.

Рисунок 7. Место моделирования предметной области в Анализе требований

ЗАКЛЮЧЕНИЕ

В ходе выявления объектов из предметной области необходимо устано­вить, какие связи существуют между ними. Особый интерес представляют два вида отношений: обобщение (отношение между подклассом и суперклас­сом) и агрегирование (отношение между целым и частью). Между классами могут существовать и другие отношения, в том числе простейшие ассоциа­ции, но эти два исключительно важны. В основу статической модели мы положим диаграммы классов, отображающие модель предметной области, Классы в UML - это место для размещения атрибутов (то есть данных-членов) и операций (то есть функций, выполняемых объектами). Однако начиная моделировать предметную область, мы обычно не хотим тратить много времени на идентификацию атрибутов и операций; этим мы займем­ся позже, при уточнении и наполнении статической части модели. Сейчас же следует сконцентрировать внимание на выявлении собственно объектов и отношений между ними.

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

СПИСОК ЛИТЕРАТУРЫ

1. Емельянова, Н.З. Проектирование информационных систем: Учебное пособие / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. - М.: Форум, 2013. - 432 c.
2. Исаев, Г.Н. Проектирование информационных систем: Учебное пособие / Г.Н. Исаев. - М.: Омега-Л, 2013. - 424 c.
3. Коваленко, В.В. Проектирование информационных систем: Учебное пособие / В.В. Коваленко. - М.: Форум, 2012. - 320 c.
4. Лукин, В.Н. Введение в проектирование баз данных / В.Н. Лукин. - М.: Вузовская книга, 2015. - 144 c.
5. Мюллер, Р.Д. Проектирование баз данных и UML / Р.Д. Мюллер; Пер. с англ. Е.Н. Молодцова. - М.: Лори, 2013. - 420 c.

ПРИЛОЖЕНИЕ 1

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

ПРИЛОЖЕНИЕ 2

Упражнения.

На представленных диаграммах (рисунки 8-12) исправьте указанные ошибки, которые наиболее часто допускают студенты при моделировании предметной области. Результаты исправления каждой диаграммы должны быть оформлены как диаграмма классов в IBM Rational Rose. Объяснение принятого решения по каждой ошибке на каждой диаграмме классов оформить как Note. Ответы оформите в виде раздела отчета по лабораторной работе.

Рисунок 8 – Упражнение 1

Рисунок 9 – Упражнение 2

Рисунок 10 – Упражнение 3

Рисунок 11 – Упражнение 4

Рисунок 12 – Упражнение 5

Задания

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

1. Какой из четырех нижеперечисленных типов взаимосвязи не используется при моделировании предметной области? Объясните почему.

a) Has-a

b) Create

c) Is-a

d) Knows about

2. Какой из перечисленных метод вы будете использовать для того, чтобы выделить классы предметной области? Объясните почему.

a) Синтаксический анализ (Noun phrase analysis)

b) Обратное проектирование (Reverse engineering)

c) Классификация глаголов (Class verb category)

d) Экстремальное программирование (Extreme Programming)

3. Какой термин используется для описания отношения, когда дочерний класс является расширением родительского класса?

a) Агрегирование (Aggregation)

b) Наследование (Inheritance)

c) Композиция (Composition)

d) Инкапсуляция (Encapsulation)

4. Создайте две модели предметной области для музыкального интернет-магазина:

• первую модель постройте на основе вашего представления о музыкальном интернет-магазине, не заглядывая на сайты подобных интернет магазинов;
• вторую модель постройте после того как ознакомитесь с работой веб-сайт любого музыкального интернет магазина, например iTunes или Napster.

Какая из ваших моделей предметной области лучше? Объясните почему.

5. Предположим, что вы могли бы выполнить обратное проектирование (reverse engineering) схемы базы данных интернет-магазина Amazon.com и импортировать ее в визуальный инструмент моделирования. Возможно ли использовать полученную модель в качестве стартовой модели для моделировании предметной области? Объясните, почему вы считаете полученную модель пригодной для моделирования предметной области. Если вы ответили, что полученная модель непригодна для моделирования, то какие изменения необходимо внести в метод обратного проектирования (reverse engineering) схемы базы данных, чтобы сделать полученный результат пригодным для моделирования предметной области?

6. Допустим, к вам руки попал код Java для прототипа графического пользовательского интерфейса нового книжного магазина в Интернете, и вы методом обратного проектирования (reverse engineering) перевели его в UML. Можно ли использовать полученную модель в качестве стартовой модели предметной области? Объясните, почему вы считаете полученную модель пригодной для моделирования предметной области. Если вы ответили, что полученная модель непригодна, то какие изменения необходимо внести в метод обратного проектирования прототипа GUI, чтобы сделать результат обратного проектирования пригодным для моделирования предметной области?

7. Предположим, вы работаете над третьей версией проекта и у вас есть подробный набор диаграмм классов, показывающих полную реализацию (complete implementation) второй версии проекта, который был получен методом обратного проектирования из кода C#. Третья версия проекта включает миграцию системы на новую платформу графического интерфейса и другую СУБД. Какие изменения необходимо внести в диаграммы классов из предыдущей версии проекта, чтобы использовать его в качестве модели предметной области для текущей версии проекта?

1. Емельянова, Н.З. Проектирование информационных систем: Учебное пособие / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. - М.: Форум, 2013. - 432 c. ↑

2. Исаев, Г.Н. Проектирование информационных систем: Учебное пособие / Г.Н. Исаев. - М.: Омега-Л, 2013. - 424 c. ↑

3. Коваленко, В.В. Проектирование информационных систем: Учебное пособие / В.В. Коваленко. - М.: Форум, 2012. - 320 c. ↑

4. Лукин, В.Н. Введение в проектирование баз данных / В.Н. Лукин. - М.: Вузовская книга, 2015. - 144 c. ↑

5. Мюллер, Р.Д. Проектирование баз данных и UML / Р.Д. Мюллер; Пер. с англ. Е.Н. Молодцова. - М.: Лори, 2013. - 420 c. ↑