Сценарии. Для анализа различных событий в системе и связанных с ними действий полезно рассмотреть реальные сценарии работы пользователя с системой и поставить себя на

Для анализа различных событий в системе и связанных с ними действий полезно рассмотреть реальные сценарии работы пользователя с системой и поставить себя на место посетителя, открывающего в браузере домашнюю страницу сайта. Проанализировав события, мы получим список элементов, которые нужно показать пользователю, и добавим на web-страницу соответствующие коды HTML. В целом мы должны получить ПРИМЕРНЫЙ НАБОР ОБЪЕКТОВ, НЕОБХОДИМЫХ ПРИЛОЖЕНИЮ. Мы придерживаемся концепции объектно-ориентированного программирования. Поэтому реальные действия в системе должны инкапсулироваться в объектах. Распределив действия по объектам. Мы сможем решить. Какие методы и свойства требуются объектам для реализации планируемых действий системы.

Правило 80:20 заключается в том, что нужно исследовать 20% всех возможных событий в системе, чтобы получить 80% необходимых пользователям действий.

1. Пользователь открывает домашнюю страницу сайта.

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

Объект Database – объект для общения с БД. Это инфраструктурный объект, поскольку обеспечивает службу, «видимую» только на уровне бизнес правил. Однако он ничего не делает, пока не получит запрос, поэтому нужен объект, способный обращаться к БД и возвращать элементы каталога товаров. Таким объектом будет Catalog. Это служебный объект, так как он обеспечивает службу по запросу. Объекту необходим метод GetFeaturedProducts (получить рекламный каталог). (добавление кода HTML относится к уровню представления, а объектная модель – только к уровню бизнес-правил. Таким образом, определены три объекта.

1. Visit

   Пользователь хочет получить описание товара.

Инфраструктура
Catalog		Product
	Службы		Данные

Рассмотрим сценарий, описывающий запрос пользователем дополнительной информации об одном из товаров, показанных на домашней странице. Необходимо обеспечить доступ к этой информации и ее преобразование в HTML. Для доступа к информации о товаре можно использовать специальный объект, который извлекает строку из базы данных и представляет ее в виде объекта с набором свойств и методов, позволяющих манипулировать этим объектом. Назовем новый объект Product. Это объект данных, поскольку он отражает одну строку в базе данных и не предоставляет службы другим объектам системы. Product будет использоваться объектом Database для извлечения информации из БД. Объект Catalog создает объект Product по требованию, инициируемому методом GetProductObject, а объект Product может самостоятельно возвращать сведения о товаре через значения свойств Name и Price.Таким образом, добавили один объект, причем расширение функциональности проводилось за счет добавления методов и свойств объектов, без введения новых объектов в модель. Сокращение числа объектов упрощает реализацию модели и понимание ее структуры.

1. Пользователь добавляет товар в корзину.

Инфраструктура
Catalog		Product
	Customers		Customer
	Orders		Order
			Basket
	Службы		Данные

Рассмотрим действия в системе, связанные с добавлением пользователем товара в корзину. Для этого нам потребуется объект, представляющий саму корзину БД и методы изменения содержания корзины. Для объекта Basket различия между объектом данных и служебным объектом незначительны. Реализуем его в виде объекта данных. Для создания объекта Basket потребуется служебный объект Orders. Расширенная версия нашей модели приобретает иной вид. Самой сложной операцией сайта является преобразование товаров, содержащихся в корзине, в оформленный заказ на из покупку. Следует предусмотреть:

• Необходимо выполнить преобразование Basket в заказ методом объекта Оrders, который мы назовем SplitBasket.(split – расколоть)
• Потребуется объект, представляющий заказ. Назовем его Order (объект данных).
• Сам заказ имеет смысл только для определенного покупателя, поэтому сформируем служебный объект Customers, создающий нового клиента методом CreateCustomer. Затем потребуется объект данных Customer, отражающий соответствующий объект в БД.

Потребовалось не так много сценариев, чтобы понять состав и возможности объектов модели с точки зрения получения необходимых данных в приложении. Например, если мы добавляем метод GetOrderForCustomer в объект Orders, то мы предполагаем, что разработчик может выполнить запрос на просмотр любого заказа, оформленного данным клиентом. Если мы добавляем в объект Orders свойство Customer, мы должны обеспечить получение значения этого свойства из метода GetOrderForCustomer. Достаточно написать один код запроса к БД и извлечения заказа потребителя, чтобы реализовать два общепринятых способа получения этих данных.