Программные продукты и системы

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

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

Процессы адаптации,самосборка и самоорганизация

Одним из наиболее важных качеств программного обеспечения следует считать свойство адаптивности. Программный продукт изготавливается в предположении, что он будет эксплуатироваться в близких, но все же различающихся условиях. Пусть m – бизнес-процесс; s – информационная система. Взаимодействие осуществляется посредством интерфейса I=(f0 , f1 , ... ,fn), где fi – прагматики, то есть идентификаторы элементов интерфейса. Обозначим множество пар S(mm,sm), mÎH как X(f0) и введем множество спецификаций B(f0), такое, что " Is Î B(f0), Is(0)=f0 , где f0 – атрибутная прагматика (общая для всех бизнес-процессов множества X); Is=(f0,, f1, ... , fn) – спецификация; Is(j) – j-й элемент кортежа Is. Процесс адаптации имеет три аспекта: прагматический, семантический и синтаксический. Под структурной адаптацией, которая имеет место на прагматическом уровне, будем понимать процесс реструктуризации программного обеспечения w таким образом, чтобы его интерфейс соответствовал заданному, то есть Is=I(w). В частности, развитие информационной системы можно рассматривать как структурную адаптацию. Адаптацию на семантическом и синтаксическом уровне будем называть параметрической.

Проблему адаптивности можно решить, если производить сборку технической системы непосредственно в среде эксплуатации. Самосборка – достижение определенного (заданного) устойчивого состояния динамической системы. При этом динамическая система может изменять свой элементный состав. Самосборка предполагает механизм сборки системы, интегрированный в саму систему. В частности, одним из таких механизмов может быть самоорганизация (см.: Тай М.Л. Динамика процессов самосборки. − Н. Новгород: Изд-во НГУ, 2000).

Ограничимся программным обеспечением со слоистой структурой. Особенность слоистых структур состоит в направленности связей со слоя i на слой i+1, но не наоборот. Сопоставим каждой букве алфавита VT={a0,a1,...,an} некоторую прагматику fÎIS0 и обозначим фактор-множество как VT/F={f0|{a1,a2,…,ak},f1|{b1,b2,…,bl},…, fN|{z1,z2,…, zm}}, где aj,bj,…,zjÎVT . Далее сопоставим каждой букве aiÎVT упорядоченную пару Li=({l1,...,lNi}, {r1,...,rMi}), где l – левые (входные), r – правые (выходные) связи. Пятерка J(VT,VL,IS0,F,L) определяет механизм сборки системы s.

Процесс сборки представляет собой процесс развития системы и в общем случае требует описания в рамках теории развития сложных систем. Рассмотрим частный случай, когда процесс развития может быть описан ориентированными деревьями сборки слов. Пусть T – класс, I(T) – его множественный интерфейс, Il=(f0,,f1,..., q). Введем для интерфейса IlÎI(T), множество вида dl={(f0,al),(fl1,bl),…,(flq,zl)}, fiÎIS0, al,bl,…,zlÎVT и составим кортеж D=(d1,d2,…,dM) для "lÎJ. Будем называть его базой опыта сборки, или метакодом объекта s. Тогда можно говорить об отображении X: D®I(T). Пусть R=X-1(Is). Таким образом, задача адаптации продукта s(T) будет решена, если заданы отображение X и правило выбора шаблона сборки rÎR.

Рассмотрим приведенную выше модель с точки зрения методологии проектирования. Во-первых, производится проектирование не самого продукта, а механизма, который создает этот продукт (пятерка J(VT,VL,,IS0,F,L)). Во-вторых, проектируется подсистема, которая вырабатывает проект изделия. Если разработка проекта также носит автоматический характер, то такой процесс развития системы будем называть автоинжинирингом (по аналогии с инжинирингом). Оба термина подчеркивают то, что процесс относится к искусственным системам.

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

Название: самосборка – паттерн поведения объектов.

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

Применимость.

· Ситуация. Можно рассмотреть, по меньшей мере, три ситуации, когда применение самосборки (в том числе автоинжиниринга) является оправданным.

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

Случай II. На множестве X(f0) пар S(mm,sm), mÎH, задано множество спецификаций B(f0), где f0 – атрибутная прагматика. Пары S(mm,sm) различаются между собой вариантными прагматиками спецификации Is=(f0,,f1,...,fn). Необходимо произвести внедрение программного продукта s на множестве заказчиков X(f0) и, кроме того, обеспечить возможность обновления версий s после внедрения и адаптации.

Случай III. Подчиненная подсистема s оказывает обратное влияние на подсистему m. Необходимо обеспечить автоматическую реорганизацию подсистемы s в процессе развития взаимодействия в паре S(m,s).

· Пример проектирования. Проект системы для программного обеспечения со слоистой структурой. Пятерка J(VT,VL,IS0,F,L) определяет механизм сборки системы s. Автоинжиниринг определяется как совокупность компонент: метакод D=(d1,d2,…,dM), выборка R=X-1(Is,D) и правило выбора шаблона сборки rÎR.

· Распознание ситуации. Самосборка имеет место только в том случае, когда механизм сборки полностью или частично интегрирован в продукт. К автоижинирингу следует прибегать тогда, когда технологический процесс самосборки на i+1 фазе связан с выбором альтернатив, а значения критериев выбора до начала сборки неизвестны.

Структура. На UML-диаграмме кооперации (см. рис.) показаны основные участники процесса самосборки (используется синтаксис Smalltalk).

· Участники. Объект a: IsPair определяет пару S(m,s). Бизнес-процесс m представлен объектом m: IsMaster, подчиненная система – как кооперация объектов aSoft:Informatory и s: IsSlave (футляр aSoft). Непосредственно процессом регенерации управляет объект aMeta: MetaCode. Объект aMem используется для хранения актуального состояния объекта aSoft (паттерн Memento).

· Отношения. В штатном режиме объект m обменивается сообщениями с объектом aSoft. Объект s управляет процессом создания и перезагрузки aSoft. При отправке сообщения connectInfSys объекту s объект aSoft выступает как параметр; метод возвращает новый экземпляр объекта. По завершению периода опытной эксплуатации объект m асинхронно получает сообщение makeSpec и возвращает объект aSp (новая спецификация). Это вызывает посылку сообщения designSoft объекту s с параметром aSp, который генерирует сообщение для объекта aMeta и вызы-

вает его метод swiitchOn. В результате выполнения последнего становится активным некоторый сегмент метакода. При посылке сообщения supportSoft производится атомарная операция перезагрузки классов aSoft под управлением объекта aMeta.

Все три процесса (в модели на Smalltalk-нити) – штатный режим, регенерация и проектирование – выполняются параллельно. Синхронизация процессов реализована посредством паттерна Observer (в модели на Smalltalk-механизм семафоров). Объект a обеспечивает также сопряжение интерфейсов m и aSoft.

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

Родственные паттерны. Паттерн самосборка похож на паттерн Builder, но в отличие от последнего относится к паттернам поведения и инкапсулирует характерные для самосборки взаимодействия между объектами системы. Как в большинстве паттернов фигурируют два вида объектов: новый объект s: IsSlave, который инкапсулирует данный аспект, и существующий объект aSoft, который пользуется первым.