Технология программирования.
8 февраля 2012
Тема: «Технология программирования».
Под технологией программирования понимается совершенствование профессиональной культуры программирования, организация и упорядочивание труда программиста, независимо от языка программирования.
Либо, ТП — совокупность обобщенных и систематизированных знаний.
Требования к современным технологиям программирования:
1. Технология программирования должна обеспечивать отторжимость продукта от его разработчика. Это необходимо для разработки, сопровождения, модификации, воспроизведения на других ЭВМ программного изделия. Здесь затрагивается проблема правильного оформления документации.
1. Основным документом является текст программы. Будет рассматриваться такие свойства как читабельность, понятность, структурированность, отсутствие избыточности, информативность.
2. Технология программирования и средства ее поддержки (автоматизации) должны поддерживать работу всего коллектива, а не отдельных членов команды.
3. Технология программирования должна быть безбумажной (т.е. весь процессс изготовления программного изделия и управления деятельности коллектива должен выполняться автоматизировано).
4. Доступ к информации на носителях должен быть простым и автоматизированным, работа пользователя должна обеспечиваться с помощью информационно-справочных систем.
5. Технология программирования должна охватывать весь жизненный цикл программного изделия. Средства автоматизации должны охватывать все этапы работы программистов, должны учитывать весь опыт работы программистов, и обеспечивать возможность гибкой и простой перенастройки.
6. Технология программирования не должна быть связана с языком программирования.
Сложность программного обеспечения.
Сложность программного обеспечения объясняется четырьмя основными причинами:
1. Сложность проблемы
2. Сложность управления процессом разработки.
3. Сложность обеспечения гибкости конечного продукта.
4. Сложность описания поведения отдельных подсистем.
Характерные черты сложных систем.
1. Наличие общей задачи и единой цели функционирования.
2. Большое количество взаимодействующих частей и элементов, составляющих систему.
3. Возможность разбиения на группы наиболее тесно взаимодействующих элементов подсистемы, имеющих свое специальное назначение и цели функционирования.
4. Иерархическая структура связей подсистем и иерархия критериев качества функционирования всей системы.
5. Сложность поведения системы. Может быть связано со случайным характером внешних воздействий и большим количеством обратных связей внутри системы.
6. Устойчивость по отношению к внешним и внутренним помехам.
7. Высокая надежность системы в целом, которая построена на не абсолютно надежных компонентах.
Этапы проектирования сложных программных средств.
Жизненный цикл программ.
Жизненный цикл включает в себя все этапы развития, от момента возникновения потребности в программе определенного целевого назначения, до полного прекращения использования этого программного средства.
По длительности жизни различают два класса: классы с малым и большим и временем жизни. К этим двум классам используют два подхода. К классу с маленьким времени жизни используют гибкий подход, а к классу с длительным временем жизни используют жесткий (промышленный) подход.
Программы с малой длительностью жизни создаются для решения инженерных или научных задач, используются для получения конкретных результатов, обычно разрабатываются небольшой группой специалистов. Они не создаются для тиражирования, и не передаются другим коллективам для дальнейшего использования. Они не могут рассматриваться как отчуждаемые изделия. Их жизненный цикл состоит из длительного интервала системного анализа и формализации проблемы, значительного интервала проектирования программ, относительно небольшого времени эксплуатации и получения результатов. Сопровождение и модификация таких программ не нужна, жизненный цикл заканчивается после получения результатов. Основные затраты в жизненном цикле таких программ приходятся на первое время.
Программы с большой длительностью эксплуатации создаются для регулярной обработки информации и управления. Размеры могут изменяться в широких пределах, но они все обладают свойством познаваемости, и могут модифицироваться в процессе длительного сопровождения и использоваться различными специалистами.
Программы этого класса допускают тиражирование. Они сопровождаются документацией как промышленное изделия, и представляют собой отчуждаемый программный продукт. Их проектированием занимаются большие группы специалистов. Для этого необходима формализация требуемых технических характеристик комплекса программ и их компонент, также формализованные испытания, и определения достигнутых показателей качества. 70-90% жизненного цикла приходится на эксплуатацию и сопровождение, и совокупные затраты в процессе эксплуатации и сопровождения могут значительно превышать затраты на системный анализ и проектирование вследствие длительного сопровождения и тиражирования.
Основные этапы жизненного цикла программ.
1. Системный анализ. На этом этапе определяется потребность в программном средстве, его назначение и основные функциональные характеристики. Оцениваются затраты и возможность эффективного применения программного средства.
2. Проектирование программного средства. Этап включает в себя разработку структуры комплекса и его компонент, программирование модулей, ряд этапов отладки. Может включать испытание и внедрение.
3. Эксплуатация программного средства. Этап заключается в исполнение функционирования программы на ЭВМ для обработки информации и получения результатов, а также в обеспечении достоверности и надежности выдаваемых данных.
4. Сопровождение программного изделия. Этап состоит в эксплуатационном обслуживании, развитии функциональных возможностей и повышении эксплуатационных характеристик программного средства.
Из всех перечисленных наиболее трудно формализуемым является этап системного анализа. На этом этапе трудно обобщить технологические процессы и критерии качества. Решаемой задачей определяются предметной областью, поэтому показатели качества программного средства и методы их определения рассматриваются на этапах проектирования, эксплуатации и сопровождения.
13 февраля 2012
Тема: «Основные этапы жизненного цикла сложных программных средств».
1. Системный анализ и проектирование алгоритмов. Системный анализ начинается с определения целей и назначения будущего программного комплекса. Проводится проектирование и моделирование основных алгоритмов закладываемых программой. Формируются основные задачи и методы их решения, которые позже будут утверждены в техническом задании на комплекс программ.
2. Структурное проектирование программного средства. Решаются две задачи:
a. формируется общая структура комплекса и его основных компонент
b. проводится предварительная оценка распределения ресурсов ЭВМ.
2. На этом этапе подготавливаются правила построения, оформления, и проверки программных модулей. Устанавливаются допустимые типы межмодульных связей. Определяется общая структура комплекса в целом. Выявляются функциональные алгоритмы с наибольшим потреблением ресурсов, оценивается реализуемость данного комплекса на выбранной ЭВМ.
3. Подготовка технологических средств. Предназначена для выбора и настройки на условия конкретной программы. Основные задачи этого этапа:
a. Организация базы данных проекта комплекса программ.
b. Адаптация языков программирования.
c. Настройка средств трансляции и отладки.
d. Разработка инструкций для применения технологий.
4. Разработка программ. На этом этапе разрабатываются спецификации на программные модули и группы программ, в соответствии с которыми подготавливаются тексты на языке программирования. Описываются основные массивы данных. Затем эти описания транслируются для последующего централизованного применения. При трансляции формализуются их модули с другими массивами данных. На этом этапе получают программу в машинных кодах.
5. Отладка программ в статике. Обеспечивает получение модулей и взаимодействующих групп программ, правильно функционирующих при заданных значениях времени и соответствующих спецификациях. Отладка проводится по определенным местам, которые заранее запланированы с целью сокращения объема времени тестирования. Выбираются определенные тестовые и эталонные значения. На этом этапе выявляются наиболее длительные по времени счета (с самым меньшим быстродействием) программы.
6. Отладка программ в динамике. Для её проведения необходимы средства автоматизированного проектирования данных. Для этого применяется программный и аппаратный имитатор внешней среды. Одновременно создаются средства автоматизированной обработки и анализа функционирования комплекса программ.
7. Выпуск машинных носителей и документирование. На этом этапе завершается оформление программного средства как промышленного изделия. Формируются машинные носители и оформляются документы. Эксплуатационная документация является минимально необходимой для освоения функций и правильного использования программ. Системная (технологическая) документация подготавливается для специалистов, которые обеспечивают её длительное сопровождение.
8. Окончательное оформление документации и выпуск машинных носителей осуществляется после испытаний опытного образца.
9. Испытание опытного программного средства. Оно проводится совместно с заказчиком. Здесь выявляются характеристики программного средства. Для этого разрабатываются программы и методики испытаний. Они обеспечивают корректную проверку соответствия программного средства техническому заданию. Испытание позволяет проверить полноту решения функциональных задач, их качество, и соответствие технической документации. Проводится обработка результатов. Получение результаты являются основой для заключения акта, и подготавливаются заключение о степени соответствия программного средства техническому заданию.
После начинается этап эксплуатации и сопровождения.
Тема: «Эффективность технологии проектирования сложных программных средств».
Критерии оценки технологии проектирования программных средств.
Критерии качества представляют собой измеряемые числовые показатели в виде некоторой функции, характеризующей степень выполнения объектом своего назначения. Эффективность (полезность) технологии программного средства характеризуются трудоемкостью и длительностью создания, а также достигаемых качеством программ при применении соответствующих технологий. Анализ критериев качества программного средства и технико-экономические показатели жизненного цикла являются основой для оценки эффективности технологии проектирования программного средства.
Критерии требуются для эффективного целевого управления при применении конкретных технологий. В процессе формирования технического задания на программное средство выявляются доминирующие показатели качества. Устанавливается относительная важность каждого из них, строится обобщенная функция требуемого качества каждого программного средства.
16 февраля 2012г.
//продолжение…
Критерии качества подразделяются на функциональные и конструктивные.
Функциональные критерии отражают степень соответствия программного средства их целевому назначению. Они (ф.к.) являются важнейшими для каждой системы. В некоторых случаях функциональные критерии можно свести к показателям обобщенной экономической эффективности применения программ в жизненном цикле. В некоторых случаях экономическая эффективность выражается в экономии труда, энергии, материалов и прочих трат, которые выражены через их стоймость.
Эффективность функционирования проявляется на этапе эксплуатации, и вырастает в процессе проведения модернизации.
Конструктивные критерии качества не зависят от целевого назначения и основных функций. К конструктивным критериям относят сложность программ, надежность функционирования, корректность, используемые ресурсы.
Выделяются следующие временные показатели жизненного цикла программ:
· Длительность проектирования.
· Продолжительность эксплуатации.
· Длительность проведения каждой модернизации.
Очень часто бывает так, что эти критерии могут быть более важными чем трудоемкость.
Важнейшим для качества программного средства является этап системного анализа, формирования технического задания и общей спецификации на программное средство. При этом для управления качеством программного средства любого назначения необходимо учитывать два типа ограничения:
· Ограничение ресурсов.
· Ограничение знаний о методах решения задач.
Тема: «Подбор команды».
Каждая разработка собирает вокруг себя команду проекта; эта команда состоит из личностей нескольких типов:
1. Конечные пользователи. Осуществляют ввод ПО в систему, обеспечивают обратную связь, проводят бета-тестирование, помогают управлять определением достижения конечной цели.
2. Разработчик. Один из разработчиков является руководителем команды проекта. Он регулирует поток информации между членами команды. Разработчики отвечают за исследование, проектирование и создание ПО. Альфа-тестирование также проводится разработчиком.
3. Начальник отдела. На него возлагается ответственность за достоверность данных выдаваемых отделом разработки информационной системе. Кроме того, он отвечает за то, соответствует ли законченное приложение техническому заданию/спецификациями/проектным задачам.
4. Начальник отдела информационных систем. Определяет цели для разработчиков, основанные на информации, получаемой от менеджеров других отделов и главного управления. Устанавливает приоритетами между проектами, работает в качестве источника между отделами и разработчиками, распределяет объемы ресурсов.
5. Ответственный за гарантию качества. Роль состоит в том, чтобы убедиться, что проект достигнет намеченных целей. Убедиться в том, что:
· проект отвечает описанию системы
· план тестирования отвечает требованиям
· план преобразования данных отвечает требованию.
· стандарты разработки информационных систем соблюдаются.
6. Ответственный за бета-тестирование. Существует два типа тестирования.
Три важных составляющих для любого проекта:
· Ответственность за весь проект несет разработчик.
· При изучении разработчиками типов связи между всеми частями проекта их квалификация повышается.
· Все члены команды должны точно знать свои обязанности.
Почти всегда критерии качества программного средства хоть и неявно связаны с экономическим эффектом от применения программы; его можно выразить доходом, повышением прибыли, или производительности труда, снижением расхода материала и энергозатрат.
Формула, выражающая эффективность создания и использования программных средств:
Э=Э0 - С∑
Э — суммарный доход использования программного средства. Время жизненного цикла обозначается как tж.
Э0 — тот доход, который можно было бы получить, если бы не было затрат.
С∑ — потери и затраты, снижающие предельный доход. Это снижение происходит вследствие затрат на проектирование, эксплуатацию и сопровождение программного средства.
Потери эффективности могут происходить в результате сбоев и отказов ЭВМ, ограничений ресурсов, и т.д.
При создании комплекса программ важнейшей задачей является максимизация экономической эффективности функционирования.
Абсолютное значение экономической эффективности не полностью характеризуют качество, потому что не учтены те усилия, которые затрачиваются на достижение эффективности.
С∑ = Ср+Сэ+Сс
Ср — совокупные затраты на создание программного средства и обеспечение решения заданных функциональных задач, в т.ч. на технологическое обеспечение и аппаратурную оснащенность.
Сэ — затраты на эксплуатацию программных и аппаратных средств, а также потери из-за ограниченных характеристик ЭВМ и неидеальных программ.
Сс — расходы на сопровождение затрат, которые включают затраты на хранение и контроль программного средства, его состояния, проведение модернизации и исправление ошибок.
Э = Э0 - Ср -Сэ - Сс.
Другие затраты и потери принимаются в качестве ограничения программного средства.
22 февраля 2012г.
Тема: «Вспомогательные средства проектирования».
Ключом к повышению эффективности процесса программирования является планирование. Разработаны различные вспомогательные средства, помогающие упростить планирование всех этапов проектирования.
Обычно планирование даётся в виде граф-схемы или развернутого плана проекта.
Граф-схема задания представляет собой схему, построенную по иерархическому принципу; охватывает все вопросы, связанные с разработкой проекта. Графическая схема детализируется, детализация происходит в тексте задания, а каждый из входящих в граф-схему блоков подробно прорабатывается на более поздних стадиях проектирования.
Графические схемы и развернутые планы проекта должны включаться в состав системы. Графическая схема должна умещаться на одном листе.
Развернутый план проектной системы:
1. Введение.
Даётся общая характеристика системы. Характеристика в достаточной степени подробная и готовится для будущего пользователя, чтобы он мог принять решение «отвечает ли система заданным требованиям?».
a. Функции системы. Поясняется назначение системы и приводится перечень основных процедур
b. Сфера применения. Характеризует круг пользователей, на которых ориентированно разрабатываемое средство.
c. Сбор и корректировка данных.
Описываются источники исходных данных, которые поступают в систему, и используются для корректировки. Сюда включаются планы и графики корректировки данных. В дальнейшем эта информация используется как руководство при детальной проработке программ корректировки данных.
d. Отчёты. Описываются формы, определяется периодичность и общее содержание отчётов, выдаваемых системой. Эта информация в дальнейшем служит для последующей детальной проработки программ генерации отчётов.
2. Вычислительная среда.
Определяется минимальный состав оборудования, необходимого для нормального функционирования системы.
a. Технические средства. Описываются конфигурации технических средств и приводятся требования к внешним устройствам.
b. Программные средства. Описание типов операционных систем, какие библиотеки будут использоваться, СУБД.
c. Режимы работы. Определяется возможность функционирования системы в условиях фонового, интерактивного режима, режима реального времени.
3. Связь с внешней средой.
Определяется взаимодействие пользователя и систем.
a. Вход системы. Здесь определяются форматы данных, вводимых пользователем, внутренняя структура данных. Эта информация служит руководству при разработке бланков входных форм и подготовке данных.
30 февраля 2012г.
b. Выход системы. Описываются форматы отчетов, сообщений и других выходных форм. Эта информация используется при составлении планов и подготовке данных.
c. Управляющие параметры. Перечисляются параметры, которые задаются при настройке системы на конкретную конфигурацию технических и программных средств.
d. Рабочие инструкции. Здесь дается общий обзор содержания инструкций, который касается, например, дисков. Эта информация используется при составлении инструкций для обслуживающего персонала.
4. Качество системы.
a. Соблюдение стандартов и общепринятых обозначений. Соответствие стандартному варианту языка программирования.
b. Универсальность. Обсуждается уровень независимости системы от конкретных внешних условий, с учетом которых она разрабатывалась. Это будет характеризовать сложность перехода системы на другие устройства.
c. Надежность функционирования. Ожидаемое время проработки на отказ, способы коррекции ошибки, точность, проверка достоверности, стандартные характеристики всех модулей, которые осуществляют расчеты.
d. Защита информации. Здесь описываются средства, обеспечивающие сохранность данных, и ограничение доступа, используются способы кодирования. Понятие «кодирования» используется по-разному.
5. Документация по системе.
a. Пособие и руководство. Здесь приводится перечень документации, которая прилагается к системе. Это могут быть и пособия, и формы отчетности
b. Спецификации. Здесь дается общее функциональное описание программ, входящих в состав системы.
c. Организация данных. Здесь приводится общее описание взаимодействующих информационных потоков. Эта информация используется при разработке принципов организации данных.
p.s. Графическая схема задания и развернутый план проекта определяет те качества, которыми должна обладать система. Они в общей форме указывают основные направления проектирования. Документы не могут служить планом проектных работ. В процессе разработки и реализации системы решается широкий круг задач.
Тема: «Программные ошибки».
Понятие «корректности» подразумевает соответствие проверяемого объекта некоторому эталонному объекту, или совокупности формализованных эталонных характеристик и правил. Корректность программы при проектировании наиболее полно определяется по степени соответствия предъявляемым к ней формализованным требованиям. Для установления корректности программ необходимы эталоны, которым они соответствуют, а также методы проверки соответствия программ эталонам и методы оценки степени корректности.
Формализованные правила проектирования программ устанавливаются стандартами и инструкциями подготовки текстов программ и их структурного построения. Они включают описание языка программирования, правила оформления текстов программ и описание данных. Программные спецификации требований образуют иерархическую структуру. В них отражается совокупность эталонных характеристик функциональных критериев свойств и условий, которым должны соответствовать различные компоненты.
Под ошибкой понимается неправильность, погрешность или неумышленное искажение в тексте программ. Является элементом, подлежащим корректировке.
Искажение выходных результатов выполнения программ вызывает необходимость выполнения ряда операций по их локализации и устранению.
Имеется два аспекта их сложности:
1. Определение сложности процесса создания программных компонент.
2. Определение ложности объектов разработки.
Эти аспекты тесно связаны. Сложность объекта обычно определяется через трудоемкость процесса разработки. Сложность ассоциируется с ресурсом, необходимым для решения конкретных задач. Для программ наиболее характерными являются ресурсы, необходимые для их реализации, которые определяют временную, программную и информационную сложность.
Временная сложность в основном определяется алгоритмами, которые используются для решения задач.
Программную сложность можно оценить (в простейшем случае) по числу символов в тексте программы, необходимых для ее полного описания на алгоритмическом языке, или по числу операторов.
Программная сложность в наибольшей степени определяет трудоемкость создания большинства крупных программных комплексов управления и обработки.
Информационная сложность в первую очередь зависит от количества типов и структуры данных, которые поступают на вход, и выдаваемых программой. Понятие информационной сложности включает емкость всех ячеек памяти и регистров, к которым осуществляется обращение при обработке операндов в процессе решения задач.
Структурная сложность программ определяется числом взаимодействующих компонент, числом связей между компонентами и сложностью их взаимодействия.
Ограниченность ресурсов на разработку модулей приводит к целесообразности выравнивания их структурной сложности и выделения затрат на проверку в соответствии со сложностью каждого модуля. На сложность будет влиять положение модуля в иерархической схеме программного средства, особенности и тип структуры ациклической части модуля, наличия модуля циклов и их характеристик, характер вычислительного процесса в модуле, характеристики нереализуемых путей исполнения программ.
В сложных программных системах используются три типа модулей:
1. Управляющие программы организации вычислительного процесса, расположенные на высших уровнях. Они почти не выполняют вычислений, имеют на входе небольшое число логических переменных, и выдают управляющее воздействие на вызовы функциональных модулей.
2. Основные функциональные программы.
3. Стандартные программы для вычисления различных функций являются самыми простыми и предназначены для выполнения простейших задач.
При анализе сложности программного средства в целом внутренняя сложность структуры модуля и обработки в нём информации не учитывается. Также не учитывается сложность реализации операторов при анализе сложности модуля. Сложность связей каждого модуля по управлению определяется числом вариантов возможных вызовов данного модуля из других модулей. При определении сложности каждая связь учитывается дважды.
Типичные ошибки в программных комплексах.
Статистические характеристики ошибок могут служить ориентиром для разработчиков при определении условий на создание программного средства. Характеристики ошибок при проектировании программного средства помогают оценить реальное состояние проекта, планировать трудоемкость и длительность до завершения, рассчитывать, проводить исследования и осуществлять адекватный выбор показателей компонент программного средства или системы.
Технологические ошибки документации и фиксирование программ в памяти.
Программные ошибки можно классифицировать по видам используемых операций на следующие виды:
· Ошибки типов операций.
· Ошибки переменных.
· Ошибки управления типов.
Степень программной ошибки определяется степенью автоматизации программирования и глубиной формализованного контроля текстов программ. Их количество зависит от квалификации разработчиков, от общего объема комплекса программ, от глубины логического и информационного взаимодействия модулей и ряда других факторов.
7 марта 2012г.
Алгоритмические ошибки. Они значительно труднее поддаются обнаружению методом формализованного контроля. К ним относятся ошибки, обусловленные некорректной постановкой функциональных задач, т.е. когда не оговорены все условия, ошибки обусловленные не полным учетом всех условий решения задач (70% всех алгоритмических ошибок).
К алгоритмическим ошибкам можно отнести ошибки связи модулей и функциональных групп программ, которые относятся к некорректной постановке задачи (7–8% ошибок).
Системные ошибки определяются неполной информацией о реальных процессах, происходящих в источниках и потребителях информации.
Задания могут уточняться в процессе проектирования и в соответствии с этим выявляться отклонения, которые квалифицируются как системные. Анализ показывает их связь с методами структурного проектирования программ, типом языка программирования, степенью автоматизации технологии программирования и других факторов.
Описаны несколько моделей, основой которых являются гипотезы о характере и появлении ошибок в программах. Эти гипотезы можно разделить на три группы допущений:
1. Включает предположение о наблюдаемости искажений данных программ или вычислительного процесса, обусловленных первичными ошибками программ. Первичная ошибка, которая является предметом искажения результатов либо фиксируется и исправляется после этапа тестирования, либо вообще не обнаруживается.
2. Является основной и проверенной интегрально по обобщённым характеристикам, в частности обнаружения ошибок по обобщенным характеристикам, и дифференцированно, путем анализа каждого допущения.
3. Детализирует использование ресурсов на корректировку программ и повышения их качества.
Тема: «Архитектура программного средства».
1. Понятие архитектуры программного средства.
Архитектура программного средства — строение, как оно видно извне, т.е. представление программного средства как системы, состоящей из взаимодействующих подсистем. В качестве таких подсистем выступают отдельные программы.
Разработка архитектуры является первым этапом борьбы со сложностью ПС, на котором выделяются принципы выделения относительно независимых компонентов.
Основные задачи разработки архитектуры.
1. Выделение программных подсистем и отображение на них внешних функций.
2. Определение способов взаимодействия между выделенными программными подсистемами.
Основные классы архитектур программного средства.
· Цельная программа.
· Комплекс автономно выполняемых программ.
· Слоистая программа.
· Коллектив параллельно выполняемых программ.
Цельная программа. В состав входит одна программа. Выполняется одна функция, реализация не представляется слишком сложной. Такая архитектура не требует описания, и нет способа взаимодействия.
Комплекс программ состоит из набора программ: любая из этих программ может быть активизирована пользователем, и другая программа не может быть запущена до тех пор, пока не закончится завершение первой активизированной программы.
Все программы этого набора применяются к одной информационной среде. То есть, здесь нет взаимодействия по управлению, а есть по информационной среде.
Слоистая программа. Состоит из некоторой совокупности программных подсистем, которые называются слоями. На каждом слое ничего не известно о свойствах (или даже существовании) последующих слоев. Каждый слой может взаимодействовать по управлению с предшествующим через заранее определенный интерфейс, ничего не зная о внутреннем строении предшествующих слоев.
Каждый слой располагает определенными ресурсами, которые он скрывает от других слоев, либо предоставляет последующему слою их абстракцию.
Связи между слоями ограничены передачей значений параметров обращения каждого слоя к предшествующему и выдачи результатов этого обращения от нижнего к верхнему.
Коллектив параллельно действующих — набор программ, способных взаимодействовать между собой находясь одновременно в стадии выполнения. Такой разновидностью архитектуры является, например, конвейер.
12 марта 2012г.
Тема: «Тестирование и отладка программного средства».
Отладка — это деятельность, направленная на обнаружение и исправление ошибок программного средства с использованием процессов выполнения его программ.
Тестирование — процесс выполнения программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения программ.
Указанный набор называется тестовым или просто тестом.
Принципы и виды отладки.
Возникают две задачи:
1. Подготовить такой набор тестов, и применить их к программному средству, чтобы отыскать в нем большинство ошибок.
2. Определить момент окончания отладки программного средства.
Признаком возможности окончания отладки является полнота охвата пропущенными через программное средство тестами, и множество различных ситуаций, возникающих при выполнении программ программного средства и относительно редкое появление ошибок на последнем отрезке тестировании.
Для оптимизации набора тестов необходимо заранее спланировать этот набор и использовать рациональную стратегию планирования тестов.
Планирование тестов можно начинать после этапа внешнего описания программного средства.
Имеется несколько вариантов проектирования стратегии тестов. Они находятся между двумя крайними подходами. Левый крайний подход заключается в том, что тесты проектируются только на основании изучения спецификации программного средства. Правый крайний подход заключается в том, что тесты проектируются на основании изучения текстов программ, но с целью протестировать все пути выполнения программ.
Оптимальную стратегию можно конкретизировать на основании следующего принципа: для каждого документа, включая текст программ, входящего в состав программного средства, должны проектироваться свои тесты с целью выявления ошибок.
Различают комплексную и автономную отладку.
Автономная отладка означает тестирование только какой-то части программ с поиском и исправлением в ней фиксируемых при тестировании ошибок. Включает в себя отладку каждого модуля и отладку сопряжения модулей.
Комплексная отладка означает тестирование программного средства в целом, с поиском и исправлением фиксируемых ошибок во всех документах (определение требований программного средства, спецификация качества, функциональная спецификация, описание архитектуры и текста), относящихся к программному средству в целом.
Автономная отладка модуля.
При автономной отладке тестируется всегда некоторая программа, построенная специально для тестирования отлаживаемого модуля. Она лишь частично совпадает с отлаживаемой программы, кроме случая, когда отлаживается последний модуль отлаживаемой программы.
Отладочные модули входящие в окружение отлаживаемого модуля зависят от порядка, в котором отлаживаются модули этой программы, от того какой модуль отлаживается, и от теста.
При методах восходящего тестирования окружение содержит только один отлаживаемый модуль (ведущий/драйвер), который будет головным в тестируемой программе. Этот модуль подготавливает информационную среду для тестирования отлаживаемого модуля, осуществляет обращение к отлаживаемому модулю и по окончанию работы выдает необходимое сообщение.
При нисходящем тестировании окружение в качестве отладочных модулей состоит из имитаторов всех модулей, к которым может обращаться отлаживаемый модуль, имитаторы тех модулей, к которым могут обращаться отлаженные модули отлаживаемой программы. Некоторые из этих имитаторов могут изменяться для разных тестов.
Достоинства восходящего тестирования: простота подготовки тестов и возможность полной реализации плана тестирования модуля.
Недостатки: обычно тесты готовятся не в той форме, в которой рассчитаны пользователя, большой объем отладочного программирования, необходимость специального тестирования сопряжения модулей.
Достоинства нисходящего тестирования: тесты рассчитаны на пользователя, относительно небольшой объем отладочного программирования, нет необходимости тестировать сопряжение модулей.
//…продолжение предпредыдущего (написано 21 марта 2012г.)
Комплексная отладка программного средства. При комплексной отладке тестируется программное средство в целом, тесты готовятся по каждому из документов программного средства. Тестирование проводится в обратном от разработки порядке. Тестирование программного средства при комплексной отладке представляет собой применение его конкретных данных, которые могут возникнуть у пользователя, но в моделируемой среде.
Тестирование архитектуры программного средства.
Целью тестирования является поиск несоответствий между описанием архитектуры и совокупностью программ программного средства. К моменту начала тестирования архитектуры должна быть закончена автономная отладка каждой подсистемы. Ошибки могут быть связаны с взаимодействием подсистем.
15 марта 2012г.
Тема: «Нисходящее проектирование программ».
Решение задачи проектирования должно состоять в разделении спецификаций на обозримые части. Проектирование «сверху-вниз» начинается с наиболее абстрактного описания функций системы. По этому общему описанию последовательно создаются более детальные описания. Процесс детализации продолжается до тех пор, пока не получим проект пригодный для программирования. Этот результирующий проект имеет вид иерархического дерева. Каждый его уровень должен содержать в себе законченное описание системы. Описание включается до построения следующего уровня. Преимущество проектирования «сверху-вниз» в том, что оно дает обозримое описание на каждой стадии и предоставляет все взаимосвязи всех составных частей проекта. Этот подход позволяет своевременно обнаружить ошибки, и не переходить к последующей детализации пока не будет завершен предыдущий уровень. Такой подход называют иерархической декомпозицией. Это проектирование содержит в себе разбиение программ на обозримые части, поэтому целесообразно использовать метод, заключающийся в определении и разделении выполняемых функций.
Сложность проектирования заключается в том, что при применении этого метода иерархической декомпозиции переходить на следующий уровень нельзя прежде чем не закончится проектирование предыдущего и это может задержать определение разрешимости программы, которая может содержать в себе более низкий уровень. При иерархической декомпозиции может возникнуть множество проблем, и в большинстве случаев они обнаруживаются только при детализации самого нижнего уровня.
Задача выявления проблем на нижнем уровне обычно решается итеративным процессом. При этом суть проблем нижнего уровня решается при повторном проектировании, которое начинается сверху.
Ключом к успешному проектированию может служить строгое и формальное определение входов функций, и выходов всех модулей программы и системы.
Как только убедились в том, что задача может быть решена отдельно (в виде отдельного модуля), можно не уделять много времени тому, как именно эта задача/модуль будет реализована/-ован.
Проектированию структуры данных нужно уделять не меньше внимания, чем проектированию процессов или алгоритмов. Во многих случаях в состав этих данных входит требование к межмодульному интерфейсу.
Нисходящее кодирование.
В простейшем случае нисходящее кодирование подразумевает, что к написанию кода приступают после проектирования. Прежде всего пишутся коды главной программы, затем кодируются модули более низкого уровня.
Существует другая форма представления нисходящего кодирования. По завершению проектирования верхнего уровня программы, до начала проектирования следующих уровней, должны быть записаны коды этих уровней. Затем проектируются 2-ой, 3-ий, n-ый уровень.
Преимущества нисходящего кодирования:
1. Программный код является более простым.
2. В процессе кодирования могут быть вскрыты те или иные трудности проектирования более низких уровней. Это происходит вследствие того, что при кодировании более тщательно обдумываются действия программиста.
3. Нисходящее кодирование упрощает нисходящее тестирование.
При программировании сверху-вниз каждый незапрограммированный модуль заменяется заглушкой, который удовлетворяет требованиям интерфейса или выполняет их частично. Заглушки дорабатываются до настоящих модулей в соответствии с кланом программирования, и на каждой стадии процесса реализации уже созданная программа должна правильно функционировать по отношению к более низкому уровню.
Из процесса разработки исключается стадия сборки, за счет чего повышается надежность.
Так как каждая часть программы тестируется по мере ее включения в целое, полностью закодированная программа к концу этапа будет полностью оттестирована. Следующий этап — нисходящее тестирование.
В восходящем тестировании сначала тестируются отдельные модули, затем они объединяются в систему, параллельно тестируется другая подсистема. Эти подсистемы объединяются в одну общую систему.
Первый этап определяет как тестирование модулей следующий этап как пусковые испытания или тестирование подсистем и следующий заключительный этап системы в целом или интеграцию.
В нисходящей схеме тестирования тестирование организуется в соттветствии с методологией нисходящего проектирования и нисходящего кодирования. Тестируется модуль главной программы и модули одного или двух более низких уровней. После того как логическое ядро программы испытано настолько, что появляется уверенность в правильности реализации основных интерфейсов, подсоединяются следующие уровни логической структуры программы. Когда система пополняется самым нижним уровнем системы или модулей задача оказывается эффективно решеной, т.е. не требуется тестирование всей системы. Тестирование на уровне системы практически упраздняется. Основные интерфейсы тестируются в первую очередь, поэтому серьезные ошибки выявляются на ранних этапах.
Предварительную версию можно предоставить на ранней стадии разработки, и это является средством урегулирования отношения с заказчиком.
Если завершение оказывается невозможным к крайнему сроку, то возможно завершение некоторой допускающей независимого использования части программы.
Использование методологии нисходящего тестирования облегчает выявление ошибок.
Затраты на тестирование распределяются более равномерно. В нисходящем тестировании обеспечивается более реальная тестовая обстановка испытания нижних уровней.
Методы восходящего тестирования, как и методы нисходящего тестирования, имеют как свои плюсы так и минусы, поэтому зачастую применяется комплексный метод.
26 марта 2012г.
Тема: «Вспомогательные средства разработки программного средства».
1. Метод дублирования кодов.
Эта структура называется решетчатой. Под каждым блоком понимается группа операторов на языке программирования. Соединяющие стрелки — графы переходов. Такая программа не является структурированной. Программы с такими структурами чреваты ошибками передачи управления в область общего пользования. Чтобы получить структурированную программу дублируются те блоки, в которые можно войти из нескольких мест.
Преимущество: переход из неструктурированного к структурированному упрощает программирование.
Недостаток: Если есть ошибка на одном из поздних этапов, то тяжело обнаружить ошибку.
Метод дублирования кода обычно не может быть применен к программам с циклами.
2. Метод введения переменной состояния.
Этот метод чаще всего применяют к программам с циклами; состоит из пяти шагов:
1. Неструктурированной схеме приписываются номера. Первому блоку обычно приписывается 1, последнему 0.
2. Вводится новая переменная целого типа.
3. Функциональные блоки неструктурированной схемы заменяют функциональными блоками, которые выполняют те же самые действия и приписывают новой, ранее введеной, переменной значение, равное номеру блока приемника.
4. Логические блоки исходной схемы преобразуются таким же способом.
5. Перестроить всю схему. Начальное значение задаем=1, затем последовательно проводится опрос значения переменной i, и исполняются соответствующие действия.
Преобразованная введением переменной состояния форма обладает тем преимуществом, что она довольно проста, и может быть продолжена неограниченно.
Подход, связанный с введением переменной состояния помогает программисту в документировании. Каждому блоку соответствует определенное состояние, которое либо выполняет логическое условие, либо выполняет некоторую обработку. Эти состояния могут быть документированы в четкой и компактной форме, и еще важно, чтобы переходы через состояния могли быть представлены в табличной форме. Этот метод позволяет упростить отладку.
Трассирование дает ясное представление о ходе управления программы.
Тема: «Модульное программирование».
Модульное программирование — способ написания программ небольшими функционально законченными частями. Эти части называются модулями, и оформляются как подпрограммы, функции или пакеты программ.
Каждый модуль выполняет минимум одну функцию, входящую в задачу. Модуль может использоваться в нескольких местах программной системы.
Определение функций программной единицы имеет ряд преимуществ: такую программу легко проектировать и разрабатывать, легко читать, проверять, модифицировать. Становится возможным создание библиотеки процедур. Нужно писать универсальные модули, которые можно использовать в различных программах.
В большинстве традиционных языков программирования модули выполняются как отдельно компилируемые, или как внешние подпрограммы. Наиболее часто информация передается от модуля к модулю списком параметров. Информация может передаваться с помощью глобальных данных общих блоков. Информация, которая передается только списком параметров, называется полностью закрытой. Такие модули обычно не имею побочных эффектов на элементах общей базы данных, и используются в других задачах независимо от имеющихся баз данных. Такая форма является более предпочтительной. Форма где используются глобальные данные, называется частично закрытой. Внутренние процедуры часто используют эту форму взаимодействия по информации.
Модули могут взаимодействовать друг с другом не только по информации, но и по управлению. Передача управления вызываемому модулю должна осуществляться через начало, а выход должен осуществляться через окончание.
Модули одного уровня должны вызываться только модулями высших уровней.
Для исполнения модуля с некоторой внутренней точки вызов должен осуществляться стандартным способом.
4 апреля 2012г.
…//продолжение
Каждый модуль характеризуется функциональной законченностью, автономностью и независимостью в оформлении от модулей, которые его используют, и которые он вызывает.
Информация от глобальных переменных доступна для использования любыми комплексами программ, в соответствии с областью действия глобальных переменных. Для взаимодействия вызываемого и вызывающего модулей используются зоны обмена переменных, информация из которых доступна лишь модулям, связанным по управлению.
Информация, находящаяся в регистрах вызывающего модуля, должна быть сохранена на период выполнения вызываемого модуля и при передаче управления в вызывающий модуль.
Информация может также передаваться с помощью глобальных данных общих блоков. Модули, информация которых передается только списком параметров, называются полностью закрытыми.
Модули, информация которых передается с использованием баз данных, которые построены на глобальных переменных и общих блоках, называются частично закрытыми.
Тема: «Методы построения модульных программ».
Самым важным качеством модульности является независимость. Если подпрограммы сильно зависят одна от другой, то их введение малополезно.
Необходимо постоянно стремиться выделять функциональный характер подпрограмм.
При построении модульных программ можно использовать таблицы решений.
Их преимущества:
1. Лучший анализ и понимание задачи.
2. Представляют собой более четкое средство общение между пользователем и разработчиком.
3. Обеспечивают более широкий контроль ошибок, исключая избыточность/неполноту и противоречивость.
Программы, построенные на основе таблиц решений оказываются достаточно модульными.
Когда составляются таблицы решений выявляются такие сочетания условий, которые не были оговорены заранее. Построение таблицы решений начинается с перечисления возможных условий на входе; определяется действие (на рисунке их четыре), и определяются все комбинации входных и выходных условий. Такую таблицу можно преобразовать к виду, в которой все комбинации входных условий ведущих к одному действию объединяются в группы. Такие таблицы носят исчерпывающий характер. В них перечисляются все возможные комбинации входных условий, многие из которых могут быть избыточны.
****лекции от 9-го апреля нет****
12 апреля 2012г.
Тема: «Разработка структуры программ».
Контроль структуры программ.
Для контроля можно использовать статический, смежный, сквозной методы.
Статический контроль состоит в оценке структуры программы: насколько хорошо программа разбита на модули с учетом значений основных характеристик модулей.
Смежный контроль «сверху»: контроль со стороны разработчиков архитектуры и внешнего описания программного средства.
Смежный контроль «снизу»: контроль спецификаций модуля со стороны разработчиков этих модулей.
Сквозной контроль — представление структуры программы при выполнении заранее разработанных тестов.
Тема: «Разработка программного модуля».
Порядок разработки.
При разработке программного модуля целесообразно придерживаться следующего порядка:
A. изучение и проверка спецификаций модуля, выбор языка программирования.
B. выбор алгоритма и структуры данных.
C. программирование модуля.
D. корректировка текста модуля.
E. проверка.
F. компиляция.
a — представляет собой смежный контроль «снизу».
b — выяснение неизвестных алгоритмов для решения поставленных задач.
c — учет всех деталей.
d — отладка, поиск ошибок.
Структурное программирование.
При программировании модуля понятие «программа должна работать на пользователя» должно строго соблюдаться.
Имеется предложение по построению программы как композиции из нескольких типов управляющих конструкций, которые позволяют сильно повысить понимаемость логики работы программы. Программирование с использованием таких конструкций называют структурным.
Основными конструкциями структурного программирования являются следование, ветвление, повторение.
Компонентами являются обобщенные операторы. Это могут быть предикаты, например.
Каждая из этих конструкций имеет только один вход и один выход по управлению.
Все конструкции являются математическими объектами. Для каждой неструктурированной программы можно построить функционально-эквивалентную структурированную программу.
Структурное программирование дает рекомендации к тому, каким должен быть текст модуля. Часто программирование начинают с построения блок-схемы.
В качестве основного метода построения текста модуля рекомендуется пошаговая детализация. Сущность этого метода заключается в разбиении процесса разработки текста модуля на ряд шагов:
Первый шаг: описывается общая схема работы модуля в обозримой текстовой форме. Описания не являются полностью формализованными и ориентированы на восприятие человеком.
На каждом следующем шаге проводится уточнение и детализация одного из понятий в каком-либо описании, разработанных на одном из предыдущих шагов. В результате такого шага создается описание выбранного уточняемого понятия либо в терминах базового языка программирования, либо в такой же форме, что и на первом шаге, с использованием новых уточняющих механизмов.
Этот процесс завершается, когда все уточняемые понятия будут уточнены.
Последний шаг: получение текста модуля на базовом языке программирования путем замены всех вхождений уточняемых понятий заданными их описаниями и выражении всех конструкций структурного программирования средствами этого языка программирования.
Пошаговая детализация связана с использованием частично формализованного языка для представления указанных описаний. Этот язык позволяет использовать все конструкции структурного программирования, которые оформляются с неформализованными для представления обобщенных операторов и условий. В качестве таких операторов могут задаваться и соответствующие фрагменты на базовом языке программирования.
Головным описанием можно считать внешнее оформление модуля на базовом языке программирования, которое должно содержать начало модуля на базовом языке, раздел описаний на базовом языке. Неформальное обозначение операторов тела модулей как одного обобщенного оператора. Неформальное описание тела каждого процедуры или функции как одного обобщенного оператора.
Последнее предложение модуля на базу.
Для каждого неформального обобщенного оператора должно быть создано отдельное описание, которое выражает логику его работы. Заголовком должно быть неформальное обозначение детализированного обобщенного оператора.
Рекомендуется на каждом шаге детализации создавать достаточно содержательное описание, но легко обозримое. Вложенные конструкции располагают со смещением справа в несколько позиций.
23 апреля 2012г.
Тема: «Объектный подход к разработке программных средств».
Объект воплощает в себе некоторую сущность и имеет некоторое состояние, которое может изменяться со временем как следствие влияния других объектов, находящихся в каких-либо отношениях с первым.
Он может иметь внутреннюю структуру, т.е. состоять из других объектов, которые находятся в некоторых отношениях между собой.
Отношение связывает некоторые объекты. Такое объединение объектов может обладать некоторым свойством.
Если объединяются n-объектов, то это n-арное объединение.
Одноместные отношения называют простым свойством объекта, а многоместные ассоциативным свойством объекта, если этот объект участвует в этом отношении.
Множество всех объектов, обладающих общим набором свойств, называют классом объектов.
Простые свойства могут задаваться непосредственно в виде отдельных компонент, либо специальными функциями над этой структурой данных. Ассоциативные свойства можно представить либо в активной форме, либо в пассивной.
В активной форме n-местные отношения представляются в некотором программном фрагменте, реализующим либо n-местную функцию, либо процедуру, которая осуществляет изменение состояния.
Сущность объектного подхода состоит в систематическом использовании декомпозиции объектов при описании и построении программного средства. При этом, функции, выполняемые этим программным средством, выражаются через отношения объектов других уровней. С точки зрения разработчиков программного средства можно рассмотреть следующие категории объектов:
· Объекты модельного мира.
· Информационные модели объектов реального мира.
· Объекты процесса выполнения программ.
· Объекты процесса разработки программного средства.
В зависимости от способа представления модельного мира и характера взаимодействия с ним различают пассивные и активные объекты.
Пассивный объект — фрагмент информационной среды, который способен хранить в себе разные данные определенного типа, с которыми связан некоторый набор операций.
Активный объект представляет собой расширение пассивного объекта, в котором объект информационной среды способен хранить и программные фрагменты, которые находятся в активном состоянии.
Объектно-ориентированный подход — объектный подход с ориентацией написания объектов модельного мира и построением их информационных моделей.
Особенности объектного подхода к разработке внешнего описания программного средства.
Определение требований заключается в неформальном описании модельного мира.
Часто определение требований завершается разработкой диаграмм вариантов использования, в которой фиксируются в каких случаях будет использоваться программное средство. Изменяется содержание спецификаций требований. Вместо разработки функциональной спецификации программного средства создается формальное описание модельного мира, состоящее из трех частей: объектная модель, динамическая модель, и функциональная.
Объектная модель показывает объектную структуру модельного мира, в которой должно быть предоставлено разрабатываемое программное средство. Оно включает определение используемых классов объектов и отношения между этими классами. Определение используемых объектов этих классов и отношение между этими объектами.
В объектной модели отношения между объектами некоторых классов обобщаются в отношения между этими классами.
Одноместные отношения называют атрибутами.
Отношения между двумя и более объектами называют связями, а их отношения ассоциациями.
Динамическая модель показывает допустимые последовательности изменений состояний объектов из объектной модели модельного мира. Такая модель необходима, если соответствующей объектной модели имеются активные объекты.
Состояние объекта — совокупность значений атрибута объекта и представление текущих связей этого объекта с другими.
Функциональная модель.
Показывает, как вычисляются выходные значения из входных без указания порядка, в котором они вычисляются. Эта модель определяет все операции условия и ограничения используемой в объектной и динамической моделях.
Функциональная модель соответствует определению внешних функций при реляционном подходе разработке программного средства.
Для определения крупных операций в этой модели используются потоковые диаграммы, которые позволяют выразить операции через более простые.
26 апреля 2012г.
…//продолжение
На этапе конструирования определяется спецификация и пользовательский интерфейс.
В случае использования активных объектов основным разработчиком архитектур является коллектив параллельно действующих программ. Типичной архитектурой является клиент-серверная архитектура.
Дальнейшая разработка структур программных подсистем и их кодирование осуществляется в рамках реляционного подхода на ориентированных на него языках программирования.
При разработке модульной структуры при объектном подходе используются преимущественно информационно прочные модули, и такой модуль, который реализует какой-либо класс объектов или логически связанную совокупность таких классов, называют компонентным программного средства.
Особенности объектного подхода на этапе кодирования программного средства.
На этом этапе используются объектно-ориентированные язык. Язык программирования поддерживает ООП, если он включает конструкции для инкапсуляции и абстракции данных, для наследования и для динамического полиморфизма.
В качестве основных средств декомпозиции реляционных программ используются описание функций процедур, а в ООП описание классов объектов. Объекты, которые возникают в программах при такой декомпозиции называются объектами процесса выполнения программ.
В ООП изменяется технология разработки модуля.
При объектном подходе при разработке модуля используется нисходящая технология разработки слоистой структуры модуля. Каждый модуль рассматривается состоящим из некоторой упорядоченной совокупности программных слоев. Каждый слой рассматривается в программной абстракции.
Структура и применение профилей стандартов жизненного цикла программных средств.
Для регламентирования жизненного цикла сложных систем и комплексов программ целесообразно применять следующие группы основных общих системных стандартов, которые определяют:
1. Процессы жизненного цикла систем на основе стандартов ISO 9000
2. Аппаратную операционную среду сложных систем определенных классов.
3. Внешнюю и пользовательскую среду функционирования и применения систем.
4. Менеджмент системы качества.
Основные общесистемные стандарты информационных систем:
· Стандарт жизненного цикла систем.
· Стандарт аппаратной операционной среды систем.
· Стандарты внешней и пользовательской среды систем.
· Стандарты менеджмента среды качества.
Технологические стандарты, регламентирующие создание, развитие и сопровождение программного средства.:
· Стандарты и руководства жизненного цикла программной системы.
· Стандарты управления качеством программной системы.
· Стандарты интерфейсов открытых систем.
· Стандарты оценки характеристик качества программной системы.
· Стандарты верификации и тестирования программной системы.
· Стандарты обеспечения функциональной безопасности программного средства.
· Стандарты сопровождения и управления конфигурацией программной системы.
· Стандарты документирования.
Применение общесистемных функциональных стандартов непосредственно поддержано группами технологических стандартов жизненного цикла комплексов программ.
Кроме того, отдельные внутренние этапы жизненного цикла комплекса программ обеспечивают группы стандартов на локальные процессы.
Эта же группа стандартов определяет инструментальные средства решения соответствующих задач.
Профиль стандартов — совокупность нескольких базовых стандартов с четко определенными и гармонизированными подмножествами обязательных и факультативных возможностей, предназначенные для реализации заданной функции или группы функций. Функциональная характеристика объекта стандартизации является исходной для формирования и применения профиля этого объекта или процесса. Профили выделяют и устанавливают допустимые факультативные возможности и значения каждого базового стандарта и нормативного документа, входящего в профиль.