Методы поиска и верификации проектных решений

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

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

· Технология вывода по прецидентам. Вывод по прецидентам основан на широком применении автоматизированнного поиска по БЗ.

CBR-цикл

Цикл поиска по прецидентам включает этапы:

1)Формулировка задачи и определение характеризующих ее параметров

2)Поиск аналогов в БЗ

3)Адаптация аналога и получение на основе его нового решения

4)Сохранение нового решения в БЗ

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

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

Преимущество:автоматизация процессов накопления и поиска знаний.

Недостаток: сложность построение параметрического описания проектных решений.

Лекция 6

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

Формально-математические методы

1)Методы формального синтеза ПО.

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

Недостатки:

· Недостаточное развитие теоретической базы.

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

· Недостаточное качество автоматически сгенерированного кода.

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

Методы формальной верификации.

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

Математическое моделирование.

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

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

Лекция 7

Анализ кода

Инспекция кода -это проверка исходного кода программного компонента путем прочтения его разработчиками не учавствовавшими в его написании.

Задачи:

1)Улучшение качества оформления кода и проверка соблюдения требований по форматировпнию и наличию комментариев(проверка форматирования частично автоматизированная).

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

3)Поиск “дыр”безопасности

4)Проверка качества модульных тестов

5)Обучение молодых разработчиков

Способы организации анализа кода:

1)Анализ кода специально выделенной группой опытных рецинзентов.

2)Анализ всего кода наиболее опытным разработчиком(применяется только в небольших проектах)

3)Взаимный анализ кода(в анализе учавствуют все разработчики просматривая чужой код).Сложно проконтролировать качество анализа.

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

Периодичность анализа:

-предварительный анализ или анализ нового кода;

-анализ внесенных изменений;

-выборочный анализ

Основной проблемой при анализе кода является человеческий фактор.Анализ кода способен как улучшить социально-психологический климат в коллективе,так и стать причиной конфликта.

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

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

 

Лекция 8

Лекция 9

Многоуровневая архитектура

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

Основное преимущество:гибкость архитектуры(изменения локализуются в пределах одного двух слоев;относительное удобство сопровождения и модернизации.

Основной недостаток:снижение производительности из-за необходимости трансляции вызовов между всеми слоями.