методические указания к практикуму по мдк 01.02 по специальности 09.05. Методические указания к выполнению лабораторных работ (1). Правила выполнения и проведения практических занятий 5 Критерии оценки практических занятий 5
 Скачать 4.84 Mb.
|
|
Выполнение работы: Содержание ТЗ должно включать следующие разделы: Введение 1. Основание для разработки 2. Назначение разработки 3. Требования к программе 4. Требования к программной документации 5. Технико-экономические показатели 6. Стадии и этапы разработки 7. Порядок контроля и приемки В разделе “Введение” указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором будут использовать программу. 1. В разделе “Основания для разработки” указывается документ, на основании которого ведется разработка (приказ по университету, задание на лаб. работу и т.п.); организация, утвердившая документ и дата его утверждения; наименование темы разработки. 2. В разделе “Назначение разработки” указывают функциональное и эксплуатационное назначение программы. 3. Раздел “Требования к программе” должен содержать следующие подразделы: 3.1. “Требования к функциональным характеристикам” –состав функций, которые будет выполнять программа, организация входных и выходных данных (синтаксис и семантика входных данных, форматы выходных сообщений и соответствующие им ситуации), временные характеристики. В этом подразделе должно быть описано поведение системы с точки зрения соотношения входа и выхода без конкретизации внутренней структуры и реакция программы на непредусмотренные данные на входе. 3.2. “Требования к надежности” –контроль входных и выходных данных, последствия возможных отказов, время восстановления, защита от несанкционированного доступа и др. 3.3. “Условия эксплуатации” – характеристики операционной среды, вид обслуживания, количество и квалификация персонала, затрачиваемое время процессора и каналов связи, число пользователей и др., а также допустимые параметры окружающей среды. 3.4. “Требования к составу и параметрам технических средств” –конфигурация системы, основные характеристики требуемых устройств. 3.5. “Требования к информационной и программной совместимости” - требования к ме-тодам решения, языкам программирования, программным средствам, используемых систе-мой, протоколам обмена, к СУБД и операционным системам. 3.6. “Требования к маркировке и упаковке” –варианты и способы упаковки (обычно специальных требований не предъявляется). 3.7. “Требования к транспортированию и хранению” –места хранения, условия и сроки, способы создания и хранения резервных копий (обычно специальных требований не предъявляется). Отдельные разделы и подразделы по согласованию с заказчиком могут быть опущены. 4. В разделе “Требования к программной документации” – состав документации и специальные требования к ней. Виды программных документов: спецификация, текст программы, описание программы, пояснительная записка, ТЗ, программа и методика испытаний, руководство программиста, руководство системного программиста, руководство оператора, руководство по техническому обслуживанию и т.д. 5. В разделе “Технико-экономические показатели” –экономические преимущества, предполагаемая экономическая эффективность и годовая потребность, экономические пре-имущества разработки, предельный объем программы, время реакции программы. 6. В разделе “Стадии и этапы разработки” -перечень стадий, разбивка на этапы, содержание, сроки разработки (дни, недели и т.д.) и исполнители. 7. В разделе “Порядок контроля и приемки” –виды испытаний, требования к приемке работ, способы проверки важнейших характеристик. Цель испытаний –установление степени соответствия готового продукта и характеристикам технического задания. Формы представления результатов: программная документация, конструкторская доку-ментация на изделие, программное изделие. В приложении приводят перечень проведенных научных и исследовательских работ, схемы алгоритмов, таблицы, описания и т.д. 1. Разработайте проект в соответствии с вариантом. 2. перейдите в режим отладки. При остановке выполнения программы добавьте в окно просмотра наименования нескольких интересующих Вас переменных. Требования к отчету: Текст должен быть написан шрифтом Times New Roman, 12. Интервал между строками и абзацами – 1,5. Отступ слева 1,5. Ориентация текста – по ширине страницы. Скриншоты необходимо подписать. Название практической работы, цель работы, ход работы, вывод, ответы на контрольные вопросы, должны быть выделены жирным шрифтом, так же как в методичке. Контрольные вопросы: 1. Назначение технического задания? 2. Кто составляет и утверждает ТЗ? 3. На каком этапе разработки программного изделия составляется ТЗ? 4. Какими документами регламентируется написание ТЗ? Лабораторная работа № 10. Отладка проекта Цель занятия: закрепление практических навыки работы с системой Visual Studio 2019; научиться использовать инструментальные средства, помогающие провести отладку приложений. Оборудование, технические и программные средства: персональный компьютер, среда программирования Visual Studio 2019. Продолжительность занятия:2 часа. Задание: Создание программы по индивидуальному варианту задания. Проведите отладку программы всеми доступными вам средствами среды разработки. Теоретические сведения: В C#, как и в других появившихся до .NET языках, главная методика по отладке состоит в добавлении точек останова и изучении того, что происходит в коде в конкретные моменты во время его выполнения. Точки останова Точку останова (breakpoint) в Visual Studio можно помещать на любую строку кода, которая в действительности выполняется. Самый простой способ — щелчок на необходимой строке в окне редактора кода внутри затененной области вдоль левого края окна документа (или выделение нужной строки и нажатие клавиши Если останов на определенной строке каждый раз не подходит для решения имеющейся проблемы, можно создать так называемую условную точку останова. Для этого выберите в меню Debug (Отладка) пункт Windows --- Breakpoints (Окнo --- Точки останова). Откроется диалоговое окно, позволяющее указать желаемые детали для точки останова. В этом окне можно выполнять следующие действия: Указать, что выполнение должно прерываться лишь после прохождения точки останова определенное количество раз. Указать, что точка останова должна вступать в действие при каждом n-ном достижении строки, например, при каждом 20-м ее выполнении (это удобно при отладке больших циклов). Задать точки останова относительно переменных, а не команд. В таком случае наблюдение будет вестись за значением указанной переменной, и точки останова будут активизироваться при каждом изменении значения этой переменной. Однако этот вариант может сильно замедлить выполнение кода, поскольку на проверку, не изменилось ли значение отслеживаемой переменной после выполнения каждой очередной инструкции, будет тратиться дополнительное время процессора. Слежения После срабатывания точки останова обычно необходимо просмотреть значения переменных. Проще всего это сделать, наведя курсор мыши на имя интересующей переменной прямо в окне редактора кода. Это приводит к появлению небольшого всплывающего окошка, в котором показано значение данной переменной; это окошко можно развернуть, чтобы просмотреть дополнительные детали. Для просмотра значений переменных можно также использовать окно Autos (Автоматические). Окно Autos представляет собой окно с вкладками, которое появляется лишь тогда, когда программа выполняется в режиме отладки. Если вы его не видите, попробуйте выбрать в меню Debug (Отладка) пункт Windows --- Autos (Окна --- Автоматические). В этом окне рядом с переменными, которые являются классами или структурами, отображается пиктограмма с изображением знака "плюс", щелчок на которой позволяет развернуть представление переменной и просмотреть значения ее полей. Три предлагаемых в этом окне вкладки предназначены для наблюдения за переменными трех разных категорий: Вкладка Autos (Автоматические) позволяет просматривать значения нескольких последних переменных, к которым осуществлялся доступ в процессе выполнения программы. Вкладка Locals (Локальные) позволяет просматривать значения переменных, к которым получается доступ в методе, выполняемом в текущий момент Вкладка Watch (Слежение) позволяет просматривать значения любых интересующих переменных за счет явного указания их имен непосредственно в окне Watch. Исключения Исключения являются замечательным средством для обеспечения надлежащей обработки ошибок в поставляемом приложении. В случае правильного применения они позволяют обрести уверенность в том, что приложению удастся справиться с трудностями, а перед пользователем никогда не появится диалоговое окно с техническим описанием неполадки. К сожалению, во время отладки исключения не столь замечательны. На то имеются две причины: Если исключение возникает во время отладки, часто не нужно, чтобы оно обрабатывалось автоматически, особенно если это подразумевает аккуратное завершение программы. Напротив, отладчик должен помочь выяснить, по какой причине возникло это исключение. Конечно же, трудность состоит в том, что в случае написания качественного надежного и отказоустойчивого кода, программа будет автоматически обрабатывать практически все, в том числе и неполадки, которые требуется обнаружить. Если возникло исключение, для которого не было предусмотрено обработчика, исполняющая среда .NET все равно будет пытаться его найти. К сожалению, к моменту, когда она обнаружит, что обработчик не существует, выполнение программы будет завершаться. Никакого стека вызовов, следовательно, не останется, и просматривать значения каких-либо переменных будет невозможно, потому что все они будут находиться за пределами области видимости. Конечно, можно устанавливать точки останова в блоках catch, но это часто особо не помогает, поскольку при достижении блока catch поток управления по определению покинет соответствующий блок try. Это означает, что переменные, значения которых, скорее всего, следовало изучить для выяснения того, что пошло не так, покинут область видимости. Не будет даже возможности просматривать трассировочные данные стека для выяснения, какой метод выполнялся во время срабатывания оператора throw, поскольку управление уже покинет этот метод. Разумеется, помещение точки останова в оператор throw позволит решить эту проблему, но надо учитывать, что при написании кода защищенным образом операторов throw будет в коде очень много. Как тогда угадать, какой из них срабатывает и приводит к генерации исключения? На самом деле в Visual Studio предлагается очень действенное решение. Если заглянуть в меню Debug (Отладка), то можно будет обнаружить там пункт Exceptions (Исключения). В случае выбора этого пункта открывается диалоговое окно Exceptions (Исключения). Это окно позволяет указывать, что должно происходить при выдаче исключения. Здесь можно указать, что выполнение должно продолжаться или же останавливаться с переходом в режим отладки, в случае чего произойдет останов, а отладчик окажется прямо на самом операторе throw:  Visual Studio известно обо всех классах исключений, которые доступны в базовых классах .NET, и о многих таких исключениях, которых могут выдаваться за пределами среды .NET. Распознавать автоматически специальные классы исключений, создаваемые разработчиками, Visual Studio не умеет, но позволяет вручную добавлять такие классы исключений в список и, следовательно, указывать, какие из таких исключений должны приводить к немедленному прекращению выполнения приложения. Для этого необходимо щелкнуть на кнопке Add (Добавить), которая активизируется при выборе самого верхнего узла в дереве, и ввести имя специального класса исключения. Дополнительные команды отладки исходного кода Компиляция практически всего коммерческого программного обеспечения на стадии отладки и на стадии подготовки окончательной версии продукта должна проводиться немного по-разному. Среда Visual Studio способна понимать это, поскольку сохраняет информацию обо всех параметрах, которые ей надлежит передавать компилятору. Для поддержки разных вариантов компоновки проекта Visual Studio потребуется сохранять подобную информацию в более чем одном экземпляре. Разные экземпляры такой информации называются конфигурациями. При создании проекта Visual Studio автоматически предлагает на выбор две таких конфигурации, которые называются, соответственно, Debug (Отладка) и Release (Выпуск): Конфигурация Debug обычно указывает, что никакие операции по оптимизации выполняться не должны, в исполняемом коде должна присутствовать дополнительная отладочная информация, а компилятор должен предполагать, что в коде определен препроцессорный символ отладки Debug, если только он не был явно отменен с помощью директивы #undefined. Конфигурация Release указывает, что компилятор должен проводить в отношении компилируемого кода оптимизацию, в исполняемом коде не должно присутствовать никакой дополнительной информации, а компилятор не должен предполагать наличие препроцессорного символа Debug. Можно также определять собственные конфигурации. Это необходимо, например, для компоновки приложения с несколькими отличающимися версиями. Раньше из-за проблем, связанных с поддержкой кодировки Unicode в Windows NT, но не в Windows 95, для многих проектов на С++ было принято создавать две конфигурации — одну для Unicode, а вторую для MBCS (multibyte character set — набор многобайтных символов). Выполнение работы: 1. Разработайте проект в соответствии с вариантом. 2. перейдите в режим отладки. При остановке выполнения программы добавьте в окно просмотра наименования нескольких интересующих Вас переменных. 3. Вызовите окно просмотра. Далее выполняйте программу по шагам. В окне просмотра можно наблюдать интересующие Вас переменные. 4. Установите в программе несколько контрольных точек и запустите программу на выполнение. 5. Просмотрите значения интересующих Вас переменных с помощью окна просмотра, так же как это было предложено в предыдущем пункте. 6. При остановке выполнения программы откройте окно и просмотрите значения интересующих Вас переменных. Измените значение какой-нибудь переменной, записав новое в окно. 7. Выполните такое же задания, используя точки останова (Breakpoint). 8. Продолжите отладку разрабатываемой программы, используя навыки работы с отладчиком. Требования к отчету: Текст должен быть написан шрифтом Times New Roman, 12. Интервал между строками и абзацами – 1,5. Отступ слева 1,5. Ориентация текста – по ширине страницы. Скриншоты необходимо подписать. Название практической работы, цель работы, ход работы, вывод, ответы на контрольные вопросы, должны быть выделены жирным шрифтом, так же как в методичке. Контрольные вопросы: 1. Что такое отладка? 2. Какие инструменты отладки вам известны? 3. Методы отладки. Лабораторная работа № 11. Инспекция кода модулей проекта Цель занятия: закрепление практических навыков работы с системой Visual Studio 2019; научиться проводить инспекцию кода модулей проекта. Оборудование, технические и программные средства: персональный компьютер, среда программирования Visual Studio 2019. Продолжительность занятия:2 часа. Задание: Изучить теоретическую часть. Выполнить задание, следуя указаниям. Ответить на контрольные вопросы (в устной форме). Предъявить преподавателю результаты работы программы и исходные коды. Оформить отчет в соответствии с ходом работы (тема, цель, условие задачи, программный код, результаты тестирования программы, выводы). Теоретические сведения: Не во всех случаях возможна разработка автоматических или хотя бы четко формализованных ручных тестов для проверки функциональности программной системы. В некоторых случаях выполнение программного кода, подвергаемого тестированию, невозможно в условиях, создаваемых тестовым окружением (например, во встроенных системах, если программный код предназначен для обработки исключительных ситуаций, создаваемых только при установке системы на реальное оборудование). В других случаях верифицируется не программный код, а проектная документация на систему, которую нельзя "выполнить" или создать для нее отдельные тестовые примеры. И в тех и в других случаях обычно прибегают к методу экспертных исследований программного кода или документации на корректность или непротиворечивость. Такие экспертные исследования обычно называют инспекциями или просмотрами. Существует два типа инспекций – неформальные и формальные. Формальная инспекция является четко управляемым процессом, структура которого обычно четко определяется соответствующим стандартом проекта. Таким образом, все формальные инспекции имеют одинаковую структуру и одинаковые выходные документы, которые затем используются при разработке. Факт начала формальной инспекции четко фиксируется в общей базе данных проекта. Также фиксируются документы, подвергаемые инспекции, списки замечаний, отслеживаются внесенные по замечаниям изменения. Этим формальная инспекция похожа на автоматизированное тестирование – списки замечаний имеют много общего с отчетами о выполнении тестовых примеров. В ходе формальной инспекции группой специалистов осуществляется независимая проверка соответствия инспектируемых документов исходным документам. Независимость проверки обеспечивается тем, что она осуществляется инспекторами, не участвовавшими в разработке инспектируемого документа. Входами процесса формальной инспекции являются инспектируемые документы и исходные документы, а выходами – материалы инспекции, включающие список обнаруженных несоответствий и решение об изменении статуса инспектируемых документов. рис. 1 иллюстрирует место формальной инспекции в процессе разработки программных систем.  Рис.1. Место формальной инспекции в процессе разработки программных систем |