Вопросы и ответы к зачету по программной инженерии.

1. Понятие «правильного» и «надежного» пс.

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

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

Альтернативой правильного ПС является надежное ПС. Надежность ПС - это его способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью [1.5]. При этом под отказом в ПС понимают проявление в нем ошибки [1.2]. Таким образом, надежная ПС не исключает наличия в ней ошибок - важно лишь, чтобы эти ошибки при практическом применении этого ПС в заданных условиях проявлялись достаточно редко. Убедиться, что ПС обладает таким свойством можно при его испытании путем тестирования, а также при практическом применении. Таким образом, фактически мы можем разрабатывать лишь надежные, а не правильные ПС.

Разрабатываемая ПС может обладать различной степенью надежности. Как измерять эту степень? Так же как в технике, степень надежности можно характеризовать [1.2] вероятностью работы ПС без отказа в течении определенного периода времени. Однако в силу специфических особенностей ПС определение этой вероятности наталкивается на ряд трудностей по сравнению с решением этой задачи в технике. Позже мы вернемся к более обстоятельному обсуждению этого вопроса.

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

2. Источники ошибок в пс.

• Сложность ПС как системы

Система – совокупность взаимодействующих друг с другом элементов. Любая программа является системой.

Простая система – та, в которой человек может уверенно перебрать все пути взаимодействия между элементами;

Сложная система – такая система, в которой перебрать все пути взаимодействия между элементами человек не в состоянии.

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

Задача технологии программирования с точки зрения построения качественных ПС – делать большие системы простыми. Достигается это посредством группировки и обобщения.

• Неправильный перевод

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

3. Методы борьбы с ошибками.

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

• сужение пространства перебора (упрощение создаваемых систем),

• обеспечение требуемого уровня подготовки разработчика (это функции менеджеров коллектива разработчиков),

• обеспечение однозначности интерпретации представления информации,

• контроль правильности перевода (включая и контроль однозначности интерпретации).

4. Жизненный цикл программного средства.

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

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

Рис. 3.1. Стадии и фазы жизненного цикла ПС

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

Внешнее описание (Requirements document) ПС является описанием его поведения с точки зрения внешнего по отношению к нему наблюдателю с фиксацией требований относительно его качества. Внешнее описание ПС начинается с определения требований к ПС со стороны пользователей (заказчика).

Конструирование (design) ПС охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию.

Кодирование (coding) создание текстов программ на языках программирование, их отладку с тестированием ПС.

На этапе аттестации ПС производится оценка качества ПС, после успешного завершения которого разработка ПС считается законченной.

Программное изделие (ПИ) - экземпляр или копия, снятая с разработанного ПС. Изготовление ПИ - это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПС с целью их поставки пользователю для применения по назначению. Производство ПИ - это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки [3.1]. Стадия производства ПС в жизненном цикле ПС является, по-существу, вырожденной (не существенной), так как представляет рутинную работу, которая может быть выполнена автоматически и без ошибок. Этим она принципиально отличается от стадии производства различной техники. В связи с этим в литературе эту стадию, как правило, не включают в жизненный цикл ПС.

Стадия эксплуатации ПС охватывает процессы хранения, внедрения и сопровождения ПС, а также транспортировки и применения (operation) ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС.

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

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

5. Понятие качества пс. Критерии.

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

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

• функциональность,

• надежность,

• легкость применения,

• эффективность,

• сопровождаемость,

• мобильность.

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

Надежность подробно обсуждалась в первой лекции.

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

Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.

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

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

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

6. Внешнее описание пс. Назначение и состав.

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

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

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

7. Функциональная и нефункциональная спецификация.

Во внешнем описании присутствуют две самостоятельные части:

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

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

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

8. Архитектура пс. Основные классы архитектур.

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

1. Выделение программных подсистем и отображение их внешних функций

2. Определение способа взаимодействия между выделенными программными подсистемами

Различают следующие классы архитектур ПС:

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

2. Комплекс автономно выполняемых программ – состоит из набора программ, организованных следующим образом:

   1. Любая программа может быть активирована пользователем

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

   3. Все программы применяются для одной и той же информационной среды

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

3. Слоистая программная система – состоит из упорядоченной совокупности подсистем. Системы формируют слои или уровни. Уровни отвечают следующим требованиям:

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

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

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

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

Пример таких систем – операционная система; стеки коммуникационных протоколов компьютерных систем

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