Средства оперативной формализации проектных решений в концептуальном проектировании автоматизированных систем

• Автор: Валюх, Вероника Валерьевна
• Шифр специальности: 05.13.12
• Научная степень: Кандидатская
• Год защиты: 2008
• Место защиты: Ульяновск
• Количество страниц: 229 с. : ил.

СОДЕРЖАНИЕ
Введение.

Глава первая. ФОРМАЛИЗАЦИЯ ПОНЯТИЙНОЙ ДЕЯТЕЛЬНОСТИ В ООЛП.

1.1 Формирование нормативных проектных решении в разработках Л С.

1.2 Тематический обзор методов и средств формализации проектных документов.

1.2.1 Системы управления проектированием ЛС

1.2.2 Средства автоматизированного анализа требований

1.2.3 Языки формальных спецификаций и средства их обработки

1.2.3.1 Языки формальных спецификаций алгебраической семантики

1.2.3.2 Языки формальных спецификаций моделеориентированной семантики.

1.2.3.3 Графические языки проектирования СЛИР.

1.2.3.4 Языки исполнимых спецификаций.
1.3 Семантические представления принимаемых решений средствами языка предикатов первого порядка.
1.3.1 Вопросноответное моделирование рассуждений
1.3.2 Место формализации в Аподходе к проектной деятельности
1.4 Задача исследовании и разработок системы средств оперативной формализации
проект ных решении.
1.4.1 Обобщенная формулировка задачи исследований
1.4.2 Вопросноответный анализ задачи исследований.
1.5 Выводы по ПЕРВОЙ ГЛАВЕ.
Глава 2. ПРОЛОГОПОДОБИЛЯ ФОРМАЛИЗАЦИЯ В КОНЦЕПТУАЛЬНОМ ПРОЕКТИРОВАНИИ
2.1 Модели предложений естсстнеппопрофсссионалыюго языка
2.1.1 Модели предложений русского языка
2.1.2 Модели предложений английского языка.
2.2 Язык прологоиодобной формализации
2.3 Выводы но ВТОРОЙ ГЛАВЕ
Глава третья. МЕТОДИКИ РЕШЕНИЯ ЗАДА Ч ОПЕРА ТИВНОЙ
ФОРМАЛИЗАЦИИ
3.1 Место оперативной формализации в Апроцессе концептуального проектирования.
3.1.1 Концептуальные модели.
3.1.2 Воиросноотвсгные модели
3.1.3 Операционная обстановка рабочего словаря
3.1.4 Динамика процессов сборки.
3.2 Задачи оперативной формализации проектных решений.
3.2.1 Структуризация действии.
3.2.2 Распознавание переподных соответствии.
3.2.3 Задачи преобразования многосоставных сложных предложений
3.2.3.1 Конструкции с однотипной синтаксической связью.
3.2.3.2 Конструкции с комбинированной синтаксической связью
3.3 Методики Рабочего Словаря.
3.4 Методики Логического Процессора.
3.5 Оценка повышении степени обнаружения ошибок.
3.6 Выводы по ТРЕТЬЕЙ ГЛАВЕ.
ГЛАВА 4. КОМПЛЕКС СРЕДСТВ ОПЕРАТИВНОЙ ФОРМАЛИЗАЦИИ.
4.1 Подсистема Рабочий Словарь
4.1.1 Описание логической структуры. Алгоритмы программы
4.2 Программна реализация компонента Рабочий Словарь
4.2.1 Состав программного комплекса.
4.2.2 Интерфейс пользователя
4.2.3 Диаграммы классов.
4.2.4 Структура базы данных Рабочего Словаря
4.3 Логическая структура Логического Процессора
4.3.1 Запуск Логического процессора из Рабочего Словаря.
4.3.2 Структура программных модулей Логического процессора
4.3.3 Описание таблиц базы данных Логического Процессора
4.3.4 Основные этапы построения формулы сложного предложения
4.3.4.1 Разбор сложного предложения на нары главных и зависимых предложений
4.3.4.2 Выявление типов логических связей между простыми предложениями в парах.
4.3.4.3 Выбор шаблона формулы логики предикатов для пары.
4.3.4.4 Составление обобщенной формулы на языке логики предикатов для сложного предложения
4.3 Интерфейс пользователя
4.5 Выводы но ЧЕТВЕРТОЙ ГЛАВЕ
Заключение.
Список литературы


Наиболее известная методология - , Rational Unified Process (RUP), предоставляющая команде разработчиков гибкую систему методов и средства коммуникации для общения на достаточном уровне формализации, с возможностью автоматизированного создания документов в соответствии с ГОСТами []. RUP реализует следующие принципы: 1) обеспечивается строгий подход к распределению задач и ответственности внутри оганизации-разработчика; 2) построение различных моделей проектируемой системы в ходе разработки, позволяет взглянуть на нее с различных точек зрения, может служить основой для дальнейшего улучшения готового изделия; присутствует возможность использования опыта предыдущих разработок. Таким образом, обеспечивается создание АС точно в срок и в рамках установленного бюджета качественного ПО, отвечающего требованиям функциональности конечных пользователей. В качестве языка моделирования в общей базе знаний RUP используется Unified Modeling Language (UML), который, кроме того, является международным стандартом [6]. Перейти от абстрактных рекомендаций по созданию хороших, полных и логичных спецификаций требований к непосредственному оформлению текста документа требований позволяют шаблоны. Шаблон VISION [] (Автор - Карл Вейгерс) определяет вид и границы проекта. Сам шаблон представляет собой развернутую структуру глав и параграфов («Бизнес требования», «Видение решений», «Масштабы и ограничения»), с пояснениями и рекомендациями, представленными как в текстовой форме, так и в табличной (Таблицы 1. В самом начале шаблона VISION располагается таблица вносимых изменений в текст уже готового документа (Таблица 1. СТ. Наличие такой информации позволяет сохранить в тексте логику и последовательность. Таблица 1. Таблица 1. Функциональности - % высоко приоритетных функций должны быть включены в выпуск 1. Шаблон Volere [], в свою очередь, предоставляет всеобъемлющий список так называемых компонент, которые рекомендуется использовать в качестве основы для написания документа спецификаций требований. Шаблон может быть обработан с применением базового инструментария автоматизированной обработки требований или в любом текстовом редакторе. Текстовый документ шаблона предусматривает секции для каждого тина требований, соответствующие проектируемой системе (См. Рис. Эскиз требования, это, по сути, руководство для написания каждого даже самого малого требования. На рисунке 1. Особенностью шаблона является наличие раздела «Комната ожидания» (“Waiting room”), в котором документируются идеи, не вошедшие в текущий выпуск, но могут быть полезными для последующих проектов, и, таким образом, ни одна из идей не будет потеряна. Другие требования. Customers atisfaction: Customer Dissatisfaction: . Рис. Таким образом, детальная стандартизация проектных процедур, связанных с извлечением, анализом и управлением требованиям, а также достаточно успешная практика в разработках АС с применением специализированных технологий и шаблонов, дает основание полагать принципиальную важность начальных этапов разработки АС для всех последующих этапов проектирования. Первоначальная регистрация материалов для формирования требований, как правило, происходит на естественно-профессиональном языке, в процессах совместной коммуникации участников, вовлеченных в разработку АС. По ряду причин, подобная форма содержит различного рода неопределенности и является опасным источником ошибок. В таблице 1. Таблица 1. Исследовательские группы Этапы проектирования Э. Финкельштейн1 ( г. CHAOS, обозначившее, так называемый, кризис в области производства программного обеспечения и касающееся оценки уровня успешности и провалов среди проектов в области информационных технологий (ИТ) в больших, средних и малых компаниях. Исследование показало (Рис. Проф. Э. Финкелышсйн (Д. IEEE по инженерии требований в году. Персональная страница: http://www. META Group - аналитическая компания, специализирующаяся на проведении исследований, сосредоточенных на проблемах н тенденциях в области информационных технологий, различных направлений бизнеса н нанлучших практик.