TKS являются моделями задач интересующей нас области. Эти модели используются в рамках процесса разработки, чтобы содействовать большей интерактивностью разрабатываемой системы. Часто целью таких систем может быть желание изменить способ, которым пользователи выполняют свои задачи, например, для улучшения эффективности их решения. Однако, с изменением характера задач пользователей, появляется проблема в обучении. Мы пытаемся спрогнозировать, с какими трудностями столкнется пользователь, при использовании новой системы путем сравнения знаний, которые он в настоящее время имеет; необходимые для эффективного взаимодействия с системой, предназначенной для поддержки своих целей в данной области.

1.2.10 Think Aloud technique Problem Solving (TAPPS, Мысли вслух)

«Мысли вслух». Метод отличается от наблюдений тем, что эксперта просят объяснить, на какие умозаключения он опирается, принимая конкретные решения. После протоколирования объяснений эксперта, аналитик может обратиться к эксперту с целью корректировки составленной систематизации.

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

Метод «Мысли вслух» означает, что субъект при решении задачи говорит вслух все приходящие на ум мысли.

Нет никаких прерываний, наводящих вопросов - чтобы избежать интерпретации для объяснения процесса решения задачи.

Концентрация субъекта на непосредственно на решении задачи.

Весь процесс решения задачи записывается на устройства записи информации (формируется протокол «Мыслей вслух»).

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

Таблица 1. Методы когнитивного анализа

№	Название метода	Краткое описание	Способ применения
1	Applied Cognitive Task Analysis (ACTA)	Метод для выполнения CTA, который состоит из серии трех структурированных шагов. На первом шаге порождается Диаграмма задачи. На втором происходит аудит знаний. На 3 шаге происходит моделирование когнитивного процесса. На выходе получается таблица когнитивных требований, которая представляет результаты так, чтобы они могли быть применены к конкретному проекту.	Индивидуальный
2	The Critical Decision Method (CDM)	Метод позволяющий оценить ситуацию и принять решение при неожиданной ситуации.	Индивидуальный
3	PARI Method	Метод, разработанный в основном для выявления когнитивных и поведенческих требования для устранения неисправностей в сложных системах. Этот метод особенно подходит для разработки программ подготовки кадров. Подход состоит из структурированных интервью, в котором новичок и эксперт по устранению неполадок диагностируют неисправность в задаче, связанной с другим экспертом.	Коллективный
4	Skill-Based CTA Framework	Структура для проведения анализа предполагает простые когнитивные навыки, основанные на более сложных навыках; производятся попытки определить иерархию навыков, необходимых для работы	Индивидуальный
5	Decompose, Network, and Asses (DNA)	DNA представляет собой автоматизированный набор инструментов, созданный для оказания помощи в выявление знаний, в первую очередь необходим для разработки интеллектуальных обучающих систем. DNA помогает разложить области на составные элементы, сетевые элементы в иерархии наследования, а также оценить структуру знаний обеспечить обоснованности и надежности.	Коллективный
6	Goal-Directed Task Analysis (GDTA)	Когнитивная методика анализа задач, которая фокусируется на раскрытии ситуацией (SA) требования, связанные с работой. По Endsley, SA является "восприятие элементов в окружающую среду в пределах объема пространства и времени, понимание их смысла, проекция их статуса в ближайшем будущем, и предсказания о том, как различные действия влияют на выполнение своих целей ".	Коллективный
7	Cognitively Oriented Task Analysis (COTA)	коллекция процедур, разработанные DuboisandShalin улучшить оценку опыта работы и производительность. COTA использует словесные методики анализа протоколов для определения стандартных методов, используемых для решения задач, как эти методы будут выбраны, инициировал и завершил, и как эти методы будут приняты к новым ситуациям.	Индивидуальный
8	CognitiveFunctionModel (CFM)	методика, разработанная, чтобы преодолеть разрыв между оператором функций модели и когнитивного анализа задач. Целью является выявление узлов в модели функция оператора, которые высоко сложные когнитивные задачи, которые должны осуществляться более глубоко с CTA. Приложение, разработанное Klein Associates and Aptima может быть использован для построения CFMs и оценки когнитивной сложности узлов.	Коллективный
9	Task-Knowledge Structures (TKS)	Основой для TKS служит предположение, что люди строят структуры знаний в памяти, при решении конкретной задачи. Это знания не случайно структурированы, они являются высокоорганизованными структурами. Некоторые объекты задач, например, тесно связаны с другими объектами, и эти классы объектов зависят от определенного контекста. Необходимо тысячи изменений связей для перехода из текущего состояния в желаемое.	Индивидуальный



2. Техническое задание

2.1 Техническое задание

2.1.1 Вопросно-ответная модель данных

Излагается технология осуществления вопросно-ответного моделирования процессов решения задач, базирующаяся на парадигме программирования. Технология предусматривает исполнение операций с объектами типа «вопросно-ответная пара», продукция вида «условие => следствие» и др., а также агрегацию операций, порождая при этом процедуры и функции.

2.1.2 Основные понятия

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

Естественной формой включения интеллектуальных активностей в процессы решения задач являются рассуждения, явное моделирование которых лежит в основе человеко-компьютерных методов решения задач. Модели рассуждений используются как посредники, обслуживающие интерактивное взаимодействие между оперативными рассуждениями лиц, участвующих в решении задач, и автоматными активностями компьютерных помощников.

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

Реальность программирования задач, нацеленного на компьютеризацию их решений такова, что накоплен богатейший опыт традиционного программирования, обеспечивающего создание компьютерных составляющих человеко-компьютерной деятельности (ЧКД), и совершенно неприемлемо состояние опыта программирования человеческих составляющих такой деятельности.

Одной из наиболее важных проблем существующего отношения между составляющими опыта, используемого в человеко-компьютерном решении задач, считается чрезвычайно низкая успешность разработок систем, интенсивно использующих программное обеспечение (Software Intensive Systems - SIS, в российской терминологии «автоматизированных систем» - АС).

В попытках изменить положение дел акцент в программировании смещён на разработку концептуальных методов и средств программирования, в результате чего созданы унифицированный язык моделирования UML, объектно-ориентированные технологии разработок SIS (например, технология Rational Unified Process - RUP), ряд нормативных концептуальных схем и стандартов (например,) и многое-многое другое.

К числу таких средств относятся и вопросно-ответные инструментальные среды, разработанные на кафедре «Вычислительная техника» Ульяновского государственного технического университета и получившие общее название WIQA (Working In Questions and Answers). Потенциал последней версии комплекса средств WIQA (WIQA.Net) доведён до состояния, когда его можно использовать для программирования человеческих составляющих ЧКД, согласованных и объединенных с компьютерными составляющими такой деятельности. Для программирования задач в вопросно-ответных средах, сущность и механизмы которого раскрываются ниже, введено название вопросно-ответное программирование (или, короче, QA-программирование)

2.1.3 Вопросно-ответная модель данных

Начнём раскрывать идеи QA-программирования с введения и определения вопросно-ответной модели данных. В разработках вопросно-ответных приложений используется полезная модель данных (Рис. 1), состоящая из иерархической совокупности пар записей, представляющих вопросы и ответы, с набором операций над ними.

К специфике такой модели данных (обладающей богатой атрибутикой) относится следующее:

* унификация с использованием автоматически порождаемых индексных имен;

* содержательное определение или толкование (с возможностью преобразования на язык логики предикатов);

* автоматическая регистрация изменений во времени с сохранением изменённых версий;

* персонификация с указанием ответственного лица и группы «поддержки»;

* визуализация на экране монитора;

* возможность объявления подтипов;

* возможность использования наследования;

* возможность оперативного дополнения атрибутики;

* наличие «черновика» для присоединения полезной текстовой информации;

* образование иерархической совокупности групп, в том числе и таких, которым может быть приписан статус «целостности»;

* серверная форма размещения с клиентским доступом в корпоративной сети, с возможностью санкционирования доступа из Интернета;

* другие полезные возможности.

Рис. 4. Вопросно-ответная модель данных.

Ко всем названным возможностям можно (и целесообразно) относиться с позиций традиционного программирования. Такой подход заложен в развитие комплекса NetWIQA, предполагающее разработку новых плагинов (расширений) с использованием вопросно-ответного типа данных.

Проясним использование вопросно-ответной модели данных в её простейшей версии, приведённой на рис. 4. и представляющей собой именованный блок В совокупности пар вопросов и ответов {Qn, An}, в которой за каждым элементом пары стоит запись с отмеченными выше характеристиками.

QA-модель данных позволяет (визуально) моделировать объявления переменных в том плане, в котором объявления используется в языках программирования. Образцы форм визуализации приведены на рис. 5.



Рис. 5. Примеры визуализации QA-данных

Рассмотрим ещё одну интерпретацию совокупности пар данных, для которой вопросно-ответная интерпретация может рассматриваться как частный случай. Первую составляющую каждой пары можно рассматривать как «условие», а вторую составляющую - как «следствие». В такой версии интерпретации каждая пара записей модели, представленной на рис. 1.4.1, кодирует импликацию: Если «условие_i», то «следствие_k» причём, с богатой атрибутикой, как для «условия», так и для «следствия».

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

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

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

Ещё одну версию интерпретации QA-данных переведём на уровень «абстракции данных», в их следующих версиях:

«вопрос» -> "имя переменной для простого типа данных, используемого в традиционном программировании" и "ответ" -» "значение этой переменной";

«определённая композиция вопросов» -> « данные составного типа (например, данные типа массив, запись, множество, массив записей или таблица, стек, очередь или другой составной тип данных)» и «соответствующая композиция ответов" -> "текущее значение данных этого типа».

Представленные версии интерпретации демонстрируют, что QA-модель данных может быть использована для эмуляции данных многих известных типов, используемых в традиционном программировании. А значит, существующие средства NetWIQA разумно дополнить специализированными средствами, обеспечивающими разработку приложений, в основе которых лежит программирование с использованием QA-данных. Следует отметить, что автоматическое именование вопросов и ответов, порождающее их уникальные имена, вводит их естественную адресацию, позволяющую обращаться к QA-данным и их составным частям по именам.

В следующей таблице укажем какие функции из представленного выше функционального базиса отсутствуют в системе WIQA.

Таблица 2.

№ п/п	Функции	WIQA	Базис
1	Защита	+	+
2	Восстановление/резервное копирование	-	+
3	Индексы	+	+
4	Представления (Views)	+	+
5	Обеспечение целостности	-	+
6	Параллелизм	+	+
7	Транзакции/Журналы	+/-	+
8	Репликации	-	+
9	Масштабирование	-	+
10	Выборка и модификация данных	+	+

2.2 Цель проекта и назначение программного средства

Целью данного проекта является создание библиотеки методов когнитивного анализа задач.

2.2.1 Условия эксплуатации

Среда рассчитана на круглосуточную работу с поддержкой сетевых подключений к общей базе данных.

Погодные условия в помещении, где работает система, должны удовлетворять требованиям, предъявляемым аппаратурой, которая участвует в процессе функционирования программной среды.

Загрузку программы осуществлять согласно принципам загрузки подсистем-расширений среды NetWIQA.

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

· обладание навыками работы в среде NetWIQA, понимание её внутренней структуры и умение обращаться с плагинами, которые составляют значительную часть функциональности среды;

· понимание системы прав NetWIQA и умение их настраивать;

2.2.2 Требования к качеству

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

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

Среда рассчитана на хранение данных в общей базе. Во время одновременной работы нескольких пользователей с базой данных необходимо обеспечить синхронизацию операций. Необходимо разработать механизм отслеживания устаревших идентификаторов, операции над которыми невозможны и уведомления пользователя об этом.

При обращении к данным и выполнении операций над ними используются системные функции среды NetWIQA. Возможность выполнения операции зависит от наличия или отсутствия прав у пользователя, от имени которого совершается операция. При создании первоначальной структуры подзадачи базы данных необходимо наделить всех пользователей, входящих в группу, правами на запись в рамках подзадачи. Следует предоставить пользователям возможность запуска средства, позволяющего редактировать эти права и на этапе после создания подзадачи.

Практичность. Набор атрибутов, относящихся к объёму работ, требуемых для использования и индивидуальной оценки такого использования определённым или предполагаемым кругом пользователей.

* Обеспечить вызов функций и окон приложения из множества мест, как то: из главного меню, из панели инструментов окна, из контекстного меню элемента интерфейса;

* Свести к минимуму время поиска необходимой информации и навигации по программе.

Эффективность. Набор атрибутов, относящихся к соотношению между уровнем качества функционирования программного обеспечения и объёмом используемых ресурсов при установленных условиях.

* Программная среда должна иметь полную сетевую поддержку пользователей при физическом соединении компьютеров на скорости менее 10 мБит/сек;

* Программная среда должна полностью функционировать на компьютерах, начиная от пятого поколения (x586 и выше).

Сопровождаемость. Набор атрибутов, относящихся к объёму работ, требуемых для проведения конкретных модификаций.

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

Мобильность. Набор атрибутов, относящихся к способности программного обеспечения быть перенесённым из одного окружения в другое.

* Обеспечить независимость приложения от аппаратных средств и посторонних программных средств;

* Обеспечить функционирование подсистемы совместно с любыми другими подсистемами, установленными в инструментально-технологической среде NetWIQA.

2.2.3 Требования к составу и параметрам аппаратно-программных средств

Проект должен быть реализован на языке программирования C#, а также в встроенном псевдокодовом языке в вопросно-ответной среде WIQA.Среда разработки -Visual Studio 2010. Допускается использование библиотек, функций, компонентов и алгоритмов других разработчиков.

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

Гарантированная работа среды рассчитана на основе среды NetWIQA версии не ниже 3.3. Для установки вопросно-ответного процессора NetWIQA требуется наличие операционной системы Windows 2000/NT/XP/2003 и примерно 75 Мб свободного дискового пространства (при полной установке системы). Кроме того, необходимо выделить дополнительное дисковое пространство на компьютере с серверной частью системы, необходимое для записи данных в базу данных и складирования файлов с дополнительной информацией о единицах QA-протокола и других элементах вопросно-ответной базы данных. Для работы с подсистемами тестирования и предикации на компьютере должна быть установлена BDE (Borland Database Engine). Для работы с подсистемой документирования и экспорта данных вопросно-ответного протокола в doc-формат на компьютере с клиентским местом должен быть установлен Microsoft Word.

Минимальная диагональ монитора - 15'' с рабочим разрешением 800x600 пикселей при частоте вертикальной развёртки 85 Гц.

Рекомендованная диагональ монитора - 17'' с рабочим разрешением от 1024x768 пикселей и выше при частоте вертикальной развёртки от 100 Гц.

2.2.4 Требования к информационной и программной совместимости

Хранение данных осуществляется централизованно, в рамках базы данных, хранящейся на сервере. Данные представлены в виде обычных вопросно-ответных единиц NetWIQA. Корневой каталог, каталоги пользователей и иные каталоги программы представляют собой единицы с типом «задача» в терминах объектов базы данных NetWIQA. Структура расположения вопросно-ответных единиц и задач относительно друг друга должна соответствовать принятым стандартам среды. Использование атрибутов вопросно-ответных единиц и задач должно совпадать с их первоначальным назначением, с целью обеспечения возможности производить операции с данными средствами любых других подсистем среды NetWIQA.

2.2.5 Требования к программной документации

В документации к разработанной системе должны быть отражены этапы:

· описание процесса установки подсистемы в среде NetWIQA;

· описание процесса первоначального конфигурирования подсистемы;

· процесс работы подсистемы;

· удаление подсистемы из среды NetWIQA;

· дополнительные возможности подсистемы.

Допускается расширение указанного списка, а также создание своих глав и слияние нескольких пунктов в один.

2.2.6 Требования к уровню реализации

Разработанная подсистема должна обеспечить ввод, изменение, удаление любой рабочей информации, при этом соответствуя требованиям информационно и программной совместимости.

Реализовать поддержку одновременной работы нескольких операторов с учётом требований к надёжности проекта.

Интерфейс реализован на русском языке.

Для стандартных операций работы с текстом (вырезать, копировать, вставить, выделить всё, удалить) обеспечить их выполнение по нажатию горячих клавиш. Соответствие комбинаций клавиш операциям производить в соответствии с традиционными комбинациями (Ctrl+C, Ctrl+V, и т. п.).

2.3 Обобщённая постановка задачи

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

2.4 Расширенная постановка задачи

2.4.1 Цель проекта и назначение программного средства

Целью данного проекта является доработка вопросно-ответной системы NetWIQA, создание библиотеки методов когнитивного анализа решения задач.

2.4.2 Назначение и область применения

Программное средство, описанное в дипломном проекте предназначено, в основном, для разработчиков, взаимодействующих между собой в вопросно-ответном процессоре NetWIQA. Пользователь данного программного средства должен обладать навыками работы в вопросно-ответной среде NetWIQA и входящими в её состав плагинами и другими вспомогательными приложениями. Программный продукт применяется когда требуется выполнит задачу по когнитивному анализу.

2.4.3 Требования к аппаратно-программным средствам

Проект должен быть реализован на языке высокого уровня C# и на языке псевдокодирования, реализованного в вопросно-ответной среде WIQA.

Требования к аппаратной части должны соответствовать требованиям вопросно-ответного процессора NetWIQA. Для установки вопросно-ответного процессора NetWIQA требуется наличие операционной системы Windows 2000/NT/XP/2003 и примерно 75 Мб свободного дискового пространства (при полной установке системы). Кроме того, необходимо выделить дополнительное дисковое пространство на компьютере с серверной частью системы, необходимое для записи данных в базу данных и складирования файлов с дополнительной информацией о единицах QA-протокола и других элементах вопросно-ответной базы данных. Для работы с подсистемами тестирования и предикации на компьютере должна быть установлена BDE (Borland Database Engine). Для работы с подсистемой документирования и экспорта данных вопросно-ответного протокола в doc-формат на компьютере с клиентским местом должен быть установлен Microsoft Word. Для нормальной работы с клиентским рабочим местом монитор должен поддерживать разрешение не менее чем 1024x768 пикселей.

Для установки системы необходимо запустить инсталляционный файл NetWIQA.exe, при этом набор прав пользователя в операционной системе должен включать:

§ возможность записи в каталог, в который будет устанавливаться система;

§ возможность записи в системный каталог операционной системы;

§ возможность записи в системный реестр;

§ возможность регистрации COM-серверов.

2.4.4 Условия эксплуатации

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

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

Для гарантированной работы программной среды на одно рабочее место требуется один персональный компьютер, один оператор с навыками:

§ знание основ и принципов работы персонального компьютера;

§ знание основ и принципов функционирования вопросно-ответной среды NetWIQA;

§ пользователь операционной системы Windows 98/ME/2000/XP.

Количество пользователей в одной рабочей группе программы ограничено количеством 30 человек. Это необходимо для оптимального отображения связей между пользователями в наглядном виде, при котором графические элементы не накладываются и не мешают друг другу.

Работа группы пользователей свыше 30 человек возможна, но режим визуального отображения тогда не сможет отразить всю группу в полной мере.

2.4.5 Требования к надёжности программного средства

Для нормальной работы программного средства необходимо, что бы оно отвечало следующим требованиям:

§ программа не должна во время работы порождать конфликты с иными плагинами, работающими параллельно с базой вопросно-ответной среды NetWIQA;

§ установка программы и её начальное конфигурирование должно быть несложным, а сам процесс установки должен быть документирован;

§ записи, производимые программой в базу не должны приводить к её повреждению, и не должны повреждать или удалять данные, которые используются в работе другими плагинами NetWIQA;



2.4.6 Программная документация

Данное программное средство должно иметь документацию, содержащую следующую информацию:

§ описание назначения и возможностей программы;

§ описание минимальных требований к аппаратным средствам компьютера;

§ руководство по установке программы;

§ описание всех инструментов и возможностей программы;

§ руководство по использованию программы.

В программной документации наряду с текстовой информацией, должны присутствовать иллюстрации, которые будут служить дополнительными поясняющими элементами.

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



3. Проектирование и реализация

3.1 Обоснование выбора технологии реализации

Для программной реализации задачи проекта отдано предпочтение среде разработки Visual Studio2010, а также встроенный язык псевдокода в вопросно-ответной среде WIQA. Выбор среды разработки Visual Studio2010 был неслучаен. Дело в том, что реализация подсистемы для инструментально-технологической среды WIQAможет быть осуществлена только с использованием С#. Это связано с тем, что сама среда скомпилирована именно C# компилятором, и все её расширения должны быть скомпилированы точно также. Реализация же подсистемы на ином языке программирования, нежели С#, значительно затруднена из-за особенностей реализации доступа подсистемы к параметрам среды во время работы программы.

Последнее время С и C++ являются наиболее используемыми языками для разработки коммерческих и бизнес приложений. Эти языки устраивают многих разработчиков, но в действительности не обеспечивают должной продуктивности разработки. К примеру, процесс написания приложения на C++ зачастую занимает значительно больше времени, чем разработка эквивалентного приложения, скажем, на VisualBasic. Сейчас существуют языки, увеличивающие продуктивность разработки за счет потери в гибкости, которая так привычна и необходима программистам на C/C++. Подобные решения являются весьма неудобными для разработчиков и зачастую предлагают значительно меньшие возможности. Эти языки также не ориентированы на взаимодействие с появляющимися сегодня системами и очень часто они не соответствуют существующей практике программирования для Web. Многие разработчики хотели бы использовать современный язык, который позволял бы писать, читать и сопровождать программы с простотой VisualBasicи в то же время давал мощь и гибкость C++, обеспечивал доступ ко всем функциональным возможностям системы, взаимодействовал бы с существующими программами и легко работал с возникающими Webстандартами.

Учитывая все подобные пожелания, Microsoft разработала новый язык - С#. В него входит много полезных особенностей - простота, объектная ориентированность, типовая защищенность, "сборка мусора", поддержка совместимости версий и многое другое. Данные возможности позволяют быстро и легко разрабатывать приложения, особенно СОМ+ приложения и Webсервисы. При создании С#, его авторы учитывали достижения многих других языков программирования: C++, С, Java, SmallTalk, Delphi, VisualBasicи т.д. Надо заметить что по причине того, что C# разрабатывался с чистого листа, у его авторов была возможность (которой они явно воспользовались), оставить в прошлом все неудобные и неприятные особенности (существующие, как правило, для обратной совместимости), любого из предшествующих ему языков. В результате получился действительно простой, удобный и современный язык, по мощности не уступающий C++, но существенно повышающий продуктивность разработок.

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

3.2 Реализация метода когнитивного анализа PARI

Метод когнитивного подхода к анализу задачи, названный методом PARI (Предусловие - Действие - Результат - Интерпретация), смешивает процессы рассуждения над поставленной задачей со структурой диагностирования возможных вариантов разрешения проблемы, то есть представляет проблему, формулирует диагностический план, выдвигает гипотезу, проверяет, интерпретирует результаты, выдвигает гипотезу и проверяет снова.

Структура элемента PARI - анализа

Для создания структуры элемента был разработан класс Pari_Variant

Рис. 6.

Он содержит следующие атрибуты:

SomeAction - описание действия для решения проблемы

SomePrecursor - описание предпосылок к действию

SomeResult - описание результата действия

SomeInterpretation - интерпретация результата

Theme - детальное описание проблемы

Атрибуты объединяются в единое целое при помощи списка List<string>methods

Для работы с ними были написаны методы:

publicstringGetMethod(intindex) - получение определенного атрибута списка по индексу.

publicstring Serialize() - получает строчку в удобном для дальнейшей обработке виде. Она объединяет атрибуты объекта класса, разделенные определенными символами.

publicvoidSetMethod(intindex, stringmethod)- задает значение определенному атрибуту списка.

Так же было создано несколько конструкторов класса Pari_Variant

public Pari_Variant() - для создания нового объекта класса

publicPari_Variant(stringserialized) - для создания нового объекта класса, и задания его элементов из сериализованной строки.

public Pari_Variant(string theme, string action, string precursor, string result, string interpretation) - для создания нового объекта и задания его элементов

Форма ввода элемента PARI - анализа

Для ввода элемента и обработки результата была разработана форма Pari_AnalysisForm

Рис7.

В ней создается объект класса Pari_Variant

Класс Pari_Analysis

Этот класс создан для обработки всех вариантов решения проблемы метода PARI

Рис. 8.

Он содержит:

Variants - список вариантов типа PariVariant

Problem - описание проблемы

Были реализованы следующие методы:

publicvoid AddVariant(Pari_Variant variant) - добавление нового варианта

publicvoid RemoveVariant(int index), publicvoid RemoveVariant(string theme) - удаление варианта по индексу или теме

publicvoid ReplaceVariant(int index, string theme, string action, string precursor, string result, string interpretation) - перемещение варианта

publicstring Serialize() - получает строчку в удобном для дальнейшей обработке виде. Она объединяет атрибуты объекта класса, разделенные определенными символами.

Конструкторы класса Pari_Analysis

publicPari_Analysis () - для создания нового объекта класса

publicPari_Analysis(stringconstructionString) - для создания нового объекта класса, и задания его элементов из сериализованной строки.

Основная форма PARI - анализа

Рис. 9.

Форма нужна для обработки объектов класса Pari_Analysis

Для работы с вариантами был разработан элемент Pari_VariantUserControl

Рис. 10.

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

3.2.1 Реализация метода когнитивного анализа PARI на псевдокодовом языке

Z 1 PARI-Анализ

Q 1.1 &branch_qaid&

Q 1.1.1 0

Q 1.2 &history_branch_qaid&

Q 1.2.1 0

Q 1.3 PROCEDURE &PARI_CreateStructure&

Q 1.3.1 PARI dummy

Q 1.3.2 &t_int& := QA_GetQAId(&current_project&, "PARI dummy")

Q 1.3.3 &t_int& := QA_GetParent(&current_project&, &t_int&)

Q 1.3.4 &branch_qaid& := QA_GetParent(&current_project&, &t_int&)

Q 1.3.5 &history_branch_qaid& := QA_CreateNode(&current_project&, &branch_qaid&, 3, "")

Q 1.3.6 ENDPROC &PARI_CreateStructure&

Q 1.4 PROCEDURE &PARI_main&

Q 1.4.1 &t_str& := QA_GetQAText(&history_branch_qaid&)

Q 1.4.2 SETHISTORYENTRIES(&t_str&)

Q 1.4.3 CALL &ShowHistory&

Q 1.4.4 IF &LastHistoryFormResult& == -1 THEN RETURN

Q 1.4.5 IF &LastHistoryFormResult& == 0 THEN &current_action_qaid& := QA_CreateNode(&current_project&, &history_branch_qaid&, 3, "") ELSE &current_action_qaid& := &LastHistoryFormResult&

Q 1.4.6 &t_str& := QA_GetQAText(&current_action_qaid&)

Q 1.4.7 PARI_DESERIALIZE(&t_str&)

Q 1.4.8 &t_int& := PARI_SHOWMAINFORM()

Q 1.4.9 &t_str& := PARI_GETSERIALIZED()

Q 1.4.10 IF &t_int& == 0 THEN QA_UpdateNode(&current_project&, &current_action_qaid&, &t_str&)

Q 1.4.11 IF &t_int& != 0 RETURN

Q 1.4.12 IF &LastHistoryFormResult& == 0 THEN QA_UpdateNode(&current_project&, &history_branch_qaid&, ADDTOHISTORY(QA_GetQAText(&history_branch_qaid&), &t_str&, &current_action_qaid&))

Q 1.4.13 IF &LastHistoryFormResult& != 0 THEN QA_UpdateNode(&current_project&, &history_branch_qaid&, TRYUPDATETOPICINHISTORY(QA_GetQAText(&history_branch_qaid&), &t_str&, &current_action_qaid&))

Q 1.4.14 FINISH

Q 1.5 &t_int&

Q 1.5.1 0

Q 1.6 &t_str&

A 1.6.1 ""

Q 1.7 &LastHistoryFormResult&

Q 1.7.1 -1

Q 1.8 PROCEDURE &ShowHistory&

Q 1.8.1 &LastHistoryFormResult& := SHOWHISTORYFORM()

Q 1.8.2 LABEL &SH_deletedLoopStart&

Q 1.8.3 &t_int& := GETDELETEDHISTORYENTRIESCOUNT()

Q 1.8.4 IF &t_int& == 0 THEN GOTO &SH_deletedEnd&

Q 1.8.5 &t_int& := POPONEDELETEDHISTORYENTRY()

Q 1.8.6 QA_DeleteNode(&current_project&, &t_int&)

Q 1.8.7 GOTO &SH_deletedLoopStart&

Q 1.8.8 LABEL &SH_deletedEnd&

Q 1.8.9 ENDPROC &ShowHistory&

Q 1.8.10 QA_UpdateNode(&current_project&, &history_branch_qaid&, GETHISTORYENTRIES())

Q 1.9 &LastHistoryFormResult&

Q 1.9.1 0

Q 1.10 &current_action_qaid&

Q 1.10.1 0

PROCEDURE &PARI_CreateStructure& - создает структуру анализа

PROCEDURE &PARI_main& - запускает форму PARI - анализа

PROCEDURE&ShowHistory& - запускает форму создания, редактирования и удаления PARI анализа.

3.3 Реализация метода когнитивного анализа TAPPS

Структура элемента TAPPS - анализа

Для создания структуры элемента был разработан класс TAPPS_Variant

Рис. 11.

Он содержит следующие атрибуты:

Steps- список шагов метода

StepsSum- сумма шагов

NAME - имя участника

Для работы со списком шагов были разработаны методы:

publicstaticintCompare(TAPPS_Varianta, TAPPS_Variantb) - сравнение значений сумм шагов двух вариантов анализа

publicstringGetConstructionString() - получение строки, объединяющей в себе атрибуты элемента класса, использует функцию GetString

privatestring GetString(List<string> list) - вспомогательная функция для GetConstructionString

privateList<string>GetRecordsList(stringinput) - получает список записей данного класса из строки

publicList<string> GetSteps() - возвращает список шагов

publicint GetSumm() - возвращает сумму шагов

publicvoidSetSteps(stringsteps), publicvoidSetSteps(List<string>steps)- задет значение списка шагов, полученных из строки или списка

Конструкторы класса TAPPS_Variant:

publicTAPPS_Variant(stringconstructionString) - для создания нового объекта класса, и задания его элементов из сериализованной строки.

publicTAPPS_Variant(stringname, List<string>steps) - для создания нового объекта и задания его элементов из списка

publicTAPPS_Variant(stringname, stringsteps) - для создания нового объекта и задания его элементов из строки

Форма ввода элемента TAPPS - анализа

Для ввода элемента и обработки результата была разработана форма TAPPS_AnalysisForm



Рис. 12.

В ней создается объект класса TAPPS_Variant

Класс TAPPS_Analysis

Этот класс создан для обработки всех вариантов решения проблемы метода TAPPS

Рис. 13.

Он содержит:

Variants - список вариантов типа TAPPS_Variant

Problem - описание проблемы

publicvoid AddVariant(string name, List<string> steps), publicvoid AddVariant(string name, string steps), publicvoid AddVariant(TAPPS_Variant variant) - добавление нового варианта

publicvoid RemoveVariant(int index), publicvoid RemoveVariant(string name) - удаление варианта по индексу или имени участника

publicvoid ReplaceVariant(int index, string name, string steps) - перемещение варианта

publicvoid Order Variants() - сортировка вариантов

publicstring Serialize() - получает строчку в удобном для дальнейшей обработке виде. Она объединяет атрибуты объекта класса, разделенные определенными символами.

Конструкторы класса TAPPS_Analysis

publicTAPPS_Analysis () - для создания нового объекта класса

publicTAPPS_Analysis(string construction String) - для создания нового объекта класса, и задания его элементов из сериализованной строки.

Основная форма TAPPS - анализа

Рис14.

Форма нужна для обработки объектов класса TAPPS_Analysis

Для работы с вариантами был разработан элемент TAPPS_VariantUserControl

Рис15.

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

Универсальная форма истории анализа

Эта форма разработана для хранения результатов проведенных анализов

Рис. 16.

Она содержит:

List<Tuple<string, int>>history, deleted - списки текущих и удаленных элементов

publicstring DeletedEntries - удаление элемента из истории

publicstring LeftEntries - добавление нового элемента в историю

public HistoryEntriesForm(string history Entries) - конструктор формы

Разработка модуля для работы с WIQA

В соответствии с требованиями работы функций в WIQA был разработан класс ExtFunctions

Он содержит объекты классов Pari_Analysis и TAPPS_Analysis

Были написаны следующие функции:

GETDELETEDHISTORYENTRIES, STRING, string GetDeletedHistoryEntries() - Получает строку со списком удаленных записей из истории мероприятий. Формат списка: \"Имя1#QAID1#Имя1#QAID2#...ИмяN#QAIDN\"

POPONEDELETEDHISTORYENTRY,INTEGER,int PopOneDeletedHistoryEntry() - Получает QAID первой удаленной из истории записи и удаляет её из списка удалённых, уменьшая тем самым количество удаленных записей.

GETDELETEDHISTORYENTRIESCOUNT,INTEGER,int GetDeletedHistoryEntriesCount() - Получает количество удаленных записей из истории.

SETHISTORYENTRIES, STRING, string SetHistoryEntries(string entries) - Задает список записей истории. Возвращает старое значение.

GETHISTORYENTRIES, STRING, string GetHistoryEntries(string entries) - Получает список записей истории.

SHOWHISTORYFORM, INTEGER, intShowHistoryForm() - Показывает модальное окно, через которое можно запросить создание нового мероприятия, редактирование, просмотр или удаление уже созданного из истории.

ADDTOHISTORY, STRING, string AddToHistory(string history, string content, int qaid) - Добавляет запись к истории записей мероприятий.

TRYUPDATETOPICINHISTORY, STRING, string TryUpdateTopicInHistory(string history, string content, int qaid) - Изменяет тему в истории мероприятий для только что отредактированного мероприятия."

SHOWMESSAGE, STRING, string ShowMessage(string msg) - показывает сообщение.

CONCATSTRINGS, STRING, string ConcatStrings(string s1, string s2) - сливает содержимое двух строк в одну и возвращает её как результат.

PARI_SHOWMAINFORM, INTEGER, int PARI_ShowMainForm() - показывает модальную форму редактирования PARI-анализа. Возвращает 0, если была нажата клавиша ОК. Возвращает 1, если была нажата Отмена.

PARI_GETSERIALIZED, STRING, string PARI_GetSerialized() - получает сериализованный экземпляр PARI-анализа.

PARI_DESERIALIZE, STRING, string PARI_Deserialize(string serializedPari) - десериализует строку в экземпляр PARI-анализа. Возвращает пустую строку, если всё прошло в штатном режиме. В случае возникновения исключения возвращает строку с исключением.

PARI_SETNEW, STRING, string PARI_SetNew() - задает новый экземпляр текущего PARI-анализа.

TAPPS_SHOWMAINFORM, INTEGER, int TAPPS_ShowMainForm() - показывает модальную форму редактирования TAPPS-анализа. Возвращает 0, если была нажата клавиша ОК. Возвращает 1, если была нажата Отмена.

TAPPS_GETSERIALIZED, STRING, string TAPPS_GetSerialized() - получает сериализованный экземпляр TAPPS-анализа.

TAPPS_DESERIALIZE, STRING, string TAPPS_Deserialize(string serializedTapps) - десериализует строку в экземпляр TAPPS-анализа. Возвращает пустую строку, если всё прошло в штатном режиме. В случае возникновения исключения возвращает строку с исключением.

TAPPS_SETNEW, STRING, string TAPPS_SetNew() - задает новый экземпляр текущего TAPPS-анализа.

3.3.1 Реализация метода когнитивного анализа TAPPS на псевдокодовом языке

Z 2 Техника "Мысли вслух"

Q 2.1 &branch_qaid&

Q 2.1.1 0

Q 2.2 &history_branch_qaid&

Q 2.2.1 0

Q 2.3 PROCEDURE &TAPPS_CreateStructure&

Q 2.3.1 TAPPS dummy

Q 2.3.2 &t_int& := QA_GetQAId(&current_project&, "TAPPS dummy")

Q 2.3.3 &t_int& := QA_GetParent(&current_project&, &t_int&)

Q 2.3.4 &branch_qaid& := QA_GetParent(&current_project&, &t_int&)

Q 2.3.5 &history_branch_qaid& := QA_CreateNode(&current_project&, &branch_qaid&, 3, "")

Q 2.3.6 ENDPROC &TAPPS_CreateStructure&

Q 2.4 PROCEDURE &TAPPS_main&

Q 2.4.1 &t_str& := QA_GetQAText(&history_branch_qaid&)

Q 2.4.2 SETHISTORYENTRIES(&t_str&)

Q 2.4.3 CALL &ShowHistory&

Q 2.4.4 IF &LastHistoryFormResult& == -1 THEN RETURN

Q 2.4.5 IF &LastHistoryFormResult& == 0 THEN &current_action_qaid& := QA_CreateNode(&current_project&, &history_branch_qaid&, 3, "") ELSE &current_action_qaid& := &LastHistoryFormResult&

Q 2.4.6 &t_str& := QA_GetQAText(&current_action_qaid&)

Q 2.4.7 TAPPS_DESERIALIZE(&t_str&)

Q 2.4.8 &t_int& := TAPPS_SHOWMAINFORM()

Q 2.4.9 &t_str& := TAPPS_GETSERIALIZED()

Q 2.4.10 IF &t_int& == 0 THEN QA_UpdateNode(&current_project&, &current_action_qaid&, &t_str&)

Q 2.4.11 IF &t_int& != 0 RETURN

Q 2.4.12 IF &LastHistoryFormResult& == 0 THEN QA_UpdateNode(&current_project&, &history_branch_qaid&, ADDTOHISTORY(QA_GetQAText(&history_branch_qaid&), &t_str&, &current_action_qaid&))

Q 2.4.13 IF &LastHistoryFormResult& != 0 THEN QA_UpdateNode(&current_project&, &history_branch_qaid&, TRYUPDATETOPICINHISTORY(QA_GetQAText(&history_branch_qaid&), &t_str&, &current_action_qaid&))

Q 2.4.14 FINISH

Q 2.5 &t_int&

Q 2.5.1 0

Q 2.6 &t_str&

A 2.6.1 ""

Q 2.7 &LastHistoryFormResult&

Q 2.7.1 0

Q 2.8 PROCEDURE &ShowHistory&

Q 2.8.1 &LastHistoryFormResult& := SHOWHISTORYFORM()

Q 2.8.2 LABEL &SH_deletedLoopStart&

Q 2.8.3 &t_int& := GETDELETEDHISTORYENTRIESCOUNT()

Q 2.8.4 IF &t_int& == 0 THEN GOTO &SH_deletedEnd&

Q 2.8.5 &t_int& := POPONEDELETEDHISTORYENTRY()

Q 2.8.6 QA_DeleteNode(&current_project&, &t_int&)

Q 2.8.7 GOTO &SH_deletedLoopStart&

Q 2.8.8 LABEL &SH_deletedEnd&

Q 2.8.9 ENDPROC &ShowHistory&

Q 2.8.10 QA_UpdateNode(&current_project&, &history_branch_qaid&, GETHISTORYENTRIES())

Q 2.9 &LastHistoryFormResult&

Q 2.9.1 0

Q 2.10 &current_action_qaid&

Q 2.10.1 0

PROCEDURE &TAPPS_CreateStructure& - создает структуру анализа

PROCEDURE &TAPPS_main& - запускает форму TAPPS - анализа

PROCEDURE&ShowHistory& - запускает форму создания, редактирования и удаления TAPPS - анализа.

3.4 Реализация метода когнитивного анализа GDTA на псевдокодовом языке

псевдокодовый когнитивный моделирование библиотека

Это когнитивный метод анализа задач, который ориентируется (сосредотачивается) на то, чтобы раскрыть понимание ситуации - SA, связанной с требованием в задании.

Понимание ситуации SA - это восприятие элементов в среде в пределах конкретного пространства и времени, понимания их значения, проекции их состояния в ближайшее будущее, и прогноза того, как различные действия будут влиять на выполнение целей.

Q 1.1.1 Идентификация ключевых лиц, принимающих решение

Q 1.1.2 Идентификация главных целей и связанных с ней подцелей для каждого лица принимающего решение

Q 1.1.2.1Определите цель высшего порядка (основную)

Цель высшего уровня отражает полную цель лица, принимающего решения.

Q 1.1.2.1.1 Главная цель

Q 1.1.2.1.1.1 &Cel_id& := QA_GetQaId(&Current_Project&, "Главная цель")

A 1.1.2.1.1.1.1 35255

Q 1.1.2.1.1.2 INPUT &s&

Введите главную цель

A 1.1.2.1.1.2.1 "Glavnaya chel"

Q 1.1.2.1.1.3 QA_CreateNode (&current_project&, &Cel_id&, 3, &s&)

Q 1.1.2.1.1.4 GOTO &L1&

A 1.1.2.1.1.1 gl

Q 1.1.2.1.2 LABEL &L1&

Q 1.1.2.2Определите ряд главных целей, которые должны быть выполнены, чтобы достигнуть полной цели

Как правило 3-6 главными целями можно описать полную

Q 1.1.2.2.1 INPUT &count_cel&

Введие число вспомогательных целей

A 1.1.2.2.1.1 1

Q 1.1.2.2.2 Вспомогательные цели

Q 1.1.2.2.2.1 &current_count_cel& := 0

A 1.1.2.2.2.1.1 0

Q 1.1.2.2.2.2 &Cel_id1& := QA_GetQaId(&Current_Project&, "Вспомогательные цели")

A 1.1.2.2.2.2.1 35258

Q 1.1.2.2.2.3 LABEL &L2&

Q 1.1.2.2.2.4 INPUT &s1&

Введите вспомогательную цель, которая поможет вам для достижения главной

A 1.1.2.2.2.4.1 "vspom chel"

Q 1.1.2.2.2.5 QA_CreateNode (&current_project&, &Cel_id1&, 3, &s1&)

Q 1.1.2.2.2.6 &current_count_cel& := &current_count_cel& + 1

Q 1.1.2.2.2.7 IF &current_count_cel&<&count_cel& THEN GOTO &L2&

Q 1.1.2.2.2.8 GOTO &L3&

A 1.1.2.2.2.1 vspom chel

Q 1.1.2.2.3 LABEL&L3&

Q 1.1.2.3Определите список подцелей для каждой из главных целей

Для каждой цели это число будет переменным, в зависимости от сложности цели.

Q 1.1.2.4Для более сложных областей у подцелей также может быть любое число связанных подцелей

Q 1.1.3 Выделение первичного решения для каждой подцели

Q 1.1.3.1 Принимающее решение лицо, должно разработать решения для достижения определенной цели.

Эти решения - по существу вопросы

Q 1.1.3.2 Принимающее решения лицо должно ответить на вопросы, чтобы достигнуть указанной цели.