После того как станет известна информация об условиях доставки, он уточняет цену. Итоговая цена заказа зависит от того, где производятся продукты, и откуда они должны быть доставлены. Вычисление первоначальной стоимости можно использовать для того, чтобы проверить, имеет ли клиент достаточный кредит, или не отказался ли он от намерения купить продукцию. Лучше убедиться в этом до заполнения формы заказа.
Мы начнем разработку поставщика сервиса с создания системного прецедента, определяющего требования к нему, и компонента <> с именем Invoicer, который будет реализовать этот прецедент. На рисунке 9 показан поставщик Invoicer после добавления сервиса инвойсинга.
Рисунок 9. Добавление сервиса InvoicingService к поставщику сервиса Invoicer.
Поставщик Invoicer предоставляет интерфейс Invoicing, имеющий две операции:
initiatePriceCalculation;
completePriceCalculation.
Поставщик Invoicer должен предоставить проект реализации или метод для каждой из этих операций сервиса. Этот метод, кроме того, должен вызывать операцию processInvoice интерфейса InvoiceProcessing после завершения вычисления стоимости. На рисунке 14 изображена схема компонента Invoicer, который является владельцем двух поведений, имена которых совпадают с именами предоставляемых операций.
Рисунок 10. Реализации сервиса Invoicer
Деятельность completePriceCalculation представляет собой метод для операции Invoicing: completePriceCalculation сервиса. Он использует нечеткое правило для вычисления итоговой стоимости, а затем вызывает операцию InvoiceProcessing: processInvoice на порту инвойсинга. (Целевой входной точкой операции processInvoice служит порт инвойсинга.) Обратите внимание на то, что это согласуется с протоколом инвойсинга по определению спецификации сервиса InvoicingService.
2.
5.2 Реализация Планирования производства Поставщик сервиса планирования производства предоставляет интерфейс Scheduling для определения места и времени производства товаров. Эта информация может использоваться для создания расписания доставки, которое используется при обработке заказов на приобретение.
Рисунок 11. Поставщик сервиса Productions
Методы операции сервиса — это поведения requestProductionsScheduling и sendShippingSchedule. Детали этих реализаций не показаны на диаграмме; они могут быть реализованы разработчиком с использованием более подходящих, платформенно-независимых языков программирования.
2.
5.3 Реализация сервиса «Доставка»
Сервис доставки предоставляет интерфейс Shipping для доставки товаров по заказу, заполненному покупателем. Сервису также необходим интерфейс ScheduleProcessing, чтобы отправить запрос на обработку готового расписания потребителю.
На рисунке 12 показано, что сервис Shipper предоставляет интерфейс доставки в соответствии с определением спецификации сервиса ShippingService.
Рисунок 12. Поставщик сервиса Shipper
2.
5.4 Комплементация типов Чтобы использовать описанный выше проект поставщика сервиса, нам нужно понять, как поставщики и потребители связаны между собой, как установить соединение между ними, указать типы портов на концах соединительной линии, и определить, совместимы ли эти типы и могут ли обеспечить работоспособное подключение.
Наша SOA-реализация готова к тому, чтобы сопоставить потребности потребителя с функциями, предоставляемыми поставщиками. Участникипотребители сервиса имеют потребности, которые они удовлетворяют посредством требования. Участники-поставщики сервиса имеют возможности, которые они предлагают через сервисы. Потребности потребителя отображаются на возможности поставщика посредством установления связей между требованиями и сервисами. Способ использования сервисов потребителями и способ предоставления их поставщиками должны быть совестимы с протоколами, определенными в спецификации сервиса и спецификации требования.
Если порт потребителя сервиса (требование) подключается к порту поставщика сервиса, то порты на обоих концах соединения должны быть совместимыми. Это означает, что требование потребителя должно запрашивать предоставляемые интерфейсы порта, а потребитель должен предоставить запрашиваемые интерфейсы. Кроме того, поставщик и потребитель сервиса должны взаимодействовать в соответствии с протоколом, определенным в интерфейсе сервиса.
Порт требования может использовать для определения своего типа любой класс. Он может предоставлять и/или запрашивать любые интерфейсы, если они совместимы с любыми портами сервиса, к которому он подключен. Таким образом, пока поставщики и потребители не установили между собой соединение, они разъединены, поэтому им не обязательно иметь определенную спецификацию сервиса, соответствующую предоставленной спецификации сервиса.
Однако существует множество ситуаций, в которых тип требования потребителя представляет собой совершенно комплементарный тип к типу порта сервиса, к которому оно подключено. В результате может оказаться удобным определить некоторое соглашение для простого указания и назначения комплементарной реализации спецификации сервиса, которую можно будет использовать как тип для потребляющего порта требования. Этот тип известен как комплементарная спецификация сервиса. Между основной и комплементарной спецификациями сервиса существует только одно отличие, заключающееся в том, что предоставляемые (реализуемые) и запрашиваемые (используемые) интерфейсы меняются местами. Все остальное в данном классе не имеет отличий, в том числе, и поведение, моделирующее протокол сервиса.
Рисунок 12. ~InvoicingService, комплементарная реализация сервиса InvoicingService.
Здесь используется то же соглашение о назначении имен, что и для основной спецификации сервиса, за исключением того, что имя начинается с символа ~ (символ тильды). Можно использовать любое соглашение о назначении имен, но выбранное соглашение следует использовать последовательно, чтобы облегчить узнаваемость взаимосвязи между этими типами. ~InvoicingService имеет такие же внутреннюю структуру и поведения, что и InvoidingService. Эта реализация просто использует интерфейсы, предоставляемые сервисом InvoicingService, и реализует запрашиваемые интерфейсы.
В будущих версиях расширения IBM Software Service Profile for UML планируется ввести понятие порта требования для различения требований от разных функциональных возможностей. Затем порт требования может использовать тот же тип, что и порт сервиса, тем самым устраняется необходимость определения комплементарных типов. Порт требования указывает на то, что функциональные возможности сервиса используются, тогда как порт сервиса указывает на то, что они предоставляются.
РЕЗУЛЬТАТЫ РАЗРАБОТКИ
В нашем работе мы рассказали и реализовали методы идентификации сервисов, обеспечивающих выполнение бизнес-требований где наш сервис это «Обработка заказов на приобретение». Мы начали с выяснения бизнес-задач и бизнес-целей, способствующих осуществлению бизнес-миссии. Затем мы смоделировали бизнесоперации и бизнес-процессы, необходимые для выполнения задач и достижения целей. После этого мы стали рассматривать бизнес-процесс как кооперацию сервиса, представляющую собой контракт для бизнес-требований к сервису, который должен выполняться нашим потенциальным решением. Затем мы воспользовались этим контрактом для требований как вспомогательным материалом для идентификации необходимых сервисов и возможных связей между ними. Это обычный способ идентификации значимых для бизнеса сервисов, ассоциируемых с бизнес-задачами и бизнес-целями, которые предполагается решить.
ЗАКЛЮЧЕНИЕ
Мы рассмотрели создание спецификации и реализацию проекта сервисов, потребителей и поставщиков, необходимых для решения бизнес-задач. В результате мы получили технологически-нейтральную модель архитектурного решения сервиса. Но мы еще не создали модель потребителя сервиса, которая может собрать вместе сервисы, предоставляемые поставщиками Invoicer, Productions и Shipper, и использовать их для обработки заказов на приобретение СПИСОК ЛИТЕРАТУРЫ Атре Ш. Структурный подход к организации баз данных. — М.: Финансы и статистика, 1983. — 320 с.
Бойко В.В., Савинков В. М. Проектирование баз данных информационных систем. — М.: Финансы и статистика, 1989. — 351 с.
Буч Г., Дж. Рамбо, А. Джекобсон. UML. Руководство пользователя, 430 стр., перевод, «T he Unified modeling Language user guide» by G. B
ooch, J. R ambaugh, I.Jacobson. Translation by DMK Press, 2000.
Гуров В.С., Мазин М. А., Шалыто А. А. Операционная семантика UML-диаграмм состояний в программном пакете UniMod //Труды XII Всероссийской научно-методической конференции «Телематика- 2005». СПб.: СПбГУ ИТМО. Т.1, с.74−76.
http://tm.ifmo.ru.
Дейт К. Руководство по реляционной СУБД DB2. — М.: Финансы и статистика, 1988. — 320 с.
Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем.
МУК «Детская централизованная библиотечная система» г. Кемерово, Центральная детская библиотека им. А. М. Береснева, [Публичный центр правовой и психологической помощи детям; сост. И.В. Менькова]. — Кемерово, 2004. 8с.
МУК «Централизованная библиотечная система» г. Кемерово, «Библиотека на Южном»; сост. Н. Л. Дементьева.
Кемерово, 2004. 2с МУК «Централизованная библиотечная система» г. Кемерово, библиотека «Гармония»; сост.: Т. А. Маврина, М. В. Пономаренко.
Кемерово, 2004. 2с.
Переписка Уварова с Гёте была издана с обширными вступительными пояснениями и примечаниями преподавателем Историко-филологического института в Петербурге Георгом Шмидом: Goethe und Uwarow, und ihre Briefwechsel / Mit Erlaeuterungen von Dr. Georg Schmid (Sonderabdruck aus der «Russischen Revue», Bd. XXVIII, H.2). St. Petersburg, 1888.
Савельев П. С. Предположения об учреждении Восточной Академии в С.-Петербурге, 1733 и 1810 гг. // Журнал министерства народного просвещения, В советской литературе отношениям Уварова с Гёте посвящен специальный этюд С. Н. Дурылина под ироничным (что показано кавычками) названием «Друг Гёте» (Дурылин С. Н. Русские писатели у Гёте в Веймаре // Литературное наследство, т.4−6, М., 1932, с.186−221 [первый параграф в гл. III — «Русские официальные и официозные гётеанцы» ]). 14Ouvaroff S. Etudes de philologie et de critique. Saint-Petersbourg, 1843.
Ouvaroff S. Projet d' une Academie Asiatique. St.-P., 1810
Годом спустя вышел русский перевод, осуществленный В. А. Жуковским: Уваров С. С. Мысли о заведении в России Академии Азиатской // Вестник Европы, 1811, № 1, с.27−52; № 2, с.94−116.
[UCMNav] Use Case Maps Navigator,
http://www.usecasemaps.org/tools/ucmnav/index.shtml
Jeffrey D. Mershon. BPwin Methods Guide. 1997 Logic Works, Inc, 128 pp.
Хубаев Г. Н., Щербаков С. М., Шибаев А. Л. Конструктор имитационных моделей деловых процессов // Свидетельство об официальной регистрации программы для ЭВМ.- № 2 005 612 262.- М.: РОСПАТЕНТ, 2005.
" Централизованная библиотечная система" г. Кемерово, библиотека «Гармония»; сост.: Т. А. Маврина, М. В. Пономаренко.
Кемерово, 2004. 2с
Информационная технология
" (см. статью Дэниелса (Daniels) и Чизмана (Cheesman) в разделе Ресурсы))
Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем
Data transfer object (DTO) IBM Redbook focuses on the Business Process Management service-oriented architecture (DTO) scenario of the IBM DTO Foundation
Service Data Objects (SDO) Г. Буч, Дж. Рамбо, А. Джекобсон. UML. Руководство пользователя, 430 стр., перевод, «The Unified modeling Language user guide» by G
Process Management service-oriented architecture (SOA) IBM Redbook focuses on the Business Process Management service-oriented architecture (SOA) scenario of the IBM SOA Foundation
