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

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

31. Отладка П.О. - это деятельность, направленная на обнаружение и ис-правление ошибок в П.О. с использованием процессов выполнения его про-грамм. Тестирование П.О. - это процесс выполнения его программ на некото-ром наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных назы-вается тестовым или просто тестом. Таким образом, отладку можно пред-ставить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в П.О. ошибки, по-иска места ошибки в программах и документации П.О. и редактирования про-грамм и документации с целью устранения обнаруженной ошибки. Другими словами: Отладка = Тестирование + Поиск ошибок + Редактирование В зарубежной литературе отладку часто понимают только как процесс поиска и исправления ошибок (без тестирования), факт наличия которых ус-танавливается при тестировании. Иногда тестирование и отладку считают синонимами. В нашей стране в понятие отладки обычно включают и тести-рование, поэтому мы будем следовать сложившейся традиции.  Тестирование – процесс многократного повторения программы с це-лью обнаружения ошибок. Тестирование – составная часть отладки.  Отладка имеет место тогда, когда программа со всей очевидностью работает неправильно. Поэтому отладка начинается всегда в предвидении отказа программы. Если же оказывается, что программа работает верно, то она тестируется. Часто случается так, что после прогона тестов программа вновь подвергается отладке. Таким образом, тестирование устанавливает факт наличия ошибки, а отладка выявляет ее причину.  Основная цель выделения отладки и тестирования как отдельных эта-пов создания программы заключается в том, чтобы обратить внимание обяза-тельности обеих стадий и на необходимость специального планирования временных затрат по каждой из них в отдельности. Нельзя гарантировать, что тестированием можно установить наличие каждой имеющейся в П.О. ошибки. Поэтому возникает две задачи. Первая за-дача: подготовить такой набор тестов и применить к ним П.О., чтобы обнару-жить в нем по возможности большее число ошибок. Однако чем дольше про-должается процесс тестирования (и отладки в целом), тем большей становит-ся стоимость П.О.. Отсюда вторая задача: определить момент окончания от-ладки П.О. (или отдельной его компоненты). Признаком возможности оконча-ния отладки является полнота охвата пропущенными через П.О. тестами (т.е. тестами, к которым применено П.О.) множества различных ситуаций, возни-кающих при выполнении программ П.О., и относительно редкое проявление ошибок в П.О. на последнем отрезке процесса тестирования. Последнее опре-деляется в соответствии с требуемой степенью надежности П.О., указанной в спецификации его качества. Заповеди, предложенные Майерсом, по тестированию П.О.. Заповедь 1. Считайте тестирование ключевой задачей разработки П.О., поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу. Заповедь 2. Хорош тот тест, для которого высока вероятность обна-ружить ошибку, а не тот, который демонстрирует правильную работу про-граммы. Заповедь 3. Готовьте тесты как для правильных, так и для неправиль-ных данных. Заповедь 4. Документируйте пропуск тестов через компьютер; деталь-но изучайте результаты каждого теста; избегайте тестов, пропуск которых нельзя повторить. Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование. Заповедь 6. Пропускайте заново все тесты, связанные с проверкой ра-боты какой-либо программы П.О. или ее взаимодействия с другими програм-мами, если в нее были внесены изменения (например, в результате устране-ния ошибки). Существуют следующие методы тестирования П.О.: 1) Статическое тестирование – ручная проверка программы за сто-лом. 2) Детерминированное тестирование – при различных комбинациях исходных данных. 3) Стохастическое – исходные данные выбираются произвольно, на выходе определяется качественное совпадение результатов или примерная оценка. Имеется два подхода к тестированию: 1) Структурное тестирование – метод «белого ящика», тестируется логика программы, внутренняя структура программы. 2) Функциональное тестирование – метод «черного ящика»- тести-руется спецификация, т.е. вход/выход без учета знаний о ее структуре. В нашей стране различаются два основных вида отладки (включая тестирование): автономную и комплексную отладку П.О..  Автономная отладка П.О. означает последовательное раздельное тес-тирование различных частей программ, входящих в П.О., с поиском и исправ-лением в них фиксируемых при тестировании ошибок. Она фактически включает отладку каждого программного модуля и отладку сопряжения мо-дулей.  Комплексная отладка означает тестирование П.О. в целом с поиском и исправлением фиксируемых при тестировании ошибок во всех документах (включая тексты программ П.О.), относящихся к П.О. в целом. К таким доку-ментам относятся определение требований к П.О., спецификация качества П.О., функциональная спецификация П.О., описание архитектуры П.О. и тексты про-грамм П.О..

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

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

33. Технология программирования как технология разработки надежного ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

35. Инструменты разработки ПО

(вместо средства обеспечение пишите)

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

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

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

редакторы,·

анализаторы,·

преобразователи,·

инструменты, поддерживающие процесс выполнения программ.

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

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

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

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