Вопросно-ответное моделирование в проектировании автоматизированных систем

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Вопросно-ответное моделирование в проектировании автоматизированных систем

В программной инженерии существует проблема успешности проектирования сложных автоматизированных систем (АС), интенсивно использующих программное обеспечение [Леффингуэлл и др., 2002]. Степень успешности разработок таких систем, выраженная через число проектов, завершившихся в соответствии с исходными замыслами и планами, чрезвычайно низка (около 30%).

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

Практика разработок АС показывает, что негативное воздействие указанных выше причин на успешность проектирования можно снизить, применяя эффективные вопросно-ответные средства для взаимодействия с опытом, вовлечённым в процесс разработки. Так, например, для формирования требований к АС было предложено [Potts at al., 1994] использовать «inquiry cycle - цикл работ с вопросами». В основу реализации цикла положены действия «спросить, исследовать, создать, обсудить, применить»

Родственным для «inquiry cycle» является предложение [Reiff at al, 2002]], получившее название «inquiry whill - колесо работ с вопросами». Идеи «inquiry whill» в настоящее время активно развиваются для их приложений в проектировании [http://www.design-principles.org]. В рамках этих приложений средства «inquiry wheel» полезно дополняются средствами типа «inquiry map - вопросная карта» и другими вопросно-ответными средствами [http://wise.berkeley.edu].К месту отметить, что последние годы наблюдается всё возрастающий интерес [Burger et al., 2001] к вопросно-ответным процессам, технологиям и системам (короче QA).

Представленные ниже средства вопросно-ответного моделирования (QA-моделирования), позволяющие внести полезный вклад в успешность проектирования АС, разработаны в рамках QA-проблематики. Реализация этих средств доведена до их использования в корпоративной среде автоматизированного проектирования [Sosnin, 2004], построенной на базе вопросно-ответного процессора NetWIQA (Net Working Into Questions and Answers). К числу отличий средств QA-моделирования от QA-средств, названных выше, относятся следующие:

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

Каждый образовавшийся и обнаруженный «вопрос», если он существенен для разработки АС, описывается и представляется в базе проекта АС как «объект» с позиций объектно-ориентированного программирования.

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

QA-модели задач конкретного процесса проектирования строятся согласованно и фронтально по образцу теорий содержательно-эволюционного типа. Механизмы, подобные «inquiry cycle» и «inquiry wheel», используются, но в рамках итеративных циклов разработки АС.

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

В технологиях ООАП и АОП для структуризации процесса и результата разработки АС используется деятельностная единица, получившая название «задача». Такая структуризация, например, является базовой в инструментально-технологической среде 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(t₀) извлекается информация для построения исходной совокупности «вопросов» {Q_i} как «объектов» процесса проектирования. Каждый «объект-вопрос» представляет собой динамический конструкт

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. Исходное множество «вопросов» {Q_i} используется как база, с которой начинается управляемый содержательно-эволюционный процесс построения «ответов», извлечения очередных вопросов и т.д. В результате эволюционного процесса формируется вопросно-ответное представление задачи

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

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

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Структура вопросно-ответного представления задачи

На этой же схеме отражены и результаты анализа протоколируемых текстов. В основу анализа положена имитация машинного перевода текстов на прологопододобный язык. Перевод нацелен на выявление очередных вопросов в рассуждениях проектировщиков и создание онтология процесса разработки АС. В 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.

Сущность QA-моделирования

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

Сущность QA-моделирования определяет интерактивное взаимодействие лиц, которым разрешён доступ к модели QA (Z(t)) = S({XI(Ob_i, Sb¹_j, Sb²_k, t, G_n)}), позволяющий:

Обогащать модель QA (Z(t)) дополнительным содержанием за счёт включения в её состав очередных единиц типа XI(Ob_i, Sb¹_j, Sb²_k, t, G¹_n), а также за счёт формирования с её помощью (в том числе используя возможности атрибутики G_n): ряда концептуальных моделей задачи Z(t), включая модели на базе языка UML; ряда визуально-интерактивных представлений модели QA (Z(t)); ряда преобразований модели QA (Z(t)).

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

Использовать результаты анализа состояний модели QA (Z(t)) для: установления понимания и взаимопонимания в группе лиц, заинтересованных в разработке АС; извлечения требований и ограничений к разработке; регистрации и использования трассировки в системе проектных решений, позволяющей управлять изменениями в проекте; мониторинга состояния процесса проектирования; контроля за ходом процесса проектирования; управления процессом проектирования; ряда других положительных эффектов процесса и результата разработки.

Инструментально-технологическая среда QA-моделирования

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

Комплекс RUP предоставляет разработчикам АС интерактивный доступ к системе моделей опыта проектирования, подготовленного к его использованию в корпоративной сети. К сожалению, в RUP практически отсутствуют средства, обслуживающие рассуждения проектировщиков по ходу проектирования, в то время как рассуждения являются основным средством взаимодействия проектировщиков с опытом и его моделями

Именно по этой причине средства QA-моделирования разработаны так, что они согласованы со средствами RUP. Более того, средства QA-моделирования входят в специализированный инструментально-технологический комплекс, позволяющий реализовать специальный поток работ поддержки «Взаимодействие с опытом», дополнительный к потокам работ RUP.

Инструментальная часть, обслуживающая поток работ «Взаимодействие с опытом», реализована [Sosnin, 2004] в виде клиент серверной версии вопросно-ответного процессора Net WIQA. В основу QA-процессора положена система структур данных и операций, позволяющая материализовать (в корпоративной сети) систему моделей QA (Z(t)) для её наиболее общего случая, когда задача Z(t) является задачей разработки АС. Технологическая поддержка потока «Взаимодействие с опытом» реализована в виде следующих приложений QA-процессора:

«Концептуальное проектирование АС» предоставляет согласованную с RUP и стандартом ISO/IEK 12207 схему действий в корпоративной среде. Процесс концептуального проектирования поддерживает система сценариев, в результате исполнения которых, кроме концептуального решения задач проекта АС, разрабатываются основные диаграммы UML, нормативные проектные документы (12 документов российских стандартов для АС) и ряд документов RUP (25 документов первых потоков работ «деловое моделирование» и «требования»). Для всех задач, которые обнаруживаются по ходу работы, формируются или используются QA-модели и их исследование.

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

«Формирование базы опыта проектной организации», позволяющего извлекать из QA-базы образцы проектных решений, включая образцы задач и их QA-моделей, и включать их в общую QA-базу разработок проектной организации.

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

Средства QA-моделирования подтвердили свою практическую полезность в разработках ряда АС, включающего «Автоматизированную систему управления университетскими процессами на базе средств массового обслуживания», «Комплекс средств автоматизации специального назначения» и «Автоматизированная система управления перевозкой грузов». Последняя версия процессора Net WIQA, предоставляющая доступ к ресурсам через WEB-оболочку, а также все приложения QA-моделирования были также разработаны с использованием идей и средств, представленных выше.

Список литературы

1. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению: унифицированный подход. М.: Вильямс, 2002

2. Burger J. et al. «Issues, Tasks and Program Structures to Roadmap Research in Question & Answering (Q&A)». NIST, p. 36, 2001.

3. Kroll P. and Kruchten Ph., The Rational Unified Process Made Easy: A Practitioners Guide to the RUP, Addison-Wesley, 2003.

4. Potts C., Takahashi K. Anton A. «Inquiry-based Requirements Analysis» // IEEE Software, 11 (2), 1994, pp 21-32.

5. Reiff R., Harwood W., Phillipson T. «A Scientific Method Based Upon Research Scientists' Conceptions of Scientific Inquiry, Session». // Proceedings of the 2002 Annual International Conference of the Association for the Education of Teachers in Science, 2002, pp 546-556.

6. Sosnin P. «Question-Answer Processor for Cooperative Work in Human-Computer Environment». // Proceeding of the 2d International IEEE conference Intelligent System 2004, pp 452-456.

Размещено на Allbest.ru