какое действие происходит в элементе контроля в модели ibm

Дайджест корпоративных событий СПБ Биржи (IBM, DELL, BLUE, ADS)

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

Итак, вот акции, по которым в скором времени ожидаются корпоративные действия, о которых можно почитать ниже в материале.

Bank Of New York Mellon стал международным депозитарием СПБ Биржи

Бест Эффортс Банк, осуществляющий функции расчетного депозитария СПБ Биржи, и Bank of New York Mellon, один из крупнейших глобальных банков-кастодианов, заключили Global Custody Agreement. Bank of New York Mellon стал выполнять функции международного депозитарного (кастодиального) банка, обслуживающего расчетный депозитарий биржи Бест Эффортс Банк.

Сотрудничество затрагивает ряд услуг, в том числе:

АДРSK Telecom Co(SPB: SKM)

26 октября 2021 года станет последним днем в период до корпоративного события, когда АДР SK Telecom Co., Ltd. SKM будут доступны для совершения сделок в режиме основных торгов. В результате ряда корпоративных действий с базовыми акциям будет произведена консолидация АДР коэффициентом 0.6073625. Подробнее…

Dell Technologies (SPB: DELL)

Dell Technologies распределит около 81% акций своей дочерней компании Vmware, Inc. (SPB: VMW) между своими акционерами. Ожидаемый коэффициент распределения 0,44 к 1. Точный коэффициент будет объявлен 29 октября 2021 года. Внимание! Вероятность образования дробных ценных бумаг на счетах клиентов является высокой. Подробнее…

Bluebird Bio (SPB: BLUE)

Bluebird Bio, Inc. планирует провести реорганизацию в форме выделения сегмента бизнеса(Cпин-офф), занимающегося онкологией, в отдельную публично торгуемую компанию 2seventy bio, Inc. Коэффициент распределения ценных бумаг 2seventy bio, Inc. является дробным (1/3 к 1). Во избежание возможного округления дробных остатков рекомендуется привести размер позиций в акциях BLUE к числу кратному 3 до 22:00 МСК 4 ноября 2021 года включительно. Подробнее…

Business Machines Corporation (SPB: IBM)

проведет выделение сегмента бизнеса в отдельную публичную компанию Kyndryl Holdings. Коэффициент распределения ценных бумаг Kyndryl Holdings, Inc. является дробным (0,2 к 1). Во избежание возможного округления дробных остатков рекомендуется привести размер позиций в акциях IBM к числу кратному 5 до 22:00 МСК 3 ноября 2021 года включительно. Подробнее…

Alliance Data Systems Corporation(SPB: ADS)

Alliance Data Systems Corporation планирует провести реорганизацию в форме выделения сегмента бизнеса (Cпин-офф отдельную публичную компанию Loyalty Ventures Inc. Владельцы акций ADS, находящиеся в реестре акционеров по состоянию на 9 ноября 2021 года, получат по 1 акции Loyalty Ventures на каждые 2,5 акций ADS. Во избежание возможного округления дробных остатков рекомендуется привести размер позиций в акциях ADS к числу кратному 5 до 22:00 МСК 5 ноября 2021 года включительно. Подробнее…

Herman Miller(SPB: MLHR)

С 25 октября акции Herman Miller стали недоступны для совершения сделок в режиме основных торгов на весь период обработки корпоративного события. Напоминаем, что компания планирует сменить наименование на MillerKnoll, Inc. Ожидается, что акции начнут котироваться на Нью-Йоркской фондовой бирже под новым наименованием «MillerKnoll, Inc.» без изменения ISIN кода. Компания Herman Miller, Inc. также рассматривала возможность изменения торгового кода (тикера) своих акций, но информация по данному решению пока не опубликована.

Источник

Системы управления бизнес-правилами IBM Industry Models и ILOG : Часть 1. Определение бизнес-правил при помощи моделей IBM Industry Models

Это первая из двух статей серии, в которой определяется природа бизнес-правил и отношение этих правил к моделям IBM Industry Models. В частности, в этой статье описываются этапы развертывания моделей IBM Industry Models, на которых выполняется анализ и проектирование правил, а также способы идентификации и управления правилами. Во второй статье этой серии обсуждается введение этих структур анализа и проектирования в среду управления правилами ILOG для разработки полных наборов правил.

Базисные модели помогают определить рамки проекта и выявить зависимости между отдельными проектами, которые без них было бы легко упустить. В дополнение к этому базисные модели составляют фундамент, на котором строятся все прочие предложения Industry Model, обеспечивая лексикон стандартных бизнес-терминов, гарантирующий согласованность между моделями набора. Получаемые модели удовлетворяют потребности доменов процессов, служб и данных соответственно в процессах, UML-сервисах и ER-моделях.

Модели Industry Models сфокусированы на формировании детального бизнес-контента. Каждая модель является итогом многолетней разработки в организациях по всему миру крупных моделей масштаба предприятия, которые впоследствии можно использовать для ускоренной реализации проектов. Модели предполагают настройку и расширение в ходе таких проектов, для чего требуется специальная методология настройки и управления моделями.

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

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

Рисунок 1. Модели IBM Industry Models

Рисунок 2. Источники правил для моделей Industry Models

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

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

Термин бизнес-правило чрезвычайно широк и требует дальнейшей классификации. В рамках настоящей статьи мы будем иметь дело с четырьмя разными формами бизнес-правил:

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

Бизнес-пользователи обычно выражают правила абсолютно неформально, пользуясь естественным языком и группируя множество правил в одном утверждении (например, «…потенциальных клиентов необходимо проверять на кредитоспособность и идентифицировать…»). Будем называть такие неформальные определения «формулировками бизнес-правил». Бизнес-пользователи также часто выражаются языком бизнес-политик, например, «мы имеем дело только с кредитоспособными и проверенными клиентами». Политики и правила, хотя они тесно связаны, представляют собой разные конструкции. Бизнес-политики часто объединяют разные бизнес-правила, которые задают общее направление или составляют контекст для бизнес-правил.

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

Рисунок 3. Степени формализации бизнес-правил

Цикл работы организации с моделями Industry Models включает этапы планирования, формулирования требований, анализа и проектирования при разработке решений, отвечающих бизнес-требованиям. Чтобы формализовать эти этапы, в дополнение к моделям был определен план действий с набором методологических принципов. Например, в области SOA этот план предписывает организации определить рамки проекта, проанализировать бизнес-процессы, выявить сервисы и так далее в соответствии с циклом разработки. (План действий входит в состав Industry Models.)

Рисунок 4. Настройка Industry Models

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

Рисунок 5. Совокупность потоков анализа и проектирования

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

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

Рисунок 6. Определение сервисов правил

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

Рисунок 7. Пример бизнес-политики

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

Рисунок 8. Пример выражения правила

Рисунок 9. Пример оператора правила

Заказчикам Industry Models знакомы рекомендации Industry Models Customization Roadmap, в которых подчеркиваются преимущества текстовых определений требований в процессе анализа. В них приводится пример шаблона для таких требований, часть которого показана в таблице 1. (Этот шаблон входит в состав Industry Models.)

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

Управление такими полуструктурированными требованиями может осуществляться в разных системах; множество полезных возможностей предоставляет IBM Rational RequisitePro. RequisitePro может встраиваться в качестве плагина на базе Eclipse в инструментарии IBM WebSphere Business Modeler (WBM) или Rational Software Architect (RSA) и позволяет отображать структурированные документы с требованиями на элементы модели. В результате информацию формулировок бизнес-политик и бизнес-правил можно вводить в текстовой форме и отображать непосредственно на бизнес-действия и UML-структуры, к которым они относятся.

Рисунок 10. Формулировки политик и правил в RequisitePro

Можно также устанавливать отношения между этими типами требований. Например, бизнес-политики можно связывать с операторами бизнес-правил, которые поддерживают эти политики, как показано на рисунке 11.

Рисунок 11. Связь между политиками и формулировками бизнес-правил в RequisitePro

Эти типы требований могут связываться не только друг с другом, но и с элементами бизнес-модели, к которой они относятся. Например, в контексте банковских услуг бизнес-политика «…мы работаем только с полностью кредитоспособными и проверенными клиентами…» может быть выражена в виде документального требования, отображенного на бизнес-процесс «Предоставление банковского продукта», который работает с документированным набором требований клиента и выдает предложение в соответствии с этими требованиями. Аналогично, формулировку бизнес-правила «…потенциальные клиенты должны быть проверены на кредитоспособность и идентифицированы…» можно отобразить на действие Анализ отношений с клиентом в рамках того же бизнес-процесса. Это обеспечивает средства для задания не только приведенных здесь упрощенных примеров, но и сложных формулировок политик и правил, связанных с бизнес-контекстами, в которых они применяются. В RequisitePro можно легко определять шаблоны клиентов, добавляя свойства в соответствии с требованиями организации для лучшего ввода необходимых правил и управления этими правилами. Однако для выбора правильного направления лучше начинать с документов Industry Models Activity Description Documents.

Отметим, что применение RequisitePro для управления формулировками бизнес-политик и бизнес-правил хорошо согласуется с текущими рекомендациями по инструментарию для Industry Models. Например, есть документированные процедуры для управления областью применения, а также функциональными и нефункциональными требованиями, связанными с моделями, которые используются в RequisitePro. Эти рекомендации в сочетании с описанными выше средствами управления формулировками политик и правил позволяют связать эти элементы с определенными проектами и бизнес-целями как в Rational Software Architect (RSA), так и в WebSphere Business Modeler (WBM).

В этой статье описывается природа бизнес-правил и их соотношение с моделями IBM Industry Models. Затем обсуждаются методы ввода требований для бизнес-правил и степени формализации этих требований. В следующей статье этой серии полученные результаты и структуры правил будут использованы в ILOG BRMS для полного описания наборов правил, применяемых в ходе бизнес-процесса или исполнения приложения.

Источник

Моделируем сервис-ориентированную архитектуру при помощи IBM Rational Software Architect: Часть 1. Учебный пример, инструменты и бизнес-видение

Перед началом работы

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

В этой серии подробно рассматривается моделирование сервис-ориентированной архитектуры (service-oriented architectures, SOA) при помощи инструмента IBM® Rational® Software Architect. Хотя изначально это программное решение предназначалось для разработчиков архитектуры программного обеспечения и для поддержки их деятельности, оно может оказаться полезным также специалистам, выполняющим другие роли в процессе разработки программного обеспечения, в том числе тем, кто вносит свой вклад в разработку архитектуры ПО, например, бизнес-аналитикам или тем, кто использует эту архитектуру в качестве отправной точки собственной деятельности, например, проектировщикам программного обеспечения и разработчикам (занимающимся реализацией архитектуры, проектированием и созданием ПО). Кроме того, в этой серии объясняются многие основные концепции SOA, которые могут заинтересовать и других специалистов. См. в разделе Ресурсы ссылку на часть 2.

Эти учебные руководства концентрируются на трех темах:

Серия начинается с описания архитектуры программного обеспечения и определения места сервисов в архитектуре. Затем рассказывается о программном продукте Rational Software Architect, его функциях и инструментах, имеющих отношение к SOA- и архитектуре.

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

В данном учебном руководстве, которое представляет собой 1 часть серии, вводится учебный пример фирмы по прокату видеодисков, который используется во всех статьях серии. Кроме того, в нем рассказывается об инструменте Rational Software Architect (версия 7 и более поздние) и о функциях, которые мы будем использовать для моделирования сервисной архитектуры. И, наконец, рассказывается об использовании следующих двух моделей на входе деятельностей по моделированию сервисов: карты компонентного моделирования бизнесов (CBM) и модели бизнес-процесса.

Изучив данное учебное руководство, вы сможете:

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

Учебный пример Video Rental

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

Из разговора с генеральным директором компании мы узнали, что около года назад он запустил новый интернет-проект. Вот механизм его работы: чтобы стать участниками сервиса, пользователи регистрируются на Web-сайте и оплачивают подписку на месяц. Участники составляют список нужных им фильмов из ассортимента, предоставленного компанией DVD2U, в режиме онлайн, как правило, такой список содержит около ста названий. Затем компания DVD2U пересылает DVD-диски участникам сервиса по обычной почте. Просмотрев фильм, участник возвращает DVD-диск по почте в предоплаченном почтовом конверте. Получив просмотренный DVD-диск, фирма DVD2U отправляет участнику следующий диск по списку.

В зависимости от типа (и стоимости) подписки участника фирма допускает выдачу со склада ограниченного количества дисков DVD за один раз (как правило, участники выбирают популярный план на 3 DVD). Компания DVD2U приветствует идею интернет-сообществ и стремится к созданию подобного сообщества на своем интернет-сайте; в таком сообществе участники могут общаться, оценивать фильмы, писать обзоры и даже знакомиться с пользователями, которые смотрели те же фильмы, что и они сами. По мнению пользователей, Web-сайт DVD2U очень эффективен для знакомства!

Однако гендиректор отметил: несмотря на то, что онлайновый сервис проката представляет собой прекрасную бизнес-возможность, с этим сервисом связан ряд проблем. Например, клиенты жалуются на то, что, по их впечатлению, они никогда не получают самые популярные фильмы из своих списков, иногда новый DVD-диск приходит только через несколько недель после того, как они отправили уже просмотренный диск по почте; иногда Web-сайт не функционирует, и они не могут обновить свои списки фильмов.

МЫ рассмотрели ряд других специфических проблем с используемым IT-решением:

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

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

Рисунок 1. Дисциплины RUP

Рисунок 2. Стек SOA-решения

На данном рисунке имеется 5 функциональных уровней (снизу вверх):

4 нефункциональных уровня:

Эти модели используются на входе деятельности моделирования сервисов.

Следующие модели используются для осуществления деятельности моделирования сервисов:

В этом учебном руководстве, первом в данной серии, мы расскажем о компонентной бизнес-модели и модели бизнес-процессов.

Rational Software Architect версии 7 и более поздних версий

Rational Software Architect создан на основе Eclipse, платформы с открытым исходным кодом, а версия 7 построена на Eclipse версии 3.2. Программа поддерживает совместную работу разработчиков при помощи следующих технологий:

Rational Software Architect объединяет инструменты IBM® Rational® Software Modeler и IBM® Rational® Application Developer в интегрированную среду. Кроме того, программа представляет функции интеграции с другими продуктами, такими, как WebSphere Business Modeler, IBM® Rational® Clear Case®, CVS (система управления параллельными версиями), IBM® Rational® ClearQuest® и IBM® Rational® RequisitePro®.

Рисунок 3. Страница Welcome программы Rational Software Architect

На странице Welcome можно включить и отключить функции Rational Software Architect в зависимости от роли (в правом нижнем углу); кроме того, на этой странице имеются ссылки на информацию о Rational Software Architect, распределенную по следующим категориям:

Выполните следующие шаги:

В смысле пользовательского интерфейса (User Interface, UI) перспектива в Eclipse представляет собой набор представлений, объединенных в группы, поддерживающие определенные роли или деятельности. В Rational Software Architect имеются встроенные перспективы (например, перспективы Modeling, Plug-in Development или Java), кроме того, можно создавать новые перспективы. В данном учебном руководстве мы проведем большую часть времени в перспективе Modeling, показанной на рисунке 4.

Рисунок 4. Перспектива Modeling в Rational Software Architect

В перспективе Modeling 4 основных представления:

Выполните следующие шаги:

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

В составе 7 версии программного продукта Rational Software Architect появились две новые SOA-функции. Обращаем ваше внимание на то, что в 6 версии эти функции были доступны как дополнительные ресурсы на Web-сайте developerWorks. По мере того, как SOA становилась все более востребованной технологией, эти функции были интегрированы в продукт и в настоящее время поддерживаются в полной мере; в данном учебном руководстве мы ими воспользуемся:

На момент написания статьи мы пользовались версией 7 с пакетом исправлений fix 001. Рекомендуется пользоваться программой с последним пакетом исправлений, доступным на момент изучения учебного руководства.

Компонентная модель бизнеса

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

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

На рисунке 6 показана карта компонентной модели бизнеса (Component Business Model Map) для компании DVD2U.

Рисунок 6. Карта компонентной модели бизнеса компании DVD2U

Компоненты бизнеса (функциональные области) могут принадлежать к одному из трех уровней ответственности (строк карты):

DVD2U обладает четырьмя бизнес-компетенциями (столбцы карты):

Модель бизнес-процесса:

Рисунок 7. Бизнес-процесс Return Video (1 из 2)

Согласно рисунку 7, процесс протекает следующим образом:

Рисунок 8. Бизнес-процесс Return Video (2 из 2)

Согласно рисунку 8, процесс протекает следующим образом:

Обратите внимание, что в объеме работ по моделированию бизнес-процесса идентифицированы и кодифицированы следующие моменты:

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

Выполните следующие шаги:

Теперь мы импортируем предоставленную модель бизнес-процесса.

В данном учебном руководстве мы подготовили почву для моделирования сервис-ориентированной архитектуры при помощи Rational Software Architect. В этой части серии мы использовали подход «сверху вниз» и описали компанию DVD2U, ее бизнес и проблемы этого бизнеса. Затем мы позиционировали архитектуру программного обеспечения и SOA в процессе разработки и рассказали о главном предмете данной серии с использованием стека SOA-решения. Далее в учебном руководстве описывается инструмент Rational Software Architect и его новые SOA-функции. Затем, после перечисления моделей, которые использовались на входе деятельности по разработке архитектуры сервиса, были описаны две модели бизнеса для этого проекта: карта компонентного моделирования бизнеса DVD2U и бизнес-процесс Return Video. Это всего лишь начало, во второй части будут подробно описаны другие входные модели и начата работа над первоначальной структурой архитектуры программного обеспечения. Поэтому не забывайте следить за событиями на Web-сайте developerWorks!

Источник