Сайт о телевидении

Сайт о телевидении

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

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

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

1. разработка;

2. эксплуатация;

3. сопровождение.

На фазе сопровождения, как правило, выполняются следующие виды работ:

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

При проведении разработки чётко выделяют следующие этапы:

  1. определение требований к ПО, которое предусматривает сбор необходимой информации.
  2. внешнее проектирование (информация, содержащаяся в техническом задании, подвергается анализу и строгой формализации; основное назначение этого этапа – дать разработчику наиболее полное и точное представление о том, что должно в конечном итоге получиться). Не является обязательным.
  3. внутреннее проектирование (уточняются те сведения, полученные на предыдущих этапах, и вырабатываются структуры данных, используемые в ПО, определяется модульная структура ПО, правила взаимодействия модулей в процессе передачи управления или обмена информацией и т.д.).
  4. программирование (кодирование).
  5. тестирование и отладка. Тестирование – процесс выявления факта наличия ошибок в программе. Отладка – тестирование + диагностика и локализация ошибок + устранение ошибок.
  6. испытание ПО. Испытание – особый вид тестирования, цель которого выявление несоответствий между полученным ПО и требованиями технического задания.

Модели жизненного цикла ПО:

§ каскадная модель

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

31. Техническое задание (ГОСТ 19.201 – 78). Его основные разделы и их содержание.

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



2. введение;

3. основание для разработки;

4. назначение разработки;

5. требования к программному изделию;

6. требования к документации;

7. технико-экономические показатели;

8. стадии и этапы разработки;

9. порядок контроля и приёмки

10. приложение.

Введение:

§ наименование;

§ краткая характеристика в области применения ПО.

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

Основание для разработки:

§ наименование документа, на основании которого ведётся разработка;

§ организация, утвердившая данный документ;

§ наименование или условное обозначение темы разработки.

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

Назначение разработки:

§ описание функционального и эксплуатационного назначения данной системы с указанием категории её пользователей.

Требования к программе или к программному изделию.

Этот раздел должен включать следующие подразделы:

1. требования к функциональным характеристикам;

2. требования к надёжности;



3. условия эксплуатации;

4. требования к составу и параметрам технических средств;

5. требования к информационной и программной совместимости;

6. требования к маркировке и упаковке;

7. требования к транспортированию и хранению.

8. специальные требования.

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

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

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

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

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

В разделе требования к маркировке и упаковке указываются способы маркировки и упаковки ПО.

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

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

Требования к программной документации.

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

Технико-экономические показатели.

Стадии и этапы разработки.

В нём указывают стадии и этапы разработки выполняемых работ с указанием сроков и исполнителей.

Порядок контроля и приёмки.

В нём указывают порядок проведения испытаний и общие требования по проведению приёмки.

Приложение: перечень НИР, обоснования, расчёты, и другие документы, которые следует использовать для разработки.

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

32. Структурное проектирование ПО: метод структурного анализа, проектирование модульной структуры.

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

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

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

3. Принцип формализации заключается в необходимости строгого методологического подхода и решению проблемы.

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

5. Принцип полноты заключается в контроле на присутствие лишних элементов.

6. Принцип непротиворечивости заключается в обоснованности и согласованности элементов.

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

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

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

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

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

* функции, которые система должна выполнять;

* отношения между данными;

* зависящее от времени поведение системы (аспекты реального времени).

Для этого применяются:

* DFD (Data Flow Diagrams) – диаграммы потоков данных совместно со словарями данных и спецификациями процессов;

* ERD (Entity–Relationship Diagrams) – диаграммы сущность–связь;

* STD (State Transition Diagrams) – диаграммы переходов–состояний.

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

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

Взаимосвязь средств структурного анализа

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

К преимуществам разработки ПО с использованием модулей можно отнести следующее:

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

Для проектирования и документирования модульной структуры применяются структурные карты Константайна (Constantine), которые являются моделью отношений между программными модулями.

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

Элементы структурных карт.

Базовым элементом структурной карты является модуль. Можно выделить различные типы модулей:

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

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

3. Библиотека отличается от подсистемы тем, что определена вне контекста системы.

4. Область данных используется для указания модулей, содержащих области глобальных (распределенных) переменных.

Типы модулей на структурных картах.

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

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

Изображения условного и итерационного вызовов.

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

а - монолитная; б - последо­вательная; в - иерархическая; г – хаотическая.

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

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

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

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

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

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

Аннотация.

Введение.

1. Жизненный цикл ПО

Введение.

Шаги процесса программирования по Райли

Введение.

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

1.1.2. Проектирование решения.

1.1.3. Кодирование алгоритма.

1.1.4. Сопровождение программы.

1.1.5. Программная документация.

Вывод к п. 1.1

1.2. Определение ЖЦПО по Леману.

Введение.

1.2.1 Определение системы.

1.2.2. Реализация.

1.2.3. Обслуживание.

Вывод к п. 1.2.

1.3. Фазы и работы ЖЦПО по Боэму

1.3.1. Каскадная модель.

1.3.2. Экономическое обоснование каскадной модели.

1.3.3. Усовершенствование каскадной модели.

1.3.4. Определение фаз жизненного цикла.

1.3.5. Основные работы над проектом.

Литература.


Введение

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

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


1 Жизненный цикл ПО

ВВЕДЕНИЕ

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

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

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

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

И, для разнообразия, – приведем шаги процесса программирования, представленные Д.Райли в книге «Использование языка Модула-2». Это представление, по-моему, является весьма простым и привычным, с него и начнём.

1.1 Шаги процесса программирования по Райли

Процесс программирования включает четыре шага (рис. 1):

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

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

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

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

Рис. 1.Четыре шага программирования.

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

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

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

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

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

Характеристики Хорошей Постановки Задачи:

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

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

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

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

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

Рассмотрим следующую постановку задачи: «Ввести три числа и вывести числа в порядке».

Такая постановка не удовлетворяет приведенным выше требованиям: она не является ни точной, ни полной, ни понятной. Действительно, должны ли числа вводиться по одному на строке или все числа на одной строке? Означает ли выражение «в порядке» упорядочение от большего к меньшему, от меньшего к большему или тот же порядок, в каком они были введены.

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

наименование задачи (схематическое определение);

общее описание (краткое изложение задачи);

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

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

Пример. Постановка задачи в стандартной форме.

НАЗВАНИЕ

Сортировка трех целых чисел.

ОПИСАНИЕ

Ввод и вывод трех целых чисел, отсортированных от меньшего числа к большему.

Вводятся три целых числа по одному числу на строке. При этом целым числом является одна или несколько последовательных десятичных цифр, которым может предшествовать знак плюс «+» или знак минус «–».

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

1) Если введено менее трех чисел, программа ждет дополнительного ввода.

2) Строки ввода, кроме первых трех, игнорируются.

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

ОШИБКА ВВОДА – допускается только одно целое число на строке.

ввод ® – 3

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

Существуют две основные модели вывода:

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

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

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

Если при этом он использует метод проектирования «сверху вниз», то единственная задача проектирования может быть разбита на две меньшие подзадачи: (1) проектирование холодильного агрегата и (2) проектирование морозильника.

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

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

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

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

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

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

Вывод к п.1.1.

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

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

определения;

реализации;

обслуживания.

1.2.1 Определение системы

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

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

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

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

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

1.2.3 Обслуживание

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

Вывод к п.1.2.

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

1.3 Фазы и работы ЖЦПО по Боэму

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

Основные характеристики модели:

Жизненный цикл разбивается на этапы (фазы);

Переход с этапа на этап – только после полного завершения текущего этапа;

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

Главные характерные черты каскадной модели следующие:

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

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

Рис.2. Каскадная модель ЖЦПО.

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

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

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

Основные достоинства:

Формирование полного набора проектной документации в конце работы над этапом. Документация отвечает критериям полноты и завершенности;

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

Основные недостатки:

Большие сроки от анализа до завершения;

Требования к ПО «заморожены» в виде ТЗ до конца разработки.

1.3.2 Экономическое обоснование каскадной модели

Не углубляясь в экономический анализ, которому Б.У. Боэм уделяет большое внимание в книге «Инженерное проектирование программного обеспечения», скажем лишь, что экономическое обоснование каскадной модели, ориентированной на последовательное достижение целей, базируется на двух главных предпосылках:

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

Любое другое упорядочение подцелей приводит к созданию менее качественного программного изделия.

1.3.3 Усовершенствование каскадной модели

Рассмотрим одно из усовершенствований идеальной каскадной модели – пошаговую разработку.

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

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

Главными преимуществами пошаговой разработки перед абсолютно повторной разработкой и поуровневой разработкой сверху – вниз являются следующие:

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

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

Значение пошаговой разработки заключается главным образом в изменении распределения затрат труда на проект. Вариант каскадной модели при пошаговой разработке показан на рисунке 3.

1.3.4 Определение фаз жизненного цикла

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

Начать фазу планирования и анализа требований. (Завершение концептуального обзора ЖЦПО.)

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

Формирование общего плана ЖЦПО с определением основных этапов, ресурсов, обязанностей, сроков и главных работ.

Завершить фазу планирования и анализа требований. Начать фазу проектирования изделия. (Завершение обзора требований к ПО).

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

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

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

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

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

Закончить фазу проектирования изделия. Начать фазу детального проектирования. (Завершение анализа результатов проектирования изделия.)

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

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

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

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

верификация полноты, непротиворечивости, осуществимости и обоснованности требований.

Установление и разрешение всех противоречий разработки, которые повышают степень риска.

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

Закончить фазу детального проектирования. Начать фазу кодирования и автономной отладки. (Завершение сквозного контроля проекта или критического поблочного анализа проекта.)

Верифицированная детальная спецификация каждого блока:

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

описание базы данных до уровня отдельных параметров, символов и битов;

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

Одобренный план приемных испытаний.

Руководства пользователю, а также завершенный предварительный план комплексирования и отладки.

Закончить фазу копирования и отладки. Начать фазу комплексирования и отладки. (Удовлетворение критериев автономной отладки.)

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

Проверка всех вариантов ввода и вывода, включая сообщения об ошибках.

Выполнение всех операторов и всех ветвей передачи управления.

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

Завершение поблочного документирования внутренней структуры.

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

Проверка удовлетворения тесту приемных испытаний программ:

проверка удовлетворения требованиям к ПО;

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

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

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

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

Проверка удовлетворительности системных требований.

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

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

Завершение всех специфицированных работ и ввод системы в действие.

Закончить фазу эксплуатации и сопровождения (путем снятия с производства).

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

1.3.5 Основные работы над проектом

Анализ требований.

Проектирование изделия.

Программирование.

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

Верификация и подтверждение.

Управление проектом.

Управление конфигурацией и контроль качества.

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

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

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

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

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


1. Б.У. Боэм «Инженерное проектирование программного обеспечения». М.: Радио и связь. 1985.

2. Д.Райли. «Использование языка Модула-2». М.: Мир. 1993.

3. Ю.В. Иванов «Программы и их жизненные циклы» (реферат по дисциплине «Метрология ПО»). 1998.

Временные преобразования

Дилей (delay) и эхо (Echo)

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

Различают два вида этого эффекта:

  • Простой дилей (Simple Delay ), использует одну линию задержки оригинального сигнала.
  • Сложный дилей (Multi Delay ), использует более одной линии задержки оригинального сигнала.

Пример сложного дилея: повторение сигнала в правом канале с периодичностью n и повторение сигнала в левом канале с периодичностью 2n .

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

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

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

Вам ведь доводилось слышать эхо в жизни?

К примеру, вы что-то крикнули и услышали отражение своего крика через определённый промежуток времени.

Почему это произошло?

Звуковая волна распространяется в воздушной среде (и не только), встречая на своём пути препятствия. В зависимости от частоты звука – она может огибать это препятствие или же отражаться от него. Чем ниже частота (больше длина звуковой волны) – тем лучше она огибает препятствия. Звук отражается различным образом от различных препятствий, именно это и учитывается в эффекте «Эхо». Дилей же просто добавляет копии оригинального сигнала без изменения их частотных характеристик.

Реверберация (Reverberation)

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

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

T= 0.164V/A , где V – объём помещения, А – звукопоглощение (зависит от материала и типа поверхностей, их площадей). В Интернете есть калькулятор реверберации помещения.

Короткая реверберация или короткие задержки придают звучанию объём.

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

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

Реверберация звучит значительно лучше, если привязана к темпу записи.

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

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

Основные регулируемые параметры, встречающиеся в современных цифровых ревербераторах, представлены ниже:

Balance (Dry / Wet) - регулирует соотношение прямого звука (Dry) и звука, обработанного эффектом (Wet).
Gate Reverb - тип специального «нелинейного» эффекта.
Density - плотность ранних (первичных) отражений, характеризует геометрию имитируемого помещения.
Diffusion - плотность структуры ранних отражений, характеризует расплывчатость реверберации, при низких значениях ощущается ее дискретность или подобие эха.
Early Reflection Level - уровень ранних отражений, соотносится с отражающими свойствами материалов помещения.
Er/Rev Balance - соотношение уровней ранних отражений и остатка реверберации.
Feedback Level - уровень обратной связи.
Hight Cut - наличие фильтра НЧ (эквалайзера). Делает тембр реверберации более мягким.
Hight Damp (LPF) - возможность демпфирования высокочастотных составляющих спектра реверберации (иногда раздельно регулируется уровень и частота). Основано на естественном эффекте более быстрого затухания высокочастотного спектра звука в процессе акустической реверберации. В некоторой степени имитирует свойства материалов отражающих поверхностей помещения.
Liveness - характер затухания сигналов ранних отражений, их огибающая.
Low Cut - наличие фильтра ВЧ (эквалайзера).
Low Damp (HPF) - возможность демпфирования низкочастотных составляющих реверберации (иногда раздельно регулируется уровень и частота).
Pre-Delay (Initial Delay) - интервал времени между приходом к слушателю прямого, необработанного сигнала, и моментом появления самого первого «отраженного» сигнала (фактически имитирует размеры помещения с учетом месторасположения слушателя).
Release Density - плотность отражений конечной фазы реверберации.
Reverb Delay - промежуток между ранними отражениями и остатком реверберации, который в одних процессорах отсчитывается относительно прямого сигнала, а в других - относительно ранних отражений.
Reverb Send Level (Depth,Volume) - уровень реверберации. Основной параметр, управляющий глубиной эффекта.
Reverb Time (Decay) - время реверберации.
Shape (Early Type) - форма нарастания ранних отражений.
Size (Room Size, Hall Size, Height, Width, Depth) - размеры (объем) имитируемого помещения, ширина (Width), глубина (Depth), высота (Height).
Wall Vary - характеризует геометрию (неровности) отража¬ющих поверхностей. Большие значения придают реверберации более рассеянный характер.

Вибрато (Vibrato)

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

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

Изменение фазы (Phasing)

Фазовые преобразования выполняются либо путем постоянного сдвига фазы сигнала, либо путем наложения некоторой фазомодулирующей функции. Такие преобразования, например, стерео сигнала, позволяют реализовать эффект вращения или "объёмности" звука.

Фазер (Phaser) - устройство (аналоговое или программное) предназначенное для сдвига фазы подаваемой на него звуковой волны, путём задержки последней на незначительный временной промежуток (от 0.0001 мс до 20мс). В результате этого эффекта звук приобретает новый оттенок

Флэнжер (Flanging)

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

Инвертирование фазы (Phase Invert)

Фазоинвертор (от фаза и инвертор) - устройство, преобразующее входной сигнал в 2 сигнала, сдвинутых по фазе на 180°.

Хорус (англ. chorus) - звуковой эффект или соответствующее устройство. Имитирует хоровое звучание музыкальных инструментов. Эффект реализуется путем добавления к исходному сигналу его собственной копии или копий, сдвинутых по времени на величины порядка 20-30 миллисекунд, причем время сдвига непрерывно изменяется.

Частотные преобразования

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

Эквалайзер

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

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

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

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

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

Амплитудные преобразования (динамическая обработка звука)

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

При компрессии же он увеличивается в той степени, в которой обрезаются его выступы. В следствии компрессии разница между самым громким и самым тихим звуком уменьшается, музыка звучит в целом громче. Что же теряется при достижении этой громкости? Широкий динамический диапазон - это когда нота имеет допустим 128 значений громкости. Узкий, когда она имеет допустим 12 значений громкости. Так, допустим в композиции из 1000 нот 20 имеют 128 значение громкости а 30 имеют 127-е значение громкости. При компрессии значение громкости 20 нот приравнивается к 127 и общая громкость повышается на один пункт. Компрессия позволяет добиться громкости звучания, кроме того она позволяет сделать звук более чётким (при правильных настройках компрессии). Так, например, когда происходит компрессия бас бочки важно начать компрессию не с самого начала а немного позже - чтобы бочка имела характерный "щелчок" в начале (это можно сделать используя параметры компрессии, о которых речь пойдёт позже). В какой степени компрессировать материал - зависит от его стиля и целях автора. Чем больше компрессии - тем меньше дышит музыка. Если Вы стремитесь к написанию коммерческой музыки - без компрессии Вам практически не обойтись.

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

Компрессия

Схематичное изображение работы компрессора

В компрессоре (Compressor) есть несколько основных параметров обработки звука:

Threshold - компрессор анализирует амплитуду (громкость) поступающего сигнала и начинает работать как только она достишает значения Threshold.

Ratio (коэффициент компрессии) - соотношение входного сигнала к выходному. Например, значение 4:1 означает, что при изменении входного сигнала на 4dB, на выходе мы получим разницу в 1dB.

Attack - задаёт промежуток времени, после истечения которого компрессор начинает работать (время отсчитывается после достижения значения Threshold).

Release - время спада (восстановления чувствительности эффекта).

Gain - При помощи этого параметра задаётся уровень сигнала на выходе компрессора. Значение задается в децибелах. Необходимо для восстановления того же уровня сигнала после обработки компрессором.


Вид сигнала до обработки компрессором

Вид сигнала после обработки компрессором

Лимитер (Лимитер, максимайзер ) отличается от компрессора тем, что он работает более грубо, срабатывает сразу же и обрезает всё что выше выставленного значения threshold:

Схематическое изображение работы лимитера

Пример работы лимитера

SideChaine

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

Экспандер

Экспандер отличается от компрессора тем, что он начинает работать после того как сигнал станет не больше а меньше значения Theshold. Т.е. после того как уровень сигнала преодолевает этот уровень - под действием экспандера он становится ещё меньше (как долго - зависит от параметра Release). С помощью экспандера удобно вырезать из записи нежелательные шумы, однако это требует хорошей настройки параметров обработки а иногда и ручного управления. Лично я не встречал частотных экспандеров, а ведь это могло бы заметно улучшить качество его работы (экспандер продолжает работать до того как в оригинальном сигнале появляются определённые частоты).

Модуляция

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

Главными варьируемыми (настраиваемыми) параметрами являются:

Initial delay - начальная задержка входного сигнала.
Modulation freq (speed) - частота модуляции.
Delay modulation - глубина циклической модуляции.
Amplitude modulation - модуляции амплитуды сигнала.
Feedback - относительная величина обратной связи.

Distortion . Эффект дистошн (от англ. "distortion" - искажение) основывается на использовании амплитудной модуляции. Фактически это замена одних значений амплитуд сигнала другими значениями. За счет переусиления, когда происходит срезание верхушек входного сигнала, можно получить, например, классический вариант гитары heavy metal (то есть сигналу придается скрежетание или своеобразная "хрипота"). Применение такого эффекта приводит к довольно резкому искажению входного сигнала (в зависимости от глубины модуляции), в результате чего сигнал становится похож на прямоугольный, и как следствие происходит расширение спектра сигнала.

Параллельная компрессия

Параллельной компрессии (Parallel Compression, Upward Compression, New York Compression, иногда Side-Chain compression) приписываются многие чудеса. Это и прозрачность звука, и сохранение его первоначальной окраски, и нежное обращение с фронтами (transients) сигнала, и добавление такого «мяса» и «плотности» которое обычным способом (downward compression)
получить очень тяжело или даже невозможно.

Параллельная компрессия - это такой способ компрессирования сигнала при котором к необработанному (Dry) параллельно подмешивается компрессированный сигнал (Wet).

Другие преобразования

Вокодер (Vocoder)

Вокодер в первую очередь предназначен для работы с вокалом. Вам наверняка доводилось слышать голос "Робота" - это результат обработки вокала вокодером. Вокодер работает с двумя источниками:

  • Голос, который нужно обработать.
  • Источник синтезирующего звука - синтезатор, гитара, другой голос.

Наиболее распространённые типы вокодеров:

  • Полосные вокодеры. Спектр делится на 5 - 20 каналов полосовыми фильтрами. Чем больше каналов - тем натуральней и разборчивей звучит результат.

  • Формантные вокодеры. Спектр речи описывается комбинацией формант. Основные параметры формант это:
    центральная частота, амплитуда, ширина спектра.

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

  • Также существуют гармонические вокодеры, которые используют разложение в ряд Фурье.

02.03.2015 в 10:15

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

Одним из главных параметров звука является его динамика. С помощью динамики можно акцентировать ноты и музыкальные фразы добавляя новые краски в произведение, но, как показывает практика, мало кому из музыкантов(здесь не берутся во внимание профессионалы своего дела) удается это сделать. Да и ударные не подверженные динамической обработке звучат сухо и невыразительно. А ответ здесь прост - наш слух более чувствителен к высоким звукам и менее к низким. В качестве примера мы можем сравнить звук тарелки и саб-бочки, нормализовать их в 0db и послушать: тарелку люди будут воспринимать более ярко, ясно и насыщено. Конечно, можно поднять и уровень саб-бочки, но при этом (учитывая наличие других инструментов в миксе) мы рискуем получить режущую ухо кашу из звуков, где бочка будет зашкаливать, а тарелка звенеть где-то позади. Именно для предотвращения «динамических конфликтов» и служит компрессор. Так же через него могут пропускать готовые миксы в целях выравнивания общего звучания, добавления ему плотности и создания эффекта накачки.

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

Принцип работы компрессора не так уж сложен, как кажется - он захватывает все, что превышает заданное значение в db и уменьшает его в соответствии с настройками. Рассмотрим на примере компрессора из пакета T-Racks Plugin Bundle

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

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

Ratio - соотношение. Зачастую данный параметр многие не понимают, или понимают неправильно. На самом деле все очень просто - он отвечает за величину ослабления сигнала. Измеряется так же в db. Допустим, у нас стоит значение 2(в некоторых компрессорах может использоваться обозначение 2:1), это означает, что сигнал превысивший порог Threshold будет ослаблен до 1 db выше значения порога, 8 db будет ослаблен до 4х и так далее. Значение Ratio в районе 3 будет считаться умеренным сжатием, 5 - средним, 8 -сильное, а значения свыше 20 будут уже считаться ограничивающими. В этом случае наш компрессор по работе начинает напоминать Limiter , но данный компрессор не позволяет выставлять такие экстремальные значения.

Attack Time - время срабатывания компрессора, которое требуется сигналу чтобы стать максимально компресированным после прохождения порога заданного параметром Threshold . Измеряется в миллисекундах.

На некоторых компрессорах значение времени атаки представляется в Дб/сек.

Release - время восстановления.Данный параметр является полностью противоположным параметру Attack Time . Если говорить конкретно, то это время, которое потребуется сигналу, чтобы вернуться в первоначальное состояние. Время восстановления, как правило, значительно больше времени атаки.

На компрессоре от T- Racks это особо заметно, т.к. значение времени Release представлено в секундах против миллисекунд значения Attack Time .

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

В некоторых компрессорах он так же может обозначаться как Output Gain , Output , Gain и т.д.

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

Типы компрессии(по принципу использования):

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

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

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

3.Многополосная компрессия — компрессия, при которой отдельные диапазоны частот обрабатываются различным образом. Давайте взглянем на многополосный компрессор от Waves

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

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

Предназначенное для обработки звука, которые можно разделить на четыре основные группы:Приборы динамической обработки , Частотной обработки, Модуляционной обработки, и Приборы пространственной и временной обработки. Приборы для динамической обработки звука : Компрессор , Лимитер , Экспандер , и Гейт . Компрессор - Прибор, сжимающий динамический диапазон сигнала. Компрессор ослабляет громкость звука, в случаи, если сигнал превысил определенный, заранее установленный уровень. Лимитер - Устройство, не позволяющее сигналу превысить установленный уровень громкости, может быть реализовано с помощью компрессора. Экспандер - Прибор, работа которого противоположна работе компрессора.Экспандер расширяет динамический диапазон сигнала. Гейт - устройство способное обрезать сигнал ниже установленного порога. Применяется для устранения шумов в паузах между полезными сигналами.Гейт ,способен обрезать «хвост» сигнала, что сделает звучание более четким. Приборы частотной обработки сигнала :Графический эквалайзер ,Параметрический эквалайзер . Графический эквалайзер - прибор, с заданными производителем наборами частот, на каждой из которых, можно усиливать или ослаблять сигнал. Параметрический эквалайзер - самый распространенный прибор частотной обработки звука, позволяющий выбрать полосу частот, и в этом частотном диапазоне, ослаблять или усиливать сигнал. Приборы модуляционной обработки сигнала : Х орус ,Фленджер . Хорус - достаточно распространенный прибор модуляционной обработки, принцип которого базируется на плавающей временной задержки сигнала, Хорус создает эффект звучания нескольких инструментов, когда звучит только один. Фленджер - устройство, работающее на подобии Хоруса , но с небольшой разницей, которая заключается в применении обратной связи, и появлении дополнительных резонансных частот. Приборы временной обработки звука :Дилэй ,ревербератор . Дилэй - устройство с эффектом эхо, с возможностью регулировки временной задержки. Ревербератор - часто используемый прибор, суть которого заключается в ослаблении сигнала при многоразовом отражении этого сигнала от препятствий, с достижением эффекта объемного звучания. Эффекты гор, большого концертного зала, эффект звучания под водой и т.д.

Фото:

Купить Приборы обработки звука можно в компанииProfessional Light and Sound .

: (Великобритания), (Дания),

BOWERS & WILKINS (Великобритания), (Германия), (Дания),

(Германия), (США), (Германия), (США),

MERIDIA N AUDIO (Великобритания), MONITO R AUIO (Великобритания),

(Великобритания).

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