Вопросно-ответная модель задачи

В технологиях ООАП и АОП для структуризации процесса и результата разработки АС используется деятельностная единица, получившая название «задача». Такая структуризация, например, является базовой в инструментально-технологической среде Rational Unified Process (RUP), разработанной корпорацией IBM [Kroll at al., 2003]. Среда RUP является наиболее мощной по сравнению с аналогичными средствами ООАП и лидирует по объемам внедрений.

Из «задач» в PUP формируются как основные «потоки работ» («деловое моделирование», «требования», «анализ и проектирование», «реализация», «испытание», «развёртывание»), так и «потоки работ» поддержки («управление конфигурацией и изменениями», «управление проектом», «среда»). Объект «задача» выбран как базовый объект для QA-моделирования. Каждый экземпляр «задачи» в процессе разработки АС образуется по объективным причинам и проявляется как определённый вид (природно-искусственного феномена) «вопроса».

Перейдём к спецификациям QA-моделей и QA-моделирования:

• 1. Объектом QA-моделирования является «задача», причём с позиций тех рассуждений, которые приходится проводить в процессе построений «задачи» и ее решения лицами, вовлечёнными в этот процесс.
• 2. В определённый момент времени t₀ процесса построения экземпляра «задачи», когда в наиболее общем виде сформулирована постановка задачи Z (t₀), начинается формирование её вопросно-ответной модели QA (Z (t₀)):
• 2.1. С помощью методик обнаружения и идентификации «вопросов» из текста Z (t0) извлекается информация для построения исходной совокупности «вопросов» {Qi} как «объектов» процесса проектирования. Каждый «объект-вопрос» представляет собой динамический конструкт

QI (T_i, Sb¹_j, Sb²_k, t, G_n), (1).

который регистрируется в базе проекта АС с использованием следующей атрибутики: уникальное индексное имя QI, приписываемое автоматически; T_j — описание «вопроса»; Sb¹_j — идентификатор субъекта, ответственного за «вопрос»; Sb²_k — указатель на субъекта (в общем случае составного субъекта), заинтересованного в ответе на вопрос; t — момент времени, в который зафиксировано текущее состояние «вопроса»; G¹_n — другие атрибуты «вопроса» QI, представляющие его в базе проекта.

Содержание динамического конструкта QI формируется и уточняется с использованием достаточного объёма коммуникативного взаимодействия субъектов Sb¹_j и Sb²_k. Для поддержки такого взаимодействия разработана система методик обоснования, обсуждения, ревизии и оценивания.

В результате построений конструкта QI может быть выявлено, что он представляет «вопрос» типа «задача». Это факт приведёт к необходимости изменения статуса и представления конструкта QI в базе проекта, к его переименованию в конструкт ZJ и к необходимости построений QA-модели не только для задачи Z (t₀), но и для задачи ZJ. В представлении «задачи».

ZJ (T_p, Sb¹_q, Sb²_r, t, Ob_s G_m) (2).

важную функцию приобретает основной объект Ob_s, с которым (в рамках «задачи») производится работа.

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

QA (Z (t)) = S ({XI (Ti, Sb1j, Sb2k, t, Gn)}), (3).

состоящее из систематизированной совокупности вопросов и ответ. С каждым вопросом QI связан соответствующий ему ответ AI, что отражено в (3) с помощью переменной XI.

Содержание конструкта (3) обобщенно отражено на Рис. Оно включает совокупность QA-протоколов для задачи Z (t) и её подзадач, а также ряд схемных представлений QA-протоколов и их преобразований в сетевые модели.

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

2.3. Каждая версия систематизации предоставляет вариант «вида» на «задачу» с вопросно-ответной «точки зрения» на опыт, вовлечённый в разработку АС. Идея архитектурных «видов» и их композиций, составляющая сущность АОП, базируется на стандарте IEEE-1471−2000. Функция «вида» подобна функции проекции в геометрическом проектировании.

К числу «видов», раскрывающих сущность QA-моделирования, относятся:

«логический вид», фиксирующий систематизацию QA (Z (t)) в рамках логики вопросов и ответов;

«концептуальный вид», раскрывающий онтологию задачи Z (t) и процесса её решения, в том числе с помощью концептуальных моделей и рассуждений;

«коммуникативный вид», раскрывающий вопросно-ответные процессы как коммуникативное взаимодействие лиц, вовлечённых в работу над задачей ZJ;

«деятельностный вид», регистрирующий систему отношений между «вопросами» и «ответами» в их разных состояниях с позиций работ, выполняемых с ними как с объектами деятельности;

«вид с позиций опыта разработки АС», фиксирующий тот опыт, который используется в процессе работы с задачей и получен по ходу и в результате такой работы;

«вид с позиций стандартов», регистрирующий соответствие всего, что связано с задачей ZJ с рекомендациями и требованиями стандартов на разработку АС.

Каждый из представленных видов (шаг за шагом, переходя от состояния к состоянию) формируется по ходу работы с задачей и регистрируется в базе проекта. С каждым видом связана определённая совокупность «интересов», моделей и документов, а также система действий, обеспечивающих построение и использование видов.

3. Общий случай QA-модели задачи Z (t) определяется как интегральная совокупность «видов» на задачу, представленных в предыдущем пункте. Основу интеграции видов в QA-модель определяет совокупность логического и концептуального видов. С позиции реализации системы средств QA-моделирования связность обеспечивают структура данных, регистрирующая логический вид (Рис. 1), варианты её преобразования и представления, в том числе представления через результаты анализа.

Если задача Z (t) содержит множество подзадач {Z_i(t)}, то QA-модель строится для каждой из задач. В этом случае QA-моделирование задачи Z (t) может (в зависимости от цели моделирования) привести к необходимости включить в этот процесс QA-моделирование подчиненных задач. Самой важной из таких ситуаций является моделирование задачи разработки АС, для которой введём обозначение Z*(t). QA-модель этой задачи в виде QA (Z*(t)) = S ({XI (T_i, Sb¹_j, Sb²_k, t, G_n)}) содержит объекты XI всех типов, то есть типов QI, ZJ и AK.