В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 23
Текст из файла (страница 23)
Корректномупредставлению решений в коде могут помешать как обычные опечатки, так и забывчивостьпрограммиста или его нежелание отказаться от привычных приемов, которые не даютвозможности аккуратно записать принятое решение.С ошибками такого рода можно справиться при помощи инспектирования кода, взаимногоконтроля, при котором разработчики внимательно читают код друг друга, опережающейразработки модульных тестов и тестирования.Первое место в неформальном состязании за место «самой дорого обошедшейся ошибки в ПО»(см.
[11,12]) долгое время удерживала ошибка, приведшая к неудаче первого запуска ракетыАриан-5 4 июня 1996 года (см. [13]), стоившая около $500 000 000. После произошедшего14 августа 2003 года обширного отключения электричества на северо-востоке Северной Америки,стоившего экономике США и Канады от 4 до 10 миллиардов долларов [14], это место можноотдать спровоцировавшей его ошибке в системе управления электростанцией. Широко известнытакже примеры ошибок в системах управления космическими аппаратами, приведшие к их потереили разрушению.
Менее известны, но не менее трагичны, ошибки в ПО, управлявшеммедицинским и военным оборудованием, некоторые из которых привели к гибели людей.Стоит отметить, что в большинстве примеров ошибок, имевших тяжелые последствия, нельзяоднозначно приписать всю вину за случившееся ровно одному недочету, одному месту в коде.Ошибки очень часто «охотятся стаями». К тяжелым последствиям чаще всего приводят ошибкисистемного характера, затрагивающие многие аспекты и элементы системы в целом. Это значит,что при анализе такого происшествия обычно выявляется множество частных ошибок, нарушенийдействующих правил, недочетов в инструкциях и требованиях, которые совместно привели ксоздавшейся ситуации.Даже если ограничиться рассмотрением только ПО, часто одно проявление ошибки (failure)может выявить несколько дефектов, находящихся в разных местах.
Такие ошибки возникают, какпоказывает практика, в тех ситуациях, поведение в рамках которых неоднозначно илинедостаточно четко определяется требованиями (а иногда и вообще никак не определяется —признак неполного понимания задачи). Поэтому разработчики различных модулей ПО имеютвозможность по-разному интерпретировать те части требований, которые относятсянепосредственно к их модулям, а также иметь разные мнения по поводу области ответственностикаждого из взаимодействующих модулей в данной ситуации.
Если различия в их понимании невыявляются достаточно рано, при разработке системы, то становятся «минами замедленногодействия» в ее коде.Например, анализ катастрофы Ариан-5 показал следующее [13].• Ариан-5 была способна летать при более высоких значениях ускорений и скоростей, чемэто могла делать ракета предыдущей серии, Ариан-4.Однако большое количество процедур контроля и управления движением по траектории в72••••коде управляющей системы было унаследовано от Ариан-4. Большинство таких процедурне были специально проверены на работоспособность в новой ситуации, как в силубольшого размера кода, который надо было проанализировать, так и потому, что этот кодраньше не вызывал проблем, а соотнести его со специфическими характеристиками полетаракет вовремя никто не сумел.В одной из таких процедур производилась обработка горизонтальной скорости ракеты.
Привыходе этой величины за границы, допустимые для Ариан-4, создавалась исключительнаяситуация переполнения.Надо отметить, что обработка нескольких достаточно однородных величин производиласьпо-разному — семь переменных могли вызвать исключительную ситуацию данного вида,обработка четырех из них была защищена от этого, а три оставшихся, включаягоризонтальную скорость, оставлены без защиты. Аргументом для этого послужиловыдвинутое при разработке требование поддерживать загрузку процессора не выше 80%.«Нагружающие» процессор защитные действия для этих переменных не былииспользованы, поскольку предполагалось, что эти величины будут находиться в нужныхпределах в силу физических ограничений на параметры движения ракеты. Обоснованийдля поддержки именно такой загрузки процессора и того, что отсутствие обработкипереполнения выбранных величин будет способствовать этому, найдено не было.Когда такая ситуация действительно случилась, т.е.
горизонтальная скорость ракетыпревысила определенное значение, она не была обработана соответствующим образом, и врезультате ею вынужден был заняться модуль, обеспечивающим отказоустойчивостьпрограммной системы в целом.Этот модуль, в силу отсутствия у него какой-либо возможности обрабатывать такиеошибки специальным образом, применил обычный прием — остановил процесс, в которомвозникла ошибка, и запустил другой процесс с теми же исходными данными. Как легкодогадаться, эта же ошибка повторилась и во втором процессе.Не в силах получить какие-либо осмысленные данные о текущем состоянии полета,система управления использовала ранее полученные, которые уже не соответствовалидействительности.
При этом были ошибочно включены боковые двигатели «длякорректировки траектории», ракета начала болтаться, угол между нею и траекториейдвижения стал увеличиваться и достиг 20 градусов. В результате она стала испытыватьчрезмерные аэродинамические нагрузки и была автоматически уничтожена.Литература к Лекции 5[1] ISO/IEC 9126-1:2001. Software engineering — Software product quality — Part 1: Qualitymodel.[2] ISO/IEC TR 9126-2:2003 Software engineering — Product quality — Part 2: External metrics.[3] ISO/IEC TR 9126-3:2003 Software engineering — Product quality — Part 3: Internal metrics.[4] ISO/IEC TR 9126-4:2004 Software engineering — Product quality — Part 4: Quality in usemetrics.[5] ISO 9000:2000 Quality management systems — Fundamentals and vocabulary.[6] ISO 9001:2000 Quality management systems — Requirements.[7] ISO 9004:2000 Quality management systems — Guidelines for performance improvements.[8] ISO/IEC 90003:2004 Software engineering — Guidelines for the application of ISO 9001:2000 tocomputer software.[9] В.
В. Липаев. Методы обеспечения качества крупномасштабных программных средств. М.:Синтег, 2003.[10] Э. М. Кларк, О. Грамберг, Д. Пелед. Верификация моделей программ: Model Checking. М.:МЦНМО, 2002.[11] http://www5.in.tum.de/~huckle/bugse.html[12] http://infotech.fanshawec.on.ca/gsantor/Computing/FamousBugs.htm[13] http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html73[14] http://www.elcon.org/Documents/EconomicImpactsOfAugust2003Blackout.pdf[15] И. Соммервилл. Инженерия программного обеспечения.
М.: Вильямс, 2002.[16] Э. Дж. Брауде. Технология разработки программного обеспечения. СПб.: Питер, 2004.[17] Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения.М.: Мир, 1991.74Лекция 6. Архитектура программного обеспеченияАннотацияРассматривается понятие архитектуры ПО, влияние архитектуры на свойства ПО, а также методыоценки архитектуры. Рассказывается об основных элементах унифицированного языкамоделирования UML.Ключевые словаАрхитектура ПО, компонент архитектуры, представление архитектуры, сценарий использования,методы оценки архитектуры, диаграммы классов, диаграммы взаимодействия, диаграммысценариев, диаграммы компонентов, диаграммы развертывания.Текст лекцииАнализ области решенийДопустим, мы разобрались в предметной области, поняли, что требуется от будущейпрограммной системы, даже зафиксировали настолько полно, насколько смогли, требования ипожелания всех заинтересованных лиц ко всем аспектам качества программы.
Что делать дальше?На этом этапе (а точнее, гораздо раньше, обычно еще в ходе анализа предметной области)исследуются возможные способы решения тех задач, которые поставлены в требованиях. Невсегда бывает нужно специальное изучение этого вопроса — чаще всего имеющийся опытразработчиков сразу подсказывает, как можно решать поставленные задачи. Однако иногда, всетаки, возникает потребность сначала понять, как это можно сделать и, вообще, возможно ли этосделать и при каких ограничениях.Таким образом, явно или неявно, проводится анализ области решений.
Целью этойдеятельности является понимание, можно ли вообще решить стоящие перед разрабатываемойсистемой задачи, при каких условиях и ограничениях это можно сделать, как они решаются, еслирешение есть, а если нет — нельзя ли придумать способ его найти или получить хотя быприблизительное решение, и т.п. Обычно задача хорошо исследована в рамках какой-либо областичеловеческих знаний, но иногда приходится потратить некоторые усилия на выработкусобственных решений. Кроме того, решений обычно несколько и они различаются по некоторымхарактеристикам, способным впоследствии сыграть важную роль в процессе развития иэксплуатации созданной на их основе программы. Поэтому важно взвесить их плюсы и минусы иопределить, какие из них наиболее подходят в рамках данного проекта, или решить, что все онидолжны использоваться для обеспечения большей гибкости ПО.Когда определены принципиальные способы решения всех поставленных задач (быть может, вкаких-то ограничениях), основной проблемой становится способ организации программнойсистемы, который позволил бы реализовать все эти решения и при этом удовлетворитьтребованиям, касающимся нефункциональных аспектов разрабатываемой программы.
Искомыйспособ организации ПО в виде системы взаимодействующих компонентов называютархитектурой, а процесс ее создания — проектированием архитектуры ПО.Архитектура программного обеспеченияПод архитектурой ПО понимают набор внутренних структур ПО, которые видны сразличных точек зрения и состоят из компонентов, их связей и возможных взаимодействий междукомпонентами, а также доступных извне свойств этих компонентов [1].Под компонентом в этом определении имеется в виду достаточно произвольный структурныйэлемент ПО, который можно выделить, определив интерфейс взаимодействия между этимкомпонентом и всем, что его окружает.
Обычно при разработке ПО термин «компонент» (см.далее при обсуждении компонентных технологий) имеет несколько другой, более узкий смысл —это единица развертывания, самая маленькая часть системы, которую можно включить или невключить в ее состав. Такой компонент также имеет определенный интерфейс и удовлетворяет75некоторому набору правил, называемому компонентной моделью.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
