Преподаватель: Ситанов Сергей Вячеславович

Для обеспечения надежности ПС (программного средства) известно 4 подхода:

1. Предупреждение ошибок

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

1. Борьба со сложностью (максимальное упрощение программы)

2. Обеспечение точности перевода

3. Преодоление барьера между пользователем и разработчиком

4. Обеспечение контроля принимаемых решений

Этот подход связан с процессом организации разработки ПС. В рамках этого подхода уже можно достигнуть приемлемого уровня надежности.

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

2. Самообнаружение ошибок

Означает, что программа содержит средства обнаружения отказов.

3. Самоисправление ошибок

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

4. Обеспечение устойчивости к ошибкам

Означает, что влияние ошибки локализовано и не влияет на работоспособность в целом.

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

Например,

Try

… (содержится элемент программы в которой контролируется ошибка)

(если произошла ошибка, то переходит к блоку Catch, где содержатся команды исправления ошибки)

Catch

… (если ошибки нет, то блок Catch игнорируется)

End Catch

Известны два метода «борьбы со сложностью»

1. Обеспечение независимости компонентов системы

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

Типичный пример – использование модульного программирования (известен также как объектно-ориентированный подход). Каждый модуль решает определенный класс задач, используя только собственные внутренние структуры. А связи формируется через стандартизированный интерфейс, независимый от содержания модуля. Благодаря этому каждый модуль может создаваться отдельно от других. И полностью отлаженный модуль в дополнительном контроле не нуждается.

2. Использование иерархических структур

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

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

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

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

1. Поймите задачу

2. Составьте план, включая цели и методы решения

3. Выполните план, проверяя правильность каждого шага

4. Проанализируйте полученное решение

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

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

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

2. Сочетание статических и динамических методов контроля

Статический контроль контролирует сам документ, а динамический контролирует процесс обработки данных который он описывает.

Внешнее описание программного средства

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

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

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

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

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

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

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

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

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

Определение требований к программному средству

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

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

Для определения требований существует 3 способа:

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

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

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

Наиболее предпочтительными является разработка, контролируемая пользователем.

Спецификация качества программного средства

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

Примечание. Некоторые примитивы могут входить в разные критерии качества.

Критерии качества и примитивы:

1. Функциональность (входит примитив завершенность)

2. Надежность (входят примитивы завершенность, точность, автономность, устойчивость и защищенность)

3. Легкость применения (входят примитивы документированность, информативность, коммуникабельность, устойчивость и защищенность)

4. Эффективность (входят примитивы временная эффективность, эффективность по памяти, эффективность по устройствам)

5. Сопровождаемость (выделяют два подкритерия: изучаемость – характеризует усилия по понимаю программы; модифицируемость – упрощает внесение изменений)

Изучаемость (входят примитивы документированность, информативность (документация по сопровождению), понятность, структурированность, удобочитаемость)

Модифицируемость (входят примитивы расширяемость, структурированность, модульность)

6. Мобильность (входят примитивы независимость от устройств, автономность, структурированность, модульность)

Функциональная спецификация программного средства

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

Функциональная спецификация состоит из 3х частей:

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

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

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

Методы контроля внешнего описания пс

Разработка внешнего описания должна завершатся проведением контроля. Цель этапа – найти как можно больше ошибок.

Существуют следующие методы контроля:

1. Статический просмотр – это внимательное прочтение текста с целью проверки на полноту и непротиворечивость. Выявляет неточности и явные ошибки.

2. Смежный контроль – выделяют:

Смежный контроль спецификации сверху – это проверка со стороны разработчика требований ПС.

Контроль функциональной спецификации – это проверка разработчиками требований ПС и спецификации качества

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

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

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

Архитектура программного средства

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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