Содержание к диссертации
Введение
1 Состояние вопроса и постановка задачи исследования 11
1.1 Обзор методов проектирования программного обеспечения 11
1.1.1 Понятие проектировании ПО 11
1.1.2 Стадии и этапы разработки программ 16
1.1.3 Моделирование в проектировании ПО 17
1.1.4 Современные CASE-средства 23
1.2 Обработка естественного языка в автоматизированных системах 27
1.2.1 Обзор систем обработки естественного языка 29
1.2.2 Методы моделирования языковой деятельности 33
1.2.3 Лингвистические теории и их реализации 40
1.3 Цели и задачи исследования 41
2 Методика анализа текста технического задания 44
2.1 Основные положения методики анализа текста технического задания... 44
2.2 Семантическая модель текста документа «Техническое задание» 52
2.3 Требования к тексту технического задания 79
2.4 Основные результаты и выводы к главе 2 82
3.1 Предварительная обработка текста 84
3.1.1 Построение дерева разделов по структурной нумерации 84
3.1.2 Автомат разбора для формирования таблицы разделов 86
3.1.3 Построение списка предложений 89
3.1.4 Автомат разбора для формирования таблицы предложений 89
3.1.5 Разбор предложений. Построение списка лексем 90
3.1.6 Автомата разбора для формирования таблицы лексем 91
3.2 Синтаксический анализ 92
3.2.1 Описание работы синтаксического анализатора 92
3.2.2 Синтаксические правила 93
3.3 Семантический анализ 94
3.3.1 Копиляция грамматики 96
3.3.2 Построение дерева лингвистических переменных 96
3.4. Построение модели программного обеспечения 101
3.5 Основные результаты и выводы к главе 3 104
4 Автоматизированная система семантического анализа текста технического задания 105
4.1 Область применения автоматизированной системы семантического анализа текста технического задания 105
4.2 Общая архитектура автоматизированной системы 106
4.3 Принцип функционирования автоматизированной системы 108
4.4 Диаграммы классов 111
4.5 Структура файлов данных 114
4.6 Основные результаты и выводы к главе 4 114
5 Пример обработки технического задания и построения модели программного обеспечения 115
5.1 Техническое задание на систему расчета локальной сети 115
5.2 Результаты предварительной обработки текста 118
5.3 Результат работы семантического анализатора 122
5.4 Результат работы подсистемы построения диаграмм 124
5.5 Оценка эффективности разработанной системы "СемантикаТЗ" 125
Заключение 127
Библиографический список
- Стадии и этапы разработки программ
- Семантическая модель текста документа «Техническое задание»
- Разбор предложений. Построение списка лексем
- Принцип функционирования автоматизированной системы
Введение к работе
Проектирование программного обеспечения (ПО) это процесс составления описания, его преобразование, определения архитектуры, компонентов, интерфейсов, других характеристик системы и конечного состава программного продукта, результатом которого является проектное решение, удовлетворяющее заданным требованиям. Проектирование представляет собой трудоемкий процесс, требующий от пользователя глубокого знания предметной области и навыков в проектировании. В связи с этим весьма актуальна задача модификации проектных процедур таким образом, чтобы процесс создания программных продуктов стал более доступным.
В настоящее время проектирование включает разработку требований или технического задания (ТЗ), разработку системы или технического проекта, программирование или рабочее проектирование, пробную эксплуатацию, сопровождение и улучшение. Необходимо учитывать взаимозависимость всех основных частей процесса проектирования от инструментария, технологий и организации работ. Большинство работ в области САПР направлены на создание и совершенствование инструментария для автоматизации процесса проектирования. Значительный вклад в развитие САПР внесли В.И.Аверченков, Г.С.Альтшуллер, А.В.Андрейчиков, Н.П.Бусленко, В.П.Быков, Б.С.Воинов, Г.Д.Волкова, В. Гаспарский, Дж. К. Джонс, Дж. Диксон, М.Ф.Зарипов, В.А. Камаев, К.В.Кумунжиев, В.М.Курейчик, П.М.Ма-зуркин, И. Мюллер, И.П.Норенков, И.Ю.Петрова, А.И.Половинкин, А.Ф.Похилько, Ю.М. Соломенцев, Ф.Ханзен, П. Хилл, А. Холл и др.
Наиболее известные из коммерческих программных продуктов, используемых для проектирования программного обеспечения, предназначены для визуализации промежуточных и конечных результатов процесса проектирования. Некоторые из них позволяют полностью автоматизировать последние этапы проектирования: генерация кода, создание отчетной и сопровождающей документации и т.д. При этом задача автоматизации начального этапа проектирования - формирование и анализ текста
технического задания остается открытой. Это связано с необычайной сложностью проблемы синтеза и анализа семантики технического текста, для решения которой необходимо использовать симбиоз методов искусственного интеллекта, прикладной лингвистики, психологии и т.п. [70, 72, 74, 75].
Таким образом, актуальной является задача автоматизации начального этапа проектирования программного обеспечения, главным аспектом которой является автоматизация семантического анализа текста технического задания.
Цель и задачи исследования.
Целью диссертационной работы является повышение эффективности проектирования программного обеспечения за счет автоматизации семантического анализа текста технического задания.
Для достижения поставленной цели необходимо решить следующие задачи:
Провести анализ процесса проектирования программного обеспечения и моделей семантического анализа текста.
Разработать методику анализа текста технического задания.
Разработать и исследовать семантическую модель текста технического задания.
Разработать алгоритмическое обеспечение анализа текста технического задания и автоматического построения модели программного обеспечения.
Реализовать разработанные формализмы, методику и алгоритмы в виде системы автоматизации начального этапа проектирования программного обеспечения.
Провести исследование разработанной программной среды при проектировании программного обеспечения: систем расчета локальной сети, диспетчерского контроля и принятия решений.
Объектом исследования является текст технического задания на проектирование программного обеспечения.
Предметом исследования является эффективность проектирования программного обеспечения.
Методы исследования. При разработке методики анализа текста использовался математический аппарат теории автоматов, нечетких множеств, методы структурной и прикладной лингвистики, методы представления знаний в искусственном интеллекте. Разработка программных и информационных средств произведена на основе современных принципов построения САПР.
Научная новизна состоит в следующем: разработана методика анализа текста технического задания на начальных этапах проектирования программного обеспечения, включающая семантическую модель текста технического задания, преобразование смысла текста во фреймовую структуру и построение на ее основе модели программного обеспечения.
Впервые семантическая модель текста технического задания представлена как расширенная нечеткая атрибутная грамматика над фреймовой структурой, содержащая синтаксические, семантические атрибуты и лингвистические переменные.
Предложены и разработаны методика и алгоритмы, предназначенные для преобразования исходного текста технического задания в разработанную фреймовую структуру, представляющую собой представление требований к проектируемому программному обеспечению, и позволяющую системе быть универсальной по отношению к естественному языку пользователя-проектировщика.
Разработан метод построения модели программного обеспечения, описанного в техническом задании, на примере диаграмм потоков данных.
Положения, выносимые на защиту:
1. Фреймовая структура теста технического задания, являющаяся представлением требований к проектируемому программному обеспечению, описанному в техническом задании.
2. Семантическая модель текста технического задания в виде
расширенной нечеткой атрибутной грамматики над фреймовой структурой для
анализа текста технического задания.
3. Методика и алгоритмическое обеспечение анализа технического
задания и построения модели программного обеспечения по результатам
анализа.
Практическая ценность работы заключается в следующем:
1. Разработанная методика анализа текста позволяет упростить процесс
проектирования программного обеспечения на начальных этапах.
Разработанные формализмы анализа текста технических заданий могут использоваться для анализа других технических текстов и на других языках в различных предметных областях при автоматизации проектирования программного обеспечения.
В результате разработки и внедрения предлагаемой методики повышается качество проектирования за счет автоматизации рутинного труда человека по извлечению полезной информации из стандартного документа и отображению ее в виде модели программного обеспечения.
Достоверность полученных результатов подтверждается
теоретическим обоснованием использованных и предлагаемых подходов к анализу текста технического задания, а также результатами исследований разработанной программной среды.
Автоматизированная система семантического анализа текста технического задания внедрена в АГТУ, АНО "СНТО сетей МГУ", ВолгГТУ, и ООО "Связь и строительство".
Апробация работы.
Основные положения и результаты работы докладывались и обсуждались на: V-ой международной научно-технической конференции "Интеллектуальные системы (AIS'05). Интеллектуальные САПР (CAD-2005)" (Россия, Черноморское побережье, Дивноморское, 3-10 сентября 2005г.); VI International conference: "Interactive systems and technologies: The problems of
human-Computer Interaction" (г.Ульяновск, Россия, 26-30 сентября 2005г.); Х-ой Международной конференции и Российской научной школе (научный центр "АССОНИКА"): "Системные проблемы надежности, качества, информационных и электронных технологий: Инноватика-2005" (г.Сочи, 3-14 октября 2005г.); V-ой Международной научно-методической конференции: "Дистанционное обучение - образовательная среда XXI века" (Белоруссия, г.Минск, 10-11 ноября 2005г.); Х-ой и ХП-ой региональных конференциях молодых исследователей Волгоградской области по направлению "Компьютерное и информационное обеспечение теоретических и прикладных задач (г. Волгоград, 8-11 ноября 2005-2006гг.); Всероссийской конференции студентов, аспирантов и молодых ученых: "Технологии Microsoft в теории и практике программирования" (г.Москва, 2-3 марта 2006г.); Всероссийской конференции студентов, аспирантов и молодых ученых: "Технологии Microsoft в теории и практике программирования"(г.Нижний Новгород, 21-22 марта 2006г.); "Научной сессии МИФИ-2006: Интеллектуальные системы" (г.Москва, 2006г.); VI-ой международной конференции "Информационные технологии в образовании, медицине и технике" (г.Волгоград, 2006г.); IV-ой всероссийской конференции "Прогрессивные технологии в обучении и производстве" (г.Камышин, 2006г.); "Научной сессии МИФИ-2007: Интеллектуальные системы" (г.Москва, 2007г.); IV-ой международной научно-практической конференции "Интегрированные модели и мягкие вычисления в искусственном интеллекте" (г.Коломна, 28-30 мая 2007г.); Joint International Scientific Events on Informatics - ITA2008, "International Conference on Intelligent Information and Engineering Systems - INFOS2008"(r.BapHa, 23 июня - 03 июля 2008г.).
Работа "Естественно-языковое проектирование программного обеспечения. Формализация технического задания" удостоена дипломом третьей степени на Х-ой Региональной конференции молодых исследователей Волгоградской области (2005 г.), "Автоматизированное проектирование программного обеспечения по тексту технического задания" дипломом за активное участие в конференции аспирантов и молодых ученых "Технологии
Microsoft в теории и практике программирования" (2006г.), а работа "Подсистема предварительной обработки текста" удостоена поощрительной грамоты на XI-ой Региональной конференции молодых исследователей Волгоградской области (2006г.).
Автор является победителем программы "Участник молодежного научно-инновационного конкурса" (У.М.Н.И.К. - 2008).
По теме диссертации опубликовано 27 работ, в том числе: 4 статьи опубликованы в изданиях, входящих в перечень ВАК; 2 статьи в международных журналах; 12 статей в сборниках трудов; 9 материалов конференций.
Структура и содержание диссертационной работы.
Диссертация состоит из введения, пяти глав, выводов, списка литературы и приложений.
Во введении обоснована актуальность темы, сформулирована цель, определены задачи, научная новизна, практическая ценность работы и основные положения, выносимые на защиту.
В первой главе проведен анализ процесса проектирования программного обеспечения и анализ существующих моделей и методов обработки текстов, на основании которых сформулированы задачи исследования.
Во второй главе представлена методика анализа текста технического задания, построена семантическая модель текста технического задания в виде расширенной нечеткой атрибутной грамматики технического задания над фреймовой структурой, предназначенная для формализации ограниченного естественного, рассмотрены особенности технического задания как класса документов, сформулированы рекомендации по подготовке текста технического задания к автоматизированной обработке.
Третья глава посвящена рассмотрению алгоритмического обеспечения анализа текста технического задания и построения модели программного обеспечения по результатам анализа.
В четвертой главе рассматривается разрабатываемая
автоматизированная система семантического анализа текста технического задания, область ее применения, архитектура и принцип функционирования.
Пятая глава описывает проведенную комплексную проверку предложенной методики и алгоритмов при анализе технических заданий с помощью автоматизированной системы "СемантикаТЗ", рассматривается техническое задание на проектирование локальное сети, проводится его семантический анализ, построение фреймовой структуры и модели программного обеспечения, производится оценка эффективности разработанной системы.
В заключении приведены выводы и основные результаты работы.
В приложении приведены материалы справочного и иллюстративного характера.
Стадии и этапы разработки программ
Один объект или система может выступать в роли модели другого объекта или системы, если между ними установлено сходство в каком-то смысле. Моделью системы (или какого-либо другого объекта или явления) может быть формальное описание системы, в котором выделены основные объекты, составляющие систему, и отношения между этими объектами.
Построение моделей - широко распространенный способ изучения сложных объектов и явлений. В модели опущены многочисленные детали, усложняющие понимание. Моделирование широко распространено и в науке, и в технике.
Модели помогают проверить работоспособность разрабатываемой системы на ранних этапах ее разработки; общаться с заказчиком системы, уточняя его требования к системе; вносить (в случае необходимости) изменения в проект системы (как в начале ее проектирования, так и на других фазах ее жизненного цикла); передавать проект иным исполнителям, например кодировщикам, поскольку сам проект является моделью проектируемой программы [98].
Любые достаточно большие программы являются сложными системами. Проблема сложности преодолевается путем декомпозиции задачи. Базовая парадигма в подходе к любой большой задаче ясна: необходимо «разделять и властвовать».
При декомпозиции используется абстрагирование для получения абстрактных моделей. Абстракция - мысленное отвлечение, обособление от тех или иных сторон, свойств или связей предметов и явлений для выявления существенных их признаков. Абстрагирование от проблемы предполагает игнорирование ряда подробностей с тем, чтобы свести задачу к более простой задаче.
Отдельные виды абстракций определяют наиболее эффективный способ декомпозиции применительно к конкретным целям. Верно опознав абстракции, можно получить модели, доступные для понимания как отдельными людьми, так и коллективом участников проекта.
Задачи абстрагирования и последующей декомпозиции типичны для процесса создания программ. Декомпозиция используется для разбиения программы на компоненты, которые затем могут быть объединены, позволяя решить основную задачу. Абстрагирование же предполагает продуманный выбор моделей будущих компонент.
Под спецификацией понимается достаточно полное и точное описание решаемой задачи на этапах проекта. Спецификация является моделью проектируемого объекта (программы).
Сложность проектируемых систем привела к созданию специальных абстрактных языков, графических нотаций и поддерживающих их автоматизированных систем, облегчающих процесс создания спецификаций.
Первичные спецификации составляют в терминах решаемой задачи, а не программы. В ходе выполнения проекта спецификации последовательно претерпевают изменения до программных документов стадий и вплоть до документации, которая необходима для эксплуатации и сопровождения программы.
Уже в первичных спецификациях можно выделить две части: функциональную и эксплуатационную. Первичная функциональная спецификация в первую очередь описывает: а) объекты, участвующие в задаче (что делает программа и что делает человек, работающий с этой программой); б) процессы и действия (проектные процедуры и эвроритмы человека, алгоритмы методов решения задачи в машине с указанием сути и порядка обработки информации с занимаемым ей и программой размером оперативной памяти); в) входные и выходные данные, их организацию (например, сценарий диалога с экранными формами, организация файлов с указанием длин полей записей и предельного количества информации в файлах). То есть вначале фиксируются внешние функциональные спецификации, а затем и внутренние.
Семантическая модель текста документа «Техническое задание»
Семантическая модель текста технического задания представлена в виде нечеткой атрибутной грамматики над фреймовой структурой технического задания.
Важным моментом является неоднозначность грамматик (можно построить более одного дерева разбора) и реализация нисходящего разбора при синтаксическом анализе.
Но разрабатываемая грамматика технического задания сводима к грамматикам типа 3 в связи с:
а) Выбором узкоспециализированной области естественного языка. То есть имеется в виду, что для анализа текста технического задания будут использоваться только грамматики построения фраз из этой сферы, а для иного случая применения будут использоваться другие грамматики. Под понятием другие имеется в виду набор используемых лексем при сохраняющемся синтаксисе.
б) Наличием в грамматике атрибутов. КС-грамматику, каждому символу которой сопоставлено множество атрибутов, а каждому правилу вывода - множество семантических правил, будем называть атрибутной грамматикой (AG).
Будем считать, что значение атрибутов терминальных символов -константы, т.е. их значения определены, но для них нет семантических правил, определеяющих их значения.
Если дана атрибутная грамматика AG и цепочка, принадлежащая языку, определяемому G, то можно построить дерево разбора этой цепочки в грамматике G. В этом дереве каждая вершина помечена символом грамматики G. Припишем теперь каждой вершине множество атрибутов, сопоставленных символу, которым помечена эта вершина. Атрибуты, сопоставленные вхождениям символов в дерево разбора, будем называть вхождениями атрибутов в дерево разбора, а дерево с сопоставленными каждой вершине атрибутами - атрибутированным деревом разбора.
Между вхождениями атрибутов в дерево разбора существуют зависимости, определяемые семантическими правилами, соответствующими примененным синтаксическим правилам.
Формализм атрибутных грамматик оказался очень удобным средством для описания семантики языков. Вместе с тем выяснилось, что реализация вычислителей для атрибутных грамматик общего вида сталкивается с большими трудностями. В связи с этим было сделано множество попыток рассматривать те или иные классы атрибутных грамматик, обладающих "хорошими" свойствами. К числу таких свойств относятся прежде всего простота алгоритма проверки атрибутной грамматики на зацикленность и простота алгоритма вычисления атрибутов для атрибутных грамматик данного класса.
Учитывая это, мы будем вести дальнейшее изложение на языке, сочетающем особенности атрибутного формализма и обычного языка, в котором предполагается возможность управления порядком исполнения операторов. Этот порядок привязывается к обходу атрибутированного дерева разбора сверху вниз слева направо. Все атрибуты должны быть вычислены за один такой обход. Атрибутные грамматики, обладающие таким свойством, называются L-атрибутными.
При записи синтаксиса мы будем использовать расширенную БНФ.
Описание атрибутной грамматики состоит из раздела описания атрибутов и раздела правил. Раздел описания атрибутов определяет состав атрибутов для каждого символа грамматики и тип каждого атрибута. Правила состоят из синтаксической и семантической части. В синтаксической части используется расширенная БНФ. Семантическая часть правила состоит из локальных объявлений и семантических действий. В качестве семантических действий допускаются как атрибутные присваивания, так и составные операторы.
Метка в семантической части правила привязывает выполнение оператора к обходу дерева разбора сверху-вниз слева направо.
Ниже дан синтаксис языка описания атрибутных грамматик. Приведен только синтаксис конструкций, описывающих атрибутные вычисления. Атрибутная грамматика ::= ALPHABET ( ОписаниеНетерминала ) ( Правило ) ОписаниеНетерминала ::= ИмяНетерминала :: [( ОписаниеАтрибутов / ; )] . ОписаниеАтрибутов ::= Тип ( ИмяАтрибута / , ) Правило ::= RULE Синтаксис SEMANTICS Семантика . Синтаксис ::= ИмяНетерминала ::= ПраваяЧасть ПраваяЧасть ::= [( ЭлементПравойЧасти )] ЭлементПравойЧасти ::= ИмяНетерминала Терминал ( Нетерминал [ V Терминал ] ) [ Нетерминал ] [( Нетерминал [ V Терминал ] )] Семантика ::= [(ЛокальноеОбъявление / ; )]
Разбор предложений. Построение списка лексем
Разделение технического задания на разделы осуществляется с помощью конечного автомата, описанного на рисунке 3.4.
Входной символ конечного автомата: с і - пустое пространство, Сг -пробел, сз- новая строка, с4 - конец текста, с5 - Г.. 9 , с6 - ГГ, с0- любой другой символ. Промежуточные состояния автомата: ai. начало разбора номера раздела, а2 - последовательность символов — текст, аз - последовательность символов — нумерация, а4 - начало разбора названия раздела, as - последовательность символов — название раздела, а6 - начало разбора текста раздела или приложения, а7 - последовательность символов — продолжение текста раздела или приложения, а8 - начало разбора названия приложения, а9 -последовательность символов - название приложения, ао - конец ТЗ.
Разбор текста ТЗ начинается с разбора разделов первого уровня и разбора приложений. После формирования таблицы первого уровня начинается анализ текста каждого из разделов первого уровня.
Так как в тексте раздела первого уровня не может быть приложений, разбор приложений не производится. После формирования таблицы разделов второго уровня анализируется текст каждого раздела второго уровня и формируется таблица разделов третьего уровня. В конце работы все таблицы объединяются.
При попадании автомата в состояние, в котором происходит изменение таблицы разделов, в таблицу разделов вносятся изменения соответственно предыдущему промежуточному состоянию. Например, если последовательность символов - название раздела, то в таблице разделов заполняется поле «Название раздела».
Разбор технического задания начинается с разбора номера раздела. Если оно начинается не с нумерации, а с текста, то выводится сообщение о несоответствии технического задания госту. По этой причине в автомате дважды используется блок разбора номера раздела. Затем создается раздел и добавляется номер в соответствующее поле таблицы разделов.
После сохранения номера производится разбор названия раздела до начала новой строки и текста раздела. Мы переходим в конечное состояние, если встречаем конец текста. Если встретили новую строку, то переходим в состояния пропуска пустого пространства. Если же в тексте имеются цифры, то проверяем не является ли это номером нового раздела. Так как в соответствии с гостом приложение начинается с "Приложение А", то переходим к разбору приложения при встречи символа "П". Разбор текста приложения проводится аналогично разбору текста раздела [77, 78].
Таблица предложений связана по полю «код раздела» отношением типа «многие к одному» с таблицей разделов.
Предложением называется фрагмент текста, не содержащий точек и символов «точка с запятой». Как правило, в реальных документах список функций системы оформляется как маркированный список, где описание каждой функции начинается с маленькой буквы, а заканчивается точкой с запятой или точкой.
Входной символ конечного автомата: со - с4 — как в автомате разбора на разделы, с7 - буква или цифра, eg- прописная буква, с9 - ; , сю - . .
На вход автомата подается таблица разделов, полученная на предыдущем этапе. Создаем новое предложение в таблице предложений и накапливаем символы до точки, точки с запятой или символа новой строки. При попадании в автомат точки производится проверка на наличие сокращения. Если сокращение, то продолжаем накапливать символы, если нет, то сохраняем накопленную последовательность в таблицу и начинаем разбор нового предложения. Производим разбор до тех пор, пока не встретим конец текста.
На основе таблицы предложений формируется таблица лексем, содержащей поля: код лексемы - уникальный числовой идентификатор; код предложения - число, равное коду предложения, в котором находится лексема; номер лексемы - число, равное номеру лексемы в предложении; текст - текст лексемы. Рассмотрим конечный автомат для разбора на лексемы (рисунок 3.6). Входной символ конечного автомата: с0 - сю— как в автомате разбора на предложения, Си - - .
На вход автомата подается каждое предложение из таблицы предложений. Производится накопление символов до точки, пробела или конца предложения и сохранение в таблицу лексем. Разбор производится до тех пор, пока не встретится конец предложения.
Принцип функционирования автоматизированной системы
Предварительная обработка текста необходима для того, чтобы разделить исходный текст технического задания на отдельные лексемы. Эта операция выполняется в три этапа: разделение на разделы, предложения и отдельные лексемы.
Уже после первого этапа производится работа не со всем текстом технического задания, а с его частями, представленными по разделам. По ходу работы текст технического задания дробится сначала на разделы все более низкого уровня, затем текст каждого раздела нижнего уровня делится на отдельные предложения, а каждое предложение делится на лексемы с указанием принадлежности к предложениям.
Входной информацией подсистемы предварительной обработки текста является текст технического задания на ограниченном естественном языке, выходной информацией - таблицы разделов, предложений и лексем рассматриваемого технического задания. Результаты могут быть представлены как в виде соответствующих таблиц, так и в виде дерева разделов. Это позволяет легко находить ошибки в оформлении документа, если он не соответствует ГОСТам.
Алгоритм предварительной обработки текста реализован следующим образом: сначала весь текст ТЗ делится на разделы первого уровня («1.», «2.», «3.» и т.д.), затем делится каждый раздел и так далее до третьего уровня. Предварительная обработка текста осуществляется с использованием аппарата конечных автоматов. В ходе работы конечного автомата символы, поступающие на его вход, накапливаются в буфере. В определенных состояниях конечного автомата осуществляется запись текущего содержимого буфера в одну из таблиц (разделов, предложений или лексем), после чего буфер опустошается. Работа автомата продолжается до достижения конечного состояния.
После этого полученные таблицы поступают на вход подсистемы синтаксического и семантического анализа. Семантический анализ текста производится на основе разработанной расширенной нечеткой атрибутной грамматики текста технического задания. Морфологический и синтаксический модули, используемые в программе, являются модулями стороннего разработчика. Если в правиле грамматики встретился терминал, имеющий синтаксический атрибут, то запускается механизм синтаксического анализа для текущего разбираемого предложения.
После создания дерева лингвистических переменных начинается построение фреймового описания технического задания. Для этого используется информация о фреймах и названиях слотов, которая содержится в атрибутах символов грамматики.
Полученная фреймовая структура содержит значимую информацию о системе: сведения о входах и выходах системы, функциях и ограничениях. Для каждой функции также выделяются входы и выходы. Это позволяет на основе фреймовой структуры получить диаграммы потоков данных системы.
Для построения потоков данных сначала производится поиск входов функций, совпадающих с входами системы. Затем функции, на все входы которых поступают данные, помещаются на диаграмму на одном уровне. Их входы соединяются с входами системы. Далее производится поиск функций, входы которых совпадают с выходами полученных на предыдущем шаге функций. Они помещаются на следующем уровне, их входы соединяются с выходами функций предыдущих уровней и с входами системы. Работа алгоритма продолжается до тех пор, пока все функции не будут помещены на диаграмму. После этого производится соединение выходов функций с необходимыми выходами системы. Функциональная структура автоматизированной системы представлена на рисунке 4.2.
Диаграмма процессов системы в нотации IDEF0 представлена в приложении А. Экранные формы диалога с пользователем показаны в приложении Б. Спецификация классов представлена в приложении Г.
Проект разработан на платформе Microsoft .NET Framework (язык разработки С#). Разработанная атрибутная грамматика текста технического задания и таблицы разделов хранятся в формате XML, а их визуальное представление возможно с использованием XSL-преобразования. Полученное при семантическом анализе фреймовое описание также сохраняется в формате XML. Построение диаграмм потоков данных осуществляется с помощью взаимодействия системы с программой MS Visio 2003 [109, 114].
Структура файлов грамматики и ER-диаграммы представлены в приложении В.
Спроектирована автоматизированная система семантического анализа текста технического задания, разработана общая архитектура, функциональная структура автоматизированной системы, представлена структура выходных файлов, показаны диаграммы классов, оценена область применимости спроектированной автоматизированной системы.
Недостатками данной системы является недоработанный графический интерфейс диалога с пользователем, ограниченный формат входных и выходных данных, высокие системные требования.
Похожие диссертации на Автоматизация семантического анализа текста технического задания
