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

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

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

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

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

Слово Предмет слишком нечеткое, тем не менее, оно важно для нас, когда мы рассматриваем нечто, что пользователь может поместить в корзину. Мы его переименуем в Элемент (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#. Третья версия проекта включает миграцию системы на новую платформу графического интерфейса и другую СУБД. Какие изменения необходимо внести в диаграммы классов из предыдущей версии проекта, чтобы использовать его в качестве модели предметной области для текущей версии проекта?