Лабораторная работа №2 Моделирование предметной области (методика iconix) Моделирование предметной области в теории 1


Основные элементы моделирования предметной области



страница2/3
Дата24.12.2017
Размер0,49 Mb.
ТипЛабораторная работа
1   2   3

Основные элементы моделирования предметной области


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

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

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


  • имена существительные и именные группы становятся объектами и атрибутами;

  • глаголы и глагольные группы становятся операциями и ассоциациями;

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

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

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

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

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



Основные плавила построения модели предметной области





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

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

Рисунок 2


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


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

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

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




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

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

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




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

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


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

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


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

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


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

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


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

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

10 самых распространенных ошибок при моделировании предметной области


Перечислим типичные ошибки, которые наши студенты допускают при моделировании предметной области:
EM1. Сразу начинают назначать кратности ассоциациям, стараясь, чтобы у каждой ассоциации была кратность.

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


EM2. Так тщательно выполняют анализ существительных и глаголов, что забывают обо всем остальном.

Книга Курта Дерра (Kurt Derr) «Applying ОМТ» (SIGS Books, 1995) - хороший источник информации о «грамматическом ана­лизе». Однако, если буквально следовать рекомендациям Дерра, есть риск спуститься на чересчур низкий уровень абстракции. Пользуйтесь этой методикой, чтобы начать выявление объектов, но не слишком увлекайтесь.


EM3. Включают в классы операции, не изучив как следует прецеденты и диаграммы последовательности.

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


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

Чем более общими являются ваши объекты и классы, тем больше шансов, что вы сможете ими повторно воспользоваться в других проектах. А полным называется класс, который теоретически мож­но использовать в любом контексте. Однако для повторного ис­пользования необходимо рассмотреть атрибуты и операции, а мы только что объяснили, почему не следует включать операции на этапе моделирования предметной области. Так что не тратьте лиш­них усилий на обеспечение возможности повторного использова­ния при работе с диаграммами классов высокого уровня. Лучше поскорее завершайте данный этап, чтобы осталось время убедить­ся, что вы проектируете то, что нужно заказчику.


EM5. По поводу каждой ассоциации вида «является частью» спорят, что использовать - агрегирование или композицию.

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


EM6. Предлагают конкретную стратегию реализации, не выполнив моделирование предметной области.

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


EM7. Дают классам маловразумительные имена, например cPortMgr-Intf вместо PortfolioManager.

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


EM8. Сразу начинают пользоваться программными конструкциями, например отношениями дружественности и параметризованными классами.

UML предоставляет массу возможностей включить в диаграммы то, что мы называем «штучками Буча». К их числу относятся кон­струкции, заимствованные из языка С++, в частности параметри­зованные классы и отношения дружественности. Но они в большей степени имеют отношение к пространству решения, а не к простран­ству задачи, а при моделировании предметной области, безусловно, следует сконцентрировать внимание на последнем.


EM9. Создают взаимно однозначное соответствие между классами из предметной области и таблицами в реляционной базе данных.

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


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

Паттерны12 часто начинают проявляться на этапе анализа пригоднос­ти. Есть две стратегии: «элемент управле­ния на экране» и «контроллер прецедентов», которые помогают об­наружить паттерны в прецедентах. Забегая вперед, отметим, что паттерны проектирования могут оказаться полезными в контексте диаграмм последовательности и диаграмм классов уровня проек­тирования. Но на этапе моделирования предметной области не время думать о терминологии паттернов.


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

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



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

  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 мес.)

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




Автор

Корзина

Продавец


База данных

Кредитная карта

Редакторский отзыв


Детальное описание книги

Мини-каталог

Результат поиска


Заголовок

Оплата

Рейтинг


Заказ

Основной каталог

Система доставки по почте


Интернет

Основной каталог книг

Список желаемых покупок


Интернет-магазин

Основной список учетных записей


Список книг


Каталог книг

Отзыв

Список учетных записей


Категория

Отзыв на книгу

Способ поиска


Клиент

Партнер

Счет на оплату


Ключевое слово

Пользователь

Учетная запись клиента


Книга

Предмет


Учетная запись пользователя

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


Клиент и Учетная запись пользователя являются разными вещами. Данные учетной записи хранятся в базе данных, Клиент – это участник взаимодействия с системой (актер).
Клиент и Продавец – также участники и должны быть размещены на диаграммах вариантов использования.
Учетная запись клиента и учетная запись пользователя являются повторами. Оставим Учетную запись клиента.
Список учетных записей и Основной список учетных записей являются повторами. Оставим второй.
Отзыв на книгу и Отзыв означают одно и то же. Оставим Отзыв на книгу.
На термин Каталог у нас следующие кандидаты: Каталог книг, Список книг, Мини-каталог, Основной каталог книг. Каталог и список являются разными понятиями, поэтому если возникают сомнения, то нужно уточнять у заказчика.

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


Из пары Основной каталог и Основной каталог книг оставим последнее, как более детально описывающее смысл.
Интернет – слишком общее понятие и ничего по существу к модели не добавляет.
Понятие Пароль – слишком маленькое, чтобы быть объектом и должно соответствовать элементу интерфейса, поэтому мы убираем его из модели. То же относится к Заголовку и Ключевому слову.
Еще повтор – это Книга и Детальное описание книги. Оставим Книгу, так как это более краткое название без потери смысла.
Слово Предмет слишком нечеткое, тем не менее, оно важно для нас, когда мы рассматриваем нечто, что пользователь может поместить в корзину. Мы его переименуем в Элемент (Line Item) и оставим в модели.
Магазин книг тоже слишком общее понятие.
В итоге, у нас остаются:


Автор

Оплата


Система доставки по почте


База данных

Основной каталог книг


Список желаемых покупок


Заказ

Основной список учетных записей


Список книг


Категория

Отзыв на книгу


Способ поиска


Книга

Партнер


Счет на оплату


Корзина

Редакторский отзыв


Учетная запись клиента


Кредитная карта

Результат поиска


Элемент


Мини-каталог

Рейтинг




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

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



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

Интернет-магазин по продаже книг. Уточнение модели предметной области



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

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

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

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

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


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

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

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

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



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

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


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




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

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





Поделитесь с Вашими друзьями:
1   2   3


База данных защищена авторским правом ©grazit.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал