Вторая половина ответов на вопросы (987661), страница 3

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

Текст из файла (страница 3)

Для повышения надежности использ. дублирование:

- резервное копирование

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

2) Эффективность программы:

1. временна’я эффективность:

- количество решенных типовых задач за ед. времени.

- время решения типовой задачи.

2. ресурсная экономичность – процент использования ресурсов ЭВМ при решении задачи: для обычных задач не более 90%, для ответственных – не более 70%.

II группа.

1) Практичность:

- понятие концепции

- простота использования

- простота изучения

- привлекательность

2) Сопровождаемость:

- анализируемость

- изменяемость

- стабильность

- тестируемость

3) Мобильность – трудоемкость переноса программы на другую программно-техническую базу.

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

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

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

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

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

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

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

Вообще говоря, защитное программирование применяется для повышения надежности ПС при программировании модуля в более широком смысле. Как утверждает Майерс [11.3], "защитное программирование основано на важной предпосылке: худшее, что может сделать модуль, - это принять неправильные входные данные и затем вернуть неверный, но правдоподобный результат". Для того, чтобы этого избежать, в текст модуля включают проверки его входных и выходных данных на их корректность в соответствии со спецификацией этого модуля, в частности, должны быть проверены выполнение ограничений на входные и выходные данные и соотношений между ними, указанные в спецификации модуля. В случае отрицательного результата проверки возбуждается соответствующая исключительная ситуация. В связи с этим в конец этого модуля включаются фрагменты второго рода - обработчики соответствующих исключительных ситуаций, которые помимо выдачи необходимой диагностической информации, могут принять меры либо по исключению ошибки в данных (например, потребовать их повторного ввода), либо по ослаблению влияния ошибки (например, мягкую остановку управляемых ПС устройств во избежание их поломки при аварийном прекращении выполнения программы).

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

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

Общее понятие исключительной ситуации

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

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

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

Исчерпание доступной памяти. Если в какой-то момент система оказывается не в состоянии выделить достаточный для прикладной программы объём оперативной памяти, программа не сможет работать нормально.

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

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

44. Унифицированный процесс разработки программных средств. Общая характеристика и этапы.

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

В предыдущих главах были рассмотрены средства для выполнения анализа и проектирования программного обеспечения. В этой главе будет рассмотрена методика использования этих средств, точнее, будет рассмотрен унифицированный процесс разработки программного обеспечения (The Unified Software Development Process) согласно [8]. Фундаментальные принципы унифицированного процесса (в дальнейшем УП) заключаются в следующих утверждениях:

• УП управляется вариантами использования.

• УП является архитектурно-ориентированным.

• УП является итеративным и инкрементным.

Рассмотрим эти утверждения подробнее.

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

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

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

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

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

• Уменьшает финансовые риски затратами на одну итерацию.

• Как показывает опыт, желания пользователей и связанные с ним требования не могут быть определены в начале разработки, а уточняются в последовательных итерациях. В [8] это сформулировано так: «Единственное, что постоянно в разработке программ – это изменение требований»

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

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

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

Для разработки программного продукта УП циклически повторяется: каждый цикл включает в себя фазы анализа, проектирования, реализации и внедрения (рис.4.1.). Каждая фаза состоит из 2-3 итераций. Каждый цикл представляет собой мини-проект, реализуемый по модели «мини-водопад».

Время

Рис. 4.1.

Характеристики

Список файлов ответов (шпаргалок)