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

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

• Документы управления разработкой ПС.
• Документы, входящие в состав ПС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таким образом, структуру внешнего описания ПС можно выразить формулой:

Внешнее описание ПС = спецификация качества ПС + функциональная спецификация ПС

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

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

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

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

Известны три способа определения требований к ПС :

• управляемый пользователем,
• контролируемый пользователем,
• независимый от пользователя.

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

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

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

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

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

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

Функциональность: завершенность.

Надежность: завершенность, точность, автономность, устойчивость, защищенность.

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

Эффективность: временнaя эффективность, эффективность по памяти, эффективность по устройствам.

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

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

Модифицируемость: расширяемость, структурированность, модульность.

Мобильность: независимость от устройств, автономность, структурированность, модульность.

Ниже даются определения используемых примитивов качества ПС [4.3-4.5].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестирование программного обеспечения охватывает целый ряд видов деятельности, аналогичных последовательности процессов разработки программного обеспечения. В него входят/1:

а) постановка задачи для теста,

б) проектирование теста,

в) написание тестов,

г) тестирование тестов,

д) выполнение тестов,

е) изучение результатов тестирования.

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

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

Альтернатива ‘черный ящик’ – ‘белый ящик’ является достаточно общей, что подтверждается ее применением не только при тестировании, но, например, в альтернативных направлениях исследований в области искусственного интеллекта.

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

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

Это необходимое, но недостаточное условие для приемлемого тестирования по принципу белого ящика.

В этой программе можно выполнить каждый оператор, записав один единственный тест, который реализовал бы путь ace. Т.е., если бы на входе было: А=2, В=0, Х=3, каждый оператор выполнился бы один раз. Но этот критерий на самом деле хуже, чем он кажется на первый взгляд. Пусть в первом условии вместо “and”®“or” и во втором вместо “x>1”®“x<1” (блок-схема правильной программы приведена на рисунке 15.2, а неправильной – на рисунке 15.3). Результаты тестирования приведены в таблице 15.1.  Обратите внимание: ожидаемый результат определяется по алгоритму на рисунке 15.2, а фактический – по алгоритму рисунка 15.3, поскольку определяется чувствительность метода тестирования к ошибкам программирования. Как видно из этой таблицы, ни одна из этих ошибок не будет обнаружена .

Таблица 15.1 – Результат тестирования методом покрытия операторов

Метод покрытия решений (покрытия переходов)

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

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

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

Для программы приведенной на рисунке 15.3 покрытие решений может быть выполнено двумя тестами, покрывающими пути {ace, abd}, либо {aсd,abe}. Пути {aсd,abe}покроим, выбрав следующие исходные данные: {A=3, B=0, X=3} и {A=2, B=1, X=1} (результаты тестирования – в таблице 15.2).

Таблица 15.2 – Результат тестирования методом покрытия решений

Метод  покрытия условий

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

В предыдущем примере имеем четыре условия: {A>1, B=0}, {A=2, X>1}. Cледовательно, требуется достаточное число тестов, такое, чтобы реализовать ситуации, где A>1, A£1, B=0 и B¹0 в точке а и A=2, A¹2, X>1 и X£1 в точке В. Тесты, удовлетворяющие критерию покрытия условий и соответствующие им пути:

а) A=2, B=0, X=4                  ace

б) A=1, B=1, X=0                  abd

Таблица 2.3 – Результаты тестирования методом покрытия условий

Критерий решений (условий)

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

Два теста метода покрытия условий

а) A=2, B=0, X=4                  ace

б) A=1, B=1, X=0                  abd
отвечают и критерию покрытия решений/условий. Это является следствием того, что одни условия приведенных решений скрывают другие условия в этих решениях. Так, если условие А>1 будет ложным, транслятор может не проверять условия В=0, поскольку при любом результате условия В=0, результат решения ((А>1)&(В=0)) примет значение ложь. Следовательно, недостатком критерия покрытия решений/условий является невозможность его применения для выполнения всех результатов всех условий.

Другая реализация рассматриваемого примера приведена на рисунке 15.4. Многоусловные решения исходной программы разбиты на отдельные решения и переходы. Наиболее полное покрытие тестами в этом случае выполняется так, чтобы выполнялись все возможные результаты каждого простого решения. Для этого нужно покрыть пути HILP (тест А=2,В=0,Х=4), HIMKT (тест А=3, В=1, Х=0), HJKT (тест А=0, В=0, Х=0), HJKR (тест А=0, В=0, Х=2)..

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

Метод эквивалентного разбиения

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

а) каждый тест должен включать столько различных входных условий, сколько это возможно, с тем чтобы минимизировать общее число тестов;

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

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

Разработка тестов методом эквивалентного разбиения осуществляется в два этапа:

а) выделение класса эквивалентности;

б)построение тестов.

Выделение классов эквивалентности

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

Таблица 15.5 – Заголовок таблицы для определения классов эквивалентности

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

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

- если входное условие описывает область значений, например, “целое данное может принимать значения от 1 до 999, то определяется один правильный класс эквивалентности (1£значение целого данного £ 999) и два неправильных (значение целого данного<1 и значение целого данного>999);

- если входное условие описывает число значений, например, “в автомобиле могут ехать от одного до шести человек”, то определяется один правильный класс эквивалентности и два неправильных (ни одного и более 6 человек);

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

- если входное условие описывает ситуацию “должно быть” (например, “первым символом идентификатора должна быть буква”), то определяется один правильный класс эквивалентности (первый символ – буква) и один неправильный (первый символ – не буква);

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

Построение тестов

Этот процесс включает в себя:

- назначение каждому классу эквивалентности уникального номера;

- проектирование новых тестов, каждый из которых покрывает как можно большее число непокрытых правильных классов эквивалентности, пока все правильные классы эквивалентности не будут покрыты тестами;

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

Метод анализа граничных значений

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

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

Анализ граничных значений отличается от эквивалентного разбиения в двух отношениях:

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

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

Метод анализа граничных значений требует творческого подхода и специализации. Приведем несколько общих правил этого метода /1/.

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

Пример: если правильная область входных значений есть -1.0 ¸ 1.0, то следует написать тесты для ситуаций: -1.0; 1.0; -1.001; 1.001.

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

Пример: если входной файл может содержать от 1 до 255 записей, то построить тесты для 0; 1; 255; 256 записей.

Использовать правило 1 для каждого входного условия.

Пример: Программа вычисляет ежемесячный расход. Минимум расхода составляет 0.00, а максимум – 1165.25 (усл. ед.). Нужно построить тесты для отрицательного расхода и расхода, большего 1165.25.

Важно проверить границы пространства результатов, поскольку не всегда границы входных областей представляют такой же набор условий, как и границы выходных областей. Пример: y=sin(x); xÎ[0;p]

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

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

Пример: система информационного поиска отображает на экране терминала наиболее релевантные рефераты в зависимости от входного запроса, но никак не более четырех рефератов. Тесты:

1. программа отображает ноль рефератов
2. - один
3. - четыре
4. - пять (ошибочная ситуация)

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

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

Тестирование модульных программ

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

Наиболее распространенным приемом тестирования модульных программ является пошаговое тестирование /1/. На практике применяют две его разновидности:

n восходящее тестирование;

n нисходящее тестирование.

Методика восходящего тестирования включает следующие щаги:

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

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

б) затем аналогично тестируются модули вышележащего уровня совместно с уже оттестированными модулями нижележащего уровня. Применительно к рассматриваемому нами примеру проектируются драйверы для тестирования пар B-E и D-F;

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

Альтернативное нисходящее тестирование состоит из следующих действий:

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

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

в) процесс тестирования продолжается до тех пор, пока не будет оттестирован последний модуль из ‘листьев’ дерева структуры программы.  Приведем две возможные последовательности тестирования модулей согласно этой методики для рассматриваемого примера:

n A (B,C,D), A-B (E), A-B-E, A-C, A-D (F), A-D-F;

n A (B,C,D), A-B (E), A-C, A-D (F), A-B-E, A-D-F.

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

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

Отладка

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

Из всех этапов проектирования логики программных модулей этап отладки является наименее формализованным. В нем выделяют две задачи:

n определение природы ошибки;

n исправление ошибки.

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

Наиболее распространенными и наименее эффективными для отладки являются так называемые методы ‘грубой силы’. К ним относят:

n отладку с использованием дампа памяти;

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

n отладку с использованием автоматических средств.

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

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

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

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

n метод индукции;

n метод дедукции.

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

Метод индукции включает:

1) определение данных тестирования, имеющих отношение к ошибке;

2) анализ от частного к общему позволит выявить закономерности в данных пункта 1);

3) в результате анализа (п.2) выдвигается гипотеза о причине ошибки;

4) для подтверждения гипотезы 3 разрабатывается один или больше тестов, которые должны либо подтвердить, либо опровергнуть гипотезу;

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

Альтернативный метод дедукции заключается в:

1) перечисление возможных причин или гипотез:

2) использование данных тестирования для исключения некоторых возможных причин;

3) уточнение выбранной наиболее вероятной гипотезы, возможно с использованием дополнительных тестов:

4) доказательство выбранной гипотезы совпадает с п.4 и п.5 метода индукции.

Ниже приводятся рекомендации по организации отладки в форме заповедей

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

Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных.

Заповедь 4. Избегайте невоспроизводимых тестов, документируйте их пропуск через компьютер; детально изучайте результаты каждого теста.

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

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Метод таблиц решений базируется на использовании таблиц следующего вида (см. табл. 12.1).

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

Табл. 12.1. Общая схема таблиц решений.

Нижняя часть таблицы решений определяет действия, которые требуется выполнить в той или иной ситуации, определяемой в верхней части таблицы решений. Она также состоит из нескольких (k) строк, каждая из которых связана с каким-либо одним конкретным действием, указанным в первом поле (столбце) этой строки. В остальных полях (столбцах) этой строки (т.е. для u[i, j], i=1, … m+1, j=1, … k) указывается, следует ли выполнять (u[i, j]= ‘+’) это действие в данной ситуации или не следует (u[i, j]= ‘-’). Таким образом, первый столбец нижней части этой таблицы представляет собой список обозначений действий, которые могут выполняться в той или иной ситуации, определяемой этой таблицей. В каждом следующем столбце этой части указывается комбинация действий, которые следует выполнить в ситуации, определяемой в том же столбце верхней части таблицы решений. Для ряда таблиц решений эти действия могут выполняться в произвольном порядке, но для некоторых таблиц решений этот порядок может быть предопределен, например, в порядке следования соответствующих строк в нижней части этой таблицы.

Рис. 12.2. Таблица решений “Светофор у пешеходной дорожки”.

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

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

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

б) если буфер формируемой строки заполнен, то подать звуковой сигнал и вернуть код ошибки;

в) если очередной символ не находится в заданном диапазоне, (положим, от ‘а’ до ‘я’), то подать звуковой сигнал и вернуть код ошибки;

г) иначе поместить символ в буфер, увеличить значение счетчика выбранных символов и вернуть новое значение счетчика.

Таблица решений для данного примера приведена ниже ( таблица 1.1).

Здесь ‘Д’ означает  ‘да’, ‘Н’ – ‘нет’, 1,2 – помеченные действия выполняются в указанном порядке.

Таблица 12.3 – ТР для функции выбора символов из входного потока

Заметим, что если выполняется условие С1, то нет необходимости в проверке условий С2 и С3. Поэтому комбинации условий 1,2,3,4 могут быть заменены обобщающей комбинацией (Д, -,  -), где ‘-’ означает любую из возможных альтернатив (в данном случае Д или Н).

Аналогично комбинации условий 5 и 6 могут быть заменены обобщающей комбинацией  (Н, Д, -). Редуцированная таким образом ТР будет иметь вид таблицы 12.4.

Таблица 12.4 Редуцированная ТР

• изучение и проверка спецификации модуля, выбор языка  программирования;
• выбор алгоритма и структуры данных;
• программирование модуля;
• шлифовка текста модуля;
• проверка модуля;
• компиляция модуля.

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

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

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

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

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

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

6.3. Пошаговая детализация и понятие о псевдокоде.

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

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

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

Цель структурного программирования – разработка программы, которой присуща определенная структура, основанная на применении принципов структурного программирования.

Перечислим эти принципы:

1. Каждый программный модуль (блок, функция, процедура) должен иметь только один вход и один выход.

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

1. В программах рекомендуется применять  4 типа конструкций:

а)  последовательность (модулей, операторов)

б)  разветвление (условный оператор)

Перечеркивание означает, что Q может отсутствовать.

в)  цикл

1)       с предусловием

2)       с постусловием

г)  выбор из нескольких альтернатив (или переключатель)

3)        разработку программ рекомендуется вести сверху – вниз или по нисходящей стратегии.

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

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

Объектно-ориентированный стиль программирования основан на объектном моделировании задачи. Здесь происходит поворот “от процедуры и от структур данных к объекту”, представляющему собой целостную модель и естественную имитацию деятельности некоторого элемента реального мира. Он во многом снимает недостатки предшествующих стилей программирования, обеспечивает компактность текстов и кодов программ, устойчивость и эволюционное развитие программ через видовую специализацию программных объектов без их изменения и позволяет преодолеть новый уровень сложности разрабатываемых систем. Следует отметить, что этот стиль является логическим продолжением развития процедурно- и потоко-ориентированного программирования, получившего широкое распространение в начале 90-х годов.

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

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

Понятия ООП

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

ПЕРЕМЕННАЯ         ТИП           ПРОЦЕДУРА         ВЫЗОВ ПРОЦЕДУРЫ

ОБЪЕКТ                КЛАСС        МЕТОД                    СООБЩЕНИЕ

Итак, ООП – это подход, в котором данные и поведение (методы обработки данных) жестко связаны. Данные и поведение представлены в виде классов, экземпляры которых – объекты. ООП позволяет пользователю вводить собственные типы данных, расширяя тем самым набор встроенных в язык типов данных.

Основными свойствами ООП являются инкапсуляция, наследование и полиморфизм.

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

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

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

Сокрытие данных обеспечивается ключевым словом class и ключевыми словами, связанными с правами доступа: public, private и protected. Класс - это способ инкапсуляции типов данных и связанных с ними функций. Разрешение частной (private) и общей (public) видимости для членов класса дает программисту возможность управлять тем, какие части структуры данных будут модифицируемы. Private части скрыты от кода пользователя, a public – доступны. Члены класса со статусом доступа protected занимают промежуточное положение: они доступны как внутри класса, так и во всех производных от него классах.

Достоинства и недостатки ООП

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

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

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

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

• Инкапсуляция информации защищает наиболее критичные данные от несанкционированного доступа.

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

Что в теории понимается под модулем?

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

Модуль – это программа, обладающая тремя основными атрибутами:

1. 1. он выполняет одну или несколько функций;
2. 2. модуль реализует некоторую логику (алгоритм).
3. 3. используется в одном или нескольких контекстах.

При этом функция – это то, что делает модуль, а не то, как он это делает. А вот логика характеризует, как модуль выполняет свои функции. Контекст описывает конкретное применение.

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

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

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

б) ослабление взаимосвязи между модулями (иначе этот принцип называется ослаблением сцепления модулей).

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

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

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

Однако на практике при реализации больших проектов процедуры и функции оказываются недостаточно удобным средством по следующим причинам:

•  большой объем текста программы затрудняет ее понимание;

•  всякий раз после изменения программы ее необходимо перекомпилировать, затрачивая определенное время;

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

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

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

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

Формально язык программирования — это открытое для пополнения множество текстов, записанных с помощью некоторого набора символов — алфавита языка

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

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

В случае языков программирования:

Синтаксис языков программирования — это совокупность требований, которым должна удовлетворять любая осмысленная программа

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

Простые значения — это числа, логические значения, литеры и ссылки. Типы простых значений часто называют простыми типами. В некоторых языках встречаются н другие простые типы.

Числа

Принято различать два основных типа чисел: целые и так называемые вещественные.

Целое – множество целых чисел в диапазоне разрядной сетки ЭВМ.

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

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

Для хранения целого числа в памяти ЭВМ выделяется фиксированное количество двоичных позиций .

Используется в ЭВМ формат представления чисел с фиксированной точкой, при этом представляется, что точка фиксирована после самого младшего разряда числа.

Действительные числа – множество вещественных чисел в диапазоне их представления в разрядной сетке ЭВМ.

В ЭВМ точность представления действительного числа является ограниченной из-за конечности (ограниченности) разрядной сетки ЭВМ. Так, число 0.1 в ЭВМ представляется неточно, так как его двоичное представление является бесконечной дробью.

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

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

X = M * E P ,

где М- мантисса со знаком, /М/>1,

Е- фиксированное основание (для десятичных чисел Е= 10, в ЭВМ чаще используется  основание 16, но может быть и 2 или 8, во всяком случае, кратное 2).

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

Опишем  синтаксис  обозначений,  принятый  в  –«Паскале».  Далее:

Логические значения

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

Тип логический или BOOLEAN характеризуется тем, что может принимать два значения “истина” или “ ложь”. В разных языках программирования эти два логических значения могут записываться по разному. Например, в Паскале это true и false.

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

Типовыми операциями над этими данными является конъюнкция (и), дизъюнкция (или), отрицание (не). Часто в языках программирования используются и более сложные логические операции: исключающее или, импликация, эквивалентность. Кроме того, логическое значение является результатом выполнения операций (<, £, >, ³,  =, ¹) над целыми и вещественными числами, символьными и другими данными, над которыми эти операции имеют смысл.

Литеры и строки

Символьный тип (или данное типа строка) включает множество символов или литер, доступных в конкретной ЭВМ.

В ЭВМ символы представляются в двоичном коде. Эти коды упорядочены и для каждого символа может быть определен соответствующий ему порядковый номер.

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

Значения  из  доступного  набора  литер  относятся  к  типу  литерный. Это  еще  не  тексты,  а  только  знаки:  из  которых  составляются  тексты  —  конечные  последовательности  литер,  называемые  обычно  строками или  цепочками. Строки  иногда  причисляют  к  простым  значениям  (типа  строковый},  иногда  -  к  составным.

Ссылочный тип данных. Динамические объекты.

Тип указатель (или POINTER) представляет собой множество адресов данных в пределах объема памяти ОЗУ (количество адресуемых байтов, слов).

1. Природа динамических объектов и способы их реализации.

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

Существуют задачи, для которых характерно наличие данных: – фактическое появление которых возможно, но не обязательно; – время жизни этих объектов меньше времени исполнения программы. Такие объекты называют динамическими объектами.

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

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

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

Значение ссылочной переменной, соответствующее отсутствию динамического объекта – nil (зарезервированное слово).

Составные  значения  и  их  типы

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

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

Структуру данных можно определить, как

S=(D,R),

где D- множество элементов данных, R-множество отношений (связей) между элементами данных.

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

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

к-мерным массивом называется конечное упорядоченное множество (к-1) мерных массивов, все элементы которых принадлежат одному и тому же типу. При к=1 получаем вектор.

Записи

Следующий  способ  образования  составных  значений  –  это  объединение  некоторого  фиксированного  числа  k значений,  возможно,  различных,  но  также  фиксированных  типов  <тип1>,.,.  ,  <тии2>,  в  одно.  Такое  объединение  принято  называть  записью (реже  структурой),  а. объединяемые  значения  —  полями этой  записи.  Чтобы  можно  было  выделять  из  записи  отдельные  поля,  они  снабжаются  индивидуальными  наименованиями  -  идентификаторами  полей, которые  входят  в  обозначение  типа  записи:

<тип  записи> ::= record  <список полей> end

<список  полей>  ::= <идентификатор>:<тип>

|  <список  полей>;  <идентификатор>:<тип>

Классический  пример  типа  записи  —  тип  комплексного  числа,  имеющий  обозначение

record re  :  real;  irn.  : real  endrec

Тип  записи  для  календарной  даты  может  быть  таким:

record day  : byte; month: string [8]:  year  : word  endrec

Определения этих структур данных основаны на понятии списка или списковой структуры.

Списком называется линейно-упорядоченная последовательность элементов данных E(1),E(2)…E(n),  где n>0,причем каждый элемент E(i) характеризуется одним и тем же набором полей. Такой список называют линейным списком из-за линейной упорядоченности элементов. Упорядоченность элементов списка может быть задана неявно путем последовательного расположения его элементов как в логической структуре, так и в памяти ЭВМ (т.е физической структуре данных). Список с таким неявным заданием упорядоченности в логической и физической структурах называют еще последовательным линейным списком. С другой стороны, упорядоченность может задаваться явно путем помещения в каждом элементе E(i) указателей или связок, в которых помещается адрес последующего или предыдущего элемента списка. Такие списки называют связными списками и о них мы буде мы говорить позже.

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

Стек – такой последовательный линейный список с переменной длиной, включение и исключение элементов из которого выполняется только с одного конца списка. Известно и другое название стека – магазин. Иногда стек называют еще очередью, функционирующей по принципу LIFO (Last- In-First- Out –последним пришел – первым вышел).

Логическая структура стека

Физическая структура стека может быть изображена следующим образом:

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

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

Очередь – такой последовательный список с переменной длиной, включение элементов в который происходит с одной стороны, а исключение с другой стороны списка.

Очередь функционирует по принципу – FIFO (First-In-First-Out-первым пришел, первым вышел).

Для индикации начала и конца очереди организуются 2 указателя: схема простейшей очереди будет следующая:

Из схемы следует: для очереди выделяется фиксированный участок памяти ЭВМ, в котором, как правило, заняты в каждый момент времени лишь некоторые слоты. Указатель P1 является адресом первого (начального), слота очереди, P2 – адресом первого свободного слота очереди.

При включении в очередь вносится по адресу P2, затем значение указателя P2 изменяется (передвигается на 1 элемент очереди), т.е. значение P2 увеличивается на длину элемента очереди.

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

Динамическая структура имеет следующие основные признаки:

1.     Непостоянство и непредсказуемость размера (числа элементов) структуры в процессе ее обработки.

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

Часто динамические структуры физически представляются в форме связных списков.

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

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

Æ -пустой указатель, означает конец списка.

Физическая структура списка может быть такой :

Включение списка и исключения элемента из списка осуществляется путем корректировки указателей.

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

В этом случае значение L2 записывается в поле указателя включаемой записи значение поля указанной записи, после которого включается новый элемент, изменяется на LN   ,Þ,окончательная логическая структура будет следующей:

Исключение из списка может быть так:

В этом случае поле указателя записи, после которого удаляется элемент изменяется на значение адреса, следующего за исключаемым элемента списка (L2®L3). Оконченная логическая структура обновленного списка:

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

Функции.

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

Описание функции.

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

<описание функции>::=<заголовок функции>;<блок>

<заголовок функции>::=function <имя функции>

[(<список формальных параметров>)] :<имя типа>.

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

1. для определения типа выражения, надо знать типы операндов;
2. для контроля правильности использования функции в программе.

Подобно процедуре, тело функции – блок. Как же определить какой из результатов, получаемых в теле функции – значение функции? Для этого в теле функции обязательно должен быть хотя бы один выполняемый оператор присваивания вида <имя функции>:=<выражение>.

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

Стадия разработки (development) ПС состоит из

• этапа его внешнего описания,
• этапа конструирования ПС,
• этапа кодирования (программирование в узком смысле) ПС,
• этапа аттестации ПС.

Всем этим этапам сопутствуют процессы документирования и управление (management) разработкой ПС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данные - это представление фактов и идей в формализованном виде, пригодном для передачи и переработке в некоем процессе,

информация - это смысл, который придается данным при их представлении.

Обработка данных - это выполнение систематической последовательности действий с данными.

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

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

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

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

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

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

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

Природа профессионализма такова, что чем он выше, тем он уже.

Выделим основные функции профессиональных программистов .

• Разработка систем большого объема. Профессионалы знают, что “выход за некоторую границу сложности создаваемого программного продукта без надлежащей технологии разработки вообще невозможен”.
• Создание системного и инструментального программного обеспечения, которым будут пользоваться остальные. Профессиональными программистами создается инструментальное обеспечение в большом диапазоне – от профессионального до массового.
• Разработка программного продукта с предъявлением особых требований к его качеству и эффективности. Различные требования предъявляются к программам, создаваемым только для себя, и к программам, предназначенным для большого количества пользователей. Во втором случае любая неаккуратность и малейшая небрежность может повториться многократно в работах будущих пользователей.
• Разработка программ на основе подхода открытых систем. Открытая система (open system) – система, которая состоит из компонентов, взаимодействующих друг с другом через стандартные интерфейсы. Общие свойства открытых систем таковы:
• мобильность (переносимость) кода. Мобильность дает возможность легко переносить программное обеспечение на различные архитектурные и операционные платформы;
• интероперабельность. Дает возможность легко осуществить обмен данными и взаимодействие с прикладными задачами в других системах;
• соответствие стандартам. После того как стандарт принят, он становится силой, помогающей двигаться вперед. Как это ни парадоксально, но следование канонам дает новые степени свободы в современном мире.

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

Программа – завершенный продукт, пригодный для запуска своим автором на системе, на которой он был разработан.

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

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

Алгоритм - точное и конечное описание того или иного общего метода, основанного на применении исполнимых элементарных тактов обработки.

Компьютер – вычислитель, он не понимает программу, а исполняет ее. Наиболее естественный способ указать компьютеру ход исполнения программы – записать ее в виде алгоритма (на алгоритмическом языке). Современное значение слова “алгоритм” во многом аналогично таким понятиям, как рецепт, процесс, метод, способ. Алгоритм имеет пять важных свойств .

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

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