методические указания к практикуму по мдк 01.02 по специальности 09.05. Методические указания к выполнению лабораторных работ (1). Правила выполнения и проведения практических занятий 5 Критерии оценки практических занятий 5
 Скачать 4.84 Mb.
|
|
Продолжительность занятия:2 часа. Задание: ознакомиться с описанием лабораторной работы; получить задание у преподавателя по вариантам; написать программу, ввести программу, отладить и решить ее на ЭВМ; оформить отчет. Теоретические сведения: Исключительная ситуация (или исключение) - это ошибка, которая возникает во время выполнения программы. Используя С# – подсистему обработки исключительных ситуаций, с такими ошибками можно справляться. В С# эта подсистема включает в себя усовершенствованные методы, используемые в языках C++ и Java. Преимущество подсистемы обработки исключений состоит в автоматизации создания большей части кода, который ранее необходимо было вводить в программы "вручную". Обработка исключений упрощает "работу над ошибками", позволяя в программах определять блок кода, именуемый обработчиком исключении, который будет автоматически выполняться при возникновении определенной ошибки. В этом случае не обязательно проверять результат выполнения каждой конкретной операции или метода вручную. Если ошибка возникнет, ее должным образом обработает обработчик исключений. Еще одним преимуществом обработки исключительных ситуаций в С# является определение стандартных исключений для таких распространенных программных ошибок, как деление на нуль или попадание вне диапазона определения индекса. Чтобы отреагировать на возникновение таких ошибок, программа должна отслеживать и обрабатывать эти исключения. Без знания возможностей С#-подсистемы обработки исключений успешное программирование на С# попросту невозможно. В С# исключения представляются классами. Все классы исключений должны быть выведены из встроенного класса исключений Exception, который является частью пространства имен System. Таким образом, все исключения - подклассы класса Exception. Программные инструкции, которые нужно проконтролировать на предмет исключений, помещаются в try-блок. Если исключение возникает в этом блоке, оно дает знать о себе выбросом определенного рода информации. Это выброшенное исключение может быть перехвачено программным путем с помощью catch-блока и обработано соответствующим образом. Системные исключения автоматически генерируются С#-системой динамического управления. Чтобы сгенерировать исключение вручную, используется ключевое слово throw. Любой код, который должен быть обязательно выполнен при выходе из try-блока, помещается в блок finally. Ядром обработки исключений являются блоки try и catch. Эти ключевые слова работают "в одной связке"; формат записи try/catch-блоков обработки исключений имеет следующий вид: try { // Блок кода, подлежащий проверке на наличие ошибок. } catch (ExcepTypel exOb) { // Обработчик для исключения типа ExcepTypel } catch (ExcepType2 exOb) { // Обработчик для исключения типа ЕхсерТуре2 } Здесь ЕхсерТуре - это тип сгенерированного исключения. После "выброса" исключение перехватывается соответствующей инструкцией catch, которая его обрабатывает. Как видно из формата записи try/catch-блоков, с try-блоком может быть связана не одна, а несколько catch-инструкций. Какая именно из них будет выполнена, определит тип исключения. Другими словами, будет выполнена та catch-инструкция, тип исключения которой совпадает с типом сгенерированного исключения (а все остальные будут проигнорированы). После перехвата исключения параметр exOb примет его значение. Задавать параметр exOb необязательно. Если обработчику исключения не нужен доступ к объекту исключения (как это часто бывает), в задании параметра exOb нет необходимости. Поэтому во многих примерах этой главы параметр exOb не задан. Важно понимать следующее: если исключение не генерируется, то try-блок завершается нормально, и все его catch-инструкции игнорируются. Выполнение программы продолжается с первой инструкции, которая стоит после последней инструкции catch. Таким образом, catch-инструкция (из предложенных после try-блока) выполняется только в случае, если сгенерировано соответствующее исключение. Выполнение работы: Задание 1: оптимизировать программу, производящую простые арифметические операции над числами (сложение, вычитание, умножение и деление), используя обработку исключительных ситуаций (обработка ввода чисел и операции деления). Пример: using System; namespace ConsoleApplication { class OurClass { static void Main(string[] args) { float num1 = 1, num2 = 2, summarize, multiply, sub, divide = 0; Console.Write("Введите первое число:"); try { num1 = float.Parse(Console.ReadLine()); } catch { Console.WriteLine("Неправильный формат числа!\n"+ "В качестве значения первого числа будет 1"); } Console.Write("Введите второе число:"); try { num2 = float.Parse(Console.ReadLine()); } catch { Console.WriteLine("Неправильный формат числа!\n"+ "В качестве значения второго числа будет 2"); } summarize = num1 + num2; multiply = num1 * num2; sub = num1 - num2; try { divide = num1 / num2; } catch(DivideByZeroException) { Console.WriteLine("Нельзя делить на нуль!"); } Console.WriteLine( "\n" + num1 + " + " + num2 + " = " + summarize + "\n" + num1 + " * " + num2 + " = " + multiply + "\n" + num1 + " - " + num2 + " = " + sub + "\n" + num1 + " / " + num2 + " = " + divide); Console.Write("\nДля выхода из программы нажмите [Enter]:"); string anykey = Console.ReadLine(); } } } Требования к отчету: Текст должен быть написан шрифтом Times New Roman, 12. Интервал между строками и абзацами – 1,5. Отступ слева 1,5. Ориентация текста – по ширине страницы. Скриншоты необходимо подписать. Название практической работы, цель работы, ход работы, вывод, ответы на контрольные вопросы, должны быть выделены жирным шрифтом, так же как в методичке. Контрольные вопросы: Как создается защищенный блок кода? Как описывается процедура обработки конкретного исключения? Как генерируется исключение? Как можно ограничить список исключений, которые могут генерироваться в функции? Лабораторная работа № 9. Применение отладочных классов в проекте Цель занятия: научиться составлять техническое задание (ТЗ) на разработку программного продукта, применять отладочные классы в проекте. Оборудование, технические и программные средства: персональный компьютер, среда программирования Visual Studio 2019. Продолжительность занятия:2 часа. Задание: Для выбранного по индивидуальному заданию программного продукта разработать техническое задание в соответствии с ГОСТ 19.201-78, предполагая, что сначала разрабатывается ТЗ, а затем будет написана программа для ТЗ. Отчет по лабораторной работе должен содержать разделы технического задания. Теоретические сведения: Большинство разработчиков предпочитают работать с техническим заданием на разработку программного обеспечения, так как этот документ обычно содержит следующее: Полное описание целей и функциональности программного обеспечения; Детали того, как программа будет работать с точки зрения скорости, времени отклика, доступности, мобильности, надёжности, скорости восстановления и т.д.; Варианты того, как пользователи будут использовать программное обеспечение; Определение того, как приложение будет взаимодействовать с оборудованием или другими программами; Нефункциональные требования (например: требования к обеспечению эффективности, стандарты качества, или проектные ограничения) Рассмотрим образец технического задания на разработку программы. 1. Введение 1.1. Наименование программы 1.2. Назначение и область применения программы 2. Требования к программе 2.1. Требования к функциональным характеристикам программы 2.2. Требования к надежности программы 2.2.1. Требования к обеспечению надежного функционирования программы 2.2.2. Время восстановления программы после отказа 2.2.3. Отказы программы из-за некоректных действий оператора 3. Условия эксплуатации программы 3.1. Климатические условия эксплуатации программы 3.2. Требования к квалификации и численности персонала 3.3. Требования к составу и параметрам технических средств 3.4. Требования к информационной совместимости 3.4.1. Требования к информационным структурам и методам решения 3.4.2. Требования к исходным кодам и языкам программирования 3.4.3. Требования к программным средствам, используемым программой 3.4.4. Требования к защите информации и программ 3.5. Специальные требования 4. Требования к программной документации 4.1. Предварительный состав программной документации 5. Технико-экономические показатели 5.1. Экономические преимущества разработки программы 6. Стадии и этапы разработки программы 6.1. Стадии разработки программы 6.2. Этапы разработки программы 6.3. Содержание работ по этапам 7. Порядок контроля и приемки 7.1. Виды испытаний 7.2. Общие требования к приемке работы 1. Введение 1.1. Наименование программы Наименование программы: "Тестовая программа" 1.2. Назначение и область применения Программа предназначена для... 2. Требования к программе 2.1. Требования к функциональным характеристикам Программа должна обеспечивать возможность выполнения перечисленных ниже функций: 2.2. Требования к надежности 2.2.1 Требования к обеспечению надежного функционирования программы Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже: а) организацией бесперебойного питания технических средств; б) использованием лицензионного программного обеспечения; в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»; г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов 2.2.2. Время восстановления после отказа Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать 30-ти минут при условии соблюдения условий эксплуатации технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств. 2.2.3. Отказы из-за некоректных действий оператора Отказы программы возможны вследствие некорректных действий оператора (пользователя) при взаимодействии с операционной системой. Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу конечного пользователя без предоставления ему административных привилегий 3. Условия эксплуатации 3.1. Климатические условия эксплуатации Климатические условия эксплутатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации 3.2. Требования к квалификации и численности персонала Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единиц — системный администратор и конечный пользователь программы — оператор. Системный администратор должен иметь высшее профильное образование и сертификаты компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить: а) задача поддержания работоспособности технических средств; б) задачи установки (инсталляции) и поддержания работоспособности системных программных средств — операционной системы; в) задача установки (инсталляции) программы. г) задача создания резервных копий базы данных. 3.3. Требования к составу и параметрам технических средств 3.3.1. В состав технических средств должен входить IВМ-совместимый персональный компьютер (ПЭВМ), выполняющий роль сервера, включающий в себя: 3.3.1.1. процессор Pentium-2.0Hz, не менее; 3.3.1.2. оперативную память объемом, 1Гигабайт, не менее; 3.3.1.3. оперативную память объемом, 1Гигабайт, не менее; 3.3.1.4. операционную систему Windows 2000 Server или Windows 2003; 3.3.1.5. операционную систему Windows 2000 Server или Windows 2003; 3.3.1.6. Microsoft SQL Server 2000 3.4. Требования к информационной и программной совместимости 3.4.1. Требования к информационным структурам и методам решения База данных работает под управлением Microsoft SQL Server. Используется много поточный доступ к базе данных. Необходимо обеспечить одновременную работу с программой с той же базой данной модулей экспорта внешних данных. 3.4.2. Требования к исходным кодам и языкам программирования Дополнительные требования не предъявляются 3.4.3. Требования к программным средствам, используемым программой Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows 2000 Server или Windows 2003 и Microsoft SQL Server 2000 3.4.4. Требования к защите информации и программ Требования к защите информации и программ не предъявляются 3.5. Специальные требования Специальные требования к данной программе не предьявляются 4. Требования к программной документации 4.1. Предварительный состав программной документации Состав программной документации должен включать в себя: 4.1.1. техническое задание; 4.1.2. программу и методики испытаний; 4.1.3. руководство оператора; 5. Технико-экономические показатели 5.1. Экономические преимущества разработки Ориентировочная экономическая эффективность не рассчитываются. Аналогия не проводится ввиду уникальности предъявляемых требований к разработке. 6. Стадии и этапы разработки 6.1. Стадии разработки Разработка должна быть проведена в три стадии: 1. разработка технического задания; 2. рабочее проектирование; 3. внедрение. 6.2. Этапы разработки На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания. На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ: 1. разработка программы; 2. разработка программной документации; 3. испытания программы. На стадии внедрения должен быть выполнен этап разработки подготовка и передача программы На этапе разработки технического задания должны быть выполнены перечисленные ниже работы: 1. постановка задачи; 2. определение и уточнение требований к техническим средствам; 3. определение требований к программе; 4. определение стадий, этапов и сроков разработки программы и документации на неё; 5. согласование и утверждение технического задания. На этапе разработки программы должна быть выполнена работа по программированию (кодированию) и отладке программы. На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями к составу документации. На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ: 1. разработка, согласование и утверждение и методики испытаний; 2. проведение приемо-сдаточных испытаний; 3. корректировка программы и программной документации по результатам испытаний. На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика. 7. Порядок контроля и приемки 7.1. Виды испытаний Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки. Приемо-сдаточные испытания программы должны проводиться согласно разработанной Исполнителем и согласованной Заказчиком Программы и методик испытаний. Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний 7.2. Общие требования к приемке работы На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию. ВВЕДЕНИЕ Полное наименование программной разработки: "Программа К", в дальнейшем именуемая как "программа". Краткое название программы – «ПК». На данный момент аналогичных программных продуктов не существует. Разрабатываемая программа применяется на любом предприятии, где имеется рабочий персонал. Разработчик данного программного продукта - студент группы 4А1 Иванов А.В. в дальнейшем именуемый как "разработчик ". Заказчик программного продукта – ОАО «РТС», в лице директора А.М. Гутенко. 1 ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ 1.1 Документ, на основании которого ведётся разработка Работа ведётся на основании задания по дисциплине «Теоретические основы автоматизированного управления» 1.2 Организация, утвердившая этот документ, и дата его утверждения Задание утверждено и выдано начальником технического отдела ОАО «РТС» Козаковым А.В. Козаков А.В. 1.3 Наименование темы разработки Наименование темы разработки – «Учёт рабочего времени». 2 НАЗНАЧЕНИЕ РАЗРАБОТКИ Данная разработка является семестровой работой по дисциплине «Теоретические основы автоматизированного управления» 2.1 Критерии эффективности и качества программы Социальный фактор. Данная программная разработка очень проста в освоении и рассчитана не только на профессионалов, но и на рядовых пользователей, работающих в ОС Windows. Удобный, интуитивно понятный интерфейс в сочетании с мощной системой вспомогательных рисунков и всплывающих подсказок позволяют работать с программой без предварительной подготовки. Соответствие текущему состоянию на рынке ПО данного профиля. В отличие от дорогих и сложных программ «ПК» идеально подходит для представителей бизнеса, так как содержит все, что им необходимо, но не перегружена бесполезными и ненужными возможностями. Технология создания программы в визуальных средах программирования делает ее интерфейс универсальным и совместимым с операционными системами Windows 7/8/10. Экономические факторы. Программа представляет наилучшее соотношение цены и предоставляемых ей возможностей и несомненно займет свою нишу на рынке дешевых программ. Основными пользователями станут представители бизнеса, которые просто не могут заплатить за дорогие программы фирмы 1С и ей подобных. 2.2 Цели разработки программы Создание данной программы преследует ряд технико-экономических целей: Создание программного продукта, необходимого для учёта рабочего времени. Создание дешевой альтернативы существующим в настоящее время дорогим программам. Создание интуитивно понятной программы с удобным и универсальным Windows. Техническое задание (ТЗ) - исходный документ,который является основанием для разработки и испытания программы или автоматизированной системы. Техническое задание на программу и программное обеспечение разрабатывается в соответствии с требованиями. Основанием для разработки ТЗ чаще всего является договор. ТЗ на программу разрабатывается, прежде всего, для тех людей, которые в последствии будут разрабатывать программный продукт. Как и любое другое ТЗ на программу должно быть предельно ясно и не содержать двусмысленные формулировки и должно максимально полно описывать все требования и пожелания Заказчика к создаваемой программе, но при этом не стоит забывать, что программисты люди творческие и освоить 150 листов технического текста им не всегда под силу. Кому поручить написание ТЗ на программу Хочется акцентировать внимание на часто совершаемой ошибке – поручить написание технического задание на программный продукт программисту, обосновывая тем, что программисту будет проще потом реализовывать собственное техзадание. Техническое задание на программу должно разрабатываться техническим писателем! Во-первых, помимо знания ГОСТ 19.201-78, необходимо знание и других стандартов (например, ГОСТ 19.106-78 , ГОСТ 19.104 – 78 и др.), не многие программисты знают эти ГОСТы, а ещё меньше согласятся их изучить. Во-вторых, необходимы знания и опыт владения техническим письменным языком (не путать с написанием кода программного обеспечения). В-третьих, только совместно работающая команда (технический писатель, программист, менеджер проекта) смогут вместе разработать полноценное техническое задание на программу и программное обеспечение. Структура технического задания Любая работа начинается с задания, а работа технического писателя должна начинаться с технического задания. Осталось только разобраться, что это такое и зачем оно нам нужно. Прочитайте статью Кимберли Чан, чтобы не попасть в такую же ситуацию, как разработчик из уже любимой нами серии комиксов. Что такое техническое задание на разработку программного обеспечения? Большинство разработчиков предпочитают работать с техническим заданием на разработку программного обеспечения, так как этот документ обычно содержит следующее: Полное описание целей и функциональности программного обеспечения; Детали того, как программа будет работать с точки зрения скорости, времени отклика, доступности, мобильности, надёжности, скорости восстановления и т.д.; Варианты того, как пользователи будут использовать программное обеспечение; Определение того, как приложение будет взаимодействовать с оборудованием или другими программами; Нефункциональные требования (например: требования к обеспечению эффективности, стандарты качества, или проектные ограничения) |