CC BY
66
УДК 004.415.2
ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ДЛЯ СПЕЦИФИКАЦИИ КОНЦЕПТУАЛИЗАЦИЙ В ПРОЕКТИРОВАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ
П.И. Соснин1, В.А. Маклаев2
1 Ульяновский государственный технический университет sosnin@ulstu. гы
2 ОАО ФНПЦ «Научно-производственное объединение «Марс» mars@mv.ru
Аннотация
Совершенствование потоков работ, обеспечивающих спецификации концептуализаций, способствует повышению степени успешности проектирования современных автоматизированных систем. В статье предлагаются новые формы и средства спецификации, в основу которых положено оперативное построение и использование онтологии проекта в процессах его пошаговой детализации, вопросно-ответного анализа проектных задач и их моделирования как прецедентов.
Ключевые слова: автоматизированные системы, вопросно-ответное моделирование, проектный прецедент, псевдо-кодовое программирование, спецификация концептуализаций, онтология проекта.
Введение
Наиболее существенным индикатором зрелости инженерной деятельности определённого вида является реально наблюдаемая степень успешности её результатов, которую целесообразно определять статистически. В этом плане говорить о достаточной зрелости «инженерии разработок систем, интенсивно использующих программное обеспечение (Software Intensive Systems, SIS)» не приходится, поскольку степень успешности такой деятельности до сих пор чрезвычайно низка (около 35 %) [1], что приводит к безвозвратным ежегодным потерям в сотни миллиардов долларов.
Сам факт такого объёма финансовых потерь, независимо от подходов и способов оценок успешности, требует изменения существующего положения дел, основная причина которого негативные проявления человеческого фактора на ранних этапах проектирования SIS [2]. Перелома в положении дел разумно ожидать от достижения достаточной зрелости «инженерии интеллектуальной активности проектировщиков в концептуальном проектировании SIS». Другими словами, перелом не возможен без комплексной автоматизации концептуальной деятельности проектировщиков SIS.
Необходимость инженерии концептуальной деятельности осознана достаточно давно. Так, например, в практике разработок SIS такое осознание привело к созданию «инженерии требований (requirement engineering)», которая активно развивается последние 20 лет [3]. Более того, в настоящее время в практику программной инженерии активно внедряются методы и средства «инженерии знаний (knowledge engineering)» [4] и «инженерии онтологий (ontology engineering)» [5]. Каждая из названных инженерий вводит элементы автоматизации в концептуальную активность проектировщиков. Их согласованная интеграция и развитие должны привести к зрелой инженерии разработок SIS.
В статье представляется комплекс средств, предназначенный для спецификации концептуализаций, порождаемых коллективом проектировщиков в концептуальном проектирова-
нии SIS. Отличия предлагаемых средств от известных инструментальных решений определяют вопросно-ответный подход к коллективной концептуальной деятельности и её структуризация, в основу которой положены прецеденты, ориентированные на активное участие в их исполнении как разработчиков SIS, так и их пользователей. Особое место в статье отводится средствам (без деталей процессов) оперативного формирования и использования онто-логий проектов SIS.
В завершение введения отметим, что в российской нормативной базе класс «Автоматизированных Систем (АС)» является родственным классу SIS и всё отмеченное выше для класса SIS справедливо и для класса АС. По этой причине все последующие предложения и рассуждения будут относиться к классу автоматизированных систем.
1 Исходные предпосылки
Особенности авторского подхода к спецификации концептуализаций обусловлены следующими исходными предпосылками:
■ Необходимо учитывать и специфицировать те и только те концептуализации, которые находят явное представление в концептуальном проекте разрабатываемой АС;. Такая установка предохраняет от бесконтрольного использования лексики в нормативных проектных документах и в рабочих текстах, регистрирующих оперативные рассуждения проектировщиков для индивидуального и общего пользования. Бесконтрольность употребления лексических единиц в процессе проектирования считается опаснейшим (потенциальным) источником концептуальных ошибок.
■ Спецификации концептуализаций должны разрабатываться как специализированная автоматизированная система АС\ представляющая разрабатываемую АС; концептуально и предназначенная (как концептуальный проект в его текущем состоянии), в первую очередь, для обеспечение адекватного понимания их содержания проектировщиками и другими лицами, заинтересованными в разработке АС.
■ Основным системообразующим ядром системы спецификаций АСК; должна быть онтология проекта, которая создаётся в процессе специфицирования концептуализаций как специализированная автоматизированная система АС0;, предназначенная для представления концептуального базиса (концептуальных конструктов), на основе которых строится система АСК;. Разработку АС; должна сопровождать её и только её онтология проекта АС0;, в построении которой целесообразно использовать концептуальные конструкты из любых полезных источников.
■ Системообразующей основой системы концептуальных конструктов АС°; должна быть система понятий, сопровождающих разработку концептуального проекта АС;. Онтология проекта АС°; должна быть материализована в виде, который обеспечивает потенциальное использование её конструктов в разработках родственных (АС]}.
■ Спецификации должны быть материализованы в интерактивной форме, способствующей различным группам их пользователей взаимодействовать со спецификациями так, чтобы адекватным образом понять их концептуальное содержание на любом этапе жизненного цикла АС;.
■ Адекватность понимания спецификаций, представляющих концептуальные конструкты с алгоритмическим содержанием, должна достигаться, при необходимости, с помощью имитационных экспериментов с прототипами. Проектировщик в таких экспериментах должен выполнять роль «процессора».
■ Форма материализации спецификаций должна быть такой, чтобы их было легко корректировать, если в них обнаружены ошибки или элементы, затрудняющие их понимание.
■ Содержание, вложенное в спецификации, должно быть достаточным для успешного построения всех составляющих разрабатываемой АС.
Содержание предпосылок было использовано как основной источник требований при разработке комплекса средств, обеспечивающего построение и использование онтологии проекта разрабатываемой АС. Этот комплекс создан в виде совокупности специализированных расширений (plug-ins) инструментальной среды WIQA (Working In Questions and Answers), предназначенной для концептуального проектирования АС коллективом разработчиков.
2 Инструментальная среда концептуального проектирования
Инструментальная среда WIQA изначально разрабатывалась для моделирования совокупностей типовых и предметных проектных задач, которые приходится решать разработчикам АС. Как источник типовых задач были использованы типовые задачи потоков работ концептуального проектирования в мастер-методологии Rational Unified Process (RUP) [6]. По предназначению и содержанию WIQA разрабатывалась как специализированная ACT технологического типа.
При использовании инструментария WIQA в концептуальном проектировании конкретной ACi с ней связывалась исходная (корневая) предметная задача Z*i разработки АС\ для построения решения которой применялся метод пошаговой детализации. Пошаговая детализация была ориентирована на порождение подчинённых задач и активное использование в процессе поиска решения вопросно-ответных рассуждений проектировщиков и типовых (технологических, служебных) проектных задач. Более того, любая задача проектирования (корневая, предметные подчинённые и типовые подчинённые) в процессе решения представлялись вопросно-ответными моделями (Question-Answer models, QA-models, QA-моделями), каждая из которых содержала текущее состояние вопросно-ответных рассуждений (QA-рассуждений), использованных в построении решения соответствующей задачи. Именно из QA-рассуждений проектировщиками извлекались очередные подчинённые задачи пошаговой детализации. Обобщённая схема такой версии концептуального проектирования приведена на рисунке 1.
Z*(t)
_ Z, _
Библиотека типовых
проектных задач >
О
г о Ч _
Э 1 3 —
о а. Z о п
« wi я из V С п СС <и а С 1 и J
If
Zu Zu . Z\m
-рЗ^;
Z„
Z21 Z2 2 Zjn
л
Итеративный процесс +
Управляемое распределение задач в коллективе
f
Zpf Zp2
2pr
\ +
xv Пошаговая детализация
v\
^ +
Вопросно-ответный анализ
Рисунок 1 - Пошаговая детализация в концептуальном решении задач проектирования
Одной из важнейших особенностей представленной версии концептуального проектирования является потенциальное применение всех средств инструментария WIQA к любой задаче Zi дерева Т(^}) проектных задач если в этом будет необходимость. В таком применении задача Zi представляется её QA-мoдeлью QA(Zi), обобщённая структура видов которой приведена на рисунке 2.
Рисунок 2 - Система видов рЛ-модели задачи
Все виды интерактивно доступны с любого рабочего места группы проектировщиков (разумеется, в рамках полномочий). Каждый вид содержит декларативную часть (артефакты вида) и процедурную часть (средства формирования и использования артефактов), которые подробно раскрыты в [7]. Центральное место в рЛ-модели занимают задачный и логико-лингвистический виды, представляющие систему постановок задач и вопросно-ответную структуризацию их решений с поясняющими диаграммными схемами и иллюстрациями других типов (если необходимо или полезно). Интерфейсная форма доступа для задачного вида и логико-лингвистического вида (в форме протокола рЛ-рассуждений) представлена на рисунке 3.
Рисунок 3 - Структура и представление задач и их рЛ-моделей
Более детально, любое образование любого из Z-, Р- или А-типов представляет собой интерактивный объект, для обозначения которого введём символику 0Ь_РЛ.1, где QA.I -индексное имя задачи, вопроса или ответа, специфицирующее тип и место объекта в иерар-
хии объектов (отметим, что задача тоже вопрос, но «задачного типа», ответом на который является решение задачи).
Свойства любого из объектов {Ob_QA.I} открываются в интерактивном взаимодействии с проектировщиком. Та часть любого QA-объекта, которая визуально доступна на интерфейсной форме рисунка 3, выступает в роли «посредника» между объектом и проектировщиком, открывающим ему доступ к любому из свойств объекта или любой их группе, если в этом появляется необходимость. Затребованные свойства доступны через команды интерфейса и плагины. Любой «посредник» открывается перед проектировщиком через его текстовое описание (постановка задачи, формулировка вопроса или ответа) и индексное имя, представляющее тип (или подтип) объекта и его «место» в иерархии дерева задач или QA-протокола. Индексное имя полезно интерпретировать и использовать как «адрес» объекта в их системе (в вопросно-ответной базе, QA-базе.)
В совокупности свойств любого QA-объекта, например Ob_Z.I, Ob_Q.J или Ob_A.K, различаются:
■ базовые свойства, каждое из которых представляется с помощью соответствующего атрибута QA-базы;
■ дополнительные свойства (дополнительные атрибуты), которые вводятся адресно, то есть приписываются конкретному QA-объекту или их определённой группе с помощью средств объектно-реляционных преобразований (специальное расширение в инструментарии WIQA).
Потенциал QA-моделирования, вложенный в инструментарий WIQA, достаточен для представления концептуализаций любых типов (тексты, таблицы, диаграммы, диаграммные схемы и композиции отмеченных форм), а также любого содержания, которые используются в проектировании ACi. Всё связанное с использованием языка проекта, интерактивно доступно с рабочих мест проектировщиков, участвующих в разработке ACi.
Особое место в осуществлении концептуализаций занимает текстовая информация, используемая в каждом Ob_QA.I и являющаяся его составной частью, для обозначения которой введём следующую символику L.I(t)= PL(Ob_QA.I(t)), где PrL - проекция объекта на использование языка проекта ACi, t - момент времени жизненного цикла объекта Ob_QA.I(t). В обозначении учтено, что каждый объект ObT_QA.I(t) является динамическим конструктом, который формируется (порождается) по ходу проектирования ACi. Часть L.I(t) соответствующего QA-объекта также является динамическим конструктом.
В общем случае проекция L.I(t) включает следующие составляющие:
■ T.I(t, tn) - текущее описание объекта, зарегистрированное в момент времени tn и доступное проектировщику непосредственно через интерфейсную форму, представленную на рисунке 3;
■ T.I(tn-1) - все предыдущие версии описания объекта, изменения которых раскрывают динамику формирования описания;
■ DC(t, tn) - черновик (draft copy), раскрывающий «черновые записи», включая информационные источники, на основе которых сформировано состояние T.I(t, tn);
■ другие употребления языка проекта, которые раскрываются при использовании плагинов, применимых для объекта Ob_QA.I;
■ для объекта Ob_QA.I, в составе которых имеются подчинённые, проекция L каждого из подчинённых включается в L.I(t), но её содержимое становится доступным при выборе этого пождчинённого объекта.
При порождении (построении) концептуализаций среди названных составляющих особое место занимает система S({T.I(t, tn)}), объединяющая (как это показано на рисунке 3) текущие описания всех объектов, сформированных и используемых в процессе проектирования
AQ в текущий момент времени. Именно лексика этой системы и является лексикой языка проекта, употребления которой должно быть обязательно доведено до явных референций на то, что найдёт материальное воплощение в ACi. Именно из составляющих системы S({T.I(t, tn)}) и их содержания должна разрабатываться онтология проекта.
3 Процесс концептуализации
Жизненный цикл любой ACi начинается с осознания определённой связной совокупности потребностей, выраженной и зарегистрированной в текстовой форме (пусть текстом T0) на естественном или естественно-профессиональном языке. Если реакция на выделенную совокупность потребностей приведёт к решению о разработке ACi, то с этого текста T0 начнётся процесс концептуализации её проекта.
Если процесс начинается в среде WIQA, то текст T0 оформляется как исходная постановка задачи Z*(ACi), регистрируемая в дереве задач проекта ACi в виде текста T*I(t0, t0), форма и содержание которого должна удовлетворять определённым требованиям [8]. В этом плане текст T*I(t0, t0) является исходной (первой) концептуализацией проекта ACi. По ходу разработки текст T*I(t, t0) без изменения формы корректируется и уточняется, его лексика приводится к языку проекта, а содержание специфицируется. Так как задаче Z* подчинены все остальные задачи проектирования ACi, то спецификацией этой концептуализации логично считать концептуальный проект ACi.
Выше было отмечено, что проектирование осуществляется в формах пошаговой детализации, в которой к любой задаче дерева задач, формируемого по ходу проектирования (по ходу пошаговой детализации), применимы все необходимые средства инструментария WIQA. В результате строится QA-модель задачи, включающая концептуализации и их спецификации, вложенные в соответствующие виды модели (рисунок 2). Формы концептуализации задачного и логико-лингвистического видов представлены выше. Остальные формы раскрываются, заполняются концептуализациями, специфицируются и интерактивно доступны с помощью специализированного набора плагинов, встроенных в WIQA.
Общим для всех форм концептуализации является то, что они ориентированы на единообразную интерпретацию любой задачи дерева задач - за задачей стоит проектный прецедент, который либо применяется в той «точке» дерева задач, где он расположен, либо строится для повторных применений в будущем, например, пользователем проектируемой ACi. Прецедент - это активность человека или группы лиц, связанная с действием или решением или поведением, осуществлённым в прошлом, которая полезна как образец для повторных использований и/или оправдания повторных действий по такому образцу [9].
Любой прецедент для обеспечения его повторных применений должен быть подготовлен. Другими словами для повторного осуществления прецедента должна быть создана его модель (схема), применение которой позволит исполнителю или исполнителям повторить закодированные в модели прецедента действия. Учитывая то, что прецеденты лежат в основе человеческого опыта, в который их модели включаются подобно условным рефлексам, а вернее интеллектуально обработанным условным рефлексам, инструментарий WIQA настроен на типовую модель прецедента [10] с обобщённой (интегральной) схемой, представленной на рисунке 4.
В набор практически полезных моделей прецедента, порождаемых в процессе его разработки, включены:
■ текстовая модель P, представляющая постановку задачи Z(P\), в результате решения которой создан образец прецедента (как определённый результат интеллектуального освоения реального прецедента);
■ логическая модель F^, конкретизирующая типовую логическую модель (представлена на рисунке 4) в виде формулы логики предикатов, записанной на языке постановки задачи
PT;
■ графическая модель прецедента P, представляющая его обобщённо с использованием «block and line» средств (например, диаграммы активности на языке UML);
■ вопросно-ответная модель F°A, соответствующая задаче Z(P);
■ модель F, представляющая вложенное в прецедент поведение исходным кодом его программы;
■ модель F®, выводящая на исполняемый код программы, кодирующей образец прецедента;
■ интегральная (схематическая) модель прецедента P в виде его схемы, объединяющей все специализированные модели прецедента в единое целое.
имя прецедента
так как [формула (Фм) для мотивов
поскольку г Ф для целей {Снесли [Ф 1 для предусловия Т Г].
то реакция гч(щ, из-за чего [Ф11 для постусловия II"]
en ь альтернанты [Ггр}].
PTi
PLi
pQA
p°i
p'i
pEi
Прецедент Pi
Имя
Ключи
Рейтинг
Рисунок 4 - Модель прецедента (жизненный цикл и интегральная схема)
Представленная типовая модель прецедента (совокупность специализированных моделей и их объединение) используется для представления как прецедентов разрабатываемой АС;, так и для представления прецедентов технологии, включая, например, прецеденты документирования и использования стандартов. Другими словами, прецедентный подход систематически применяется для задач формирования и использования всех видов, включённых в ОА-модель задачи (рисунок 2).
Система видов ОА-модели и типовая модель прецедента специфицированы так (содержат совокупность декларативных и процедурных форм), чтобы с их помощью можно было специфицировать концептуализации любых типов и любого содержания, которые было решено включить в концептуальный проект АС;. С их помощью можно выразить и специфицировать концептуализации функциональных и нефункциональных требований, ограничений и принятых решений с декларативным и алгоритмическим содержанием.
4 Средства формирования и использования онтологий проектирования
В концептуализации АС; особое место занимает лексика Ьл(1;) языка проекта Ьп(1;), для спецификации которой используется онтология проекта АС°; (1). С инструментальной средой 'ЩА как специализированной АСТ также связана лексика её языка и онтология '1-
ОА°(1;), развиваемая за счёт расширений ('ЩА открытая система инструментальных средств). Так, что проектировщикам в их оперативной работе приходится использовать два связанных языка Ьп(1;) и , согласованных с онтологиями АС°; (1) и '1ОА°(1). На проек-
тировщиках лежит ответственность только за формирование языка Ьп(1;) и онтологии АС°; (1). Вся информация, необходимая и достаточная для таких построений, а вернее для построения текущих состояний Ьп(1;) и АС°; (1), присутствует в системе 8({Т.!(1;, 1п)}).
В общем случае построения Lп(t) и АС°; (^ начинет осуществляться с «пустых» состояний, но в любом случае и в любом и в любом их состоянии в основу развития языка и онтологии в WIQA положен предикативный анализ простых предложений, извлекаемых из текстов системы S({T.I(t, 1п)}). Обобщённая схема формирования онтологии АС^ (^ приведена на рисунке 5.
Логический процессор
о H Статья 1
T о Статья 2
>л
о
г
и я Статья N
уТолковый словарь (Тезаурус) WIOA
Рисунок 5 - Обобщённая схема формирования онтологии проекта
Средства предикативной обработки текстовой информации, вложенной в поток {T.I(t, tn)}, доступны как «Лингвистический процессор» с каждого рабочего места проектировщиков, разрабатывающих ACi. Эти средства объединены с другими (Рабочий словарь, Логический процессор, Онтология), представленными на рисунке 5, в единый комплекс LINA (Linguistic In Nominative Activity), обслуживающий логико-лингвистические потоки работ с языком проекта и его употреблениями. Комплекс LINA обеспечивает формирование языка проекта Ln(t) и его материализацию в виде онтологии AC°i (t) в процессах контроля текстов постановок проектных задач и текстов формулировок требований, ограничений и проектных решений. Другими словами, существенные действия по построениям Ln(t) и AC°i (t) включены в процессы контроля тех текстов в процессе проектирования и проекте, которые в обязательном порядке должны быть проверены на их правильность.
Когда (в определённых приложениях) вводится оценка «правильность», предполагается, что её значения можно проверить или явно или неявно. В рассматриваемом случае «правильность» введена для оценивания «понимания» теми лицами (субъектами, обозначим {Sbi}), которые используют или будут использовать постановки задач и формулировки требований, ограничений и проектных решений. Для успешности коллективного проектирования «правильность» должна быть проверяемой. Один из важнейших типов проверок на «правильность» должен быть связан с «достаточной степенью единообразного понимания», когда при взаимодействии любого Sbi c выбранной единицей T.I(t, tn) у него отсутствуют весомые причины для исправления T.I(t, tn) или составляющих этой единицы. Более того, если такие причины имеются, то Sbi обязан объяснить что, как и почему должно быть исправлено. Разумеется, для того, чтобы исправлять, то, что исправляется, должно быть написано.
К числу важнейших проверок на «правильность» относится и связь проверяемой единицы T.I(t, tn) «с её материальным представлением в проектируемой АС». Специфицируются только те концептуализации, которые обязательно найдут своё материальное воплощение в созданной АС. Более того, в такие спецификации должна вкладываться информация о референции, например, в форме адресных указаний на (все) материализации специфицируемой концептуализации. Разумеется, в спецификации должны присутствовать и указания на кон-
цептуализируемые (моделируемые) референты (по крайней мере, в виде примера или примеров).
Таким образом, для построения онтологии проекта необходимы средства, обеспечивающие контроль на правильность текстовых описаний, в первую очередь, в представленном выше смысле. В комплексе средств LINA контроль за правильностью лексики текста T.I(t, tn) обслуживает лингвистический процессор. Правильность лексики контролируется на уровне простых предложений в контексте их употребления. Поэтому на лингвистический процессор ложится задача анализа текста T.I(t, tn), для решения которой используется его автоматизированный перевод на язык логики предикатов простых предложений. Проверяемые семантические составляющие простого предложения 111 lijk , где i - индекс текста, j - индекс (номер) сложного приложения в тексте, k - индекс простого предложения в сложном, представлены на рисунке 6.
So
AS;
Рисунок 6 - Структура семантики простого предложения III lljk
Семантическая модель S(HHijk), используемая для спецификации его концептуального содержания, определена как аддитивная совокупность составляющих S(nnyk) = Sc(nnyk) +ZASm(nnyk),
в число которых включены:
So(nnijk) - предикатная модель PPijk, прошедшая проверку на соответствие онтологии;
ASi(nnijk) - синтаксемные характеристики [2] предложения ППук;
AS2(nnijk) - вероятностные характеристики ППук;
AS3(nnijk) - характеристики нечёткости свойства или отношения, названного в ППук;
AS4(nnijk) - причина управляющего воздействия на процесс проектирования;
AS5(nnyk) - вариант интерпретации проектировщиком содержания ППук.
Реальность семантических анализа ППук и проверок такова, что «вычисления» семантических составляющих могут быть прерваны из-за различных объективных причин (новое понятие, непонимание, неполнота знаний, преждевременность предикации, ...). Часть из этих причин приводит к вопросам, на которые следует найти ответ или построить его (развитие онтологии, управление процессом проектирования).
Контроль за правильностью текстов и их фрагментов типов «сложное предложение» или «группа сложных предложений» (например, абзац) обслуживается с помощью «Логического процессора», с помощью которого проектировщик решает задачу синтеза формулы логики предикатов для текста T.I(t, tn) или его фрагмента. Для контроля за правильностью формулы используется автоматизированное построение её диаграммного (block and line) представле-
ния. Для сборки простых предикатов в формулы используется библиотека шаблонов «сложных предложений, состоящих из двух простых» для русского языка. Формулы специфицируют концептуальное содержание текстов и их фрагментов. Построение каждой конкретной формулы осуществляется проектировщиком в операционной обстановке с использованием средств визуального редактирования.
Принципиальным типом формул логики предикатов для текстовых единиц является логическая модель PL проектного прецедента Р, построенная на основе его текстовой модели PT Одним из применений формулы PL является её использование для построений формулы PA доступа к прецеденту. В простейшем виде формула PA может представлять собой И-связку «k1& k2&....&kN» ключей {kn} доступа. Именно такой вид логического доступа (обозначим его f1({kn})) используется в комплексе WIQA для «грубого» доступа к прецедентам. Для повышения степени избирательности в комплексе WIQA предусмотрено построение формул доступа типа f2({kn}), в которых ограничения на использование логических операций сняты.
В осуществлении потоков работ, исполняемых с помощью лингвистического и логического процессоров, используются компоненты «Рабочий словарь», «Онтология» и «Толковый словарь», который не включён в комплекс LINA. Компонента «Рабочий словарь», выполняет функции «мягкой» версии онтологии, аккумулирующей всю извлечённую на текущий момент времени онтологическую информацию, для её распределения по статьям «Онтологии».
Каждая статья «Онтологии» включает информацию, проверенную в процессах контроля правильности и используемую в очередных процедурах контроля правильности. Более того, компонента «Онтология» содержит средства, обеспечивающие выполнение потоков работ для систематизации статей онтологии. В «Онтологии» поддерживается систематизация по следующему набору отношений «часть-целое», «род-вид», «ассоциация».
Компонента «Толковый словарь» включена в состав инструментария WIQA для исполнения традиционной нагрузки, возлагаемой на тезаурусы. В толковый словарь включают лексику и её определения (разных видов), к которой не предъявляют таких же жестких требований, как к лексике языка проекта Ln(t). В частности. в этот словарь вынесена лексика языка lwiqa, ориентированная на её использование проектировщиками AC¡.
5 Средства псевдо-кодовой спецификации онтологических конструктов с алгоритмическим содержанием
Основу лексики языка проекта составляют лексические единицы, которые используются в спецификациях проектных прецедентов, а вернее, используются в представлении их моде-
I Е
лей, в состав которых входят модели Р и Р . Для представления этих моделей в концептцу-альном проектировании, то есть для их концептуального представления и специфицирования, в состав комплекса '1ОА включены средства псевдо-кодового программирования. В каждой псевдо-кодовой программе специфицирован определённый объём использования естественного (или естественно-профессионального) языка в его алгоритмическом употреблении.
Отметим, что в типологии определений понятий выделяют, например, операциональные определения (процедуры измерения физических величин и других понятий), генетические определения (процедуры порождения определяемых объектов) и алгоритмические определения (алгоритмические схемы определяемых объектов).
Без использования понятий, содержание которых раскрывают определения отмеченных типов, невозможно создавать модели проектных прецедентов, так как:
■ в проверках условий доступа нельзя полагаться на умозрительное оценивание того, что стоит за понятиями, входящими в ключи доступа {кп} и логические формулы ^({кп}) и Г2({кп}), а следует использовать конструктивные вычисления их значений;
■ реакции гч(1), кодируемые в моделях прецедентов, в общем случае состоят из совокупности действий 8({ёрч(1:)}), связанных условиями их выполнения (например, последовательное выполнение действий, циклические выполнения, условные версии продолжения активности).
Особо важным является и то, что исполнение действий {ёрч(1:)} реакции гч(1:), предусмотренных их описанием в модели прецедента, может осуществляться человеком или группой лиц, использующих инструменты (например, компьютеры) или нет. А значит, алгоритмическое представление 8({ёрч(1:)}) для его исполнения в человеко-компьютерной среде (возможно с инструментами других типов) возможно, но оно должно ориентироваться на его исполнение связанной совокупностью «процессоров», включающих в самом простом случае человека, выполняющего роль «процессора» («интеллектуального процессора», 1-процессора), и компьютерного процессора (К-процессора).
В предлагаемом подходе к специфицированию концептуализаций любой проектный прецедент представляется в виде нормативной модели (рисунок 1), визуальные формы которой ориентированы на взаимодействия с проектировщиками, выполняющими функции 1-процессоров, использующих в таких взаимодействиях К-процессоры. Модели проектных прецедентов и их составляющих включаются в онтологию проекта в обязательном порядке. Именно по названным причинам в состав средств комплекса '1ОА для представления алгоритмического содержания прецедентов введены средства псевдо-кодового программирования. Комплекс средств псевдо-кодового программирования включает:
1) Язык псевдо-кодового программирования «'1ОА», конструкты которого ориентированы на создание псевдо-кодовых программ, согласованно исполняемых в инструментальной среде '1ОА совокупностью 1-процессоров и К-процессоров, используемых в процессах концептуального проектирования АС. В выборе названия языка (псевдо-кодовый алгоритмический язык «'1ОА») было учтено, что этот язык является встроенным алгоритмическим языком инструментария '1ОА (инструментария, обслуживающего процессы концептуального решения задач). Кроме уже отмеченной специфики, язык '1ОА позволяет: приписывать необходимую семантику традиционным типам данных; разрабатывать объектно-ориентированные псевдо-кодовые программы; разрабатывать прототипы программных решений, учитывающих обращения к базам данных. Так как имеется возможность настройки лексики языка «'1ОА» на проект конкретной АС;, то можно считать, что язык '1ОА входит в состав языка ьш°А как его составная часть, формализующая естественно-профессиональный язык (проекта) в его алгоритмическом употреблении.
2) Инструментальную среду псевдо-кодового программирования в следующем составе:
■ Редактор псевдо-кодовых программ, обеспечивающий построение исходного кода программ на языке '1ОА и его автоматическое преобразование в форму ОА-протокола программируемой задачи. Адресация в протоколе (вопросно-ответная индексация операторов программы) может быть привязана проектировщиком к точке загрузки в дерево задач или к хранению программы в библиотеке псевдо-кодовых программ. Для объявления переменных используется вызов «Мастера объявлений», настроенный на традиционные типы данных, но позволяющий расширять атрибутику объявления проектировщиком (например, вводить атрибутику, определяющую семантические характеристики переменной).
■ Компонента «Дополнительная атрибутика», предназначенная для объектно-реляционного преобразования ОА-объектов, в которые вложены операторы псевдо-кодовой программы. Именно за счёт функционала этой компоненты проектировщик (выполняющий роль про-
граммиста на языке WIQA) может приписать любому QA-объекту дополнительные атрибуты, в частности атрибуты типа для специфицируемой переменной.
■ Интерпретатор псевдо-кодовых программ, предоставляющий возможность I-процессору исполнять программу шаг за шагом, контролируя оперативные результаты исполнения операторов. Интерпретатор позволяет проектировщику выделить группу операторов программы и автоматически их выполнить. Исполнение программы (под контролем «Системы прерываний» инструментария WIQA) может быть прервано на любом шаге с возможностью возврата в «точку прерывания».
■ Компилятор псевдо-кодовых программ, обеспечивающий выполнение программ К-процессором в соответствии с алгоритмов, вложенным в программу. К такому режиму исполнения определённой программы логично переходить в условиях, когда её исполнение в режиме интерпретации I-процессором доведено до автоматизма (многократное исполнение доведено до навыка).
■ Компонента «Графический редактор диаграммных схем с интерактивностью», предоставляющая возможно «зарисовывать» интерфейсы для интерактивного связывания совокупностей псевдо-кодовых программ с возможностью передачи между ними данных. Редактор позволяет включать в комплексы программ такого рода необходимые exe-коды, если они есть и необходимы, а также вызов для демонстрации файлов, например doc-файлов.
Представленные возможности псевдо-кодовой спецификации концептуализаций полезны не только для представления алгоритмической семантики сложных концептов в онтологии проекта. С их помощью можно создавать исполняемы прототипы проектных решений, допускающие их имитационное моделирование, например, для проверки их правильности.
В завершение пункта и не более, чем с демонстрационными целями, представим одну из псевдо-кодовых процедур программы, обслуживающей диагностику и ремонт приборного блока:
Q 1.12 PROCEDURE &Отказ_ВМС& Q 1.12.1 ENDPROC &0тказ_ВМС& Q 1.12.2 CALL &Отключитъ_прибор& Q 1.12.3 CALL &Заменитъ_ВМС& Q 1.12.4 CALL &Включитъ_прибор& Q 1.12.5 INPUT &indSETVMS&
Введите 1, если индикатор СЕТЬ на лицевой панели BMC светится, 0, если не светится. Q 1.12.6 INPUT &indTGVMS&
Введите 1, если индикатор ТГ на лицевой панели BMC светится, 0, если не светится. Q 1.12.7 INPUT &indFACEVMS&
Введите 1, если есть изображение на лицевой панели ВМС, 0, если нет. Q 1.12.8 IF ( &indSETVMS& == 1) && ( &indTGVMS& == 1) && ( &indFACEVMS& == 0) THEN GOTO &UVS01FAIL& Q 1.12.9 LABEL &UVS01FAIL&
Q 1.12.9.1 Неисправность:Неисправность УВС.01 Q 1.12.9.2 CALL &Отключитъ_прибор& Q 1.12.9.3 CALL &Заменитъ_УВС_01& Q 1.12.10 Неисправность: Неисправность ВМС Q 1.12.11 CALL &Отключить_прибор& Q 1.12.12 RETURN
В представленной процедуре, и в проверке условий и в действиях, основная нагрузка ложится на человека (оператора, инженера в роли 1-процессора), ответственного за надёжную работу блока, в составе определённой АС. Действия процедуры считываются 1-процессором с экрана монитора и выполняются шаг за шагом (под контролем интерпретатора) в соответствии со складывающейся обстановкой в диагностике блока.
Заключение
В статье представлен комплекс средств спецификации концептуализаций, порождаемых и используемых в процессах проектирования автоматизированных систем. Основное внимание сосредоточено на средствах, обслуживающих концептуальный этап проектирования, на котором концептуальные ошибки наиболее опасны и дорогостоящи. Детали использования средств из интересов статьи (в основном из-за её объёма) исключены.
Для спецификации концептуализаций, порождаемых в процессе пошаговой детализации проектных задач, разработана система интерактивных вопросно-ответных форм, заполняемых информационным содержанием - дерево проектных задач, вопросно-ответная модель задачи, вопросно-ответное представление проектного решения. Особое место в спецификациях отведено типовой модели прецедентов, поскольку основным предназначением спецификаций концептуализаций является их повторное многократное использование как в процессе разработки АС, так и в процессах её эксплуатации. К числу важнейших задач повторного использования концептуализаций отнесены задачи их единообразного понимания членами группы разработчиков и другими лицами, заинтересованными в создании АС и участвующими в её эксплуатации.
Центральное место в спецификациях концептуализаций отведено онтологии проекта, в статьях которой регистрируются базовые концепты (определения лексики проекта) и другие концептуальные конструкты (состоящие из связанной совокупности базовых концептов), материализованные в разрабатываемой (разработанной) АС. Средства формирования базовых концептов онтологии ориентированы на предикативный анализ правильности употребления лексики в текстах постановок задач, формулировок проектных решений и ограничений. В процессе анализа используются предикатные формы простых предложений. Для формирования составных концептуальных конструкций разработаны средства синтеза их формул в логике предикатов, для построения которых используются предикатные модели сложных предложений, состоящих из двух простых. Для составных концептуальных конструкций предусмотрено их разбиение на две (связанные ссылкой) части, одна из которых включается в онтологию, а другая либо в библиотеку, либо в базу прецедентов.
Для формирования концептуальных конструктов с алгоритмическим содержанием разработан комплекс средств их псевдо-кодового программирования на специализированном языке «^10А», встроенном (как и все предлагаемые средства) в инструментальный комплекс 'ШОА. Специфику языка определяет его настройка на формы спецификации, представленные выше. Потенциал языка «^10А» достаточен для создания имитационных моделей проектных решений в объектно-ориентированном стиле с использованием доступа к моделям баз данных или их фрагментов.
Список источников
[1] Reports of the Standish Group. http:// www.standishgroup. com (дата обращения: 03.03. 2012).
[2] Software Intensive systems in the future. Final Report//ITEA 2 Symposium. http://symposium.itea2.org/ sympo-sium2006/ main/publications/ TNO_IDATE_study_ ITEA_SIS_ in_the_future_Final_Report.pdf (дата обращения: 15.03. 2012).
[3] Westfall L. Software Requirements Engineering: What, Why, Who, When, and How. http://www.westfallteam.com/Papers/ The_Why_What_Who_When_and_How_Of_Software_Requirements.pdf. (дата обращения: 20.03. 2012).
[4] Kendal, S.L., Creen, M. An introduction to knowledge engineering. - London: Springer, 2007. - 287 p
[5] Falquet G., Metral C., Teller J., Ch. Tweed Ch. Ontologies in Urban Development Projects (Advanced Information and Knowledge Processing). v. VIII, - Springer-Verlag, 2011. - 241 p.
[6] Кролл П., Крачтен Ф. Rational Unified Process - это легко. Руководство по RUP для практиков. [Текст]. -М.: Изд. Дом Кудиц-Образ, 2004. - 432 с.
[7] Соснин П.И. Вопросно-ответное моделирование в разработке автоматизированных систем. [Текст]. / П.И. Соснин - Ульяновск:УлГТУ,2007. - 333 с.
[8] Соснин П.И. Вопросно-ответное программирование человеко-компьютерной деятельности. [Текст]. / П.И. Соснин - Ульяновск:УлГТУ,2010. - 240 с.
[9] Precedent. URL: http://dictionary.reference.com/browse/precedent. (датаобращения: 11.03. 2012).
[10] Sosnin P. Question-Answer Shell for Personal Expert System..// Chapter in the book "Expert Systems for Human, Materials and Automation." Published by Intech, 2011. - pp. 51-74.
Сведения об авторах
Соснин Пётр Иванович, 1945 г. рождения, д.т.н., профессор, заведующий кафедрой "Вычислительная техника" Ульяновского государственного технического университета. Член Международной академии информатизации, Российской и Европейской Ассоциаций искусственного интеллекта, член IEEE и Computer Society, член международного общества WSEAS, председатель Ульяновского отделения Российской ассоциации искусственного интеллекта, эксперт Министерства промышленности, науки и технологий, рецензент "Journal of Intelligent and Fuzzy System". Автор более чем 290 публикаций, в том числе в 9 монографий и 6 учебных пособий.
Peter Ivanovich Sosnin, 1945, doctor of technical sciences, professor, head of the department "Computer Science", Ulyanovsk State Technical University. Member of the International Academy of Informatisation, a member of the Russian and the European Associations of Artificial Intelligence, a member of IEEE and Computer Society, a member of international society WSEAS, chairman of the Ulyanovsk Branch of the Russian Association of Artificial Intelligence, Expert of Ministry of industry, Science and Technology, a re-viewer of "Journal of Intelligent and Fuzzy System". The research results are presented in more than 290 publications, including 9 monographs and 6 textbooks.
Маклаев Владимир Анатольевич, генеральный директор Федерального научно-производственного центра Открытое акционерное общество "Научно-производственное объединение "Марс", к.т.н.
Vladimir Anatolievich Maklaev, candidate of technical sciences , Managing Director, Federal Research-and-Production Center Open Joint-Stock Company "Research-and-Production Association "Mars"
