Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Моделирование предметной области).pdf

ВВЕДЕНИЕ

Актуальность темы исследования. Моделирование предметной области является основой статической части модели 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].

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