Содержание к диссертации
Введение
ГЛАВА 1. Методы конструктивного учёта причинно-следственного потенциала элементов проектной деятельности в процессах формирования и принятия проектных решений на этапе концептуального проектирования автоматизированных систем 13
1.1. Объектно-ориентированный анализ и проектирование автоматизированных систем 13
- 1.1.1. Особенности проектирования автоматизированных систем 13
1.1.2. Методологии анализа и проектирования автоматизированных систем 15
1.1.3. Rational Unified Process (RUP) 17
1.2. Базис конструктивного учёта причинно-следственного потенциала элементов проектной деятельности в процессе формирования и принятия проектных решений... 20
1.2.1. Варианты постановки задачи принятия решений 20
1.2.2. Типология инструментальных средств автоматизации проектирования 22
1.2.3. Вопросно-ответный подход к автоматизации проектирования 27
1.2.4. Способы оценивания проектных решений при проектировании автоматизированных систем 29
1.3. Принятие решений в проектировании автоматизированных систем 31
1.4. Элементы проектной деятельности и связанный с ними причинно-следственный потенциал 34
1.4.1. Структуризация проектной деятельности 34
1.4.2. Причинно-следственный потенциал проектной деятельности 36
1.4.2.1. Феномены мотивации и целеполагания. Различные трактовки мотивации 36
1.4.2.2. Целевая теория мотивации 41
1.4.2.3. Конструктивный учёт мотивации в автоматизированном проектировании 44
1.4.2.4. Конструктивный учёт целеполагания в автоматизированном проектировании 45
1.4.2.5. Конструктивный учёт предусловий, постусловий и нормативов в автоматизированном проектировании 48
1.4.2.6. Конструктивный учёт причинно-следственных закономерностей процессаи объекта проектирования 49
1.5. Постановка задачи 51
1.6. Выводы по главе 1 58
ГЛАВА 2. Разработка подхода к конструктивному учёту причинно-следственного потенциала элементов проектной деятельности в процессах формирования и принятия проектных решений 59
2.1. Мотивы и цели в процессах формирования и принятия проектных решений 59
2.1.1. Структура мотивов и целей проекта и её представление в вопросно-ответном протоколе 60
2.1.2. Мотивационно-целевая модель состояния проекта 70
2.1.3. Формализация зависимостей, имеющихся в мотивационно-целевой модели 73
2.1.4. Применение мотивационно-целевой модели в актах принятия проектных решений 82
2.1.5. Другие эффекты от применения мотивационно-целевой модели в проектной деятельности 94
2.2. Система причинно-следственных закономерностей проекта 96
2.2.1. Формализация причинно-следственных закономерностей вопросно-ответного протокола проекта 96
2.2.2. Спецификации причинно-следственных моделей состояния проекта 99
2.2.2.1. Модель схемы условного деятельности ого рефлекса задачи 99
2.2.2.2. Графовая модель задачной структуры проекта 102
2.2.2.3. Сетевые причинно-следственные модели 104
2.3. Выводы по главе 2 106
ГЛАВА 3. Методики конструктивного учёта причинно-следственного потенциала элементов проектной деятельности и их инструментальная поддержка 108
3.1. Система правил мотивационно-целевого и причинно-следственного сопровождения процесса принятия решений 108
3.2. Комплекс методик мотивационно-целевого и причинно-следственного сопровождения процесса принятия решений 115
3.3. Вопросно-ответный процессор NetWIQA 123
3.3.1. Структура процессора и назначение его компонент 123
3.3.2. Подключение дополнительных функциональных подсистем к вопросно-ответному процессору NetWIQA 126
3.4. Общая постановка задачи на проектирование комплекса средств мотивационно-целевого и причинно-следственного сопровождения процесса принятия проектных решений 128
3.5. Выводы по главе 3 137
ГЛАВА 4. Практическая реализация комплекса средств мотивационно-целевого и причинно-следственного сопровождения процесса принятия проектных решений 139
4.1. Детализация поставленных задач при помощи описания динамических аспектов вида системы сточки зрения прецедентов 139
4.2. Реализация подсистемы мотивационно-целевого и причинно-следственного моделирования 152
4.2.1. Вид системы с точки зрения проектирования 152
4.2.2. Адаптация вопросно-ответного процессора NetWIQA для обеспечения возможности решения поставленных задач 159
4.2.3. Вид системы с точки зрения реализации 163
4.2.4. Пользовательский интерфейс разработанных компонент 165
4.3. Пример использования разработанного комплекса средств в процессе принятия проектных решений 170
4.4. Оценивание эффектов совершенствования проектной деятельности за счёт использования предлагаемых методов и средств 176
4.5. Формирование библиотек типовых мотивов и целей проектной деятельности 179
4.6. Выводы по главе 4 183
Заключение 185
Библиографический список использованной литературы
- Методологии анализа и проектирования автоматизированных систем
- Формализация причинно-следственных закономерностей вопросно-ответного протокола проекта
- Комплекс методик мотивационно-целевого и причинно-следственного сопровождения процесса принятия решений
- Реализация подсистемы мотивационно-целевого и причинно-следственного моделирования
Введение к работе
Актуальность работы.
Результативность и многие другие важные характеристики процесса проектирования, в том числе и в актах принятия проектных решений (ППР), существенным образом зависят от того, насколько полно и последовательно используется причинно-следственный потенциал всего того, что вовлечено в работу.
Причинно-следственный потенциал проектной деятельности (ПД) является сложноструктурированным образованием, в состав которого входят:
совокупность мотиваций каждого члена группы проектировщиков и проектной группы в целом;
совокупность факторов, обеспечивающих степень мотивации по каждой из составляющих проектных работ;
рациональная система целеполаганий, используемая в проекте;
адекватный учёт причинно-следственных закономерностей процесса и объекта проектирования;
обязательное следование нормативам процесса проектирования;
набор предусловий и постусловий, учитываемых в процессе формирования проектных решений.
Конструктивный учёт и использование указанных причинно-следственных факторов деятельности позволяет добиться ряда полезных эффектов, направленных на совершенствование процессов проектирования. Однако, зачастую, в реальной практике проектных работ и их регламенте ряд из отмеченных выше элементов игнорируется. Исследование современных инструментальных средств, технологий и методов концептуального проектирования автоматизированных систем (АС) показало, что на практике они в достаточной мере обеспечивают конструктивный учёт условий и постусловий при помощи средств ресурсного планирования, а также средств задания требований и контроля за количественно оцениваемыми характеристиками систем. Кроме того, широко используются средства, обеспечивающие работу с различными нормативами процесса проектирования, такими как стандарты IDEF, UML, STEP, ISO.
Определённый опыт накоплен в области конструктивного учёта целеполагания, в частности - подход к управлению проектированием при помощи деревьев целей, представление целей в постусловной части продукции и т.д. Однако в существующих подходах цели (как инструменты оперативного контроля за ходом проекта) явно не
-7-связываются ни с эффектами, которые намечено достичь в проектировании, ни с проектными спецификациями, обеспечивающими достижение этих целей.
К сожалению, конструктивный учёт и использование мотивации в автоматизированном проектировании практически не проводится, хотя работу с данным феноменом вполне можно включить в практику ПД и одним из направлений использования мотивации может являться перевод в разряд мотивов нацеленности проектировщиков на достижение важных качественных характеристик. В автоматизированном проектировании эффективность и другие характеристики принято оценивать при помощи количественных показателей процесса и/или объекта проектирования в сопоставлении с прототипами, а в тех случаях, когда спецификации имеют качественный характер, они обычно декларируются без оценивания и аргументации. В то же время именно качественные характеристики в виде эффектов для пользователей ожидаемых от решения задачи проектирования стоят в основе проекта. Перевод таких характеристик в разряд мотивов, их представление в проекте в конструктивных формах, а также использование в ПД, позволит внести положительный вклад, как в сам процесс проектирования, так и в задачи управления им.
В истории психологии феномен мотивации широко исследовался, в частности, в работах Х.Хекхаузена, А.Маслоу, Д.Аткинсона, Л.Фестингера, Л.С.Выготского, Н.Н.Ланге, А.Ф.Лазурского, А.Н.Леонтьева и многих других. В диссертационной работе предлагается подход, решающий задачу обеспечения конструктивного учёта и использования мотивации с позиций целевой теории мотивации Э.Локе.
Другим важным аспектом совершенствования процессов ППР является учёт и использование в них причинно-следственных закономерностей и причин различных уровней в роли факторов. Конструктивный учёт и использование таких феноменов, как мотивация и целеполагание, позволяет организовать оценивание альтернатив в задачах ППР по субъективным критериям эффективности с точки зрения их значимости для пользователя, а конструктивная работа с логикой причинно-следственных закономерностей позволяет использовать специфические средства аргументации и организовать управление процессами ППР. Базовым средством решения задачи организации конструктивного учёта и использования причинно-следственного потенциала является инструментально-технологическая поддержка рассуждений различных типов.
Исследования в области объектно-ориентированного анализа и проектирования (ООАП) программных и автоматизированных систем связаны с работами таких
-8-зарубежных и отечественных учёных, как Г.Буч, И.Якобсон, Д.Рамбо, Э.Иорден, У.Ройс, Ф.Крачтен, П.Кролл, А.Кокбёрн, В.А.Семёнов, Н.Н.Мансуров, С.В.Морозов, О.А.Тарлапан, А.М.Вендров и др. Наиболее известной и широко применяемой для концептуального проектирования АС реализацией данного подхода является Rational Unified Process (RUP). Однако данная технология, равно как и другие родственные технологии, не содержит в своём составе средств моделирования рассуждений, в том числе связанных с мотивацией и целеполаганием, в то время как конструктивный учёт этих элементов ПД и других причинно-следственных факторов позволяет повысить эффективность действий проектировщиков, а также обоснованность и качество принимаемых проектных решений на ранних стадиях проектирования (в особенности при работе с требованиями). В результате сокращаются затраты и сроки проектирования, а также снижаются риски, связанные с успешностью завершения проекта.
На основании вышесказанного можно утверждать, что исследование и разработка системы методов и средств конструктивного учёта и использования причинно-следственного потенциала ПД (в том числе связанного с мотивацией и целеполаганием). направленных на совершенствование процессов ППР при концептуальном проектировании АС в корпоративных средах, является в настоящее время актуальной задачей.
Целью работы является разработка системы методов и средств, обслуживающих конструктивное включение в процессы автоматизированного проектирования причинно-следственных закономерностей, а также потенциалов мотиваций и целеполагания, обеспечивающих повышение рациональности действий проектировщиков в корпоративных средах за счёт включения в процесс проектирования дополнительных управляющих воздействий и дополнительных средств выбора.
В соответствии с поставленной целью в работе формулируются и решаются следующие задачи исследований:
Исследование и разработка системы мотивационно-целевых и причинно-следственных моделей проектов, исполняемых в вопросно-ответных корпоративных средах автоматизированного проектирования.
Разработка системы правил и рекомендаций для конструктивного учёта в процессах принятия проектных решений феноменов мотивации и целеполагания.
Разработка инструментария мотивационно-целевого и причинно-следственного моделирования в задачах управления и ППР в корпоративных средах автоматизированного проектирования.
Областью исследований диссертационной работы являются методы и средства ООАП, обеспечивающие конструктивное использование причинно-следственного потенциала ПД при разработке АС, нацеленное на формализацию проектных задач.
Объект исследований диссертационной работы составляют методы и средства решения задач управления и документирования в процессах ППР в корпоративных средах автоматизированного проектирования.
Специфику направления исследований диссертационной работы определяет рациональное использование в оперативной ПД объективных и субъективных факторов, в том числе связанных с мотивациями, которые позитивно воздействуют на характеристики активности и целеустремлённости проектировщиков.
Предмет исследований диссертационной работы составляет разработка мотивационно-целевых и причинно-следственных моделей состояния проекта, а также методик их использования в ППР и формировании базы опыта проектной организации.
Методы исследований основаны на использовании положений и методов содержательно-эволюционного подхода к интеллектуальной деятельности в человеко-компьютерных средах [103,106,107], целевой теории мотивации [123,146,147], теории принятия решений [30,60,67,69,70,80,89,98,99, 124], теории множеств [26], теории графов [116,120], теории автоматизированного проектирования [87,95], методологии объектно-ориентированного анализа, проектирования и программирования [27,29,62,63,113,119], методологии управления проектами [96,105,114,117].
Достоверность полученных результатов обеспечивается использованием достоверных знаний, методов и средств из теории множеств и теории графов, из прикладной информатики, программной инженерии, логики, целевой теории мотивации. Практический вклад в достоверность обеспечивается использованием разработанных средств в ПД, что подтверждается актом о внедрении.
На научную новизну претендуют:
1) Система мотивационно-целевых и причинно-следственных моделей проектов, сущность которой определяет система вопросно-ответных отношений между мотивами, целями и спецификациями процесса и результата автоматизированного проектирования. Использование таких моделей позволяет повысить эффективность управления ходом автоматизированного проектирования за счёт организации контроля за рациональностью принимаемых проектных решений; повысить качество принимаемых проектных решений за счёт обеспечения возможности выбора из альтернатив по критериям субъективной эффективности; облегчить понимание задачи и повысить доверие к результату решения
-10-за счёт явного представления структуры причинно-следственных закономерностей задачи; а также рационально организовать полученные результаты проектирования в форме специфических единиц опыта, что облегчает использование этих результатов в дальнейшем проектировании.
2) Система продукций, регламентирующая правила и методики работы с мотивационно-целевыми и причинно-следственными моделями в автоматизированном проектировании. В основе системы правил лежат вопросно-ответное представление типовых проектных решений и вопросно-ответный анализ ситуаций процесса проектирования, а представления методик согласованы с требованиями технологии ООАП Rational Unified Process.
Практическую ценность работы составляют:
Разработанная подсистема мотиваиионно-иелевого и причинно-следственного моделирования для QA-npoueccopa NetWIQA, обеспечивающая: а) регистрацию в QA-протоколе мотивов, целей, спецификаций, б) оперативное формирование мотивационно-целевых и причинно-следственных моделей состояния проекта, в) использование моделей в процессах ППР и в формировании базы опыта проектной организации. v.
Разработанная подсистема автоматизированного поиска в опыте для ОА-процессора NetWIQA, позволяющая осуществлять поиск единиц опыта различного типа (QA-единицы, вопросно-ответные прецеденты, схемы условных деятельностных рефлексов, МЦ-структуры) в вопросно-ответной базе опыта проектной организации, как по их тексту, так и по сходным мотивам и целям.
3) Разработанный комплекс методик мотивационно-иелевого и причинно-
следственного сопровождения ППР в автоматизированном проектировании с
использованием ОА-процессора NetWIQA.
4) Разработанная библиотека типовых мотивов и иелей проектирования АС.
Реализация и внедрение результатов работы. Разработанные программные средства и комплекс методик их использования в составе QA-процессора NetWIQA внедрены в проектную деятельность ФГУП НПО «Марс».
Апробация работы. Основные положения и результаты диссертационной работы докладывались и обсуждались на: международных конференциях «Interactive Systems: The Problems of Human-Computer Interaction» (IS-2003, IS-2005), г. Ульяновск, 2003,2005; международных конференциях «Континуальные алгебраические логики, исчисления и нейроинформатика в науке и технике» (КЛИН-2004, КЛИН-2005), г. Ульяновск,
2004,2005; девятой национальной конференции по искусственному интеллекту с международным участием (КИИ-2004), г. Тверь, 2004; ежегодных внутривузовских конференциях профессорско-преподавательского состава, г. Ульяновск, 2003, 2004.
Публикации. По материалам диссертационной работы опубликовано 10 печатных работ.
Структура и объём работы. Диссертационная работа состоит из введения, четырёх глав с выводами, заключения, библиографического списка использованной литературы (161 наименование), изложенных на 199 страницах машинописного текста. Диссертация содержит 51 рисунок и 8 таблиц.
В первой главе рассматривается методология ООАП АС; проводится анализ способов конструктивного учёта и использования различных причинно-следственных факторов ПД, а также достигаемых за счёт этого эффектов; описывается базис решения задачи организации конструктивного учёта и использования в процессах ППР причинно-следственного потенциала ПД в виде аналитического обзора, включающего варианты постановки задачи принятия решений, типологию средств автоматизации проектирования, основные положения вопросно-ответного подхода, способы оценивания проектов АС; показывается целесообразность усовершенствования широко применяемой технологии ООАП Rational Unified Process за счёт включения предлагаемых в работе методов и средств; разрабатывается МЦ-структура задачи исследований.
Во второй главе разрабатывается подход к конструктивному учёту причинно-следственного потенциала элементов ПД в процессах формирования и принятия проектных решений. Описываются структуры систем мотивов и целей проекта, их представление в вопросно-ответном протоколе проекта и взаимосвязь с системой проектных спецификаций. Определяются спецификации мотивационно-целевой модели состояния проекта, а также формализуются имеющиеся в ней зависимости в терминах каузальной логики. Описывается методика использования мотивационно-целевой модели для организации поддержки ППР на основе критериев субъективной эффективности. Формализуются виды причинно-следственных закономерностей QA-протоколов проектов, и описывается система причинно-следственных моделей состояния проекта, включающая модель схемы условного деятельностного рефлекса задачи, графовую модель задачной структуры проекта и ряд сетевых причинно-следственных моделей.
В третьей главе разрабатывается система правил практического использования мотивационно-целевых и причинно-следственных моделей состояния проекта. Предлагается комплекс методик мотивационно-целевого и причинно-следственного
-12-сопровождения процесса ППР, регламентирующих выполнение действий по формированию и анализу артефактов дополнительного потока работ RUP «Взаимодействие с опытом», который основывается на оперативном вопросно-ответном документировании хода проектирования. Отмечается рациональность разработки комплекса средств инструментальной поддержки предложенных методик и правил на базе QA-процессора NetWIQA и проводится анализ его архитектуры. Определяется общая постановка задачи на проектирование комплекса средств мотивационно-целевого и причинно-следственного сопровождения процесса ППР в виде системы функциональных требований, представленных прецедентной моделью системы.
В четвёртой главе осуществляется разработка подсистем мотивационно-целевого и причинно-следственного моделирования и автоматизированного поиска в вопросно-ответной базе опыта, которые комплексируются с системой NetWIQA и обеспечивают практическое применение разработанного во второй главе подхода. Представлена детализация поставленных задач при помощи описания динамических аспектов прецедентной модели UML-диаграммами взаимодействия, а также описан вид системы с точки зрения проектирования при помощи диаграммы классов и диаграмм деятельности для наиболее важных групп операций. Описываются изменения, внесённые в серверную часть QA-процессора для обеспечения его адаптации для решения поставленных задач, и представлена компонентная структура разработанной подсистемы. Описывается пользовательский интерфейс разработанных компонент с указанием основных доступных функциональных возможностей, приводится пример использования разработанных методов и средств, а также содержание разработанной библиотеки типовых мотивов и целей ПД. Проводится количественное оценивание эффектов совершенствования процессов работы с требованиями за счёт использования разработанных методов и средств.
В заключении констатируется, что поставленные задачи исследований, предполагающие разработку системы мотивационно-целевых и причинно-следственных моделей состояния проекта, системы правил и методик по их использованию в автоматизированном проектировании, а также реализацию их инструментальной поддержки, решены. Перечисляются основные эффекты, достигнутые в результате решения задач исследований, и указываются ближайшие перспективы дальнейшего развития разработанного подхода и комплекса инструментальных средств.
Методологии анализа и проектирования автоматизированных систем
В ЖЦ АС выделяется 3 технологических процесса - анализ, синтез, сопровождение. В ходе анализа выявляются разнообразные требования к будущей системе, а в ходе синтеза обеспечивается реализация предъявленных требований. Содержание синтеза составляют 3 этапа ЖЦ - проектирование, кодирование и тестирование, а ключевым из них является процесс проектирования. Исходными сведениями для работы на этом этапе являются информационные, функциональные и поведенческие модели анализа, а результатом - разработка данных, архитектуры и процедур.
Исторически первой проработанной методологией разработки АС была методология структурного анализа и проектирования АС, ориентированная на процедурную реализацию систем. Она возникла в ходе революции, вызванной структурным программированием, когда базовые структуры программирования стали распространять на всю область конструирования сложных АС. Из числа формализованных методов структурного анализа требований можно выделить методику SADT, предложенную Россом в 1973 г. [77,155] и впоследствии ставшую основой стандарта IDEF0, метод структурного анализа Де Марко [135], в которых система рассматривается как преобразователь информационного потока данных и описывается
-16 при помощи иерархически организованных диаграмм потоков данных (Data Flow Diagram - DFD). Также можно отметить методы, ориентированные на структуризацию данных и представляющие их иерархию в виде специальных диаграмм - метод Варнье-Орра [151,161], метод Джексона [141]. Наиболее известные методы проектирования, относящиеся к структурной методологии - методы структурного проектирования, направленные на формирование иерархической структуры систем [153,160], и метод Джексона [141], в котором определяется структура процессов и объектов системы.
С течением времени, усложнением разрабатываемых АС и с необходимостью сокращения сроков разработки, появилась методология ООАП. Основными её преимуществами явились возможность повторного использования элементов проекта и сокращение числа возможных ошибок несогласованности. ООАП АС основывается на принципах абстрагирования, инкапсуляции, модульности, иерархической организации, их совместное применение рассчитано на проведение объектно-ориентированной декомпозиции сложной системы в виде структур классов и объектов, что обеспечивает простое и обозримое для человека представление системы. Существует несколько различных вариантов объектно-ориентированной методологии.
Методология объектно-ориентированного анализа (ООА) предложенная Кодом и Йорденом [134] позволяет адекватно отобразить предметную область в системе и создаёт условия для создания надёжного и легко перестраиваемого проекта. ООА включает 5 основных шагов по определению: 1) предметной области, 2) объектов предметной области, 3) структуры объектов, 4) атрибутов объектов, 5) методов поведения объектов и взаимодействий за счёт посылки сообщений между объектами. Соответственно модель ООА включает схемы, соответствующие каждому указанному шагу.
Бучем был предложен подход к объектно-ориентированному проектированию (ООП) [27], в процессе которого решаются следующие задачи: 1) выбор классов и определение взаимосвязей между ними, 2) определение механизмов взаимодействия объектов, 3) выбор места объявления классов и объектов, 4) распределение вычислительных процессов между исполнителями (процессорами) и методы управления процессами. При этом наблюдается некоторая терминологическая путаница с ООА -объекту в ООА соответствует класс в ООП, а экземпляр объекта из ООА в ООП называется объектом. Проект в данном подходе включает в себя совокупность диаграмм, которая представляет функционирование системы в виде взаимодействия объектов и состоит из: 1) диаграмм классов, 2) диаграмм объектов, 3) диаграмм модулей, 4) диаграмм процессов, 5) диаграмм переходов, 6) временных диаграмм.
Наиболее известной реализацией методологии ООАП, претендующей на роль мирового корпоративного стандарта, является технология Rational Unified Process (RUP) [62,63,126]. RUP была предложена корпорацией Rational Software, ныне входящей в состав IBM, на основе анализа деятельности наиболее успешных компаний, и представляет собой структурированную базу знаний, формализующую технологический процесс разработки. RUP представляет собой методологическое руководство, в котором подробно рассказывается когда, кто и что должен делать в проекте, чтобы в результате получить АС в установленные сроки, с определённой функциональностью и в рамках отведённого бюджета. При этом данная методология является достаточно гибкой, она постоянно расширяется и совершенствуется, а все её требования носят рекомендательный характер.
Технология RUP предлагает собственную модель ЖЦ разрабатываемой системы, являющуюся развитием спиральной модели Боэма [59,62,126]. Эта модель является эволюционно-инкрементнои, при этом эволюционная составляющая основывается на доопределении требований в ходе работы, а инкрементная - на планомерном приращении реализации требований. ЖЦ разбивается на циклы, каждый из которых работает над новым поколением изделия, при этом каждый цикл развития включает 4 последовательные стадии (см. рис. 1.1, взятый из [62]):
1. Начало (Inception) - заключается в определении деловых применений системы и рамок проекта, включающих критерии успеха, оценку рисков и необходимых ресурсов. В конце начальной стадии решается вопрос о продолжении разработки.
2. Уточнение (Elaboration) - заключается в определении основных архитектурных решений, разработке плана и устранении самых высоких элементов риска проекта.
3. Конструирование (Construction) - заключается в построении законченной АС в виде серии инкрементных итераций, а также тестировании системы.
4. Переход (Transition) - предполагает передачу разработанной системы пользователям и внедрение АС в среду пользователя. В конце этой стадии определяется степень достижения целей ЖЦ, и по результатам взаимодействия с пользователями запускается новый цикл разработки.
Формализация причинно-следственных закономерностей вопросно-ответного протокола проекта
Как уже отмечалось, QA-протокол проекта содержит вопросы и ответы различных типов, но при формализации ПСЗ будем отдельно выделять только задачи и гипотезы, поскольку для остальных типов QA-единиц ПСЗ в QA-протоколе инвариантны. В данном разделе рассматриваются только закономерности, которые могут быть заданы между QA-единицами, с учётом иерархической структуры QA-протокола. При описании вновь используются операции логики причинности [21,44,45,65,157,158], а именно - каузальная импликация. Наличие иерархической структуры в QA-протоколе означает, что каждый его конкретный элемент может каузально имплицироваться только одним другим элементом, т.е. для QA-единицы в протоколе можно выделить только одну причину.
Поскольку QA-протокол постоянно динамически изменяется, все QA-единицы будут рассматриваться в их состоянии в некоторый момент времени t. Если говориться о вопросе любого типа, то имеются в виду вопросы всех типов, кроме вопросов-задач, поскольку каузальные закономерности, связанные с ними рассматриваются отдельно. Аналогичная ситуация и с ответами любого типа - под ними понимаются ответы всех типов, кроме ответов-гипотез. Итак, в QA-протоколе проекта можно выделить следующие основные каузальные закономерности:
1. Вопрос любого типа Q(t) является причиной соответствующего ему ответа A(t) любого типа, т.е. вопрос Q(t) каузально имплицирует некоторый ответ A(t). Q(t)- A(t) (2.48)
2. Вопрос любого типа Q(t) может являться причиной уточняющего вопроса Q (0 любого типа, т.е. вопрос Q(t) может каузально имплицировать некоторый уточняющий вопрос Q (t). Q(t) - Q (t) (2.49)
3. Ответ любого типа A(t) может являться причиной уточняющего вопроса Q (0 любого типа, т.е. ответ A(t) может каузально имплицировать уточняющий вопрос Q (t). A(t) - Q (t) (2.50)
4. Особым случаем закономерности из пункта 1 является то, что вопрос типа задача Z(t) является причиной соответствующего ему ответа типа гипотеза H(t), т.е. задача Z(t) каузально имплицирует гипотезу H(t). Z(t)-»H(t) (2.51)
5. Задача Z(t) может каузально имплицировать последовательность QA-рассуждений по её решению, которые всегда начинаются с постановки некоторого вопроса Q(t) или группы вопросов Qi(t), Q2(t),..., Q„(t), т.е. Z(t) - Q2(t) Z(t) - Q(t) или 2W \ (2.52) Z(t) Qn(t)
6. Гипотеза H(t) может каузально имплицировать последовательность QA-рассуждений по её рассмотрению, которые всегда начинаются с постановки некоторого вопроса Q(t) или группы вопросов Qi(t), (ЫО,..., QJt), т.е. H(t) -+Qt(t) H(t) Q2(t) H(t) - Q(t) или V2W і (2.53) H(t)- Qn(t)
7. Вопрос любого типа Q(t) может являться причиной группы соответствующих ему ответов Ai(t), A2(t), ..., An(t) любого типа, т.е. вопрос Q(t) каузально имплицирует группу ответов Ai(t), A2(t),..., An(t), Q(t)— { Aj(t) i=l..n }. Q(t)- A,(t) Q(t) (t) (2.54) Q(t)- An(t) 8. Задача Z(t) может являться причиной группы соответствующих ей гипотез Hi(t), H2(t), -98-..., Hn(t), т.е. задача Z(t) каузально имплицирует группу гипотез Hi(t), H2(t), ..., Hn(t), Z(t)- { H,(t) i=l..n }. Z(t)- H,(t) Z(t)- H2(t) (2.55) Z(t)- Hn(t)
9. Вопрос любого типа Q(t) может являться причиной группы уточняющих вопросов любого типа Qi(t), Q2O), ..., Qn(t), т.е. вопрос Q(t) может каузально имплицировать группу уточняющих вопросов Qi(t), Q2(t),..., Qn(t), Q(t)-»{ Qi(t) I i=l..n }. Q(t)- Qi(t) m (t) (2.56) Q(t)- Qn(t)
10. Ответ любого типа A(t) может являться причиной группы уточняющих вопросов любого типа Qi(t), Q2(t), ..., Qn(t), т.е. ответ A(t) может каузально имплицировать группу уточняющих вопросов Qi(t), Q2(t), ..., Qn(t) A(t)— { Q;(t) I i=l..n }. A(t) Q,(t) " W 2W (2.57) A(t)- Qn(t)
11. Задача Z(t) может являться причиной группы детализирующих задач Zi(t), Z2(t), ..., Zn(t), т.е. задача Z(t) может каузально имплицировать группу задач Zi(t), Z t),..., Zn(t), Z(t)- { Z,(t) I i=l..n }. Z(t)- Z,(t) Z(t)- Z2(t) W 2V (2.58) Z(t)- Zn(t)
12. ПСЗ, указанные в пунктах 1-11, могут задаваться последовательно, т.е. QA-единицы могут одновременно являться следствиями и причинами, образуя причинно-следственные цепочки, например: Zj(t)— Qi(t)— Ai(t) — Q2(t) —»(}з(0 — A2(t) —»....
13. QA-единица любого типа (включая задачи и гипотезы) может каузально имплицировать другую версию этой же единицы, т.е.: QA (t)- QAi+1(t + l), (2.59) где QA(t) - некоторая QA-единица (Q(t), A(t), Z(t) или H(t)), і - номер версии QA-единицы-причины. Такая каузальная зависимость может быть задана последовательно п раз, т.е. возможна следующая цепочка ГТСЗ: QA (t) - QAi+1(t +1) - QAi+2(t + 2) - ... - QAi+n(t + n) ( 2.60 )
14. Вопросу любого типа Q(t) по результатам анализа может быть присвоен статус задачи, в таком случае можно говорить, что некоторый вопрос Q(t) каузально имплицирует задачу Z(t+1). Q(t)- Z(t + l) (2.61)
15. Ответу любого типа A(t) по результатам анализа может быть присвоен статус гипотезы, в таком случае можно говорить, что некоторый ответ A(t) каузально имплицирует гипотезу H(t+1). A(t)- H(t + l) (2.62)
16. QA-единица любого типа (включая задачи и гипотезы) может быть аргументирована, в таком случае можно говорить, что некоторая QA-единица QA(t) каузально имплицирует некоторый набор аргументов {Argj(t) i=l..n } QA(t) - Argl(t) u Arg2(t) u... и Arg„(t) (2.63)
В данном разделе даётся ответ на вопрос Q6, сформулированный в параграфе 1.5, при этом в параграфе 2.2.2.1 отвечается на подчинённый вопрос Q6.1 о модели схемы условного деятельностного рефлекса, в параграфе 2.2.2.2 - на вопрос Q6.2 о графовой модели задачной структуры проекта, а в параграфе 2.2.2.3 - на вопрос Q6.3 о сетевых причинно-следственных моделях
Комплекс методик мотивационно-целевого и причинно-следственного сопровождения процесса принятия решений
Практическое применение подхода, изложенного во второй главе, предлагается осуществлять при разработке АС с использованием методологии Rational Unified Process (RUP) [62,63,126]. Более конкретно, это применение заключается в выполнении действий по формированию специфических артефактов дополнительного потока работ RUP, основу которого составляет оперативное документирование хода решения проектных задач в вопросно-ответной форме. Для набора действий по конструктивному включению в процесс автоматизированного проектирования элементов, обладающих причинно-следственным потенциалом, был разработан комплекс методик их выполнения.
Комплекс методик мотивационно-целевого и причинно-следственного сопровождения процесса ППР составляют: методика формирования мотивов, целей и спецификаций; методика формирования мотивационно-целевой модели состояния проекта; методика формирования схем УДР; методика анализа мотивационно-целевой модели состояния проекта; методика формирования библиотеки типовых мотивов и целей; методика формирования прототипов задач;
В данном параграфе приводится описание этих методик, использующих систему правил, описанную в параграфе 3.1, причём описание методик проведено в соответствии с требованиями RUP к описанию наборов действий потоков работ [62,63]. Формирование мотивационно-целевой модели состояния проекта Формирование мотивов целей и спецификаций
Описание потоков работ в RUP начинается с представления диаграммы краткого обзора действий (Activity Overview). В данном параграфе на такой диаграмме (см. рис. 3.1) показываются только действия, связанные с мотивационно-целевым и причинно-следственным сопровождением процесса ППР, а действия вопросно-ответного документирования опускаются.
Как показано на рис. 3.1 в потоке работ выделяются 2 роли работников - рядовой член проектной группы и руководитель проектной группы, причём предполагается, что обе эти роли могут выполняться одним лицом. Напротив каждой из ролей показаны действия, выполняемые ими, а стрелками показаны взаимосвязи между действиями.
Другим аспектом представления потоков работ в RUP является описание артефактов, формируемых в результате выполнения действий потока работ. Данное описание представляется диаграммой краткого обзора артефактов (Artifact Overview), для описываемого потока работ такая диаграмма представлена на рис. 3.2, и на ней также показаны только артефакты, связанные с мотивационно-целевым и причинно-следственным сопровождением процесса ППР. На диаграммах обзора артефактов также показываются роли работников, при этом все артефакты на диаграмме изображаются во взаимосвязи с ролями работников, ответственных за их формирование.
Далее можно перейти к описанию методик мотивационно-целевого и причинно-следственного сопровождения процесса ППР, соответствующих действиям на диаграмме 3.1. Методики представляются как текстовым описанием последовательности выполняемых операций, так и графически при помощи диаграмм деталей потоков работ (Workflow Detail), показывающих работников, выполняющих действия, артефакты ввода и вывода, зависимые элементы и сопутствующие действия. В качестве зависимых элементов на диаграммах всех методик данного параграфа показаны: постановка задачи, текстовое представление методики и пример использования инструментальных средств. 1. Методика формирования мотивов, целей и спецификаций 1.1. Открыть задачу Zj для работы. 1.2. Если регистрируется мотив, то: 1.2.1. Запустить команду вопросно-ответной среды «Регистрация мотива». 1.2.2. Если формулировка качественной цели имеется в списке целей, составленном по ТЗ, то копировать формулировку и перейти к п. 1.5. 1.2.3. Если формулировка имеется в библиотеке мотивов, то копировать формулировку и перейти к п.1.5. 1.2.4. Построить новую формулировку на основе рассуждений и перейти к п.1.5. 1.3. Если регистрируется цель, то: 1.3.1. Запустить команду вопросно-ответной среды «Регистрация цели». 1.3.2. Если формулировка цели имеется в списке, составленном по ТЗ, то копировать формулировку и перейти к п.1.5. 1.3.3. Если формулировка имеется в библиотеке целей, то копировать формулировку и перейти к п.1.5. 1.3.4. Построить новую формулировку цели на основе рассуждений и перейти к п.1.5. 1.4. Если регистрируется спецификация, то: 1.4.1. Запустить команду вопросно-ответной среды «Регистрация спецификации». 1.4.2. Если формулировка спецификации имеется в списке построенных QA-единиц типов «ответ», «решение», «процедурный ответ», «теория» и спецификация на основе данной единицы не создана, то копировать формулировку и перейти к п.1.5. 1.4.3. Вернуться к решению задачи. 1.5. Сохранить сформированную единицу в БД проекта. 1.6. Аргументировать сформированную единицу. 1.7. Обсудить единицу. 1.8. Уточнить формулировку единицы. 1.9. Завершить работу по методике.
На графических схемах методик, артефакты, используемые в процессе выполнения некоторого действия, связываются с ним стрелкой со стереотипом «в», а результаты выполнения (артефакты вывода) - показываются стрелкой со стереотипом «из». При помощи сплошных линий показаны зависимые элементы, которые должны использоваться при выполнении действия. В нижней части схемы показываются сопутствующие действия данного потока работ, которые исполняются при реализации методики (в том числе и не показанные на диаграмме на рис. 3.1).
Реализация подсистемы мотивационно-целевого и причинно-следственного моделирования
Следующим после детализации модели прецедентов шагом работы в рамках методологии RUP на фазе «Уточнение» является описание вида системы с точки зрения проектирования (Design View) [62,63,145]. Статические аспекты этого вида описываются при помощи диаграмм классов (Class diagrams), показывающих абстракции, выделенные при проектировании системы, соответствующие им атрибуты и операции, а также отношения между ними [28,59,93]. В самом первом приближении диаграмму классов можно построить на основе диаграмм сотрудничества и последовательности, описанных в параграфе 4.1. Тогда систему классов составят классы, соответствующие объектам, представленным на этих диаграммах, кроме объектов-актёров. На основе анализа диаграмм из параграфа 4.1 построена начальная диаграмма классов (см. рис. 4.13), на которой представлены следующие классы: 1. МО-Structure - класс, объектами которого являются МЦ-структуры; 2. CAR-Scheme - класс, объектами которого являются схемы УДР; 3. DataBase - класс, объектом которого является БД вопросно-ответной среды; 4. ExtFile - класс, объектами которого являются внешние файлы для сохранения схем; 5. QA-Unit - класс, объектами которого являются единицы QA-протокола; 6. Unit - класс, объекты которого - мотивационно-целевые единицы («Единица»); 7. Links - класс, объектами которого являются наборы сетевых связей единиц; 8. UnitJHierarchy - класс, объектом которого является иерархия единиц; 9. Search_Module - класс, объектом которого является модуль поиска данных; 10. Search_Results - класс, объектом которого являются результаты поиска данных.
Кроме того, определён абстрактный суперкласс Scheme, определяющий минимальные функциональные возможности строящихся моделей, включающие возможности просмотра окна со схемой, просмотра атрибутов элементов схем и т.д. Все строящиеся в системе модели являются потомками этого суперкласса.
Операции и атрибуты классов также выявлены по диаграммам сотрудничества и последовательности, при этом операции соответствуют сообщениям, стрелки которых на диаграммах последовательности подходят к линиям жизни объекта, соответствующего классу. Связи между абстрактным суперклассом Scheme и классами МО-Structure и CAR-Scheme показаны при помощи отношений обобщения, между различными классами также заданы отношения ассоциации, соответствующие созданию экземпляров классов и вызову их операций.
Динамические аспекты вида системы с точки зрения проектирования можно представить в виде диаграмм деятельности (Activity diagrams) [28,59,93]. Эти диаграммы представляют переход потока управления от одной деятельности к другой при выполнении некоторой операции, и таким образом с их помощью могут быть смоделированы рабочие процессы, соответствующие вариантам использования проектируемой системы. Далее, при помощи диаграмм деятельности описываются следующие наиболее важные прецеденты из числа определённых в параграфе 3.4: регистрация сетевых связей для мотивов, целей и спецификаций; работа с МЦ-структурами; работа со схемами УДР; регистрация типовых мотивов и целей;
Диаграмма деятельности для операции «Регистрация сетевых связей для мотивов, целей и спецификаций» представлена на рис. 4.14. Начало выполнения данного прецедента на диаграмме показано начальным состоянием - закрашенным кругом, а первым действием должен являться запуск плагина работы с мотивами, целями и спецификациями. Затем начинается просмотр иерархий мотивов, целей и спецификаций в целях выбора элемента, для которого будут производиться изменения в наборе сетевых связей. Существует 2 варианта просмотра иерархий - перебор, в случае выбора которого должна осуществляться навигация по иерархиям до обнаружения требуемого элемента, и поиск. В случае выбора поиска, сначала задаются его критерии, а после выполнения поиска осуществляется позиционирование на требуемый элемент из числа найденных.
Далее происходит слияние разветвившегося потока управления (показано на диаграмме горизонтальной чертой) и выполняется действие «переход в режим редактирования элемента». После этого должна начинаться регистрация сетевых связей, в ходе которой у пользователя существует три варианта действий - добавление, удаление и изменение сетевых связей. После выполнения одного из этих действий можно продолжить регистрацию (соответствует варианту [Да] соответствующего ветвления) или завершить её (вариант [Нет]). В последнем случае выполняется действие «Сохранить изменения» и переход на ветвление «Продолжение работы». В случае выбора продолжения (вариант [Да]) осуществляется возврат к просмотру иерархий мотивов, целей и спецификаций, а иначе выполнение прецедента завершается, что показано на диаграмме конечным состоянием (закрашенный круг внутри окружности).
