Программирование

11.3. Обеспечение точности программного средства.

Обеспечение этого примитива связано с действиями над значениями вещественных типов (точнее говоря, со значениями, представляемыми с некоторой погрешностью). Обеспечить требуемую точность при вычислении значения той или иной функции - значит получить это значение с погрешностью, не выходящей за рамки заданных границ. Видами погрешности, методами их оценки и методами достижения требуемой точности (так называемыми приближенными вычислениями) занимается вычислительная математика [11.1, 11.2]. Здесь мы лишь обратим внимание на некоторую структуру погрешности: погрешность вычисленного значения (полная погрешность) зависит

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

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

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

11.4. Обеспечение автономности программного средства.

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

11.5. Обеспечение устойчивости программного средства.

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

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

11.6. Обеспечение защищенности программных средств.

Различают следующие виды защиты ПС от искажения информации:

защита от сбоев аппаратуры;

защита от влияния "чужой" программы;

защита от отказов "своей" программы;

защита от ошибок оператора (пользователя);

защита от несанкционированного доступа;

защита от защиты.

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

Защита от влияния "чужой" программы относится прежде всего к операционным системам или к программам, выполняющим частично их функции. Различают две разновидности этой защиты:

защита от отказов,

защита от злонамеренного влияния "чужой" программы.

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

защиту памяти,

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

два вида операций: привилегированные и ординарные,

корректную реализацию прерываний и начального включения компьютера,

временное прерывание.

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

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

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

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

Защита от взлома защиты связана с использованием в ПС специальных программистских приемов, затрудняющих преодоление защиты от несанкционированного доступа. Использование обычных паролей оказывается недостаточной, когда речь идет о чрезвычайно настойчивом стремлении (например, преступного характера) добиться доступа к ценной информации. Во-первых, потому, что информацию о паролях, которую использует ПС для защиты от несанкционированного доступа, "взломщик" этой защиты относительно легко может достать, если он имеет доступ к самому этому ПС. Во-вторых, используя компьютер, можно осуществлять достаточно большой перебор возможных паролей с целью найти подходящий для доступа к интересующей информации. Защититься от такого взлома можно следующим образом. Секретное слово (пароль) или просто секретное целое число X знает только владелец защищаемой информации, а для проверки прав доступа в компьютере хранится другое число Y=F(X), однозначно вычисляемое ПС при каждой попытке доступа к этой информации при предъявлении секретного слова. При этом функция F может быть хорошо известной всем пользователям ПС, однако она обладает таким свойством, что восстановление слова X по Y практически невозможно: при достаточно большой длине слова X (например, в несколько сотен знаков) для этого требуется астрономическое время. Такое число Y будем называть электронной (компьютерной) подписью владельца секретного слова X (а значит, и защищаемой информации).

Другая разновидность такой защиты связана с защитой сообщений, пересылаемых по компьютерным сетям, преднамеренных (или злонамеренных) искажений. Такое сообщения может перехватываться на "перевалочных" пунктах компьютерной сети и подменяться другим сообщением от автора перехваченного сообщения. Такая ситуация возникает прежде всего при осуществлении банковских операций с использованием компьютерной сети. Путем подмены такого сообщения, являющего распоряжением владельца банковского счета о выполнении некоторой банковской операции деньги с его счета могут быть переведены на счет "взломщика" защиты (своеобразный вид компьютерного ограбления банка). Защиту от такого взлома защиты можно осуществить следующим образом [11.4]. Наряду с функцией F, определяющей компьютерную подпись владельца секретного слова X, которую знает адресат защищаемого сообщения (если только ее владелец является клиентом этого адресата), в ПС определена другая функция Stamp, по которой отправитель сообщения должен вычислить число S=Stamp(X,R), используя секретное слово X и текст передаваемого сообщения R. Функция Stamp также считается хорошо известной всем пользователям ПС и обладает таким свойством, что по S практически невозможно ни восстановить число X, ни подобрать другое сообщение R с соответствующей компьютерной подписью. Само передаваемое сообщение (вместе со своей защитой) должно иметь вид:

R Y S ,

причем Y (компьютерная подпись) позволяет адресату установить истинность клиента, а S как бы скрепляет защищаемое сообщение Rс компьютерной подписью Y. В связи с этим будем называть число S электронной (компьютерной) печатью. В ПС определена еще одна функция Notary, по которой получатель защищаемого сообщения проверяет истинность передаваемого сообщения:

Notary(R,Y,S).

Эта позволяет однозначно установить, что сообщение R принадлежит владельцу секретного слова X.

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

Литература к лекции 11.

11.1. И.С. Березин, Н.П. Жидков. Методы вычислений, т.т. 1 и 2. - М.: Физматгиз, 1959.

11.2. Н.С. Бахвалов, Н.П. Жидков, Г.М.Кобельков. Численные методы. - М.: Наука, 1987.

11.3. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. С. 127-154.

11.4. А.Н. Лебедев. Защита банковской информации и современная криптография//Вопросы защиты информации, 2(29), 1995.

Лекция 12. ОБЕСПЕЧЕНИЕ КАЧЕСТВА ПРОГРАММНОГО СРЕДСТВА

12.1. Общая характеристика процесса обеспечения качества программного средства.

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

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

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

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

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

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

П-документированость ПС определяет состав пользовательской документации

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

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

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

12.3. Обеспечение эффективности программного средства.

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

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

сначала нужно разработать надежное ПС, а уж потом добиваться требуемой его эффективности в соответствии со спецификацией качества этого ПС [12.2, 12.3];

для повышения эффективности ПС используйте прежде всего оптимизирующий компилятор - это может обеспечить требуемую эффективность [12.3];

если достигнутая эффективность ПС не удовлетворяет спецификации его качества, то найдите самые критические модули с точки зрения требуемой эффективности ПС (в случае временнoй эффективности для этого потребуется получить распределение по модулям времени работы ПС путем соответствующих измерений во время выполнения ПС); эти модули и попытайтесь оптимизировать в первую очередь путем их ручной переделки [12.3];

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

12.4. Обеспечение сопровождаемости.

С-документированность, информативность и понятность определяют состав и качество документации по сопровождению (см. следующую лекцию). Кроме того, относительно текстов программ (модулей) можно сделать следующие рекомендации.

используйте в тексте модуля комментарии, проясняющие и объясняющие особенности принимаемых решений; по-возможности, включайте комментарии (хотя бы в краткой форме) на самой ранней стадии разработки текста модуля [12.3];

используйте осмысленные (мнемонические) и устойчиво различимые имена (оптимальная длина имени - 4-12 литер, цифры - в конце), не используйте сходные имена и ключевые слова [12.2, 12.3];

соблюдайте осторожность в использовании констант (уникальная константа должна иметь единственное вхождение в текст модуля: при ее объявлении или, в крайнем случае, при инициализации переменной в качестве константы [12.2]);

не бойтесь использовать не обязательные скобки (скобки обходятся дешевле, чем ошибки [12.3 ];

размещайте не больше одного оператора в строке; для прояснения структуры модуля используйте дополнительные пробелы (отступы) в начале каждой строки [12.2, 12.3];

избегайте трюков, т.е. таких приемов программирования, когда создаются фрагменты модуля, основной эффект которых не очевиден или скрыт (завуалирован), например, побочные эффекты функций [12.2].

Расширяемость обеспечивается созданием подходящего инсталятора.

Структурированность и модульность упрощают как понимание текстов программ, так и их модификацию.

12.5. Обеспечение мобильности.

Литература к лекции 12.

12.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.

12.2. Г.Майерс. Надежность программного обеспечения. - М.: Мир, 1980. С. 127-154.

12.3. Д.Ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. С. 8-44, 117-178.

12.4. Документация пользователя программного обеспечения/Стандарт ANSI/IEEE 1063-1987.

Лекция 13. ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ

13.1. Документация, создаваемая в процессе разработки программных средств.

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

Эту документацию можно разбить на две группы [13.1]:

Документы управления разработкой ПС.

Документы, входящие в состав ПС.

Документы управления разработкой ПС (process documentation), протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами (managers) - лицами, управляющими разработкой. Эти документы могут быть следующих типов [13.1]:

Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения.

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

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

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

Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.

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

Пользовательская документация ПС (П-документация).

Документация по сопровождению ПС (С-документация).

13.2. Пользовательская документация программных средств.

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

В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС. Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью ПС. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными пользователями, поддерживать связь с поставщиками ПС или выполнять определенные действия, чтобы поддерживать ПС в рабочем состоянии, если оно включено как часть в другую систему.

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

В соответствии с работами [13.1, 13.2] можно считать типичным следующий состав пользовательской документации для достаточно больших ПС:

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

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

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

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

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

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

13.3. Документация по сопровождению программных средств.

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

Документация по сопровождению ПС можно разбить на две группы:

(1) документация, определяющая строение программ и структур данных ПС и технологию их разработки;

(2) документацию, помогающую вносить изменения в ПС.

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

Внешнее описание ПС (Requirements document).

Описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы.

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

Для каждого модуля - его спецификация и описание его строения (design description).

Тексты модулей на выбранном языке программирования (program source code listings).

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

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

Документация второй группы содержит

Руководство по сопровождению ПС (system maintenance guide), которое описывает известные проблемы вместе с ПС, описывает, какие части системы являются аппаратно- и программно-зависимыми, и как развитие ПС принято в расчет в его строении (конструкции).

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

Литература к лекции 13.

13.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.

13.2. ANSI/IEEE Std 1063-1988, IEEE Standard for Software User Documentation.

13.3. ANSI/IEEE Std 830-1984, IEEE Guide for Software Requirements Specification.

13.4. ANSI/IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Description.

13.5. ANSI/IEEE Std 1008-1987, IEEE Standard for Software Unit Testing.

13.6. ANSI/IEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans.

13.7. ANSI/IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.

13.8. ANSI/IEEE Std 829-1983, IEEE Standard for Software Test Documentation.

Лекция 14. АТТЕСТАЦИЯ ПРОГРАММНОГО СРЕДСТВА

Назначение аттестации программного средства. Испытания и оценка качества программного средства. Виды испытаний и методы оценки качества программного средства.

14.1. Назначение аттестации программного средства.

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

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

14.2. Виды испытаний программного средства.

Известны следующие виды испытаний ПС [14.2,14.3], проводимых с целью аттестации ПС:

испытания компонент ПС;

системные испытания;

приемо-сдаточные испытания;

полевые испытания;

промышленные испытания.

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

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

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

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

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

14.3. Методы оценки качества программного средства.

Оценка качества ПС по каждому из критериев сводится к оценке каждого из примитивов, связанных с этим критерием качества ПС, в соответствии с их конкретизацией, произведенной в спецификации качества этого ПС [12.4]. Методы оценки примитивов качества ПС можно разделить на четыре группы:

непосредственное измерение показателей примитива качества;

обработка программ и документации ПС специальными программными инструментами (процессорами);

тестирование программ ПС;

экспертная оценка на основании изучения программ и документации ПС.

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

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

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

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

Литература к лекции 14.

14.1. Г.Майерс. Надежность программного обеспечния. - М.: Мир, 1980. - С. 174-175.

14.2. В.В.Липаев. Тестирование программ. - М.: Радио и связь, 1986. - С. 231-245.

14.3. Д.Ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. - С. 281-283.

14.4. Б.Шнейдерман. Психология программирования. - М.: Радио и связь, 1984. - С. 99-127.

Лекция 15.ОЪЕКТНЫЙ ПОДХОД К РАЗРАБОТКЕ ПРОГРАММНЫХ СРЕДСТВ

15.1. Объекты и отношения в программировании. Сущность объектного подхода к разработке программных средств.

Окружающий нас мир состоит из объектов и отношений между ними [13.1]. Объект воплощает некоторую сущность и имеет некоторое состояние, которое может изменяться со временем как следствие влияния других объектов, находящихся с данным в каком-либо отношении. Он может иметь внутреннюю структуру: состоять из других объектов, также находящихся между собой в некоторых отношениях. Исходя из этого можно построить иерархическое строение мира из объектов. Однако, при каждом конкретном рассмотрении окружающего нас мира некоторые объекты считаются неделимыми ("точечными"), причем в зависимости от целей рассмотрения такими (неделимыми) могут приниматься объекты разного уровня иерархии. Отношение связывает некоторые объекты: можно считать, что объединение этих объектов обладает некоторым свойством. Если отношение связывает n объектов, то такое отношение называется n-местным (n-арным). На каждом месте объединения объектов, которые могут быть связаны каким-либо конкретным отношением, могут находиться разные объекты, но вполне определенные (в этом случае говорят: объекты определенного класса). Одноместное отношение называется свойством объекта (соответствующего класса). Состояние объекта может быть изучено по значению свойств этого объекта или неявно по значению свойств объединений объектов, связываемых вместе с данным тем или иным отношением.

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

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

При исследовании модельного мира пользователь может по-разному получать (или захотеть получать) информацию от компьютера. При одном подходе его могут интересовать получение информации об отдельных свойствах интересующих его объектов или результатах какого-либо взаимодействия между некоторыми объектами. Для этого он заказывает разработку того или иного ПС, выполняющего интересующие его функции, или некоторую информационную систему, способной выдавать информацию об интересующих его отношениях, используя при этом соответствующую базу данных. В начальный период развития компьютерной техники (при не достаточно высокой мощности компьютеров) такой подход к использованию компьютеров был вполне естественным. Именно он и провоцировал функциональный (реляционный) подход к разработке ПС, который был подробно рассмотрен в предшествующих лекциях. Сущность этого подхода состоит в систематическом использовании декомпозиции функций (отношений) для построения структуры ПС и текстов программ, входящих в него. При этом сами объекты, к которым применялись заказываемые и реализуемые функции, представлялись фрагментарно (в том объеме, который необходим для выполнения этих функций) и в форме, удобной для реализации этих функций. Тем самым не обеспечивалось цельного и адекватного компьютерного представления модельного мира, интересующего пользователя: отображение его на используемые ПС могло оказаться для пользователя достаточно трудоемкой задачей, попытки незначительного расширения объема и характера информации об интересующем пользователя модельном мире. получаемой от таких ПС, могло привести к серьезной их модернизации. Такой подход к разработке ПС поддерживается большинством используемых языков программирования, начиная от языков ассемблеров и процедурных языков (ФОРТРАН, Паскаль) до функциональных языков (ЛИСП) и языков логического программирования (ПРОЛОГ).

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

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

15.2. Объекты и субъекты в программировании.

15.3. Объектный и субъектный подходы к разработке программных средств.

Декарт отмечал, что люди обычно имеют объектно-ориентированный взгляд на мир ([29] в [13.3]).

Считают, что объектно-ориентированного проектирование основано на принципах [13.3, стр. 31]:

выделение абстракций,

ограничение доступа,

модульность,

иерархия,

типизация,

параллельность,

устойчивость.

Но все это может применяться и при функциональном подходе.

Следует различать достоинства и недостатки общего объектного подхода и его частного случая - субъектно-ориентированного подхода.

Достоинства общего объективного подхода:

Естественное отображение реального мира на строение ПС (естественное восприятие человеком возможностей ПС, не нужно "выдумывать" строение ПС, а использовать естественные аналогии).

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

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

15.4. Объектный подход к разработке внешнего описания и архитектуры программного средства.

Объектно-ориентированное проектирование - метод, использующий объектную декомпозицию; объектно-ориентированный подход имеет свою систему условных обозначений и предлагает богатый набор логических и физических моделей для проектирования систем высокой степени сложности. [13.3, стр. 30].

.....На объектный подход оказал объектно-ориентированный анализ (ООА). ООА направлен на создание моделей, более близких к реальности, с использованием объектно-ориентированного подхода; это методология, при которой требования формируются на основе понятий классов и объектов, составляющих словарь предметной области. [2, стр.42].

Особенности объектно-ориентированного программирования.

Объекты, классы, поведение объекта, свойства, события.

Литература к лекции 15.

15.1. К. Фути, Н. Судзуки. Языки программирования и схемотехника СБИС. - М.: Мир, 1988. С. 85-98.

15.2. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P. ?-?

15.3. Г.Буч. Объектно-ориентированное проектирование с примерами применения: пер. с англ. - М.: Конкорд, 1992.

15.4. В.Ш.Кауфман. Языки программирования. Концепции и принципы. М.: Радио и связь, 1993.

Страницы: 1, 2, 3, 4, 5, 6