И. Соммервилл - Инженерия программного обеспечения (1133538), страница 94
Текст из файла (страница 94)
В работе 196) показано, что использование оператора безусловного перехода йо1о приводит к логическим конструкциям, существенно подверженным ошибкам программирова. ния. Они также затрудняют локализацию изменений состояния системы. Зто наблюдение привело к появлению так называемого струкэгу~ного ярогрлмми~юванкя Речь идет о про. граммированин без использования оператора 901о, использующем для управление только циклы по условию шЫ1е и условные операторы 10 Переход к структурному программированию был важной вехой в развитии инженерии программного обеспечения, поскольку это был первый шаг на пути к научному подходу в практике разработки ПО. Кроме операторов безусловного перехода, существуют другие языковые конструкции и методы программирования, подверженные ошибкам. 1. Чксла с элаэаюжек язвящей.
Зти числа неточны по своей природе. Зто порождает определенные проблемы, особенно при сравнении чисел. Например, число 3.00000000 может иногда представляться как 2.99999999, а иногда как гь00000001. Сравнение последних чисел показало бы„что они не равны. Числа с фиксированной запятой, где установлено количество десятичных знаков, более "надежны" прн точном сравнении. 2. Указаэмли. Зто низкоуровневые конструкции, содержащие адреса, которые являют. ся ссылками непосредственно на ячейки оперативной памяти машины. Они опасны, поскольку допускают совмещение имен, а также затрудняют проверку массивов и других структур.
3. Динамическое расиундэмкке яаилжк. В этом случае выделение памяти для программы осуществляется во время ее выполнения, а не во время компиляции. Опасность кроется в возможности такого распределения памяти, при котором программа будет выполняться вне доступной области памяти. Этот тип ошибки очень трудно об. наружить, поскольку сисгема может успешно работать в течение длительного времени, прежде чем возникнут какие-либо проблемы. 18. Разработка критических систем 365 4.
Ларалылькасжь ярокэиээ. Параллельное выполнение процессов опасно тем, что трудно предсказать взаимовлияние от обмена данными между процессами, которое может быть разным в зависимости от временньег параметров обмена. Эту проблему невозможно обнаружить просмотром текста программ; кроме того, во время испьгганий системы не всегда можно выявить комбинации временных параметров, которые приводят к непредвиденному взаимовлиянию процессов. Если без параллелыюсти процессов невозможно обойтись, необходимо минимизировать вэаимоэависимосги между процессами.
В некоторых языках программирования (например, Аоа и ~эта) имеются средства для управления параллельным выполнением процессов. 5. Рекурсия. Это ситуация, когда процедура или метод вызывает себя или другую про. цедуру, которая затем вызывает первоначальную процедуру. Использование рекурсии позволяет создавать короткие программы, однако в них трудно проследить логику. Поэтому ошибки программирования также трудно обнаружить.
Использоыние рекурсии может привести к ошибкам в адресации памяти, так как создаются временные стеки переменных. 6. Цырьмакия. Это средство управления принудительным переходом к определенному разделу программы независимо от текущего ее выполнения. Опасности этого очевидны, поскольку прерывание может привести к непредвиденному прекращению выполнения какой-либо критически важной операции. 7. Оасмдоэаккс Наследование в объектно. ориентированных языках программирования позволяет многократно использовать определенные фрагменты кода и выполнять декомпозицию задач, но это также приводит к тому, что программный код, относящийся к одному объекту, может находиться в разных разделах программы. Это затрудняет понимание поведения объекта, поэтому вероятны ошибки программирования.
8. Саемээзэкиг алин. Это случается, когда различные имена используются для обращения к одному н тому же программному объекту. При чтении текста программы лен ко пропустить момент изменения состояния объекта, для обращения к которому используется несколько имен. 9.
Ввод дямкых эгэ проверки. Некоторые системы организуют процесс ввода данных независимо от нх содержания. Это просчет в защищенности системы, поскольку мо. гут быть введены данные, которые не отвергаются системой, но могут привести к ее сбою. Некоторые стандарты проектирования систем, критических по обеспечению безопасности, полностью запрещают использование перечисленных программных конструкций. Однако такая категоричность не всегда оправдана.
Все эти конструкции и методы полез. ны, но они должны использоваться осторожно. Везде, где возможно, их потенциально опасные эффекты должны контролироваться, используя эти конструкции внутри абстрактных типов данных или объектов. 18.1.2. Сокрытие информации Принцип защищенности, который принят военными организацилми, гласит: "нет не. обходимости знать". Только тем, кому требуется знать особую часть информации для выполнения своих обязанностей. предоставляется доступ к ней. Информация, которая прямо не относится к их работе, скрывается. Збб Часть ТУ. Критические системы В программировании аналогичный принцип должен применяться для управления доступом к данным.
Программным компонентам должны быть доступны только те данные, которые им необходимы для выполнения своих функций. Доступ к другим данныи должен быть закрыт с помощью правил видимости, которые есть практически в любом языке программирования, Если используется сокрытие информации, то скрытая информация не может быть разрушена компонентами системы, которые ее не используют. Сокрытие информации наиболее просто реализуется в языке )ага, в отличие от более ранних языков программирования типа С или Рааса). Эти языки не имеют конструкций инкапсуляции, таких как классы объектов, поэтому структуры данных не защищены, Другие части программы мокнут обращаться к данным непосредственно, что может вести к не.
предвиденным побочным эффектам. В объектно-ориентированных языках предусмотро ны методы, которые позволяют выбирать и обновлять значения атрибутов, не предоставляя другим объектам непосредственного доступа к этим атрибутам. Таким образом, значение атрибута можно изменять независимо от других объектов, которые используют атрибут. Этот же принцип в языке )ага можно использовать для объявления интерфейса объекта независимо от его выполнения, что проиллюстрировано в листинге 18.1.
Пользователи объектов типа Оцвце (Очередь) могут поместить элементы в очередь и выбрать их из очереди, а также запросить размер очереди. Однако в кзассе, который осуществляет этот интерфейс, фактическая реализация очереди скрыта путем объявления атрибутов н методов собственностью этого класса объектов. Подобный пример сокрытия информации показан в листинге 18.2.
В ситуациях, когда некоторая переменная может принимать ограниченное множество значений, эти значения могут быть объявлены как константы. Языки, полобные С++, поддерживают перечислимые типы данных, но в языке )ага длл этого необходимо испольэовать объявление класса. Для примера рассмотрим сигнальную систему, которая поддерживает красный, желтый и зеленый цвета. Тип 8)дпа! (Сигнал) необходимо определить так, чтобы включить объявления констант, соответствующих этим цветам. После этого можно ссылаться на 8)дпа).геб (красный сигнал), 8(бпа).ягееп (зеленый сигнал) и т.д. Этим избегается случайное пр>жвоение неправильных значений переменным типа 8)дпа1.
Листинг 18.1. Спецификация очереди с помощью объявления интерфейса 1псеггасе Опеце ( рпЫ1с чогб рцг (ОЬбесг о) рпЫгс чо1с) геточе (ОЬбвсс о) риЫгс гпс в1зе () г //диене Листинг 18.2. Объявление класса 81япа1 в языке )ача с1авэ Яздпа1 ( эсасгс рпЫзс 11па1 1пс гес) = 1 всаггс рпЫзс Ггпа1 зпе апЬег = 2 всасгс рпЬ11с б1па1 1пс дгееп = 3 рпЬ11с зпс э1дясасе ) 1В.
Разработка критических систем 567 18.1.3. Разработка безотказного ПО Для разработки программного обеспечения с минимальным числом отказов необхо. димо иметь технологический процесс, который хорошо определен, опробован и содержит этапы контроля и аттестации ПО. Хорошо определенный процесс — это стандартизированный и документированный процесс.
Опробованный процесс не зависит от индивидуальной интерпретации и решений разработчиков ПО. (Эти вопросы подробно рассматриваются в главе 25.) Процесс разработки ПО должен включать в себя хорошо спланированный комплексный процесс тестирования, имеющий целью обнаружение системных ошибок.
Процесс тестирования, минимизирующий количество системных ошибок, имеет несколько составляющих. 1. Проверка жребовапий, цель которой состоит в обнаружении ошибок и других проблем в системной спецификации (см. главу 6). Большая доля отказов и сбоев в работе готового программного продукта обусловлена ошибками в спецификации требований. 2. Управление яфебоваиилми. В задачу управления требованиями, как указывалось в главе 6, входит контроль за изменениями в требованиях и отслеживание внесения соответствующих изменений (вызванных изменением требований) на всех этапах создания системы.
Многие ошибки в готовых системах появляются в результате то. го, что изменения требований не были'учтены при проектировании или реализации системы. 5. Проверка моделей. Это автоматический анализ системных моделей с помощью ннст. рументальных САВЕ средств, которые контролируют внутреннюю и внешнюю не.
противоречивость этих моделей. Внутренняя непротиворечивость означает непротиворечивость отдельной модели системы; внешняя — непротиворечивость всех моделей системы (например, модели состояний и модели объектов). 4. Проверка сиплемкой аркивмкиурм и инспекция кода програилс Как будет показано в главе 19, проверка архитектуры и кода программ базируется на технологических картах проверки программ и предназначена для обнаружения н устранения этих ои~ибок перед тестированием системы.
5. Свюмичеекий а1иыиз. Это автоматизированный метод анализа программ, предназначенный для нахождения потенциально ошибочных условий. Этот метод описывается в главе 19. 6. Планирование и управление вмсмироваикем гиеомиьс Необходимо разработать набор всесторонних тестов и сам процесс тестирования, гарантирующий полную проверку системы. Вопросы тестирования систем рассматриваются в главе 20, 18.2. Устойчивость к сбоям Устойчивой к сбоям (отказоустойчивой) являетсл такая система, которая может продолжить работу после проявления некоторых системных сбоев. Другими словамн, в отказоустойчивых системах сбои не приводят к отказу системы. Устойчивость к сбоям пеобхо. дима там, где отказ системы может стать причиной катастрофических последствий или где остановка работы системы приводит к большим экономическим потерям.
Например, ком пьютерныс системы самолета должны безотказно работать до тех пор, пока он не при- 368 'Часть Тт. Критические системы зсмлится; система управления воздушным движением должна быть работоспособной, пока самолеты в воздухе. Можно предположить, что средства отказоустойчивости не должны включаться в систему, которая разрабатывается на основе методов минимизации ошибок. Если в системе нет ошибок, то, казалось бы, нет и причин для системных отказов. Но "без ошибок" не означает "безотказный". "Без ошибок" только означает, что программа соответствует своей спецификации.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
