3 подхода к созданию безошибочного кода


Содержание

Защита программного обеспечения системы управления магнитолевитационным транспортом Текст научной статьи по специальности « Автоматика. Вычислительная техника»

Аннотация научной статьи по автоматике и вычислительной технике, автор научной работы — Корниенко Анатолий Адамович, Глухов Александр Петрович, Диасамидзе Светлана Владимировна, Шатов Александр Михайлович

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

Похожие темы научных работ по автоматике и вычислительной технике , автор научной работы — Корниенко Анатолий Адамович, Глухов Александр Петрович, Диасамидзе Светлана Владимировна, Шатов Александр Михайлович,

Software protection of the maglev transport control system

Background: The article examines the issues of regulation and the development of methodological approaches to ensuring the security of the software system for the management of magnetic-leaving transport at all stages of the life cycle, as well as the development of a tool to detect high-level (logical) software vulnerabilities. Aim: Development of a methodology for the creation of an error-free and impact-resistant software for the management system of magnetic-levitational transport. Methods: In the development of the methodology, the existing practices of searching for errors and vulnerabilities in software and approaches to the algorithmization of program code were studied. Results: During the study, a methodology was developed for creating an error-free and impact-resistant software for the management system of magnetic-levitational transport, which makes it possible to exclude the possibility of errors in the software, which significantly increases the safety of the overall transportation process. Conclusion: The application of the developed technique will improve the security of software for magnetic levitation transport control system from destructive external influences

Текст научной работы на тему «Защита программного обеспечения системы управления магнитолевитационным транспортом»

УДК [ЦОС] 004.056.5

© А. А. Корниенко, А. П. Глухов, С. В. Диасамидзе, А. М. Шатов

Петербургский государственный университет путей сообщения Императора Александра I (Санкт-Петербург, Россия)

ЗАЩИТА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ УПРАВЛЕНИЯ МАГНИТОЛЕВИТАЦИОННЫМ ТРАНСПОРТОМ

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

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

Материалы и методы. Изучены существующие практики поиска ошибок и уязвимостей в ПО и подходы к алгоритмизации программного кода.

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

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

Ключевые слова: магнитолевитационный транспорт, безошибочное программное обеспечение, информационная безопасность, алгоритмизация

© A. A. Kornienko, A. P. Glukhov, S. V. Diasamidze, A. M. Shatov

Emperor Alexander I St. Petersburg State Transport University (St. Petersburg, Russia)

SOFTWARE PROTECTION OF THE MAGLEV TRANSPORT

Background: The article examines the issues of regulation and the development of methodological approaches to ensuring the security of the software system for the management of magnetic-leaving transport at all stages of the life cycle, as well as the development of a tool to detect high-level (logical) software vulnerabilities.

This article is available under license

Aim: Development of a methodology for the creation of an error-free and impact-resistant software for the management system of magnetic-levitational transport.

Methods: In the development of the methodology, the existing practices of searching for errors and vulnerabilities in software and approaches to the algorithmization of program code were studied.

Results: During the study, a methodology was developed for creating an error-free and impact-resistant software for the management system of magnetic-levitational transport, which makes it possible to exclude the possibility of errors in the software, which significantly increases the safety of the overall transportation process.

Conclusion: The application of the developed technique will improve the security of software for magnetic levitation transport control system from destructive external influences.

Key-words: magnetic levitation transport, error-free software, information security, algorithmization

Сегодня магнитолевитационный транспорт — один из наиболее перспективных и экологически безопасных видов транспорта. К его достоинствам относят малое потребление электроэнергии, низкие эксплуатационные затраты вследствие снижения трения между деталями подвижного состава и рельсового пути. Кроме того, использование технологии магнитной левитации позволяет подвижному составу достигать скорости 500-600 км/ч, что сравнимо со скоростью самолета.

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

Активные разработки в данном направлении ведутся Германией, Японией, Китаем, Южной Кореей. Наибольшего прогресса достиг Китай: только по маглев-трассе от международного аэропорта «Пудон» до станции шанхайского метро «Лунъян Лу» осуществляется коммерческая эксплуатация высокоскоростного подвижного состава на магнитном подвесе. На этой трассе состав развивает максимальную скорость 430 км/ч.

В России разрабатывается магнитолевитационная транспортная система, опытная эксплуатация которой будет проводиться на участке Порт «Бронка» (Санкт-Петербург) — станция «Владимирская» (Гатчина, Ленинградская область). Для организации этой системы, направленной на грузовые перевозки, используется ряд подсистем, одной из ключевых выступает подсистема управления. Ее основу составлят автоматизированная система управления (АСУ) движением магнитолевитационного транспорта.

Безопасность АСУ представляет собой одно из основных условий их функционирования. При воздействии на них может произойти не только

This article is available under license

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

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

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

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

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

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

Множество уязвимостей ПО можно условно разделить согласно их местоположению в коде следующим образом:

— низкоуровневые уязвимости (ошибки доступа к данным, ошибки в вычислениях и т. д.);

— среднеуровневые уязвимости (ошибки в логике работы ПО);

— высокоуровневые уязвимости (ошибки в архитектуре ПО).

Способы поиска уязвимостей в ПО нельзя считать удовлетворительными,

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

АВТОМАТИЗИРОВАННАЯ СИСТЕМА УПРАВЛЕНИЯ КАК ОБЪЕКТ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

This article is available under license

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

СОЗДАНИЕ БЕЗОШИБОЧНОГО И УСТОЙЧИВОГО К ВОЗДЕЙСТВИЯМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ СИСТЕМЫ УПРАВЛЕНИЯ ДВИЖЕНИЕМ МАГНИТОЛЕВИТАЦИОННЫМ ТРАНСПОРТОМ

Предлагаемая методология, направленная на поиск ошибок и уязвимостей в ПО АСУ движением магнитолевитационного транспорта, включает три основных этапа:

— создание встроенных механизмов контроля в микропроцессорных устройствах как элементов системы функционального контроля и диагно стирования;

верификация и тестирование;

подтверждение соответствия ПО, которое может быть использовано на всех этапах его жизненного цикла.

Согласно этим направлениям была составлена модель исследуемой предметной области (Рис. 1), содержащая области жизни уязвимостей в различных представлениях программного обеспечения.

Рис. 1. Модель предметной области

На основе данной модели был разработан алгоритм создания безошибочного и устойчивого к воздействиям ПО для АСУ движением магнитолевитационного транспорта (Рис. 2).

This article is available under license I

Рис. 2. Алгоритм создания безошибочного и устойчивого к воздействиям ПО


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

На следующем этапе проводится поиск низкоуровневых уязвимостей в полученном коде с помощью существующих методов. Для обеспечения большего процента покрытия возможно совместное использование нескольких методов. Далее выполняется алгоритмизация кода с использованием языка ДРАКОН — визуального алгоритмического языка программирования и моделирования, обеспечивающего большую наглядность [3, 7]. Правила по созданию диаграмм в языке ДРАКОН создавались с упором на требования эргономики (например, в них запрещено пересечение линий алгоритма, которое обычно осложняет его понимание пользователем), т. е. они изначально оптимизированы под восприятие алгоритмов человеком в основном при использовании компьютерной графики.

Схемы, разработанные при помощи указанного языка, просты и понятны даже человеку, далекому от программирования, что позволяет расширить круг специалистов, использующих разрабатываемую методологию. ДРАКОН делает упор на визуальную составляющую, что значительно повышает читаемость программы. Обычно блок-схемы позволяют графически отобразить логику программы, но при достаточно большом объеме программного кода они становятся громоздкими и теряют наглядность.

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

This article is available under license I

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

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

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

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

1. Корниенко А.А., Диасамидзе С.В. Подтверждение соответствия и сертификация программного обеспечения по требованиям безопасности информации: учеб. пособие. — СПб.: ПГУПС, 2009. [Kornienko AA, Diasamidze SV. Confirmation of compliance and certification of software for information security requirements: schoolbook. St. Petersburg; 2009. (In Russ.)].

2. Диасамидзе С.В. Метод выявления недекларированных возможностей программ с использованием структурированных метрик сложности: дис. канд. техн. наук. -СПб; 2012. [Diasamidze SV. Metod vyavleniya nedeklarirovannikh vozmozhnostey program s ispolzovaniem structurirovannikh metrik slozhnosti [dissertation]. St. Petersburg; 2012. (In Russ.)].

3. Израилов К.Е. Метод алгоритмизации машинного кода для поиска уязвимостей в телекоммуникационных устройствах: дис. канд. техн. наук. — СПб; 2020. [Izrailov KE. Method algoritmizatcii mashinnogo koda dlya poiska uyazvimostey v telekommunikatcionnykh ustroistvakh [dissertation]. St. Petersburg; 2020. (In Russ.)].

Библиографический список / References

This article is available under license

4. Академия Miсrosoft. Лекция 8: Методы проверки и тестирования программ и систем. Доступно по: https://www.intuit.ru/studies/courses/2190/237/lecture/6130. Ссылка активна на 10.03.2020. [Akademiya Мсгс^ой. Lekciya 8: Metody proverki i testirovaniya programm i sistem. Available from: https://www.intuit.ru/studies/courses/2190/237/ lecture/6130]. (In Russ.) Accessed 10 March 2020].

5. Академия Мюгс^й. Лекция 12: Проверка требований. Доступно по: https://www.intuit. ru/studies/courses/2190/237/lecture/6138. Ссылка активна на 15.03.2020. [Akademiya Misrosoft. Lekciya 12: Proverka trebovanij. Available from: https://www.intuit.ru/studies/ courses/2190/237/lecture/6138. (In Russ.) Accessed 15 March 2020.].

6. Кулямин В.В. Методы верификации программного обеспечения. — М.: Институт системного программирования им. В.П. Иванникова РАН, 2008. [Kuliamin VV. Metody verifikacii programmnogo obespecheniya. Moscow: Ivannikov Institute for System Programming of the RAS; 2008 (In Russ.)].

7. ДРАКОН. Доступно по: https://ru.wikipedia.org/ДРАКОН. Ссылка активна на 17.03.2020. [DRAKON. Available from: https://ru.wikipedia.org/DRAKON. (In Russ.) Accessed 17 March 2020].

Сведения об авторах:

Анатолий Адамович Корниенко, д-р техн. наук, профессор; eLibrary SPIN: 8943-3184; ORCID: 0000-0002-6076-7241; E-mail: kaa.pgups@yandex.ru

Александр Петрович Глухов, д-р техн. наук; eLibrary SPIN: 6034-3986; ORCID: 0000-0001-5368-4109; E-mail: inib@pgups.ru

Светлана Владимировна Диасамидзе, канд. техн. наук, доцент; eLibrary SPIN: 1207-0600; ORCID: 0000-0003-2683-0697; E-mail: sv.diass99@yandex.ru

Александр Михайлович Шатов;

Information about the authors: Anatoly A. Kornienko, Dr., prof.;

eLibrary SPIN: 8943-3184; ORCID: 0000-0002-6076-7241; E-mail: kaa.pgups@yandex.ru

Alexander P. Glukhov, Dr.;

eLibrary SPIN: 6034-3986; ORCID: 0000-0001-5368-4109; E-mail: inib@pgups.ru

Svetlana V. Diasamidze, PhD, docent;

eLibrary SPIN: 1207-0600; ORCID: 0000-0003-2683-0697;

This article is available under license

Alexander М. Shatov;

Корниенко А.А., Глухов А.П., Диасамидзе С.В., Шатов А.М. Защита программного обеспечения системы управления магнитолевитационным транспортом // Транспортные системы и технологии. — 2020. — Т. 4. — № 4. — С. 138-145. doi: 10.17816/10.17816/ transsyst202044138-145

To cite this article:

Kornienko АА, Glukhov AP, Diasamidze SV, Shatov AM. Software Protection of the Maglev Transport Control System. Transportation Systems and Technology. 2020;4(4):138-145. doi: 10.17816/transsyst202044138-145

Три подхода к информационной безопасности

Читайте также:

  1. V. Требования безопасности по окончании работы
  2. Активные методы обучения основам безопасности жизнедеятельности
  3. Алгоритм затратного подхода
  4. Алгоритм сравнительного подхода
  5. Анализ рисков информационной безопасности.
  6. Анализ системы обеспечения информационной безопасности и защиты информации.
  7. Анализ стандартов информационной безопасности.
  8. Анализ факторов изменения безубыточного объема продаж и зоны безопасности предприятия
  9. Анатомо-физиологические механизмы обеспечения безопасности и защиты человека от негативных воздействий
  10. Безопасности
  11. Безопасности государства
  12. Безопасности жизнедеятельности учащихся в повседневной жизни

Угрозы безопасности компьютерных систем

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

Угрозы конфиденциальности направлены на разглашение секретной информации, т. е. информация становится известной лицу, которое не должно иметь к ней доступ. Иногда для обозначения этого явления используется понятие “несанкционированный доступ” (НСД), особенно популярное у отечественных специалистов. Традиционно противостоянию угрозам этого типа уделялось максимальное внимание и, фактически, подавляющее большинство исследований и разработок в области компьютерной безопасности было сосредоточено именно в этой области, т. к. она непосредственно относится к задаче охраны государственных и военных секретов.

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

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

Цель защиты систем обработки информации — противодействие угрозам безопасности. Следовательно, безопасная или защищенная система — это система, обладающая средствами защиты которые успешно и эффективно противостоят угрозам безопасности.

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

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

Существует три подхода к информационной безопасности:

Нормативный подход появился в 80-е годы XX века. Название подхода происходит от слова «норма», означающего некий эталон. Существуют различные стандарты информационной безопасности, документы в которых определены признаки, свойства и требования к безопасным информационным системам, также определена шкала, с помощью которой все системы можно оценить на предмет безопасности.

Теоретический подход основан на построении модели безопасности – некоего абстрактного представления реальной системы с точки зрения безопасности. Полученные модели должны быть теоретически и математически обоснованы. Чем сильнее математическая и теоретическая база построенной модели, тем безопаснее система.

3) Практический (экспериментальный)

Зарождение практического подхода определения безопасности можно связывать с началом эпохи Интернета. Безопасность системы при этом проверяется на практике: одна система более безопасна, чем другая, если она более устойчива к внешним воздействиям и лучше противостоит угрозам.

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

Цель данного курса — выяснить, что скрывается за понятием «информационная безопасность», т.к. без конструктивного определения этого понятия невозможно рассматривать основные принципы функционирования защищенных систем и технологии их создания.

Контрольные вопросы

1. Какие существуют подходы к определению информационной безопасности?

2. Какова главная задача стандартов информационной безопасности?

3. Что такое угроза информационной безопасности?

4. Какие выделяют виды угроз информационной безопасности?

5. Какова цель защиты систем обработки информации?


Лекция 2.

НОРМАТИВНЫЙ ПОДХОД. КЛАССИЧЕСКИЕ СТАНДАРТЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Безопасность является качественной характеристикой системы, ее нельзя измерить в каких-либо единицах, более того, нельзя даже с однозначным результатом сравнивать безопасность двух систем — одна будет обладать лучшей защитой в одном случае, другая — в другом. Кроме того, у каждой группы специалистов, занимающихся проблемами безопасности информационных технологий, имеется свой взгляд на безопасность и средства ее достижения, а, следовательно, и свое представление о том, что должна представлять собой защищенная система. Разумеется, любая точка зрения имеет право на существование и развитие, но для того, чтобы объединить усилия всех специалистов в направлении конструктивной работы над созданием защищенных систем необходимо определить, что является целью исследований, что мы хотим получить в результате и чего в состоянии достичь.

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

В соответствии с этими документами ответ на поставленный вопрос в общем виде звучит так: защищенная система обработки информации — это система отвечающая тому или иному стандарту информационной безопасности. Конечно, это условная характеристика, она зависит от критериев, по которым оценивается безопасность, но у нее есть одно неоспоримое преимущество — объективность. Именно это позволяет осуществлять сопоставление степени защищенности различных систем относительно установленного стандарта.

Итак, рассмотрим, что представляет собой защищенная система с точки зрения существующих стандартов безопасности.

Дата добавления: 2014-11-20 ; Просмотров: 1434 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Алгоритмы прямой коррекции ошибок и особенности их применения. Турбо-код

Сегодня требования, предъявляемые к качеству передачи данных, ведут к необходимости увеличения пропускной способности каналов, устойчивости системы к ошибкам и уменьшению времени отклика. Соответственно, разработчики телекоммуникационных систем ищут новые способы расширения доступной полосы пропускания и повышения качества передачи. Один из них — применение технологии прямой коррекции ошибок (FEC). Различные варианты архитектуры этой технологии используются уже в течение многих лет, чтобы обеспечить эффективную, высококачественную передачу данных по зашумленным каналам, таким как спутниковые и сети сотовой связи.

На данный момент развитие технологий прямой коррекции ошибок позволило современным телекоммуникационным системам достичь значительных результатов в приближении к верхней границе максимального количества передаваемых безошибочных цифровых данных (пределу Шеннона). Теоретически это понятие представляет собой максимальный уровень информационного контента для любого канала передачи. Нужно отметить, что использование технологии прямой коррекции ошибок не ведет к увеличению пропускной способности канала, наоборот, она даже несколько уменьшается из-за избыточных данных, так как ключевой особенностью технологии FEC является добавление дополнительных данных к передаваемому потоку, что позволяет принимающему устройству выявлять и исправлять ошибки, возникающие при передаче. Выигрыш в объеме информации, посылаемой по некоему каналу с помощью прямой коррекции ошибок (в отличие от каналов без нее), достигается исключительно благодаря тому, что данные гарантированно доходят до получателя. Другими словами, не нужны многократное дублирование, повторная отправка запроса на передачу и т. п., что с лихвой компенсирует их избыточность.

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

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

Как уже говорилось, технология FEC предполагает, что информация будет закодирована. Исходные данные пользователя, которые должны передаваться по каналу, называются битами информации, а данные, полученные после добавления информации коррекции ошибок, — кодированными битами.

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

Цукерберг рекомендует:  Intellij idea - Сохранение в Intellij Idea

Для генерации оценки n‑битов, в качестве промежуточного шага процесса коррекции ошибок, декодирования не требуется. В качественно спроектированном декодере квантованные данные канала измерения берутся с входа декодера. Эти исходные данные измерений канала состоят из n‑метрик, где каждая метрика соответствует вероятности того, что конкретный бит является логической единицей. Вероятность того, что заданный бит представляет собой логический ноль, также связана с данным числом. Эти показатели обычно представлены в виде 3‑ или 4‑разрядных целых чисел и называются метриками максимального правдоподобия. Выход декодера — это вычислитель k‑информационных битов. Как правило, декодирование метрик максимального правдоподобия является вычислительно интенсивным и очень часто выполняется на ASIC-декодерах, специально разработанных для выполнения указанной задачи.

Эффективность кода очень зависит от зашумленности канала передачи данных. Чтобы облегчить сравнение одного кода с другим, используется модель, когда шум добавляется к антиподальным сигналам. В этой модели шум является аддитивным белым гауссовым шумом (АБГШ). Несвязанные выборки шума добавлены к антиподальными символам канала (рис. 1). Дисперсия шума связана с мощностью спектральной плотности шума (No). Антиподальная сигнализация, показывает, где будут передаваться единицы и нули, посылаемые как +Z и –Z. В канале передачи Z может быть представлена в виде 1V. Так, единицы и нули будут передаваться как +1V и –1V соответственно. Полученная энергия на передаваемый бит данных (Еb) пропорциональна Z2. Важным параметром в системе представляется отношение уровня сигнала к шуму — отношение Eb/No. Модель (АБГШ) точно демонстрирует множество типов реальных каналов. Различные виды ошибок, многократно проявляющиеся в канале, также имеют АБГШ-подобный вид.

Рис. 1 — Добавление шума к исходному сигналу

FEC-коды бывают двух основных типов: сверточные и блочные. Рассмотреть их работу можно на примере абстрактных устройств, не вдаваясь в их схемотехнику. В простом сверточном кодере последовательность информационных битов проходит через регистр сдвига, и для каждого бита информации генерируются два выходных бита. Затем два выходных бита передаются. По существу, декодер оценивает состояние кодера для каждого набора из двух получаемых символов канала. Если декодер точно знает последовательность состояний кодера, он также знает исходную последовательность информации. Пример сверточного кода — разработанный В 1967 году Эндрю Витерби алгоритм декодирования, основанный на принципе максимального правдоподобия, позднее названный его именем.

Блочный код немного проще. Кодовый блок будет принимать K информационных битов и генерировать один или несколько битов четности. Эти биты четности добавляются к информационным битам, в результате чего образуется группа из N битов, где N > K. Закодированный модуль из N битов называется кодовым словом, и это кодовое слово передается целиком. На рис. 2 показан принцип работы (n, k) = (8, 4) кодового блока кодера. Приемник получает метрики канала n, а декодер оценивает наиболее вероятную последовательность (которых существуют 2000) согласно собранным данным. В блоках декодера, как правило, используется сложная алгебраическая структура, которая может быть применима для облегчения расшифровки. Пожалуй, наиболее популярным из ныне существующих блочных кодов является совместный код Рида — Соломона. Зачастую используют укороченный вариант, где n = 2040 кодов (255 байт). До недавнего времени самые мощные коды были построены из конкатенации сверточного кода и кода Рида — Соломона.

Рис. 2 — Принцип работы кодового блока кодера

Турбокод

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

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

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

Принцип работы турбокода, где с выхода одного декодера подается входной сигнал на следующий декодер, в чем-то напоминает работу турбокомпрессора в двигателях внутреннего сгорания. Турбокомпрессор использует выхлопные газы двигателя (выход) для питания вентилятора турбины (вход), усиливая тем самым подачу воздуха. Таким образом объясняется наличие термина «турбо» в названии технологии турбокода. Турбокоды — это циклично декодируемые коды.

Технология турбокода наилучшим образом иллюстрируется на примере, где в качестве составных кодов используются блочные коды. Рассмотрим расширенный кода Хемминга (8,4), изображенный на схеме на рис. 3. Этот код использует четыре информационных бита, вычисляет 4 бит четности добавляет их к информационным битам для создания 8‑битного кодового слова для передачи: I1.1 I1.2 I1.3 I1.4 PH1.1 PH1.2 PH1.3 PH1.4 и т. д.

Рис. 3 — Схема расширенного кода Хемминга

Здесь I соответствует информационному биту и P соответствует битам четности или избыточности. Двумерный код продукта построенный из такого (8,4) расширенного кода Хэмминга может выглядеть следующим образом:

где I — информационный бит (числовой индекс показывает номер столбца и номер строки); PH — бит четности для каждого кодового слова, построенного по горизонтали (числовой индекс показывает номер строки и количество бит в слове); PV — бит четности для каждого кодового слова, построенного вертикально (числовой индекс показывает номер столбца и количество бит в слове); PVH — бит четности кодированных битов четности (числовой индекс показывает номер столбца и номер строки, использованных для вычисления полностью).

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

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

Рабочие характеристики турбокода лучше всего определяются с помощью компьютерного моделирования. Производительность турбокода (TPC), построенного из (64,57) кодов, используемого в обоих, X‑ и Y‑измерениях, показана на рис. 4. Этот код называется (64,57)2 TPC, или (4096, 3249) TPC. Также включен график коэффициента ошибок (BER) передаваемых данных без кодирования на канале с АБГШ (AWGN). Различие в показателях отношения сигнал/шум (Eb/No) между кривыми эффективности коэффициента ошибок (BER-симуляция) с кодированием на канале и без такового, при заданной величине коэффициента ошибок, называется коэффициентом эффективности кодирования.

Как правило, показатель, используемый для оценки качества обслуживания (QoS) канала связи, — это коэффициент ошибок (BER). Хотя этот показатель не всегда применим. Например, в сетях, где передаются пакеты данных, любое количество ошибочных битов в пакете составляют ошибку пакета. Когда это происходит, пакет данных отбрасывается и запрашивается повторная передача. В таком случае более подходящим показателем QoS-метрики является коэффициент пакетных ошибок. Когда при использовании прямой коррекции ошибок происходит одно событие ошибки, зачастую ошибочны несколько битов. Таким образом, эффективность коэффициента пакетных ошибок близка к эффективности коэффициента ошибок BER.

Если кодирование не применяется, пакетные ошибки возникают из случайных несвязанных входных битовых ошибок. Типичное событие пакетной ошибки имеет только один ошибочный бит во всем пакете. Как следствие, коэффициент пакетной ошибки значительно больше, чем коэффициент BER. Увидеть это можно на кривой коэффициента ошибок блоков кода (CER), показанной на рис. 4, на канале с некодированным сигналом. В данном примере размер пакета мы устанавливаем равным размеру кодового блока из 3249 бит.

Рис. 4 — Производительность турбокода (ТРС)

Результаты моделирования (64,57)2TPC показывают исключительную производительность в пределах 1,2 дБ от теоретического предела Шеннона. Использование противоположной модуляции, BER = 10–6, и скорость кода = k/n = 0,8. Большие размеры блоков могут значительнее сократить этот разрыв.

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

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

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

Рассмотрим пример, где основным требованием является увеличение пропускной способности в системе с ограниченной мощностью. Предположим, что желаемое качество обслуживания сети (QoS-quality of service) достигается при коэффициенте ошибок BER = 10 –6 . Без кодирования приемнику требуется отношение сигнала к шуму, соответствующее Eb/No 10,5 дБ. Если используется турбокод (64,57) 2 ТРС, то QoS может поддерживаться при Eb/No 3,2 дБ. Таким образом, тот же энергетический сигнал может распространить в 5,3 раза больше битов информации. Кроме того, FEC обеспечит необходимые качество обслуживания сети (QoS). Однако для передачи в 5,3 раза больше данных понадобится в 5,3x(4096/3249), или в 6,68 раз, больше трафика. Если ширины полосы пропускания достаточно, пропускная способность может быть увеличена на коэффициент 5,3 без повышения мощности передатчика.

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

Для достижения показателя ошибки блока кода CER = 10–5 требуемое значение отношения Eb/No = 12,25 дБ для системы c незакодированным сигналом, в то время как система, использующая метод турбокода (64,57) 2 TPC, достигает аналогичного показателя ошибки CER при Eb/No = 3,4 дБ, что соответствует уменьшению нужной мощности в 8 раз. Это означает, что можно использовать маломощные усилители и меньшие антенны, в следствии чего стоимость такой системы существенно снизится.

Рассмотрим сценарий, в котором основным требованием является увеличение срока службы аккумулятора портативной беспроводной системы и, следовательно, уменьшение мощности передачи. Предположим, что желаемое качество обслуживания сети (QoS) достигается при показателе ошибок BER = 10 –6 . Использование турбокода (64,57) 2 TPC обеспечивает QoS на 3,2 дБ. Мощность передачи может быть урезана на коэффициент, равный 5,3. Для поддержания скорости передачи данных необходимо расширение полосы пропускания на 26% или (4096/3249). Если расширение невозможно, мощность передачи следует урезать на коэффициент, равный 6,8. Однако это приведет к снижению скорости передачи данных на 21% или (1–3249/4096). Если срок службы батареи не имеет значения, данные передаются на полной мощности. В этом случае коррекция ошибок FEC используется для передачи данных в большем диапазоне. Если снижение скорости передачи данных на 21% приемлемо, диапазон может быть расширенна 160%. Без мощной технологии коррекции ошибок FEC нужно будет применить либо усилитель высокой мощности, либо антенны большего размера. К сожалению, во многих системах такой подход невозможен, к тому же это увеличит стоимость самой системы.

Прямая коррекция ошибок успешно применяется и в оптоволоконных сетях. Вдоль всей протяженности трассы дальнемагистрального волокна предусмотрено некоторое количество оптических усилителей. Но это повышает стоимость, а также потребление электроэнергии системы. Интеграция FEC в подобную систему, в начале и в конце линии, может увеличить расстояние между этими узлами, что сведет к минимуму количество необходимых усилителей. Использование FEC либо увеличит ширину полосы пропускания, либо уменьшит пропускную способность. Высокоскоростные коды (k/n = скорость >0,75) сводят к минимуму этот эффект, не затрагивая высокую эффективность кодирования.

До сегодняшнего дня для решения данной задачи использовали либо некодированный сигнал, либо код Рида — Соломона, который был практически единственным доступным кодом, способным поддерживать необходи мые скорости для волокна (>1 Гбит/с). С появлением декодирующих TPC-микросхем предшествующий уровень развития технологии Рида — Соломона может быть улучшен почти на 4 дБ, что подразумевает значительное сокращение числа необходимых усилителей.

Если ограничение ширины полосы пропускания не является проблемой, для достижения более высокой пропускной способности при одновременном сохранении постоянной мощности передачи и полосы пропускания можно применить модуляции высшего порядка в сочетании с FEC.

Рассмотрим систему с некодирован ной структурой, реализованную на QPSK модуляциях с требуемым QoS при BER = 10 –6 . Нужный показатель отношения Eb/No = 10,5 дБ. Используя QPSK, которая составляет 2 бит на канал, показатель отношения Es/No (где Es — энергия на символ канала) составит 13,5 дБ.

Использование кодовой модуляции более высокого порядка, такой как Серокодированная 16‑QAM и ограничение канала в той же средней Es/No требуют такой же ширины полосы частот и мощность передатчика. Но уменьшенные интервалы между символами приводят к значительной деградации в QoS для BER = 10 -2 . Система реализации (64,57) 2 TPC может принимать QoS значительно ниже BER 10 -15 , будучи пригодной для всех практических целей, при полном отсутствии ошибок. Каждый переданный символ теперь носит 3,172 бит в среднем, что в 1,59 раза выше, чем в некодированной схеме QPSK.

Системы с кодовым разделением множественного доступа (Code division multiple access, CDMA) также получают большую пользу от FEC. Все пользователи, работающие в системе, могут рассматриваться как шум по отношению к любому произвольно выбранному пользователю. Применение FEC может значительно увеличить количество пользователей, одновременно работающих в системе. На самом деле максимальное число одновременно работающих пользователей в системе CDMA требует присутствия самого мощного из доступных кодов.

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

Довольно старые коды Рида — Соломона — Витерби (RSV), по существу, блочные коды, могут генерировать довольно большие информационные блоки. Результатом станут значительное задержки, поскольку декодер не может генерировать выходные информационные биты, пока не будет получен весь блок. В системах RSV большие размеры блоков способны вызвать неприемлемые латентности. Турбокод может превосходить код RSV благодаря значительно более короткому размеру блока и, следовательно, уменьшать время задержки. Кроме того, чтобы достичь максимальной эффективности кодирования при низких скоростях битовых ошибок, размер блока Turbo Code обычно велик. Это приводит к увеличению задержки, хотя системы, работающие с низким уровнем битовых ошибок, как правило, являются системами с высшей скоростью передачи данных.

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

Сверточные турбокоды (Turbo Convolutional Codes, или TCCs) выявляют вероятность ошибки и, таким образом, эффективны исключительно при более низких значениях битовых ошибок. Снижение или устранение вероятности ошибки является очень активной областью исследования, поскольку эта вероятность ограничивает использование сверточных тубокодов во многих системах.

TCCs и TPC имеют немного разные свойства, что делает их подходящими для различных областей применения.

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

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

Данная статья была опубликована в журнале «Компоненты и технологии», № 11 ‘2020


Создан безошибочный код из 7500 строк

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

«По приблизительной оценке качественно разработанное программное обеспечение имеет около 10 ошибок на тысячу строк кода, а очень качественное – от 1 до 3, — поясняет Хайзер. Это означает, что в системах множество недочётов. Мы же показали возможность добиться намного меньшего, предельного уровня, причём наиболее подверженная риску часть имеет доказанную отказоустойчивость. Я думаю, не будет преувеличением сказать, что это открывает совершенно новый мир для создания систем с высокими показателями надёжности и безопасности»

Настолько стабильное программное обеспечение очень важно в медицинской, военной, навигационной и других сферах.

«Команда NICTA добилась переломного результата, который изменит подход к критическому с точки зрения безопасности ПО, — продолжает профессор. – Верификация окончательно подтвердила возможность существования кода без ошибок, и в будущем ничто менее передовое не должно признаваться приемлемым в особо важных приложениях».

Глава 3

ОСНОВНЫЕ ИНЖЕНЕРНЫЕ ПОДХОДЫ К СОЗДАНИЮ ПРОГРАММ

3.1. ОСНОВНЫЕ СВЕДЕНИЯ

Традиционно инженеры стремились, а некоторые из них, не снижая качества проектов, добивались значительного сокращения сроков проектирования. В начале Великой Отечественной войны начальник Центрального артиллерийского конструкторского бюро В.Г. Грабин разработал и применил методы скоростного комплексного проектирования артиллерийских систем с одновременным проектированием технологического процесса. Внедрение этого метода позволило сократить сроки проектирования, производства и испытаний артиллерийских орудий с 30 мес (1939) до 2–2,5 мес (1943), увеличить их выпуск, уменьшить стоимость, упростить эксплуатацию.

Инженерный технологический подход [20] определяется спецификой комбинации стадий разработки, этапов и видов работ, ориентированной на разные классы программного обеспечения и особенности коллектива разработчиков.

Основные группы инженерных технологических подходов и подходы для каждой из них следующие:

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

Строгие (классические, жесткие, предсказуемые) подходы рекомендуется применять для средних, крупномасштабных и гигантских проектов с фиксированным объемом работ. Одно из основных требований к таким проектам — предсказуемость.

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

Классификация технологических подходов к созданию программ:

Подходы со слабой формализацией

Подход «кодирование и исправление»

Каскадные технологические подходы:

— каскадный подход с перекрывающимися видами работ;

— каскадный подход с подвидами работ;

Каркасные технологические подходы:

— рациональный унифицированный подход к видам работ.

Генетические технологические подходы:

— сборочное (расширяемое) программирование;

Подходы на основе формальных преобразований:

— технология стерильного цеха;

— формальные генетические подходы.

Ранние подходы быстрой разработки:

Адаптивные технологические подходы:

Подходы исследовательского программирования:

3.2. РАННИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

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

Подход «кодирование и исправление» (code and fix) упрощенно может быть описан следующим образом. Разработчик начинает кодирование системы с самого первого дня, не занимаясь сколь-либо серьезным проектированием. Все ошибки обнаруживаются, как правило, к концу кодирования и требуют исправления через повторное кодирование.

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

Этот подход может быть рекомендован к использованию в двух случаях:

• для очень маленьких проектов, которые должны завершиться разработкой демонстрационного прототипа;

• для доказательства некоторой программной концепции.

3.3. КАСКАДНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

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

Классический каскадный подход (от англ. pure waterfall — чистый водопад) считается «дедушкой» технологических подходов к ведению жизненного цикла. Его можно рассматривать как отправную точку для огромного количества других подходов. Сформировался классический каскадный подход в период с 1970 по 1985 г. Специфика «чистого» каскадного подхода такова, что переход к следующему виду работ осуществляется только после того, как завершена работа с текущим видом работы (рис. 3.1). Возвраты к уже пройденным видам работ не предусмотрены.

Рис. 3.1. Классический каскадный подход

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

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

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

Каскадный подход с перекрывающимися видами работ (англ. waterfall with overlapping), так же как и классический каскадный подход предполагает проведение работ отдельными группами разработчиков, но эти группы не меняют специализацию от разработки к разработке, что позволяет распараллелить работы и в определенной степени сократить объем передаваемой документации (рис. 3.4).

Рис. 3.2. Каскадно-возвратный технологический подход

Рис. 3.3. Каскадно-итерационный технологический подход

Рис. 3.4. Каскадный подход с перекрывающимися видами работ

Каскадный подход с подвидами работ (англ. waterfall with subprocesses) очень близок подходу с перекрывающимися видами работ. Особенность его в том, что с точки зрения структуры, проект достаточно часто может быть разделен на подпроекты, которые могут разрабатываться индивидуально (рис. 3.5). В данном подходе требуется дополнительная фаза тестирования подсистем до объединения их в единую систему. Следует особое внимание обращать на грамотное деление проекта на подпроекты, которое должно учесть все возможные зависимости между подсистемами.

Рис. 3.5. Каскадный подход с подвидами работ

Рис. 3.6. Спиральная модель

Спиральная модель (spiral model) была предложена Барри Боэмом (Barry Boehm) в середине 80-х годов XX в. с целью сократить возможный риск разработки. Фактически, это была первая реакция на устаревание каскадной модели. Спиральная модель использует понятие прототипа — программы, реализующей частичную функциональность создаваемого программного продукта. Создание прототипов осуществляется в несколько витков спирали, каждый из которых состоит из «анализа риска», «некоторого вида работ» и «верификации» (рис. 3.6). Обращение к каждому виду работы предваряет «анализ риска», причем если риск превышения сроков и стоимости проекта оказывается существенным, то разработка заканчивается. Это позволяет предотвратить более крупные денежные потери в будущем.

Цукерберг рекомендует:  Video - ускоренный просмотр видео

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

3.4. КАРКАСНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

Каркасные подходы представляют собой каркас для видов работ и включают их огромное количество.

Рациональный унифицированный подход к выполнению работ

(rational unified process-RUP), изложенный подробно в десятой главе данного учебника, вобрал в себя лучшее из технологических подходов каскадной группы. Весомое преимущество данного подхода состоит в созданном инструментарии его автоматизированной поддержки — программного продукта Rational Rose фирмы «Rational Software Corpation».

При использовании подхода выделяют четыре этапа: начало, исследование, построение, внедрение. В период прохождения этих этапов выполняются виды работ (например, анализ и проектирование), которые к тому же предусматривают итеративность их выполнения (рис. 3.7).


Основные особенности данного подхода:

• итеративность с присущей ей гибкостью;

• контроль качества с возможностью выявления и устранения рисков на самых ранних этапах;

• предпочтение отдается моделям, а не бумажным документам;

• основное внимание уделяется раннему определению архитектуры;

• возможность конфигурирования, настройки и масштабирования.

Рис. 3.7. Рациональный унифицированный подход к видам работ

3.5. ГЕНЕТИЧЕСКИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

Термин «генетический» в названии этой группы подходов связан с происхождением программы и дисциплиной ее создания.

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

— доопределить детали, которые нельзя выразить при помощи языка спецификации, но которые необходимы для получения исполняемого кода;

— выбрать язык реализации и аппаратно-программную платформу для реализации;

— зафиксировать отображение понятий языка спецификаций на язык реализации и аппаратно-программную платформу;

— осуществить трансформацию представления (из спецификации в исполняемую программу на языке реализации);

— отладить и протестировать исполняемую программу.

Автоматическая генерация программ по спецификациям возможна для многих языков спецификаций, особенно для SDL, ASN.1, LOTOS, Estelle, UML (Rational Rose).

Сборочное (расширяемое) программирование предполагает, что программа собирается путем повторного использования уже известных фрагментов (рис. 3.8).

Сборка может осуществляться вручную или может быть задана на некотором языке сборки, или извлечена полуавтоматическим образом из спецификации задачи. Цейтин в 1990 г. изложил основные направления для создания техники сборочного программирования:

— выработка стиля программирования, соответствующего принятым принципам модульности;

— повышение эффективности межмодульных интерфейсов; важность аппаратной поддержки модульности;

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

Рис. 3.8. Сборочное программирование

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

1. Модульное сборочное программирование — исторически первый подход, который базировался на процедурах и функциях методологии структурного программирования.

2. Объектно-ориентированное сборочное программирование базируется на методологии объектно-ориентированного программирования и предполагает распространение библиотек классов в виде исходного кода или упаковку классов в динамически компонуемую библиотеку.

3. Компонентное сборочное программирование предусматривает распространение классов в бинарном виде и предоставление доступа к методам класса через строго определенные интерфейсы, что позволяет снять проблему несовместимости компиляторов и обеспечивает смену версий классов без перекомпиляции использующих их приложений. Существуют конкретные технологические подходы, поддерживающие компонентное сборочное программирование — COM (DCOM, COM+), CORBA, Net. (см. 6.6).

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

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

Наиболее известная технология конкретизирующего программирования — это подход с применением паттернов проектирования (см. 8.6).

Дополнительно к паттернам существуют каркасы (framework) — наборы взаимодействующих классов, составляющих повторно используемый дизайн для конкретного класса программ. Каркас диктует определенную архитектуру приложения, в нем аккумулированы проектные решения, общие для проектной области. Например, существуют каркасы, которые используются для разработки компиляторов.

3.6. ПОДХОДЫ НА ОСНОВЕ ФОРМАЛЬНЫХ ПРЕОБРАЗОВАНИЙ

Эта группа подходов содержит максимально формальные требования к виду работ создания программного обеспечения.

Технология стерильного цеха. Основные идеи технологии стерильного цеха (cleanroom process model) были предложены Харланом Миллзом в середине 80-х годов XX в. Технология складывается из следующих частей (рис. 3.9):

• разработка функциональных и пользовательских спецификаций;

• инкрементальное планирование разработки;

Процесс проектировании связан с представлением программы как функции в виде так называемых «ящиков»:

• черного ящика с фиксированными аргументами (стимулами) и результатами (ответами);

• ящика с состоянием, в котором выделяется внутреннее состояние;

• прозрачного (белого) ящика, представляющего реализацию в виде совокупности функций при пошаговом уточнении.

Использование ящиков определяют следующие три принципа:

— все определенные при проектировании данные скрыты (инкапсулированы) в ящиках;

— все виды работ определены как использующие ящики последовательно или параллельно;

— каждый ящик занимает определенное место в системной иерархии.

Рис. 3.9. Технология стерильного цеха

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

Прозрачный ящик получаем из ящика с состояниями, определяя процедуру, выполняющую требуемое преобразование. Таким образом, прозрачный ящик — это просто программа, реализующая соответствующий ящик с состоянием.

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

Технология стерильного цеха предполагает бригадную работу, т. е. проектирование, уточнение, инспекцию и подготовку текстов ведут разные люди.

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

Формальное синтезирующее программирование использует математическую спецификацию — совокупность логических формул. Существуют две разновидности синтезирующего программирования: логическое, в котором программа извлекается как конструктивное доказательство из спецификации, понимаемой как теоремы, и трансформационное, в котором спецификация рассматривается как уравнение относительно программы и символическими преобразованиями превращается в программу.

Формальное сборочное программирование использует спецификацию как композицию уже известных фрагментов.

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

3.7. РАННИЕ ПОДХОДЫ БЫСТРОЙ РАЗРАБОТКИ

Развитием и одновременно альтернативой каскадных подходов является группа подходов быстрой разработки. Все эти подходы объединяют следующие основные черты:

• итерационную разработку прототипа;

• тесное взаимодействие с заказчиком.

Эволюционное прототипирование. Первый прототип при эволюционном прототипировании (evolutionary prototyping) обычно включает создание развитого пользовательского интерфейса, который может быть сразу же продемонстрирован заказчику для получения от него отзывов и возможных корректив. Основное начальное внимание уделяется стороне системы, обращенной к пользователю. Далее до тех пор, пока пользователь не сочтет программный продукт законченным, в него вносится необходимая функциональность (рис. 3.10).

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


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

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

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

Рис. 3.10. Эволюционное прототипирование

Рис. 3.11. Итеративная разработка

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

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

3.8. АДАПТИВНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

Адаптивные технологические подходы были задуманы как подходы, поддерживающие изменения. Они только выигрывают от изменений, даже когда изменения происходят в них самих. Данные подходы ориентированы на человека, а не на процесс. Во время работы в них необходимо учитывать природные качества человеческой натуры, а не действовать им наперекор (http://www.martinfowler.com).

Экстремальное программирование. Наиболее концентрированно идеи быстрой разработки программ оказались выражены в подходе экстремального программирования (extreme programming) (XP) (http://www.extremeprogramming.org). Две основные черты, присущие быстрым разработкам, являются базовыми и в этом подходе. Методы, объединенные в данном подходе, не являются принципиально новыми. Однако именно их рациональное объединение и совокупное использование дают существенные результаты и успешно выполненные проекты. Наибольшую пользу подход экстремального программирования может принести в разработке небольших систем, требования к которым четко не определены и позднее могут измениться.

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

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

Экстремальное программирование позволяет привлечь конечных пользователей для тестирования уже на ранних этапах проектирования и разработки системы. При этом заказчик обращается к разработчикам с просьбой изготовить программную систему. На протяжении всей работы над проектом необходимо присутствие представителя заказчика. Проект делится на три этапа:

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

— итерационный этап: заказчики пишут тесты и отвечают на вопросы разработчиков, пока последние программируют;

— этап выпуска версии: разработчики устанавливают систему, заказчики принимают работу.

Заказчик в экстремальном программировании имеет массу возможностей повлиять на направление работы команды, так как итерации проекта выдают каждые две недели программное обеспечение, которое можно использовать и тестировать. Принимая такое активное участие в разработке, заказчик может быть уверен в актуальности информации, используемой в работе системы.

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

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

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

Подход начинается с анализа назначения системы и определения первоочередной функциональности. В результате составляется список историй — возможных применений системы. Каждая история должна быть ориентирована на определенные задачи бизнеса, которые можно оценить с помощью количественных показателей. Наконец, ценность истории определяется материальными и временными затратами на ее разработку командой разработчиков.

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

Рис. 3.12. Работа над проектом на основе экстремального программирования

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

• программисты сами пишут тесты для тестирования программы;

• эти тесты пишутся до начала кодирования.

Для любого автономного модуля (класса, процедуры, Unit-модуля) программисты пишут отдельный модульный тест, который должен тестировать все основные варианты использования этого модуля и храниться вместе с ним. Результаты прогонов тестов должны быть лаконичными, например «ОК! (10 tests)». Главное — тест должен писаться до написания самого модуля! Такое тестирование называют опережающим. Внесение изменений на каждой итерации проекта (рефакторинг) всегда сопровождается прогоном всех тестов, чтобы гарантировать стабильную работу системы. Уверенность в нормальной работе как каждого отдельного теста, так и всех тестов комплексного теста придает разработчикам уверенность в нормальной работе очередной версии системы на каждой итерации проекта.

Цель каждой итерации (рис. 3.13) — включить в версию несколько новых историй. На собрании по планированию итерации определяется, какие именно истории и каким образом будут они реализованы командой разработчиков.

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

Рис. 3.13. Работа на итерации экстремального программирования

Рис. 3.14. Коллективное владение кодом при экстремальном программировании

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

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

Адаптивная разработка. В основу подхода адаптивной разработки (Adaptive Software Development — ASD) положены три нелинейных перекрывающих друг друга этапа — обдумывание, сотрудничество и обучение. Автор данного подхода Джим Хайсмит (Jim Highsmith) обращает особое внимание на использование идей из области сложных адаптивных систем.

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

Рис. 3.15. Работа над кодом парой программистов при экстремальном программировании

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

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

3.9. ПОДХОДЫ ИССЛЕДОВАТЕЛЬСКОГО ПРОГРАММИРОВАНИЯ

Исследовательское программирование имеет следующие особенности (http://www.osp.ru/pcworld/2001/01/062.htm):

— разработчик ясно представляет направление поиска, но не знает заранее, как далеко он сможет продвинуться к цели;

— нет возможности предвидеть объем ресурсов для достижения того или иного результата;

— разработка не поддается детальному планированию, она ведется методом проб и ошибок;

— работа связана с конкретными исполнителями и отражает их личностные качества.

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

Компьютерный дарвинизм. Название данного подхода было предложено Кеном Томпсоном (Ken Thompson). Подход основан на принципе восходящей разработки, когда система строится вокруг ключевых компонентов и программ, которые создаются на ранних стадиях проекта, а затем постоянно модифицируются. Все более крупные блоки собираются из ранее созданных мелких блоков.

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

Подход состоит из трех основных видов работ:

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

• Традиционно инженеры стремились, а некоторые из них добивались не снижая качества проектов, значительного сокращения сроков проектирования.

• Инженерный технологический подход определяется спецификой комбинации стадий и видов работ, ориентированной на разные классы программного обеспечения и на особенности коллектива разработчиков.

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

• Ранние технологические подходы не используют явных технологий и их обычно применяют только для очень маленьких проектов.

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

• Каркасные подходы представляют собой каркас для видов работ. Одним из ярких представителей каркасного подхода является рациональный унифицированный подход к выполнению работ, поддерживаемый САПР на основе программного продукта Rational Rose фирмы «Rational Software Corporation».

• Термин «генетический» в названии группы генетических технологических подходов связывается с происхождением программы и дисциплиной ее создания.

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

• Выбор оптимального инженерного технологического подхода обеспечивает сокращение сроков выполнения проекта без снижения качества проекта.


1. За счет чего инженеры добиваются резкого сокращения сроков выполнения проектов?

2. Какие известны основные группы инженерных технологических подходов?

3. Какой классификационный признак положен в основу разделения инженерных технологических подходов на основные группы?

4. Какие инженерные технологические подходы были развиты в последнее время?

5. В чем состоят преимущества и недостатки каскадно-возвратного подхода по сравнению с классическим каскадным подходом?

6. Какой вид работ отсутствует в технологии стерильного цеха?

7. В каких случаях разумно применять эволюционное прототипирование?

8. Какие две основные черты, присущие быстрым разработкам, являются базовыми при экстремальном программировании?

9. В чем состоит суть адаптивной разработки?

Помехоустойчивое кодирование

Содержание

Аннотация [ править ]

Здесь мы рассмотрим основные принципы и методы надёжной и эффективной передачи данных между двумя машинами, соединёнными каналом. Под каналом следует понимать любую физическую среду передачи данных. Посредством этой физической среды нужно научиться передавать биты так, чтобы они безошибочно принимались получателем точно в той последовательности, в какой они были переданы.

Канальный уровень [ править ]

На уровне канала данных решается ряд проблем, присущих только этому уровню:

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

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

Разбиение на кадры [ править ]

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

Типовой подход к решению этой проблемы — разбиение потока битов на кадры и подсчёт контрольной суммы для каждого кадра при посылке данных.

Контрольная сумма — это, в общем смысле, функция от содержательной части кадра (слова длины m <\displaystyle m>), область значений которой — слова фиксированной длины r <\displaystyle r>.

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

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

Первый метод очевиден. В начале каждого кадра указывается сколько символов в кадре. При приёме число принятых символов подсчитывается опять. Однако, этот метод имеет существенный недостаток — счётчик символов может быть искажён при передаче. Тогда принимающая сторона не сможет обнаружить границы кадра. Даже обнаружив несовпадение контрольных сумм, принимающая сторона не сможет сообщить передающей какой кадр надо переслать, сколько символов пропало. Этот метод ныне используется редко.

Таким образом, кадр легко может быть распознан по флаг-байту. Если граница очередного кадра по какой-то причине была потеряна, то все что надо делать — ловить ближайший флаг-байт.

И наконец, последний метод используется там, где конкретизирована физическая среда. Например, в случае проводной связи для передачи одного бита используется два импульса. 1 кодируется как переход высокое-низкое, 0 — как низкое-высокое. Сочетания низкое-низкое или высокое-высокое не используются для передачи данных, и их используют для границ кадра.

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

Контроль ошибок [ править ]

Решив проблему разбиения на кадры, мы приходим к следующей проблеме: как обеспечить, чтобы кадры, пройдя по физическому каналу с помехами, попадали на сетевой уровень по назначению, в надлежащей последовательности и в надлежащем виде?

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

Если кадр-подтверждение несет положительную информацию, то считается что переданные кадры прошли нормально, если там сообщение об ошибке, то переданные кадры надо передать заново.

Однако, возможны случаи когда из-за ошибок в канале кадр исчезнет целиком. В этом случае получатель не будет реагировать никак, а отправитель будет сколь угодно долго ждать подтверждения. Для решения этой проблемы на канальном уровне вводят таймеры. Когда передаётся очередной кадр, то одновременно устанавливается таймер на определённое время. Этого времени должно хватать на то, чтобы получатель получил кадр, а отправитель получил подтверждение. Если отправитель не получит подтверждение раньше, чем истечёт время, установленное на таймере то он будет считать, что кадр потерян и повторит его еще раз.

Однако, если кадр-подтверждение был утерян, то вполне возможно, что один и тот же кадр получатель получит дважды. Как быть? Для решения этой проблемы каждому кадру присваивают порядковый номер. С помощью этого номера получатель может обнаружить дубли.

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

Управление потоком [ править ]

Другая важная проблема, которая решается на канальном уровне — управление потоком. Вполне может случиться, что отправитель будет слать кадры столь часто, что получатель не будет успевать их обрабатывать(например, если машина-отправитель более мощная или загружена слабее, чем машина-получатель). Для борьбы с такими ситуациями вводят управления потоком. Это управление предполагает обратную связь между отправителем и получателем, которая позволяет им урегулировать такие ситуации. Есть много схем управления потоком и все они в основе своей имеют следующий сценарий: прежде, чем отправитель начнёт передачу, он спрашивает у получателя сколько кадров тот может принять. Получатель сообщает ему определённое число кадров. Отправитель после того, как передаст это число кадров, должен приостановить передачу и снова спросить получателя, как много кадров тот может принять, и т.д.

Цукерберг рекомендует:  Выводим сообщение о старости записи

Помехоустойчивое кодирование [ править ]

Характеристики ошибок [ править ]

Физическая среда, по которой передаются данные, не может быть абсолютно надёжной. Более того, уровень шума бывает очень высоким, например в беспроводных системах связи и телефонных системах. Ошибки при передаче — это реальность, которую надо обязательно учитывать.

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

Основной характеристикой интенсивности помех в канале является параметр шума — p. Это число от 0 до 1, равное вероятности инвертирования бита, при условии, что он был передан по каналу и получен на другом конце.

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

У групповых ошибок есть свои плюсы и минусы. Плюсы заключаются в следующем. Пусть данные передаются блоками по 1000 бит, а уровень ошибки 0,001 на бит. Если ошибки изолированные и независимые, то 63 % ( 0.63 ≈ 1 − 0.999 1000 <\displaystyle 0.63\approx 1-0.999^<1000>> ) блоков будут содержать ошибки. Если же они возникают группами по 100 сразу, то ошибки будут содержать 1 % ( 0.01 ≈ 1 − 0.999 10 <\displaystyle 0.01\approx 1-0.999^<10>> ) блоков.

Зато, если ошибки не группируются, то в каждом кадре они невелики, и есть возможность их исправить. Групповые ошибки портят кадр безвозвратно. Требуется его повторная пересылка, но в некоторых системах это в принципе невозможно, — например, в телефонных системах, использующие цифровое кодирование, возникает эффект пропадания слов/слогов.

Для надёжной передачи кодов было предложено два основных метода.

Первый — добавить в передаваемый блок данных нескольких «лишних» бит так, чтобы, анализируя полученный блок, можно было бы сказать, есть в переданном блоке ошибки или нет. Это так называемые коды с обнаружением ошибок.

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

Такое деление условно. Более общий вариант — это коды, обнаруживающие k ошибок и исправляющие l ошибок, где l ≤ k <\displaystyle l\leq k>.

3 подхода к созданию безошибочного кода

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

Однако так как число ошибок в программах заранее неизвестно, то неизвестна заранее и продолжительность отладки программ на ЭВМ. Более того, даже после «завершения» отладки никто не может гарантировать отсутствие ошибок. Естественно, что использование таких программ приводит к возникновению отказов, сбоев и получению неверных результатов.

Структурный подход снижает количество ошибок в алгоритмах и программах. Однако и при этом подходе число ошибок также заранее неизвестно. Хотя структурная форма записи и упрощает поиск и исправление ошибок в текстах программ, гарантии отсутствия ошибок структурный подход не дает.

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

Спецификации программ — это точные, математически строгие описания результатов выполнения алгоритмов и программ. Толькопри наличии спецификаций возможно создание алгоритмов и программ, в которых можно гарантировать отсутствие ошибок.

Более того, при систематическом использовании спецификаций возможен не только анализ правильности алгоритмов и программ, но и становится возможным составление программ с одновременным доказательством правильности.

Безошибочное программирование — это составление алгоритмов и программ с гарантиями отсутствия в них ошибок. А составление алгоритмов и программ с одновременным доказательством правильности называется доказательным программированием. И в том и другом подходе необходимо составление спецификаций.


Для составления программ на любом языке программирования весьма полезно предварительное составление реализуемых в них алгоритмов. Эти описания алгоритмов вместе со спецификациями позволяют в полной мере оценить правильность составленных программ.

Пример составления алгоритмов с использованием в качестве иллюстрации спецификаций сценария диалога с ЭВМ:

В соответствии с этими четырьмя картинками построим три вспомогательных алгоритма рисования отдельных картинок из «Галереи» и общий алгоритм выбора картинок в соответствии с принятым сценарием:

алг «Галерея картинок»

нач алг «рисунок_треугольника»

вывод («Список картинок:») нач

вывод («1. треугольник») линия(150,50)-(100,100)

вывод («2. прямоугольник») линия(150,50)-(200,100)

вывод («З. кольцо») линия(100,100)-(200,100)

запрос («номер=», п) кон

если п = 1 то алг «рисунок_прямоугольника»

инес п = 2 то рамка(50,50)-(150,100)

рисунок_кольца алг «рисунок_кольца»

вывод («нет такого рисунка») окружность(100,100),20

Правильность каждого из вспомогательных алгоритмов и подпрограмм определяется сравнением с соответствующими фрагментами сценария, а правильность всего алгоритма и соответствующей программы — со сценарием в целом.

Данный подход к составлению алгоритмов и программ с использованием спецификаций позволяет реализовать основную идею безошибочного программирования — создание алгоритмов и программ, правильных по построению. Такой подход может применяться к составлению алгоритмов и программ для любых современных языков программирования — Паскаль, Си, Ада, Модула, Бейсик и т.д.

Приведем примеры составления сложных алгоритмов и программ с циклами с использованием спецификаций. Первый пример — построение алгоритма и программы изображения на экране картинки «Звездное небо» из n случайных точек:

В приводимом ниже алгоритме для формирования и вывода последовательности случайных точек на экране используется цикл со счетчиком и датчик случайных чисел для генерации координат «звезд».

алг «звездное небо» ‘ звездное небо

запрос(«звезд=», п) input «звсзд=», n

графический _экран screen 2,0

от k = 1 до п цикл for k = 1 to п

x: = случайное [0:200] х = rnd*200

у: = случайное [0:200] у = rnd*200

точка (х,у) pset (x,y),3

Второй пример — составление с использованием спецификаций алгоритма и программы игры «Угадай-ка». В этой игре ЭВМ «загадывает» число от 0 до 100, а человек должен его отгадать, вводя пробные числа с клавиатуры. Для составления алгоритма и программы примем следующий сценарий:

Для реализации этого сценария воспользуемся циклом с выходом, в котором задается вопрос число=? и проверяются числа, вводимые человеком. Выход из цикла происходит после совпадения ответа с числом, задуманным ЭВМ.

алг «угадай-ка» ‘ угадай-ка

вывод («Угадай число») print «Угадай число»

вывод («от 1 до 100») print «от 1 до 100»

z: = случайное [0:100] z = int (rnd*100)

запрос(«число=», х) input «число=», х

при х = z вых if х = z then exit do

если х z то elseif х > z then

вывод («много») print «много»

вывод («молодец, умница») print «молодец, умница»

Сравнение алгоритма со сценарием показывает их полное соответствие друг другу.

1. Сколько ошибок содержится в программах?

2. Как долго длится отладка программ?

3. Что такое спецификации программ?

4. Зачем нужны спецификации?

5. Можно ли гарантировать отсутствие ошибок в программах?

6. Что такое систематический подход к алгоритмизации?

1. Составьте сценарий и алгоритм диалога «Распорядок дня», с помощью которого можно узнать, что запланировано на заданный час дня.

2. Составьте сценарий и алгоритм диалога с выбором по меню:

а) национальных флагов;

б) каталога строительных блоков;

в) набора рисунков;

г) каталога строений.

3. Предложите сценарии и алгоритмы рисования на экране абстрактных рисунков:

а) из случайных разноцветных точек;

б) из случайных разноцветных отрезков;

в) из случайных разноцветных рамок;

г) из случайных разноцветных окружностей;

д) из случайных разноцветных кругов;

е) из случайных разноцветных окошек.

4. Составьте сценарий и алгоритм, моделирующий на экране броуновское движение частиц.

Свойство «Стратегия создания кода». Большое количество ошибок


31.12.2013, 11:27

Паттерн «Стратегия». Зачем нужен контекст
Здравствуйте, у меня вопрос про паттерн «Стратегия». Я понимаю что он используется для.

Изменять свойство «ConnectionString» не разрешается. Подключение открыто
доброй ночи Появляется непонятная ошибка Подключение не было закрыто. Подключение открыто. В базе.

Свойство «Список» для DataMember не найдено в DataSource
Здравствуйте уважаемы форумчане! У меня возникает такая исключительная ситуация при запуске.

System.InvalidOperationException: «Свойство ConnectionString не инициализировано.»
Не компилится эта часть кода. Хочу сделать добавление записей в БД Access. Почитал про эту ошибку.

01.01.2014, 19:06 2 05.01.2014, 07:56 3 05.01.2014, 14:10 [ТС] 4
05.01.2014, 14:10
05.01.2014, 14:17 [ТС] 5
Вложения
InventoryEDMConsoleApp.rar (3.22 Мб, 9 просмотров)
05.01.2014, 22:44 6
06.01.2014, 15:35 7

Entity Framework и MVC[2,3,4] — разные и не зависимые друг от друга вещи. в той части Freeman-а , о которой Вы говорите, скорее всего использована , так называемая «Code First» модель работы с EF. Это когда на основе модели данных пользователя (структуры классов) и с описанных взаимоотношений с помощью FluentAPI между ними создается база данных. Есть также и Database First модель, когда на основе схемы из БД создается набор классов и navigation propertys. А вообще — смотрите здесь — там ответы на многие вопросы с примерами.

Добавлено через 28 минут
Судя по проекту (у меня он прекрасно собрался) — в нем использована модель Database First. К сожалению — книгу не читал, и немного не понимаю сложности процесса удаления записи из контекста (что именно пытался донести автор)- можно сделать так

06.01.2014, 15:37 [ТС] 8
06.01.2014, 15:39 [ТС] 9
06.01.2014, 16:09 10

Судя по всему — автор использует одну из предыдущих версий EF. В более новых немного изменился подход к сущностям. Вот найдено на просторах интернету:

DbContext is an adapter (wrapper) over ObjectContext. Also it implements explicitly interface IObjectContextAdapter. Cast you dbContext to this interface type and wrapped ObjectContext instance will be available:
ObjectContext context = ((IObjectContextAdapter)dbContext).ObjectContext;

BTW new class DbSet has method Find which also searches entities by key. So, it seems all your code now will look like
T entity = dbContext.Set ().Find(id);

Т.е. конкретно Ваш пример будет так выглядеть:

Ну и в добавление о API работы с контекстом:
DbContext is newer API which should polish developers experience when using most common tasks — simply the API is better designed but you still have to get ObjectContext from DbContext and use the older API if you want to use some more complex features. If you plan to upgrade EF to 5.x or 6.x in the future it will probably be easier with DbContext because that is what ADO.NET team is recommending.

In terms of generators EF 4.x POCO generator creates more complex classes which internally use relations fix up. This feature proved itself to be quite inefficient when used together with lazy loading so newer EF DbContext generator doesn’t use it.

Side note: The code transition from one API to another is fully supported:
You can use DbContext constructor accepting ObjectContext to move from ObjectContext API to DbContext API
You can use IObjectContext adapter to move from DbContext API to ObjectContext API

Добавлено через 2 минуты
По поводу «стратегия создания кода» — немного не понял — зачем ее менять? В большинстве случаев при установке пакета EF с нугета — генераторы ставяться правильно, и не требуют допиливания.

06.01.2014, 16:29 [ТС] 11

Судя по всему — автор использует одну из предыдущих версий EF. В более новых немного изменился подход к сущностям. Вот найдено на просторах интернету:

DbContext is an adapter (wrapper) over ObjectContext. Also it implements explicitly interface IObjectContextAdapter. Cast you dbContext to this interface type and wrapped ObjectContext instance will be available:
ObjectContext context = ((IObjectContextAdapter)dbContext).ObjectContext;

BTW new class DbSet has method Find which also searches entities by key. So, it seems all your code now will look like
T entity = dbContext.Set ().Find(id);

Т.е. конкретно Ваш пример будет так выглядеть:

Ну и в добавление о API работы с контекстом:
DbContext is newer API which should polish developers experience when using most common tasks — simply the API is better designed but you still have to get ObjectContext from DbContext and use the older API if you want to use some more complex features. If you plan to upgrade EF to 5.x or 6.x in the future it will probably be easier with DbContext because that is what ADO.NET team is recommending.

In terms of generators EF 4.x POCO generator creates more complex classes which internally use relations fix up. This feature proved itself to be quite inefficient when used together with lazy loading so newer EF DbContext generator doesn’t use it.

Side note: The code transition from one API to another is fully supported:
You can use DbContext constructor accepting ObjectContext to move from ObjectContext API to DbContext API
You can use IObjectContext adapter to move from DbContext API to ObjectContext API

Добавлено через 2 минуты
По поводу «стратегия создания кода» — немного не понял — зачем ее менять? В большинстве случаев при установке пакета EF с нугета — генераторы ставяться правильно, и не требуют допиливания.

Подходы к автоматизации тестирования веб-приложений

Рубрика: Технические науки

Научный журнал «Студенческий форум» выпуск №21(21)

Подходы к автоматизации тестирования веб-приложений

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

Существует множество подходов к автоматизации тестирования. Все чаще мы слышим такие аббревиатуры, как TDD (англ. Test Driven Development), BDD (англ. Behaviour Driven Development), KDT (англ. Keyword Driven Testing), DDT (англ. Data-driven testing) и многие строго следуют этим подходам в разработке.

Тестирование, управляемое данными (Data-Driven Testing) представляет собой такой подход к тестированию, при котором тестовые данные хранятся отдельно от тест-кейсов, например, в файле или базе данных. Такое разделение делает тесты логически более простыми [1].

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

Как правило, тестирование, управляемое данными, выполняет следующие операции:

— извлекает часть тестовых данных из хранилища;

— водит данные в форму приложения;

— продолжает тестирование со следующим набором входных данных.

На рисунке 1 представлен DDT подход.

Рисунок 1. DataDriven Testing подход

Для успешной проверки приложения требуются разные комбинации данных.

Одним из инструментов программной поддержки DDT является TestComplete, который включает в себя ряд специальных функций и программных объектов, которые помогут подготовить и получить доступ к тестовым данным.

Keyword Driven Testing (Тесты, управляемые ключевыми словами) – это подход, в котором используются ключевые слова, описывающие набор действий, необходимых для выполнения определенного шага тестового сценария. Сперва определяется набор ключевых слов, а затем ассоциируется действие (или функция), связанное с эти ключевым словом. Т.е. каждый шаг теста, такой как открытие или закрытие браузера, щелчок мышью, нажатие клавиши и т.д., описывается ключевым словом, таким как «открыть» (openbrowser), «нажать» (click).

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

Основные этапы разработки KDT тестов:

Шаг 1. Определение ключевых слов;

Шаг 2. Реализация ключевых слов как исполняемых файлов;

Шаг 3. Создание тест-кейсов;

Шаг 4. Создание скриптов;


Шаг 5. Выполнение автоматизированных сценариев.

Преимущества данного подхода:

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

2) Тесты могут быть разработаны без знания программирования.

3) Данный подход не зависит от конкретного языка программирования или инструмента [2].

Методика разработки через тестирование (TDD) заключается в организации автоматического тестирования разрабатываемых приложений путем написания модульных, интеграционных и функциональных тестов, определяющих требования к коду непосредственно перед написанием этого самого кода. Сначала пишется тест, который проверяет корректность работы еще ненаписанного программного кода. Этот тест, разумеется, не проходит. После этого разработчик пишет код, который выполняет действия, требуемые для прохождения теста. После того, как тест успешно пройден, по необходимости осуществляется доработка написанного кода, причём под контролем прохождения тестов.

Рисунок 2. Test Driven Development подход

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

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

BDD — разработка, основанная на поведении. BDD, это разновидность TDD, разница в том, что BDD ориентирован на поведение сущности, которую вы тестируете, в то время как в TDD весь фокус идет на сам код. Суть BDD — в описании системы архитектуры приложения в терминах эксперта предметной области, а не программиста, что позволяет ускорить процесс получения обратной связи и убрать традиционные языковые барьеры между создателями ПО и его пользователями.

Одним из инструментов программной поддержки BDD является Cucumber. Тесты пишутся на простом языке управляемой поведением разработки (BDD) в стиле Given, When, Then (условия, операция, результат), которой понятен любому пользователю. Затем контрольные тесты записываются в файлы функций, охватывающие один или несколько сценариев тестирования. Cucumber интерпретирует тесты на указанном языке программирования и использует Selenium для управления тестами в браузере.

BDD-синтаксис Given, When, Then интуитивно понятен. Элементы синтаксиса:

— Given предоставляет контекст выполнения сценария тестирования, например, точки вызова сценария в приложении, а также любые необходимые данные.

— When определяет набор операций, инициирующих тестирование, таких как действия пользователей или подсистем.

— Then описывает ожидаемый результат тестирования.

На рисунке 3 представлен тест входа в систему для простого веб-приложения.

Рисунок 3. Листинг тестового сценария

Как мы видим, Cucumber предоставляет возможность повторно использовать этот тест путем выбора значений из таблицы. Cucumber читает указанные файлы функций и выполняет тесты, используя указанные теги (@run). Для интерпретации файлов функции создается класс, где каждый метод имеет аннотации Given, When или Then, содержащие регулярные выражения, соответствующие строкам файла функций [3].

Основные преимущества Cucumber:

1) Тесты понятны всем — самим тестировщикам, программистам, менеджерам и заказчикам. Можно смело отправлять их на анализ команде разработки или заказчику и получить ценные рекомендации по их улучшению.

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

3) Ненадобность логирования при написании тестов – каждый степ (действие пользователя) по сути своей является логированием.

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

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

5.Избирательный подход к обеспечению безопасности данных.Обязательный подход к обеспечению безопасности данных.

В современных СУБД поддерживается один из двух наиболее общих подходов к вопросу обеспечения безопасности данных: избирательный подходиобязательный подход. В обоих подходах система безопасности может быть создана как для всей базы данных, так и для любого ее объекта.

Избирательный подход— каждый пользователь обладает определенными правами (полномочиями, привилегиями) при работе с тем или иным объектом БД.

Обязательный подход— каждому объекту БД присваивается уровень доступа, а пользователям — уровень допуска.

В случае избирательного подходапредусмотрены слелующие правила:

правила или привилегии;

диапазон применения привилегий;

действие при нарушении правила.

При обязательном подходепредусмотрено следующее:

пользователь имеет возможность работы с объектом, если уровень его допуска больше или равен уровню доступа объекта;

пользователь имеет возможность модифицировать объект, если уровень его допуска равен уровню доступа объекта.

Эти два подхода отличаются следующими свойствами:

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

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

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

Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. В стандарте вводится понятиегруппы PUBLIC, для которой должен быть определен минимальный стандартный набор прав. По умолчанию предполагается, что каждый вновь создаваемый пользователь, если специально не указано иное, относится к группе PUBLIC.

6. Контрольный след файла, модификация запроса как подходы к обеспечению безопасности данных.

Запись в файле контрольного следа может содержать информацию:

Терминал, с которого вызвана операция

Пользователь, задавший операцию

Дата и время запуска операции

Вовлеченные в процесс исполнения операции базовые отношения, кортежи и атрибуты

7. Безопасность в статистических бд.

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

8. Проблемы обеспечения управляемой избыточности и целостности данных.

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

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

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

Целостностьданных (integrity) — происхождение данных из подлинного источника и уверенность в том, что они позже не изменились, и / или их позже несанкционированно не изменяли.

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

Данные, как правило, связаны с создателем, со временем создания, контекстом и пр., нарушение этих связей может привести к непредвиденным последствиям.

Примеры нарушения целостности:

Взломавший базу данных Riigi Teataja хакер может самоуправно изменять законы

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

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих