Реферат: Программа сложной структуры с использованием меню

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙГОРНЫЙ УНИВЕРСИТЕТ

кафедра вм

Курсовик

“Программасложной структуры с использованием меню”

ВЫПОЛНИЛ: Пикулин Е. Г.

принял: Солодовников А. Д.

ã мОСКВА 1996 год

ОГЛАВЛЕНИЕ.

<img src="/cache/referats/3517/image001.gif" v:shapes="_x0000_s1026">1. ВИДЫ КОНТРОЛЯПРОГРАММ 3

2. ЦЕЛИ,ПРИНЦИПЫ И ЭТАПЫ ТЕСТИРОВАНИЯ

3. СТРУКТУРНОЕТЕСТИРОВАНИЕ

4. СОВМЕСТНОЕТЕСТИРОВАНИЕ МОДУЛЕЙ

5.ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ

6.ТЕСТИРОВАНИЕ ПРОГРАММНОГО КОМПЛЕКСА В ЦЕЛОМ

7. ОТЛАДКАПРОГРАММ

ВИДЫ КОНТРОЛЯ ПРОГРАММ

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

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

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

комментариям и их соответствию текступрограммы ;

условиям в операторах условного выбора( IF, CASE ) и цикла;

сложным логическим выражениям;

возможности незавершения итерационныхциклов ( WHILE, REPEAT, LOOP ).

Второйэтап визуального контроля — сквозной контроль программы

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

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

Сообщениякомпилятора обычно делятся на несколько групп в зависимости от уровня тяжестинарушения синтаксиса языка программирования:

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

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

PAGE 3

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

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

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

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

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

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

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

— наличие в тексте программы фрагментов, никогда не выполняющихся;

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

— наличие в тексте программы заведомо бесконечных циклов ;

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

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

PAGE 4

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

упрощенопри применении следующих принципов:

1) проведение этихдополнительных форм статического контроля после завершения компиляции и толькодля синтаксически корректных программ ;

2) максимальное использованиерезультатов компиляции программы и, в частности, информации, включаемой влистинг компилятора;

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

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

Четвертойформой статического контроля программ является их верификация, то естьаналитическое доказательство их корректности.

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

надежность характеризует какпрограмму, так и ее “окружение” ( качество аппаратуры, квалификациюпользователя и т.п. );

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

Надежность можно представить совокупностьюследующих характеристик :

1) целостность программногосредства (способность его к защите от отказов);

2) живучесть (способность к входному контролю данных и их проверки входе работы) ;

3) завершенность(бездеффектность готового программного средства, характеристика качества еготестирования);

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

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

PAGE 5

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

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

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

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

1) доказательство частичной корректности ;

2) доказательство частичной некорректности ;

3) доказательство завершенияпрограммы;

4) доказательство незавершенияпрограммы;

5)доказательство тотальной (полной )корректности (то есть одновременное решение первой и третьей задач);

6)доказательство некорректности (решениевторой или четвертой задачи).

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

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

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

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

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

PAGE 6

входной предикат ;

выходной предикат ;

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

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

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

Наконец, динамический контроль программы — этопроверка правильности программы при ее выполнении на компьютере, т.е.тестирование.

ЦЕЛИ,ПРИНЦИПЫ И ЭТАПЫ ТЕСТИРОВАНИЯ .

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

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

Другоеопределение тестирования ( у Г. Майерса ) тестирование — это процесс выполнения программы с целью обнаружения вней ошибок. Такое определение цели стимулирует поиск ошибок в программах.Отсюда также ясно, что “удачным” тестом является такой, на котором выполнениепрограммы завершилось с ошибкой. Напротив, “неудачным можно назвать тест, непозволивший выявить ошибку в программе.

Определение Г. Майерса указывает на объективную трудностьтестирования: это деструктивный ( т.е. обратный созидательному ) процесс.Поскольку программирование — процесс конструктивный, ясно, что большинствуразработчиков программных средств сложно “переключиться” при тестировании созданной ими продукции.

PAGE 7

У Майерсасформулированы также основные принципы организации тестирования :

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

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

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

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

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

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

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

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

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

10) следует всегдапомнить, что тестирование — творческий процесс, а не относиться к нему как крутинному занятию.

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

PAGE 8

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

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

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

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

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

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

Втестирование многомодульных программных комплексов можно выделить четыре этапа:

1) тестирование отдельныхмодулей ;

2) совместное тестированиемодулей ;

3) тестирование функцийпрограммного комплекса (т.е. поиск различий между разработанной программой и еевнешней спецификацией ) ;

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

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

на последующих этапах тестирования эти методы использовать сложнее из-за больших размеров проверяемогопрограммного обеспечения ;

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

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

1) построение эффективногомножества тестов ;

2) выбор способакомбинирования (сборки) модулей при создании трестируемого варианта программы .

СТРУКТУРНОЕ ТЕСТИРОВАНИЕ .

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

Наиболееслабым из критериев полноты структурного тестирования является требование хотябы однократного выполнения (покрытия) каждого оператора программы.

Болеесильным критерием является так называемый критерий С1: каждая ветвь алгоритма(каждый переход) должна быть пройдена (выполнена) хотя бы один раз. Длябольшинства языков программирования покрытие переходов обеспечивает и покрытиеоператоров, но, например, для программ на языке ПЛ/1 дополнительно к покрытиювсех ветвей требуется всех дополнительных точек входа в процедуру (задаваемыхоператорами ENTRY) и всех ON — единиц.

Использованиекритерия покрытия условий может вызвать подбор тестов, обеспечивающих переход впрограмме, который пропускается при использовании критерия С1 (например, впрограмме на языке Паскаль, использующей конструкцию цикла WHILE х AND y DO…, применение критерия покрытия условийтребует проверки обоих вариантов выхода из цикла: NOT x иNOT y ).

С другой стороны покрытие условий может необеспечивать покрытия всех переходов. Например, конструкция IF A AND BTHEN... требует по критерию покрытияусловий двух тестов (например, A=true, B=false и A=false, B=true ), при которыхможет не выполняться оператор, расположенный в then — ветви оператора if.

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

Правда,с помощью этого же инструмента можно проверить и выполнение критерия С1. Но дляэтого предварительно текст программы должен быть преобразован таким образом,чтобы все конструкции условного выбора (IF и CASE

PAGE 10

или SWITCH ) содержали ветви ELSE или DEFAULT,хотя бы и пустые. В этом случае все ветви алгоритма, не выполнявшиеся наданном тесте будут “видимы” из таблицы частоты выполнения операторовпреобразованной программы.

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

1) накапливать информации опокрытых и непокрытых ветвях для всех использованных тестов ;

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

3) поддерживать более мощныекритерии полноты структурного тестирования.

Совместное тестирование модулей.

Известны дваподхода к совместному тестированию модулей: пошаговое и монолитноетестирование.

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

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

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

А

B C D

E F

рис.1

PAGE 12

При сравнениипошагового и монолитного тестирования можно отметить следующие преимуществапервого подхода :

1) меньшая трудоемкость (дляпримера на рис.1 при монолитном тестировании требуются 5 драйверов и 5 заглушек; при пошаговом тестировании требуются или только 5 драйверов — если модулиподключаются “снизу вверх ”, — или только 5 заглушек — если модули подключаются“сверху вниз”) ;

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

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

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

Естьприемущества и у монолитного тестирования :

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

2) предоставляется большевозможностей для организации параллельной работы на начальном этапе тестирования.

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

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

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

Поскольку послетестирования главного модуля процесс проверки может продолжаться по-разному,следует придерживаться следующих правил :

а) модули, содержащие операцииввода-вывода, должны подключаться к тестированию как можно раньше ;

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

PAGE 12

Основные достоинства нисходящего тестирования:

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

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

Недостатки нисходящей стратегиипродемонстрируются с помощью рис.2.

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

1) может оказатьсятрудным или даже невозможным построить такой тест на входе модуля J, которыйсоотвеьствовал бы любой заданной наперед последовательности значений данных навходе модуля Н ;

2) не всегда окажетсявозможным легко оценить соответствие значений данных на входе модуля Jтребуемым тестам для проверки модуля Н;

3) т. к. результатывыполнения прграммы на построенном для проверки модуля Н тесте выводятся не им,а модулем I, может оказаться трудным восстановлении дейсвительных результатов работы модуля Н.

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

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

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

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

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

Другие достоинства восходящего тестирования :

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

нет возможностисовмещения проектирования с тестированием ;

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

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

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

На третьем этапе тестирования программныхкомплексов (тестировании функций) ипользуются прежде всего методыфу

еще рефераты

Еще работы по программированию, базе данных

Реферат по программированию, базе данных

Расчётно-пояснительная записка к курсовой работе по ОМПТ

29 Августа 2013

Реферат по программированию, базе данных

Разработка программного обеспечения решения нелинейных уравнений

29 Августа 2013

Реферат по программированию, базе данных

Резидентный обработчик клавиатуры (перехват нажатий клавиш и запись в файл)

29 Августа 2013

Реферат по программированию, базе данных

Разработка информационно-справочной системы

29 Августа 2013