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

2.7. Пример системы электронной коммерции спроектированной с помощью языка UML.

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

Рисунок 14. Система электронной коммерции. Прецеденты

Модель прецедентов для системы электронной коммерции изображена на рисунке 14. В ней есть три актера: «Покупатель», «Поставщик» и «Банк». Покупатель инициирует три прецедента: «Просмотреть Каталог», «Разместить Заявку» и «Подтвердить Доставку». Поставщик также инициирует три прецедента: «Обработать Заказ», «Подтвердить Отгрузку» и «Послать Счет-Фактуру.» Это основные прецеденты; менее значимые прецеденты, такие как запросы к серверам и отслеживание выполнения заказа, для краткости опущены. Опишем вышеупомянутые прецеденты. В прецеденте «Просмотреть Каталог» покупатель просматривает различные размещенные в Internet каталоги и выбирает из них товары. В прецеденте «Разместить Заявку» клиент отмечает товары из каталога и делает па них заявку. Система должна найти такой контракт покупателя с поставщиком, где есть достаточный операционный лимит. Если контракт найден, система авторизует заявку и посылает заказ поставщику. В прецеденте «Обработать Заказ» система находит заказ, проверяет, есть ли на складе нужное количество товара для его выполнения, и передает заказ поставщику. В прецеденте «Подтвердить Отгрузку» поставщик вручную формирует партию товаров и затем подтверждает ее отгрузку. В прецеденте «Подтвердить Доставку» покупатель подтверждает факт доставки товара. Из операционного лимита резервируется сумма для его оплаты. После того как доставка подтверждена, бухгалтерия покупателя дает разрешение на оплату, и в банк получателя уходит платежное поручение.

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

В системе электронной коммерции^[5] есть клиентские агенты двух типов: «Агент Покупателя» (один экземпляр для каждого покупателя) и «Агент Поставщика» (один экземпляр для каждого поставщика). Серверных агентов три, и каждый может существовать в нескольких экземплярах^[6]:

• «Агент Заявок», по одному экземпляру для каждой заявки;
• «Агент Заказов», по одному экземпляру для каждого заказа;
• «Агент Счетов-Фактур», по одному экземпляру для каждого счета-фактуры

«Агент Покупателя» - это клиентский агент, действующий от имени человека-покупателя. Он помогает покупателю, который хочет заказать товары по каталогу. «Агент» принимает запрос покупателя и взаимодействует с серверными агентами, которые берут на себя дальнейшую обработку заказа и отслеживание его состояния. «Покупатель» может выбрать из каталога несколько товаров. Когда выбор сделан, «Агент Покупателя» инициирует определенные действия от имени покупателя, в частности посылает запрос «Агенту Заявок». «Агент Заявок» - это серверный агент, который обращается к различным базам данных и взаимодействует с разными агентами для обработки размещенной покупателем заявки. Точнее, он получает информацию из баз данных заявок, контрактов и операционных лимитов, а также взаимодействует с «Агентом Покупателя». Базе данных заявок посылается сообщение с целью определить, имеется ли подходящий контракт. Из базы данных операционных лимитов серверный агент получает информацию о наличии необходимого лимита. Если ответы на оба запроса положительные, то «Агент Заявок» авторизует заявку и посылает ее статус «Агенту Покупателя», который, в свою очередь, направляет запрос. «Агенту Заказов». «Агент Поставщика» - это клиентский агент, предназначенный для работы с поставщиком. Он получает заказ у «Агента Заказов» и помогает поставщику его выполнить. «Агент» обновляет базу данных запасов и посылает статус заказа «Агенту Заказов» и «Агенту Покупателя». В конечном итоге покупатель подтверждает получение товара, и в заказе проставляется дата доставки. «Агент Поставщика» посылает счет-фактуру «Агенту Счетов-Фактур», находящемуся на стороне покупателя. Когда «Агент Счетов-Фактур «получает от «Агента Заказов» уведомление о получении товара, он обращается к базе данных контрактов и базе данных операционных лимитов. Если ответы положительны, то «Агент Счетов-Фактур» авторизует платеж и посылает счет-фактуру в базу данных счетов к оплате, а затем отправляет электронное платежное поручение в банк покупателя.

В этом приложении используется несколько унаследованных баз данных. Каждая из них автономна и хранится на большой ЭВМ. Необходимо интегрировать имеющиеся базы в единое приложение электронной коммерции с помощью брокеров объектов - таких, например, как предлагает технология CORBA^[7]. На стороне покупателя унаследованными будут базы данных контрактов, операционных лимитов, заявок, счетов-фактур и счетов к оплате. На стороне поставщика таковыми являются базы данных каталога, запасов и заказов. Чтобы все это интегрировать, серверные объекты, осуществляющие доступ к данным, должны быть обертками базы данных, то есть должны

инкапсулировать детали чтения и обновления конкретных баз. Соответствующие объекты-обертки таковы: «Сервер Заявок», «Сервер Контрактов», «Сервер Операционных Лимитов», «Сервер Счетов к Оплате», «Сервер Счетов-Фактур», «Сервер Каталогов», «Сервер Заказов» и «Сервер Запасов». Дополнительно, чтобы обеспечить слабую связанность клиентов, агентов и серверов, используется брокерская служба имен, цель которой - хранить информацию о местонахождении различных сервисов. Серверы и агенты регистрируются у брокера объектов. Когда требуется некий сервис, его расположение легко определить, послав запрос брокеру.

На рисунке 15 показано, как «Агент Покупателя» узнает у «Брокера» местонахождение серверного «Агента Заказов». После этого «Агент Покупателя» работает с «Агентом Заказов» напрямую.

Рисунок 15. Брокер объектов в системе электронной коммерции на базе агентов

Статическая модель предметной области изображена на диаграмме классов^[8] (рисунок 16). Поскольку в этом приложении используется много различных данных, основное внимание уделяется сущностным классам, большинство из которых представляет информацию, хранящуюся в унаследованных базах. Объекты-обертки служат для отображения концептуальных объектов на реальные базы данных. Поскольку у каждого покупателя и поставщика могут быть собственные базы данных, то неизбежно

наличие множества частных решений. Однако с помощью брокеров объектов и технологии оберток удается найти систематический подход к интеграции плохо совместимых баз. На рисунке 16 представлены классы для наиболее важных сущностей предметной области, а также связи между ними. В их число входят: «Заявка», «Контракт», «Операционный Лимит», «Платеж», «Счет-Фактура», «Каталог», «Заказ» и «Запасы». Атрибуты классов показаны на рисунке 17.

Рисунок 16. Статическая модель системы электронной коммерции на базе агентов

Рисунок 17. Классы в системе электронной коммерции на базе агентов

Для каждого прецедента разрабатывается диаграмма кооперации, на которой изображены объекты, принимающие участие в этом прецеденте, и последовательность сообщений, которыми они обмениваются. Модель кооперации для первого прецедента «Просмотреть Каталог» показана на рисунке 18.

В диаграмме кооперации для прецедента «Разместить Заявку» (рисунок 19) «Агент Заявок» посылает запрос «Серверу Контрактов» с целью выяснить, существует ли контракт. Затем он обращается с «Серверу Операционных Лимитов», чтобы узнать, выделен ли лимит. Если оба ответа положительны, то «Агент Заявок» авторизует заявку и передает ее статус «Агенту Покупателя», который отправляет запрос на закупку «Агенту Заказов».

Рисунок 18. Диаграмма кооперации для прецедента «Просмотреть Каталог»

Рисунок 19. Диаграмма кооперации для прецедента «Разместить Заявку»

В модели кооперации^[9] для прецедента «Обработать Заказ» (рисунок 20) «Агент Поставщика» просит у «Агента Заказов» новый заказ, а «Агент Заказов» выбирает заказ. «Агент Поставщика» проверяет уровень запасов и выводит заказ и информацию о запасах поставщику с помощью его интерфейса.

Рисунок 20. Диаграмма кооперации для прецедента «Обработать Заказ»

В диаграмме кооперации для прецедента «Подтвердить Отгрузку» (рисунок 21) поставщик вручную готовит партию товаров к отгрузке. Затем он подтверждает факт отгрузки, вводя необходимые данные, в том числе дату отгрузки. «Агент Поставщика» обновляет уровни запасов и передает статус заказа «Агенту Заказов» и «Агенту Покупателя», который отображает эти

сведения на экране.

Рисунок 21. Диаграмма кооперации для прецедента «Подтвердить Отгрузку»

В диаграмме кооперации для прецедента «Подтвердить Доставку» (рисунок 22) покупатель подтверждает факт получения товара и обновляет заказ, вписывая дату доставки. Кроме того, посылается извещение «Агенту Заявок».

Рисунок 22. Диаграмма кооперации для прецедента «Подтвердить Доставку»

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

Заключение

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

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

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