CC BY
17
сложностью для заданного порядка нелинейности функции комбинирования. В частности, полином Жегалкина, используемый в качестве нелинейной функции комбинирования, должен
содержать слагаемые с порядками нелинейности от 1 до А- включительно, причем порядковый номер сомножителей в каждом из слагаемых полинома Жегалкина должен быть различен.
СПИСОК ЛИТЕРАТУРЫ
1. Фомичева С. Г. Теория потоковых систем защиты информации. Норильск: 2007. 243 с.
2. Фомичева С. Г. Зашита информации в распределенных иерархических системах // Научно-технические ведомости СПбГПУ: Информатика. Телекоммуникации. Управление. 2008. №2. С. 91-97
3. Блейхут Р. Теория и практика кодов, контролирующих ошибки: Пер. с англ. М.: Мир, 1986. 576 с.
4. Логачев О. А., Сальников А. А., Я том ко В. В.
Булевы функции в теории кодирования и криптологии. М.: МЦНМОб 2004. 470 с.
5.Лидл P., H илеррай I ер Г. Конечные поля. Т. 1,2. М.: Мир. 1988
6. Fomitchova S. G. Equivalent schemes of stream scrambler cryptosystems // Proceedings XI International Symposium on Promblems of Redundacy in Information and Control Systems. Saint-Petersburg, Russia. 2007. P. 189-193.
Лаптев В. В., МорозовА. В. Метод оценки качественных характеристик
объектно-ориентированных программных продуктов
Обеспечение высокого качества при разработке программных продуктов — одна из важнейших задач разработки, и, в то же время, сложнейшая проблема. Для определения качества разрабатываемого продукта требуется оценка его качественных характеристик, которые можно разбить на два множества: внутренние и внешние. Внешние характеристики определяют потребительское качество системы и видимы пользователю. К ним относятся в первую очередь надежность, безопасность, функциональность, производительность, эргономичность. Внутренние характеристики более важны для разработчиков, так как оказывают существенное влияние на потребительское качество и экономические затраты при разработке. Внутренними характеристиками являются переносимость, понятность, модифицируемость. модульность, подверженность ошибкам, удобство сопровождения и т. д.
Задача оценки качественных характеристик может ставиться на разных стадиях разработки. Наиболее просто она может быть решена на завершающих этапах, когда в наличии имеется уже готовый программный продукт или большая его
часть. Внешнее качество продукта оценивается путем тестирования, при котором осуществляются непосредственные наблюдения и измерение внешних характеристик. Оценка внутренних качественных характеристик является значительно более сложной задачей, поскольку для этого нужно выполнять инспекцию исходного кода. Эту работу обычно выполняет группа высококвалифицированных экспертов, что требует значительных экономических затрат (до 30-40 % от обшей стоимости разработки).
Однако оценка качественных характеристик на 'завершающих этапах разработки по сути является просто констатацией достигнутого уровня качества. Значительно более важной задачей является определение, а точнее, прогнозирование качественных характеристик продукта на более ранних этапах разработки, в частности, на этапе проектирования. Актуальность этой задачи очевидна, поскольку своевременное уточнение характеристик позволит планировать мероприятия по улучшению качества будущего продукта в процессе разработки, а не после окончания проекта. Это может существенно снизить затраты на разработку.
Для автоматизации оценки качественных характеристик программного продукта необходимо решить следующие задачи:
1. Определить состав характеристик, по которым следует классифицировать программный продукт.
2. Построить модель программного продукта. по которой будет оцениваться его качество.
3. Решить задачу классификации построенной модели по выбранным характеристикам.
В различных источниках приводится примерно одинаковый набор качественных характеристик программного обеспечения [1, 2, 3]. В результате анализа были выявлены следующие наиболее общие характеристики, решающим образом влияющие на качество программного продукта:
1. Сложность реализации (сотр!ехИу,
СРЬХ(Х)) - отражает объем затрат материальных и человеческих ресурсов, необходимых для первоначальной реализации проекта.
2. Сложность модернизации (\oIatily, УЬТЬ(Х)) - отражает объем затрат, которые по-
следующий шаг в решении задачи оценки качества - построение проектной модели, необходимой, для того чтобы представить разнообразные и разрозненные составляющие разрабатываемого продукта в едином формализме.
В рамках данной работы рассматриваются только объектно-ориентированные программные продукты (ООПГТ), поскольку эта
требуются для развития функциональности программного продукта.
3. Сложность сопровождения (maintenance, MNTN(X)) - отражает объем затрат, необходимых для поддержания в рабочем состоянии программного продукта без изменения его функциональности.
4. Подверженность ошибкам (weakness, IVCK(X)) - показывает количество ошибок, которые могут быть допущены при реализации программного продукта разработчиками.
5. Возможность повторного использования (recycling, RCCL(X)) - отражает степень готовности проекта к повторному использованию для реализации другого программного продукта в той же предметной области.
Каждая из перечисленных характеристик не вычисляется количественно, а определяется некоторой лингвистической величиной (хорошо, допустимо, плохо и т.д.). Поэтому в рамках данного подхода характеристики предлагается определять как лингвистические переменные с фиксированным набором термов. Например, характеристика VLTL(X)-сложность модернизации - может быть представлена набором термов, показанных в табл. 1.
методология на текущий момент является самой распространенной и в достаточной мере формализованной.
Проектную модель можно строить на разных этапах разработки: при проектировании, при кодировании, и при тестировании. На различных этапах разработки ООПП создаются различные артефакты, показанные в табл. 2.
Таблица I
Значения характеристики VLTL(X)
Название терма Определение терма
Проект не модернизируем Затраты на модернизацию программного продукта равны или больше, чем реализация нового продукта е модернизированной функциональностью
Проект трудно модернизируем При модернизации программного продукта меняется больше старого кода, чем добавляется нового
Проект модернизируем При модернизации программного продукта добавляется больше нового кода, чем изменяется старого
Проект легко модернизируем При модернизации программного продукта добавляется только новый код
Таблица 2.
Артефакты ООПП
Этап Артефакты
Анализ требований к системе Диаграммы вариантов использования, взаимодействия, диаграммы классов, каталоги С-требований
Проектирование системной архитектуры Диаграммы развертывания, диаграммы компонентов, текстовые описания архитектуры
Анализ требований к программным средствам Диаграммы компонентов, текстовые описания требований
Проектирование программной архитектуры Диаграммы компонентов, диаграммы классов, диаграммы взаимодействия, диаграммы состояний, диаграммы пакетов, текстовые описания архитектуры
Техническое проектирование программных средств Диаграммы классов, диаграммы взаимодействия, диаграммы состояний, прототипы пользовательских интерфейсов, текстовое описание проектных решений
Программирование и тестирование программных средств Диаграммы классов, диаграммы взаимодействия, диаграммы состояний, программный код. сценарии тестирования, руководство пользователя и программиста
Сборка программных средств Бинарные исполняемые и ресурсные файлы
Из перечисленных артефактов наибольший интерес представляют поддающиеся формализации артефакты, а именно диаграммы (в нотации иМЬ [3]), программный код и бинарные исполняемые файлы.
На основе проведенного анализа основных артефактов проекта были выявлены семантически значимые понятия ООПП и связи между ними, установлены соответствия между понятиями в различных артефактах и построена единая проектная метамодель. Понятия метамодели и связи между ними в нотации диаграммы классов иМ1_ 2.0 показаны на рис. 1.
Диаграммы Ь'М1_ выгодно отличают от других артефактов проекта, поскольку они создаются на самых ранних этапах разработки. Поэтому их анализ позволит отбросить неэффективные проектные решения на ранней стадии разработки.
Построение модели ООПП на основе диаграмм 1!МЬ должно производиться в два этапа. На первом этапе анализируются статические иМЬ-модели -диаграммы компонентов, пакетов и классов. При этом определяются элементы, соответствующие понятиям метамодели «проект», «пространство имен», «тип данных», «элемент данных», «функция-член».
На втором этапе проводится анализ динамических моделей - диаграмм последовательностей и коопераций. По ним достраивается часть
модели, относящаяся к внутреннему описанию функций-членов.
Построение конкретной модели ООПП на основе программного кода также выполняется за два шага. На первом шаге осуществляется построение дерева синтаксического разбора кода, которое по структуре сходно с предлагаемой метамоделью, но не содержит обратных ссылок. Вместо них указываются идентификаторы, заданные в коде. На втором шаге производится разрешение имен идентификаторов, и построенное дерево синтаксического разбора преобразуется в метамодель.
Итоговыми артефактами проекта ООПГ1 являются двоичные исполняемые файлы, которые представляют собой последовательность команд процессора или виртуальной исполняющей среды, а также сохраненную метаинформацию о внутренней структуре программы. Для большинства современных платформ, включая Win32-npn-ложения. сборки NET, пакеты Java, разработаны механизмы манипулирования и анализа вышеупомянутой метаинформацией, которые носят общее название рефлексия. С помощью рефлексии можно получать информацию об определенных типах данных внутри исполняемых файлов, свойствах, полях, методах определенных в них и таким образом строить конкретную модель ООПП.
Для каждого анализируемого проекта с использованием описанных выше артефактов
Project 1 Solution
• -♦!
Namespace
►Name
Atom
1п1
Double
Enum
DataType
•Name
-GenericParam
g.
Complex
-Visibility
S
Structure Class
Constructor
Destructor
Method
Data Memeber
+Name •'■Type
<b
Field
Property
Function Membei
•Name ■ReturnType
1
1..2
♦getter / setter
Parameter
♦Name "Type
Declaration
♦Name "■Type
Operator
Data Access
Operator braces
Cycle
Condition
call
Рис. 1. Метамодель проекта ООПП
строится конкретная модель, являющаяся воплощением метамодели. Первоначально модель строится на основе диаграмм ЦМЬ, а затем дополняется и уточняется на основе данных, получаемых в результате анализа программного кода и бинарных исполняемых файлов.
Задачу определения качественных характеристик ООПП можно свести к задаче отнесения проектной модели к одному из классов качества (классификации). Однако решить эту
задачу непосредственное использованием графа проектной модели достаточно сложно. Поэтому представляется целесообразным вычислить по графу количественные метрики. Тогда задача классификации проектной модели сводится к задаче классификации вектора количественных характеристик.
На сегодняшний день разработано достаточно много наборов метрик для программных проектов, и по многим из них уже собрана достаточная
историческая и аналитическая информация для различных типов проектов. Примерами широко используемых наборов метрик являются QMOOD (Quality Model for Object-Oriented Design), MOOSE (Metrics for Object-Oriented Software Engineering), MOOD (Metrics for Object-Oriented Design) и MOOD 2 [4].
На основе предлагаемой метамодели ООПП можно достаточно быстро и эффективно осуществлять расчет метрических показателей. Для этого достаточно применить аппарат реляционной теории баз данных. Структура метамодели может быть интерпретирована как схема реляционной базы данных, в которой дополнительно учитываются связи типа общее-частное (наследование). Последнее реализуется одним из трех типовых решений объектно-реляционного отображения [5].
Задача определения качественных характеристик ООП имеет следующие особенности:
1. Объект классификации представлен вектором четких величин - значений метрик проектной модели программного обеспечения.
2. Результат решения задачи - лингвистическая величина - значение характеристики.
3. Не определены однозначные зависимости между значениями метрик проектной модели и ее характеристиками.
Слой 1 Слой 2
4. Существует ограниченное количество доступных в открытом виде данных о метриках проектов и оценках их успешности.
Для решения поставленной задачи предлагается применить подход, основанный на концепции нечетких нейронных продукционных сетей. В качестве основной выбрана структура сети, предложенная Вангом и Менделем (L.-X. Wang J.M. Mendel) [6].
Нечеткая продукционная сеть Ванга-Мен-деля реачизует нечеткую продукционную модель, основанную на правилах с MISO - струюурой:
Белил, есть А , И... Их есть Я И... Их есть
III J и т
А. ТО у есть В, i = 1.....п
im - г
Кроме того, выполняемый данной нечеткой нейронной продукционной сетью алгоритм нечеткого вывода базируется на следующих положениях:
1. Входные переменные являются четкими.
2. Функции принадлежности всех нечетких множеств представляются функцией Гаусса [6].
3. Нечеткая импликация - нечеткое произведение.
4. Т-норма - нечеткое произведение.
5. Аккумулирование активизированных заключений правил не проводится.
6. Метод дефаззификации - средний центр.
Структура применяемой нечеткой нейронной сети представлена четырьмя слоями (рис. 2).
Слой 3 Слой 4
Рис.2. Структура нейронной сети
Слой 1 выполняет фаззификацию входных переменных V (/ = 1,...п). Элементы этого слоя вычисляют значения функций принадлежности р (х'), заданных гауссовыми функциями принадлежности с параметрами а.. и Ь . В слое 2, количество элементов которого равно количеству правил в базе, осуществляется агрегирование степеней истинности предпосылок соответствующих правил. В слое 3 первый нейрон служит для активизации заключений правил с в соот ветствии со значениями агрегированных на предыдущем слое степеней истинности предпосылок правил. Второй нейрон слоя выполняет вспомогательные вычисления для последующей дефаззификацин результата. Слой 4, состоящий из одного элемента, выполняет дефаззификацию выходной переменной.
Параметрическими слоями сети являются первый и третий слои, а настраиваемыми параметрами служат соответственно параметры термов посылок и заключений а ., Лис.
и О I
Таким образом, нечеткую нейронную модель и механизм нечеткого вывода для данной нечеткой нейронной продукционной сети можно представить следующим образом:
Ив (У) - Бир'м^ (*)Тцд^д (.у)} =
хеЛ'
= 5ир!р4и)рл_>в(у)} =
леХ
= Бир^ОО • Ц.^и) ■ Ре, О')} =
хеХ
т
= вир)Ре (у)П Ц) • (*,))}.
.геЛ" '
В данном случае входные переменные хгх„...хш являются четкими, поэтому выражение принимает следующий вид:
т
Цд ОО = Мв ЫПм, (*/ )•
Так как аккумулирования активизированных заключений правил не производится, а методом дефаззификацин является метод среднего центра, то дефаззифицированное значение выходной переменной определяется по формуле:
у =
i
1=1
агцшахрд (у)Ря(у)
i Нв;(У)
/=1
г \
п т
£ а^ тахрй (у)р5 (у)П ц^ (х))
,=1^ .V ' у»| "
I нй,(у)Пи, (*})
1-11 М "
С учетом того, что максимальное значение, которое //д .(у) может принять в точке аг% тах ¡л1и (у). равно единице, выражение приводится к следующему виду:
п т
£ а^ тахрд (у)1~~[ Ру )
<=|1 у ' у=1 '"
У =
1=1/=|
В нашем случае функции принадлежности всех нечетких множеств представляются функцией Гаусса, поэтому выражение примет вид:
¿=1
а^ шах
м1
о \ 1 /
п*
7=1
V =
i
/=|
/» т
еп*
1=1 /=1 / ,. »1 1. с.Пе К
7=>
V
1п'
1 = 1 7 = 1
Здесь с, с/ - соответственно центры и ширина гауссовых функций, представляющих функции принадлежности нечетких множеств В заключений правил; а, Ьи - соответственно центры и ширина гауссовых функций, представляющих функции принадлежности нечетких множеств А^ предпосылок правил.
Обучение нейронной сети осуществляется методом обратного распространения ошибки [6], путем корректировки параметров первого и третьего слоев.
Предложенный подход позволит осуществить непрерывную оценку качественных характеристик программного продукта на всех этапах разработки, что в свою очередь упрощает и позволяет повысить эффективность принимаемых при разработке программного обеспечения решений.
СПИСОК ЛИТЕРАТУРЫ
1. Шафер Д. Ф., Фатрелл Р. Т., Шафер Л. И.
Управление программными проектами: достижение максимума качества при минимуме затрат. М: Вильяме, 2003.
2. Макконел С. Сколько стоит программный проект. М: Русская редакция. СПб: Питер. 2007.
3. Ларман К. Применение UML 2.0 и шаблонов проектирования. 3-е издание.: Перс, с англ. М: ООО «И.Д.Вильямс», 2007.
4. Определение метрик объектно-ориентирован-ного программного обеспечения http://ndepend.com/ Metrics.aspx
5. Амблер С. Гибкие технологии: эксгремальное программирование и унифицированный процесс разработки. СПб: Питер, 2005.
6. Борисов В. В., Круглое В. В.. Федулов А. С.
Нечеткие модели и сети. М.: Горячая линия - Телеком. 2007.
Ненашев А. В.
Разработка метода параметрических характеристик
для моделирования нелинейных радиотехнических устройств
Огромную роль сегодня играют радиотехнические системы, предназначенные для радиосвязи, радиолокации, радио- и телевизионного вещания и других целей. Несмотря на широкое внедрение цифровых методов передачи и обработки сигналов, основой всех этих систем остаются аналоговые устройства и узлы, которые строятся на электронных компонентах, обладающих нелинейностью. Во многих устройствах, например усилительных, нелинейность является нежелательным качеством, и ее стремятся сделать как можно меньше. Ряд других узлов радиотехнических систем, таких как модуляторы, детекторы, преобразователи и умножители частоты, принципиально являются нелинейными. Для правильного конструирования тех и других устройств необходимы адекватные методы анализа и моделирования, позволяющие учитывать нелинейность характеристик с возможно большей точностью.
Из известных способов исследования нелинейных устройств лишь немногие находят применение при проектировании радиоэлектронной техники. Из аналитических известен метод функциональных рядов Вольтерра (РВ) [1]. Недостатком его является то, что сложность вычисления ядер ряда быстро увеличивается с ростом их порядка. Реально метод применим, когда нелинейная зависимость описывается полиномом 3-го, максимум 5-го порядков. Это соответствует небольшой нелинейности, что имеет место при малых входных воздействиях. Если использовать метод РВ при значительной нелинейности, схо-
димость функционального ряда ухудшается до полного расхождения.
В связи с трудностью применения аналитических методов распространение находят методы численного анализа и моделирования с помощью пакетов компьютерных программ. Одними из первых были известны версии программы PSpice и сходные с ними, которые ведут исследование нелинейных устройств во временной области путем численного решения дифференциальных уравнений. Недостаток такого подхода - сложность получения результата в установившемся режиме, который чаше всего представляет интерес на практике. К недостаткам также относят трудность применения метода для анализа и моделирования устройстве распределёнными параметрами. По этим и другим причинам все большее распространение находит пакет Microwave Office [2], ориентированный на проектирование устройств диапазона СВЧ. В нем используются два алгоритма нелинейного моделирования: метод РВ. применяемый для устройств с малой нелинейностью, и метод гармонического баланса (ГБ), который эффективен в условиях сильной нелинейности и дает результат для установившегося режима. Известны недостатки метода ГБ: отклик нелинейного устройства представляется в виде суммы ограниченного числа гармоник; входное воздействие должно состоять из небольшого числа гармонических функций; для многих реальных устройств алгоритм расходится. К этому следует добавить, что на каждом шаге решения произво-
