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

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

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

Выход из данных тупиков:

не брать одну вилку (ресурс) до тех пор, пока не убедился, что обе вилки (оба ресурса) доступны;

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

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

31. Технология синхронизации ПО. Система Intel Thread Checker (ITC) и типы обнаруживаемых ею ошибок.

Назначение программной системы Intel Thread Checker (ITC) – поиск мест с возможным недетерминированным поведением многопоточной программы, написанной как на основании (Windows или POSIX

48

threads) библиотеки потоков, так и при помощи технологии Open MP. ITC неплохо справляется с обнаружением ошибки, даже если эта ошибка в программе не проявила себя в текущем варианте исполнения программы.

ITC обнаруживает ошибки следующих типов:

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

Тупики.

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

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

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

32. Конструирование ПО

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

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

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

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

[Введите текст]

Минимизации сложности.

Сокрытие информации.

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

Конструированию с возможностью удобной проверки(тестированию)–контролепригодность.

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

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

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

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

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

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

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

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

2.проектирование и написание классов и методов ( при ООП),

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

4.определение способов последующего тестирования кода,

50

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

6.модульное тестирование и отладка,

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

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

9.«шлифовка кода» путем его рефакторинга.

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

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

Взависимости от размера и сложности программного проекта на конструирование уходит 30-80% от общей трудоемкости.

33.Минимизация сложности ПО. Стандартные приемы в конструировании

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

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

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

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

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

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

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

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

34. Рефакторинг

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

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

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

52