Методы создания программных средств. Основные направления. 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Методы создания программных средств. Основные направления.



Постановка задачи.

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

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

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

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

План написания постановки задачи:

1. Наименование задачи.

2. Назначение.

3. Достигаемая цель.

4. Для кого предназначена.

5. Технические средства.

6. Периодичность использования.

7. Входная информация.

8. Выходная информация (формируется по запросам).

9. Метод проверки правильности (сравнивается с контрольным примером).

10. Организация внедрения задачи.

11. Разработка контрольного примера (входная информация с конкретными данными, выходная информация).

12. Методы защиты.

6. Выбор и обоснование метода решения.

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

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

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

 
 

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

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

В него входит семнадцать процессов ЖЦ:

Основные процессы:

~ приобретение;

~ поставка;

~ разработка;

~ функционирование;

~ сопровождение;

Вспомогательные процессы:

~ документирование;

~ управление конфигурацией;

~ обеспечение качества;

~ верификация;

~ валидация;

~ совместный анализ;

~ аудит;

~ решение проблем;

Организационные процессы:

~ управление;

~ усовершенствование;

~ создание инфраструктуры;

~ обучение.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

· каскадная (водопадная) модель (70-85 г.г.);

· спиральная модель (86-90 г.г.).

· инкрементальная модель

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

~ анализ;

~ проектирование;

~ программирование;

~ тестирование;

~ документирование.

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

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

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

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

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

~ оценка и разрешение рисков,

~ определение целей,

~ разработка и тестирование,

~ планирование.

Технологии программирования. Основные понятия.

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

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

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

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

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

Изначально понятие технологии как таковой — это 60-е годы прошлого столетия — это период "стихийного" программирования. В этот период отсутствовало понятие структуры программы, типов данных и т.д. Вследствие этого код получался запутанным, противоречивым. Программирование тех лет считалось искусством. Конец 60-х — кризис в программирование.

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

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

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

Поддержка принципов структурного программирования была заложена в основу так называемых процедурных языков программирования. Как правило, они включали основные "структурные" операторы передачи управления, поддерживали вложение подпрограмм, локализацию и ограничение области "видимости" данных. Среди наиболее известных языков этой группы стоит назвать PL/1, ALGOL-68, Pascal, С.

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

Модульное программирование предполагает выделение групп подпрограмм, использующих одни и те же глобальные данные, в отдельно компилируемые модули (библиотеки подпрограмм), например, модуль графических ресурсов. Связи между модулями при использовании данной технологии осуществляются через специальный интерфейс, в то время как доступ к реализации модуля (телам подпрограмм и некоторым "внутренним" переменным) запрещен. Эту технологию поддерживают современные версии языков Pascal и С (C++), языки Ада и Modula.

 

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

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

Бурное развитие технологий программирования, основанных на объектном подходе, позволило решить многие проблемы. Так были созданы среды, поддерживающие визуальное программирование, например, Delphi, C++ Builder, Visual C++ и т. д. При использовании визуальной среды у программиста появляется возможность проектировать некоторую часть, например, интерфейсы будущего продукта, с применением визуальных средств добавления и настройки специальных библиотечных компонентов. Результатом визуального проектирования является заготовка будущей программы, в которую уже внесены соответствующие коды.

Объект ООП — это совокупность переменных состояния и связанных с ними методов (операций).

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

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

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

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

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

Этапы решения задачи на ЭВМ

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

постановка задачи включает в себя:

1. Сбор сведений о задаче;

2. Формулировка условий задачи;

3. Определение конечных целей решения;

4. Определения формы вывода результатов.

5. Выбор метода решения. Построение математической модели для решения математических соотношений.

6. Разработка алгоритма по выбранному методу решения. Алгоритм записывается в любой форме.

7. Запись алгоритма на языке программирования.

8. Отладка и тестирование программы на компьютере.

Отладка – процесс нахождения и исправления ошибок в программе. Отладка включает в себя синтаксическую, семантическую, логическую отладку.

Тестирование – проверка конкретных вариантов значений на соответствие фактическим данным.

II. Анализ полученных результатов.

Нисходящее проектирование

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

Достоинства:

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

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

3. одновременная параллельная работа нескольких программистов может оказаться эффективной.

Недостатки:

1. Необходимость заглушек.

2. До самого последнего этапа проектирования неясен размер программного комплекса и его эксплуатационные характеристики, за которые, как правило, отвечают модули самого низкого уровня.

Восходящее проектирование

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

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

Недостатки:

· Сложность объединения модулей в единую систему;

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

· Затрудненное объединение модулей в общую систему.

Проектирование.

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

· требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;

· требуемую пропускную способность системы;

· требуемое время реакции системы на запрос;

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

· простоту эксплуатации и поддержки системы;

· необходимую безопасность.

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

· проектирование объектов данных, которые будут реализованы в базе данных;

· проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

· учет конкретной среды или технологии

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

Разработка.

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

Сопровождение.

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

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

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

§ для устранения ошибок;

§ для модификации в соответствии с изменяющимися потребностями пользователей.

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

Прочность по совпадению.

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

3. Временная связность. Модуль выполняет несколько функций, отнесённых разработчиком к одному классу потому, что они необходимы в один и тот же период работы системы.

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

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

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

7. Функциональная прочность. Модуль выполняет одну функцию – то, к чему следует стремиться при проектировании модульной структуры.

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

Виды сцепления:

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

2. Сцепление по общей области. Модули ссылаются на одну и ту же глобальную структуру данных.

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

4. Сцепление по формату (образцу). Модули ссылаются на одну и ту же структуру данных.

5. Сцепление по данным. Передаются параметры из одной программы в другую.

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

§ размер модуля (от нескольких десятков до нескольких сотен операторов);

§ прочность модуля и сцепление с другими модулями;

3. рутинность модуля.

28. Организация связей между модулями

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

Виды сцепления:

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

2. Сцепление по общей области. Модули ссылаются на одну и ту же глобальную структуру данных.

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

4. Сцепление по формату (образцу). Модули ссылаются на одну и ту же структуру данных.

5. Сцепление по данным. Передаются параметры из одной программы в другую.

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

§ размер модуля (от нескольких десятков до нескольких сотен операторов);

§ прочность модуля и сцепление с другими модулями;

§ рутинность модуля.

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

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

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

30. Программная инженерия: назначение, основные принципы и понятия

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

Программная инженерия как некоторое направление возникло и формировалось под давлением роста стоимости создаваемого программного обеспечения. Главная цель этой области знаний – сокращение стоимости и сроков разработки программ.

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

Метод программной инженерии

Метод программной инженерии — это структурный подход к созданию ПО, который способствует производству высококачественного продукта эффективным в экономическом аспекте способом.

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

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

Методы должны включать в себя следующие компоненты:

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

· Правила и ограничения, которые надо выполнять при разработке моделей (например, каждай объект должен иметь одинаковое имя);

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

· Руководство по применению метода — описание последовательности работ (действий), которые надо выполнить для построения моделей (все атрибуты должны быть задокументированы до определения операций, связанных с этим объектом).

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

Виды:

1. Эвристические методы:

· Структурные;

· ориентированные на данные;

· объектно-ориентированные;

· ориентированные на область применения;

2. Формальные методы:

· Языки спецификаций и нотации;

· Уточнение;

· Подтверждение/доказательство;

3. Методы прототипирования:

· Быстрое прототипирование;

· Эволюционное прототипирование;

ООП. Структуры

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

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

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

Пояснительная записка

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

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

Для создания пояснительной записки к техническому проекту, описывающему автоматизированную систему (АС) рекомендуется использовать стандарт РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».

Стиль программирования

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

Три фактора хорошего стиля программирования:

1. требования простоты, лёгкости и удобочитаемости программы;

2. использование программистом особенностей языка программирования;

3. стремление программиста повысить эффективность программы в результате тщательного анализа структуры данных и ресурсов.

43. Тестирование программного обеспечения. Основные принципы разработки тестов для программных продуктов. Особенности тестирования объектно - ориентированных программ.

Тестирование – выполнение программы с целью обнаружения факта наличия в программе ошибок.

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

Цель тестирования – обнаружение ошибок в программе.

Этапы тестирования:

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

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

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

Принципы:

1. Ошибки в программе есть всегда.

2. Тестовые данные должны быть достаточно просты для проверки.

3. Готовятся тесты заранее до выхода на машину.

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

5. Результаты тестирования должны быть зафиксированы.

6. Тесты должны быть одинаково как для правильных исходных данных, так и для неправильных.

7. Необходимо проверить два момента:

· программа делает то, что должна делать;

· программа не делает то, чего она делать не должна.

8. Результаты тестов необходимо тщательно анализировать.

9. Ради упрощения тестирования недопустимо изменять саму программу.

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

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

12. Тестирование лучше проводить не автору, а другому человеку.

Объектно-ориентированная технология привносит свои особенности в процесс тестирования систем. Формулируется несколько вопросов, которые необходимо разрешить для успешного проведения тестирования:

§ Какая часть унаследованных свойств должна заново тестироваться.

§ Когда и как можно проверять информацию о состоянии класса.

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

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

Решение подобных вопросов выполняется путем разработки новых подходов и модернизации старых, специально для тестирования объектно-ориентированных систем.

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

Основные свойства объектов добавляют новые аспекты тестирования:

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

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

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

44. Основные понятия и определения теории тестирования. Подходы к тестированию. Стратегии тестирования. Критерии тестирования.

Тестирование программного обеспечения — процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.



Поделиться:


Последнее изменение этой страницы: 2017-02-06; просмотров: 826; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.237.178.126 (0.235 с.)