CC BY
32
он будет создан на основе описания следующего интерпретируемого соответствия и назначен конечным фрагментом данной дуги управления.
На рисунке 2 приведен пример описания соответствия между понятием языка программирования Паскаль "Оператор присваивания" и конструкцией языка единого представления. Данное описание выполнено в соответствии с представленной выше моделью онтологии.
В работе изложена концепция подсистемы генерации единого внутреннего представления программ на основе описаний проекций языков программирования высокого уровня на единое представление. Приведен фрагмент модели онтологии
проекций языков программирования высокого уровня на единое представление и на примере продемонстрировано, каким образом на основе модели онтологии представляется фрагмент описания отдельной проекции. На основе предложенной концепции разработан прототип подсистемы генерации единого внутреннего представления программ в рамках системы преобразований программ в специализированном банке знаний о преобразованиях программ. Прототип реализован в среде программирования Java в среде разработки IntelliJ Idea с использованием ресурсов многоцелевого банка знаний (http://www.iacp.dvo.ru/es/ mpkbank).
САМОСБОРКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КАК ПАТТЕРН ПРОЕКТИРОВАНИЯ
В.И. Гурьянов (Региональный институт психологии и гуманитарных наук, г. Чебоксары)
Одним из способов преодоления барьера сложности технических систем может стать применение процесса самосборки. В частности, можно ожидать, что технологии, основанные на самосборке, окажутся полезными в решении проблемы адаптивности программных продуктов.
Изучение методологии проектирования систем, использующих процесс самосборки, удобно проводить на имитационной модели развития информационной системы в среде программирования Smalltalk. Для программного обеспечения со слоистой структурой возможно построение полной замкнутой модели инжиниринга.
Процессы адаптации, самосборка и самоорганизация
Одним из наиболее важных качеств программного обеспечения следует считать свойство адаптивности. Программный продукт изготавливается в предположении, что он будет эксплуатироваться в близких, но все же различающихся условиях. Пусть m - бизнес-процесс; s - информационная система. Взаимодействие осуществляется посредством интерфейса I=(f0, fi , ... ,fn), где f -прагматики, то есть идентификаторы элементов интерфейса. Обозначим множество пар S(m^,s^), цеЫ как E(f0) и введем множество спецификаций B(f0), такое, что V Is е B(f0), Is(0)=f0 , где f0 - атрибутная прагматика (общая для всех бизнес-процессов множества Е); Is=(f0,, fi5 ... , fn) - спецификация; Is® - j-й элемент кортежа Is. Процесс адаптации имеет три аспекта: прагматический, семантический и синтаксический. Под структурной адаптацией, которая имеет место на прагматическом уровне, будем понимать процесс реструктуризации программного обеспечения w таким обра-
зом, чтобы его интерфейс соответствовал заданному, то есть Ь=1^). В частности, развитие информационной системы можно рассматривать как структурную адаптацию. Адаптацию на семантическом и синтаксическом уровне будем называть параметрической.
Проблему адаптивности можно решить, если производить сборку технической системы непосредственно в среде эксплуатации. Самосборка -достижение определенного (заданного) устойчивого состояния динамической системы. При этом динамическая система может изменять свой элементный состав. Самосборка предполагает механизм сборки системы, интегрированный в саму систему. В частности, одним из таких механизмов может быть самоорганизация (см.: Тай М.Л. Динамика процессов самосборки. - Н. Новгород: Изд-во НГУ, 2000).
Ограничимся программным обеспечением со слоистой структурой. Особенность слоистых структур состоит в направленности связей со слоя 1 на слой 1+1, но не наоборот. Сопоставим каждой букве алфавита Ут={а0,а1,...,ап} некоторую прагматику Ге1§0 и обозначим фактор-множество как Ут/Р={ВДаьа2,...,ак}А1{ЬьЬ2,...,Ь,},..., ..,
2т}}, где Ут . Далее сопоставим каждой
букве а1еУт упорядоченную пару Ь1=({/1,...,/К1}, {гь...,гМ1}), где I - левые (входные), г - правые (выходные) связи. Пятерка 1(Ут,Уь,1в0,Р,Ь) определяет механизм сборки системы 8.
Процесс сборки представляет собой процесс развития системы и в общем случае требует описания в рамках теории развития сложных систем. Рассмотрим частный случай, когда процесс развития может быть описан ориентированными деревьями сборки слов. Пусть т - класс, 1(т) - его
множественный интерфейс, ч)- Введем
для интерфейса 1^е1(Т), множество вида ^{(^аьШьЬь),---^^)}, ^е^о, аъЬъ...^е Ут
и составим кортеж для УА,е1. Бу-
дем называть его базой опыта сборки, или мета-кодом объекта 8. Тогда можно говорить об отображении X: Б^1(Т). Пусть К=Х"1(1э). Таким образом, задача адаптации продукта э(Т) будет решена, если заданы отображение X и правило выбора шаблона сборки ге К.
Рассмотрим приведенную выше модель с точки зрения методологии проектирования. Во-первых, производится проектирование не самого продукта, а механизма, который создает этот продукт (пятерка 1(УТ,Уь,,180,Г,Ь)). Во-вторых, проектируется подсистема, которая вырабатывает проект изделия. Если разработка проекта также носит автоматический характер, то такой процесс развития системы будем называть автоинжинирингом (по аналогии с инжинирингом). Оба термина подчеркивают то, что процесс относится к искусственным системам.
Классифицировать системы с самосборкой можно по двум признакам. Во-первых, по типу подсистемы проектирования - активной (с участием инженера) или автоматической. Во-вторых, будем различать процессы самосборки с самоорганизацией и с подсистемой управления сборкой. Во всех случаях механизм сборки считается встроенным в продукт.
Название: самосборка - паттерн поведения объектов.
Назначение: подсистема продукта, обеспечивающая его синтез и реорганизацию в контексте среды эксплуатации и тем самым его адаптив-
ность.
Применимость.
• Ситуация. Можно рассмотреть, по меньшей мере, три ситуации, когда применение самосборки (в том числе автоинжиниринга) является оправданным.
Случай I. В результате воздействия внешних и внутренних причин состав требований т-элемента к 8-му элементу в паре 8(т,э) испытывают определенные колебания за время, большее, чем характерное время рефакторинга э-элемента. Необходимо обеспечить соответствующее изменение функциональности э-элемента за счет изменения его структуры.
Случай II. На множестве 2(10) пар 8(тц,8ц), це Н, задано множество спецификаций В(10), где 1 - атрибутная прагматика. Пары 8(тц,эц) различаются между собой вариантными прагматиками спецификации 18=(10,,Г1,...,ГП). Необходимо произвести внедрение программного продукта э на множестве заказчиков 2(10) и, кроме того, обеспечить возможность обновления версий э после внедрения и адаптации.
Случай III. Подчиненная подсистема э оказывает обратное влияние на подсистему т. Необходимо обеспечить автоматическую реорганизацию подсистемы э в процессе развития взаимодействия в паре 8(т,э).
• Пример проектирования. Проект системы для программного обеспечения со слоистой структурой. Пятерка 1(УТ,Уь,1в0,Р,Ь) определяет механизм сборки системы э. Автоинжиниринг определяется как совокупность компонент: метакод Б=(а1Д!,...4м), выборка К=Х-1(15^) и правило выбора шаблона сборки ге К.
1.2: с^дпвоЙ: а8р
а: ^Рап 2.1: suppoгt8oft s: Isвlave
♦-- 3: a8oft := connectInfSys: a8oft 3.1: аМет:= cгeateMemento 3.3: Destroy
-Сesign8oft() -mng() -specifySoft() -support8oft() +business() -гeLoaС8oft() +connectInf8ys() +Сesign8oft() +support8oft()
3.5: зе1Метеп1о: аМет 1.1: а8р := таке8р
3.4: Сгеа1е
т: IsMaster
+таке8р() +mMasteг1 ()
авоП: И^огта^гу
+answeг1 () +о^еМетейо() +тдшгу1 () +setMemento()
1.3: swiitchOn: а8р ^ 2.2: next Ж
3.2: wгite 3.6: геаС
Ч Ч
аМет: воПМет
+геаС() +wгite()
Диаграмма кооперации объектов пары S(m,s) при самосборке
• Распознание ситуации. Самосборка имеет место только в том случае, когда механизм сборки полностью или частично интегрирован в продукт. К автоижинирингу следует прибегать тогда, когда технологический процесс самосборки на 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. При отправке сообщения connectlnf-Sys объекту s объект aSoft выступает как параметр; метод возвращает новый экземпляр объекта. По завершению периода опытной эксплуатации объект m асинхронно получает сообщение makeSpec и возвращает объект aSp (новая спецификация). Это вызывает посылку сообщения designSoft объекту s с параметром aSp, который генерирует сообщение для объекта aMeta и вызы-
вает его метод swiitchOn. В результате выполнения последнего становится активным некоторый сегмент метакода. При посылке сообщения supportSoft производится атомарная операция перезагрузки классов aSoft под управлением объекта aMeta.
Все три процесса (в модели на Smalltalk-нити)
- штатный режим, регенерация и проектирование
- выполняются параллельно. Синхронизация процессов реализована посредством паттерна Observer (в модели на Smalltalk-механизм семафоров). Объект а обеспечивает также сопряжение интерфейсов m и aSoft.
Результаты. Можно сказать, что для систем с поддержкой автоинжиниринга результатом проектирования является саморегулирующая среда существования продукта, которая, в частности, порождает его. Благодаря этому продукт приобретает ряд ценных качеств, таких как адаптивность, конкурентоспособность и устойчивость к колебаниям конъюнктуры бизнес-среды.
Родственные паттерны. Паттерн самосборка похож на паттерн Builder, но в отличие от последнего относится к паттернам поведения и инкапсулирует характерные для самосборки взаимодействия между объектами системы. Как в большинстве паттернов фигурируют два вида объектов: новый объект s: IsSlave, который инкапсулирует данный аспект, и существующий объект aSoft, который пользуется первым.
АВТОМАТИЗИРОВАННАЯ СИСТЕМА УПРАВЛЕНИЯ КАДРОВОЙ ПОЛИТИКОЙ ПРЕДПРИЯТИЯ
С.Н. Недзиев (Волгоградский государственный технический университет)
Автоматизированная система управления кадровой политикой предприятия предназначена для повышения эффективности управления персоналом на промышленных предприятиях.
Система позволяет решать следующие основные задачи: повышение эффективности поиска персонала, повышение эффективности кадровых перестановок, реализацию долгосрочной стратегии управления кадрами.
Для повышения вероятности успеха в поиске специалистов кадровым работникам необходимо владеть информацией обо всех соискателях, желающих устроиться на вакантную должность. Для этого необходимо задействовать все возможные каналы получения информации о соискателях: личные рекомендации, объявления в газетах, резюме на сайтах для работодателей, предложения кадровых агентств и служб занятости. Некоторые виды операций по поиску и подбору персонала можно автоматизировать. Например, информацию
о вакансиях с указанием требований к кандидатам можно опубликовать на Интернет-порталах по трудоустройству, а также отправлять по электронной почте заинтересованным организациям, таким как службы занятости, кадровые агентства, и учебные заведения. Система автоматизации управления кадровой политикой предприятия позволяет обмениваться информацией с подобными организациями в автоматическом режиме. Благодаря этому, кадровые агентства своевременно получают информацию о вакансиях на предприятии, а предприятие владеет информацией о специалистах, ищущих работу, выпускниках вузов, желающих устроиться по специальности.
К расходам на кадровые перестановки можно отнести расходы на повышение квалификации работников, на обучение и адаптацию принятых на работу соискателей, выплату выходного пособия уволенным сотрудникам.
Принятие решения о переводе сотрудника на
