Тема 1.1. ОСОБЕННОСТИ СОЗДАНИЯ ПРОГРАММНОГО ПРОДУКТА.  

1.1.1 Программа как формализованное описание процесса обработки данных. Программное средство.

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

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

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

 

 ИСТОРИЧЕСКИЙ И СОЦИАЛЬНЫЙ КОНТЕКСТ ПРОГРАММИРОВАНИЯ

 

Тема 1.1.2. Критерий оценки качества программного обеспечения.

 

            Разработка программного обеспечения - это, прежде всего, нахождение способов получения качественного программного продукта. Что мы подразумеваем, когда мы говорим о "качестве" программного обеспечения? Качество программного обеспечения может измеряться во внешних характеристиках (например, легкий в использовании, выполняется быстро) или во внутренних характеристиках (например, модульная конструкция, читабельный код). Внешние метрики - единственные, которые, в конце концов, действительно имеют значение. Никто, на самом деле, не заботится, насколько хорошую модульную конструкцию вы использовали при создании программы. Всех только заботит, чтобы она хорошо выполнялась. Однако, внутренняя (скрытая) метрика является ключом к созданию внешних, и при этом необходимо учитывать правила конструирования программ и технику программирования. В таблице 1 приводится список наиболее общих внешних факторов, найденных в качественном программном обеспечении. Более подробно некоторые из них будут рассмотрены ниже.

 

Таблица 1.

Характеристики качества программного обеспечения

 

 

 

Корректность и устойчивость

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

 

 

Расширяемость

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

·                     Простота проекта. Более простые проект и архитектура позволяют произвести изменения намного быстрее и легче, чем при сложном проекте.

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

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

Многократность (повторность) использования и совместимость

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

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

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

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

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

 

 

Характеристика качества ПИ

 

 

 

Понятность – легкость понимания документации, сопровождающей ПИ.

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

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

Характеристики понятности:

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

Открытость ПИ – дает возможность понять назначение каждого оператора ПИ при чтении ее текста, т.е. каждый из идентификаторов должен нести смысловую нагрузку, например, SUM= CENA*KOL.

Согласованность ПИ – бывает внутренняя и внешняя.

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

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

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

1.                 а) линейная структура    б) условный переход                 в) цикл

    (или последовательная).        

S1

                                                                             Да         Нет                               

S2

S1

                                                                                        условия                                                            условие                      

S2

                                                                 

 

 

 

 

 

 

2.                 Подробное комментирование текста программ.

3.                 Использование модульного программирования (отдельная программная единица).

4.                  Ограничение на объем модулей (количество операторов).

 

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

Она характеризуется:

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

Например, независимые ПИ:

–           отсутствие в нем одного из модулей (нет перехода с года на год, нет перехода с века на век);

–           некомплектная документация (т.е. нет документа целиком, либо  раздела в документе).

 

Точность -  характеристика, определяющая точность результатов расчета в соответствии с их назначением.

            Например: если ведутся расчеты банковским операциям, то разумная точность – 3 знака после запятой, с последующим округлением до 2 знаков. Если в программе производятся расчеты по биологическим экспериментам, на молекулярном уровне, то точность по 10-12 знаков после запятой.

            4. Эффективность – выполнение требуемых функций при минимальных затратах ресурсов. Причем под ресурсами подразумевается: объем оперативной памяти, время работы процессора, объем внешней памяти, пропускная способность канала.

            Часто характеристика эффективности вступает в противоречие с другими характеристиками качественного ПИ.

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

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

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

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

            Человеческий фактор: (сервис)

1.      Легкость использования ПИ.

2.      ПИ должно удовлетворять требованиям пользователя.

3.      ПИ должно реализовывать потенциальные потребности пользователя.

4.      Необходимо при разработке ПИ следовать золотому правилу: относить к людям так же, как бы ты хотел, чтобы относились к тебе.

Мобильность – возможность работы ПИ в различных ОС.

Качество оформления исходных текстов

 

1.1.2. Неконструктивность понятия правильной программы.

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

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

1.1.3. Надежность программного средства.

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

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

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

1.1.4. Технология программирования как технология разработки надежных программных средств.

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

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

 

1.1.5. Критерии надежности программ.

 

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

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

·        искажения исходной информации, поступающей от внешних абонентов;

·        самоустраняющиеся отказы или сбои в аппаратуре ЭВМ;

·        не выявленные ошибки в программах.

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

Первопричинами искажений данных, поступающих от внеш­них абонентов, могут быть:

·        искажения данных на первичных носителях информации при их подготовке;

·        сбои и частичные отказы в аппаратуре ввода данных с пер­вичных носителей информации;

·        шумы и сбои в каналах связи при передаче сообщений по телекодовым линиям связи;

·        сбои и частичные отказы в аппаратуре передачи или приема телекодовой информации;

·        потери или искажения сообщений в ограниченных буферных накопителях ЭВМ;

·        ошибки в документах, используемых для подготовки данных, вводимых в ВС.

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

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

 

 

 

Содержание