Программная инженерия лабораторный практикум
 Скачать 1.48 Mb.
|
|
Министерство образования и науки Российской Федерации Южно-Российский государственный технический университет (Новочеркасский политехнический институт) имени М.И. Платова __________________________________________________ ПРОГРАММНАЯ ИНЖЕНЕРИЯ ЛАБОРАТОРНЫЙ ПРАКТИКУМ учебно-методическое пособие к лабораторным работам для направления подготовки 09.03.03 «Прикладная информатика» Новочеркасск ЮРГТУ(НПИ) 2013 2 УДК 004.4 (075.8) Рецензент: кандидат технических наук, доцент Гринченков Д.В. (ЮРГПУ(НПИ)) Составитель - В.А.Зуев Программная инженерия. Лабораторный практикум: учебно- методическое пособие к лабораторным работам/В.А. Зуев; Южно-Российский государственный технический университет (НПИ) имени М.И. Платова – Ново- черкасск: ЛиК, 2013. – 52с. Представлены материалы для проведения лабораторного практикума по дисциплине «Программная инженерия». Содержит методические рекомендации по применению современных инструментальных средств на этапе проектиро- вания программного обеспечения на основе UML, тестирования, отладки про- грамм и получения метрик кода в среде MS Visual Studio. Пособие предназначено для студентов, обучающихся по направлению подготовки 09.03..03 Прикладная информатика всех форм обучения. УДК 004.4(075.8) © Южно-Российский государственный технический университет (НПИ) имени М.И.Платова, 2013 3 Содержание Введение……………………………………….……………..……4 Лабораторная работа №1. Разработка спецификаций систем- ных требований к программному продукту…….…….............5 Лабораторная работа №2. Функциональное моделирование программного продукта………….…………………….……….10 Лабораторная работа №3. Расчет характеристик модульной программной системы …………………………………………. 15 Лабораторная работа №4. Разработка диаграмм классов на язы- ке UML………………………………………………..…………..19 Лабораторная работа №5. Разработка диаграмм взаимодействия объектов на языке UML………………………………………..25 Лабораторная работа №6. Разработка диаграмм поведения на языке UML………………………………………………………30 Лабораторная работа №7. Реализация компонентов программ- ных средств……………………………………………………35 Лабораторная работа №8. Тестирование и отладка программ- ных средств……………………………………………………40 Лабораторная работа №9. Вычисление метрик программных систем…………………………………………………………..47 Список литературы…………………………………………….51 4 ВВЕДЕНИЕ Дисциплина «Программная инженерия» относится к дисципли- нам базовой части учебного плана. Она формирует базовые знания проектирования качественных программных систем (ПС) в различ- ных областях приложений. Для решения этих задач требуется гра- мотная организация процесса создания ПС, реализация технологиче- ских принципов и методов (формирования требований, анализа, син- теза и тестирования) промышленного конструирования. Цель преподавания дисциплины: изучение современных инже- нерных принципов (методов) создания надежного, качественного программного обеспечения (ПО), удовлетворяющего предъявляемым к нему требованиям; формирование у студентов понимания необхо- димости применения данных принципов программной инженерии. Задачи данного практикума дисциплины: освоить на практиче- ских примерах и научить студентов формулировать требования к создаваемым программным комплексам; формировать архитектуру программных комплексов различного назначения, разрабатывать про- граммные приложения; владеть навыками разработки программных комплексов для решения прикладных задач, оценки сложности алго- ритмов и программ, использования современных технологий про- граммирования, тестирования и документирования программных комплексов; получить представление и уметь использовать основные международные и отечественные стандарты в области программной инженерии. В лабораторном практикуме студенты получают практические навыки работы с современными технологиями проектирования и про- граммных средств, используя для этого инструментальные средства UML (Rational Rose, Visual Studio), IDEF. В качестве инструменталь- ной среды разработки ПС используется MS Visual Studio .Net, кото- рая позволяет писать программы на разных языках программирова- ния высокого уровня, эффективно выполнять отладку и тестирование, получать числовые метрики кода для оценки сложности программ- ного продукта. Выполнение лабораторного практикума содержит элементы курсовой работы, поэтому для лабораторных работ используется сквозной объект в индивидуальных заданиях. 5 Лабораторная работа №1 РАЗРАБОТКА СПЕЦИФИКАЦИЙ СИСТЕМНЫХ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ПРОДУКТУ Цель работы: изучение требований к создаваемому программному продукту, разработка технического задания Программа выполнения работы 1. Изучить нормативные документы по разработке технического задания на разработку программного продукта. 2. Разработать техническое задание на программный продукта по задан- ному варианту. Содержание отчета Техническое задание на программный продукт Методические указания Техническое задание представляет собой документ, в котором сформулированы основные цели разработки, требования к программ- ному продукту, определены сроки и этапы разработки и регламенти- рован процесс приемно-сдаточных испытаний. В разработке техниче- ского задания участвуют как представители заказчика, так и предста- вители исполнителя. В основе этого документа лежат исходные тре- бования заказчика, анализ передовых достижений техники, результа- ты выполнения научно-исследовательских работ, предпроектных ис- следований, научного прогнозирования и т. п. Основные факторы, определяющие характеристики разрабатывае- мого программного обеспечения: - исходные данные и требуемые результаты, которые определяют функции программы или системы; - среда функционирования (программная и аппаратная); может быть задана, а может выбираться для обеспечения параметров, указанных в техническом задании; - возможное взаимодействие с другим программным обеспече- нием или специальными техническими средствами - также может 6 быть определено, а может выбираться исходя из набора выполняемых функций. Разработка технического задания выполняется в следующей по- следовательности. Прежде всего, устанавливают набор выполняемых функций, а также перечень и характеристики исходных данных. Затем определяют перечень результатов, их характеристики и способы пред- ставления. Далее уточняют среду функционирования программного обеспече- ния: конкретную комплектацию и параметры технических средств, версию используемой операционной системы и, возможно, версии и параметры другого установленного программного обеспечения, с ко- торым предстоит взаимодействовать будущему программному про- дукту. В случаях, когда разрабатываемое программное обеспечение соби- рает и хранит некоторую информацию или включается в управление каким-либо техническим процессом, необходимо также четко регла- ментировать действия программы в случае сбоев оборудования и энергоснабжения. На техническое задание существует стандарт ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». В соответствии с этим стандартом техническое задание должно содер- жать следующие разделы: - введение; - основания для разработки; - назначение разработки; - требования к программе или программному изделию; - требования к программной документации; - технико-экономические показатели; - стадии и этапы разработки; - порядок контроля и приемки. При необходимости допускается в техническое задание включать приложения. Рассмотрим более подробно содержание каждого раздела. Введение должно включать наименование и краткую характеристи- ку области применения программы или программного продукта, а также объекта (например, системы) в котором предполагается их ис- пользовать. Назначение введения - продемонстрировать актуальность данной разработки и показать, какое место эта разработка занимает в ряду подобных. 7 Раздел Основания для разработки должен содержать наименова- ние документа, на основании которого ведется разработка, организа- ции, утвердившей данный документ, и наименование или условное обозначение темы разработки. Таким документом может служить план, приказ, договор и т. п. Раздел Назначение разработки должен содержать описание функ- ционального и эксплуатационного назначения программного продук- та с указанием категорий пользователей. Раздел Требования к программе или программному изделию дол- жен включать следующие подразделы: - требования к функциональным характеристикам; - требования к надежности; - условия эксплуатации; - требования к составу и параметрам технических средств; - требования к информационной и программной совместимости; - требования к маркировке и упаковке; - требования к транспортированию и хранению; - специальные требования. Наиболее важным из перечисленных выше является подраздел Требования к функциональным характеристикам. В этом разделе должны быть перечислены выполняемые функции и описаны состав, характеристики и формы представления исходных данных и результа- тов. В этом же разделе при необходимости указывают критерии эф- фективности: максимально допустимое время ответа системы, мак- симальный объем используемой оперативной и/или внешней памяти и др. Примечание. Если разработанное программное обеспечение не будет выполнять указанных в техническом задании функций, то оно считается не соответствующим техническому заданию, т. е. непра- вильным с точки зрения критериев качества. Универсальность буду- щего продукта также обычно специально не оговаривается, но подра- зумевается. В подразделе Требования к надежности указывают уровень на- дежности, который должен быть обеспечен разрабатываемой систе- мой и время восстановления системы после сбоя. Для систем с обыч- ными требованиями к надежности в этом разделе иногда регламенти- руют действия разрабатываемого продукта по увеличению надежно- сти результатов (контроль входной и выходной информации, создание резервных копий промежуточных результатов и т. п.). 8 В подразделе Условия эксплуатации, указывают особые требо- вания к условиям эксплуатации: температуре окружающей среды, от- носительной влажности воздуха и т. п. Как правило, подобные требо- вания формулируют, если разрабатываемая система будет эксплуати- роваться в нестандартных условиях или использует специальные внешние устройства, например для хранения информации. Здесь же указывают вид обслуживания, необходимое количество и квалифика- ция персонала. В противном случае допускается указывать, что тре- бования не предъявляются. В подразделе Требования к составу и параметрам технических средств указывают необходимый состав технических средств с ука- занием их основных технических характеристик: тип микропроцессо- ра, объем памяти, наличие внешних устройств и т. п. При этом часто указывают два варианта конфигурации: минимальный и рекомендуе- мый. В подразделе Требования к информационной и программной со- вместимости при необходимости можно задать методы решения, оп- ределить язык или среду программирования для разработки, а также используемую операционную систему и другие системные и пользо- вательские программные средства, с которым должно взаимодейство- вать разрабатываемое программное обеспечение. В этом же разделе при необходимости указывают, какую степень защиты информации необходимо предусмотреть. В разделе Требования к программной документации указывают необходимость наличия руководства программиста, руководства поль- зователя, руководства системного программиста, пояснительной за- писки и т. п. На все эти типы документов также существуют ГОСТы. В разделе Технико-экономические показатели рекомендуется указывать ориентировочную экономическую эффективность, предпо- лагаемую годовую потребность и экономические преимущества по сравнению с существующими аналогами. В разделе Стадии и этапы разработки указывают стадии раз- работки, этапы и содержание работ с указанием сроков разработки и исполнителей. В разделе Порядок контроля и приемки указывают виды испы- таний и общие требования к приемке работы. В приложениях при необходимости приводят: перечень научно- исследовательских работ, обосновывающих разработку; схемы алго- 9 ритмов, таблицы, описания, обоснования, расчеты и другие докумен- ты, которые следует использовать при разработке. В зависимости от особенностей разрабатываемого продукта раз- решается уточнять содержание разделов, т. е. использовать подразде- лы, вводить новые разделы или объединять их. В случаях, если какие-либо требования, предусмотренные тех- ническим заданием, заказчик не предъявляет, следует в соответст- вующем месте указать «Требования не предъявляются». Разработка технического задания - процесс трудоемкий, тре- бующий определенных навыков. Наиболее сложным, как правило, яв- ляется четкое формулирование основных разделов: введения, назна- чения и требований к программному продукту. Контрольные вопросы 1. Что понимают под технологичностью программного обеспе- чения? Почему? 2. Какие типы программных продуктов можно выделить? Чем они различаются? 3. Назовите основные эксплуатационные требования к про- граммным продуктам. Какими средствами и приемами обеспечивает- ся каждый из них? Для каких типов программных систем целесооб- разно указывать каждый из них? 4. В каких ситуациях необходимы предпроектные исследова- ния? Какие вопросы при этом решают? Что получают в результате таких исследований? 5. Назовите, какой раздел технического задания можно считать основным и почему? Какую информацию должны содержать осталь- ные разделы? В чем основная сложность разработки технического за- дания? Варианты заданий 1. Программа учета домашней медиатеки 2. Программа планирования дел «Ежедневник» 3. Информационная система учета услуг в автомастерской 4. Программа информационной поддержки спортивных сорев- нований 5. Информационно-справочная система для продажи билетов в кинотеатре 10 6. Программа учета и анализа продаж в продовольственном ма- газине 7. Информационная система факультета «Абитуриент» 8. Программа информационного обеспечения фестиваля худо- жественной самодеятельности студентов 9. Программа информационной поддержки спартакиады уни- верситета 10. Программа учета и анализа доходов и расходов семьи 11. Программа формирования счетов-квитанций для жильцов ТСЖ 12. Система управления теплицей 13. Программа обработки данных аттестации студентов 14. Визуальный конструктор Е-сетей 15. Программа управления очередностью обслуживания клиен- тов в поликлинике 16. Программа терминала оплаты за услуги населению 17. Программа информационной поддержки спортивных сорев- нований 18. Программа учета контингента студентов на факультете 19. Программу «Маклер» для учета заявок на обмен квартир и поиска вариантов обмена 20. Компьютерная игра «Сражение роботов» Лабораторная работа №2 ФУНКЦИОНАЛЬНОЕ МОДЕЛИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА Цель работы: функциональное моделирование программного про- дукта с использованием диаграммы вариантов использования UML Программа выполнения работы 1. Изучить технологию построения диаграммы вариантов ис- пользования в среде CASE системы Rational Rose 2. Произвести построение диаграммы вариантов использовани- ям среды Rational Rose на примере программной системы из лаб. Ра- боты №1. 11 Методически указания Работа над моделью в среде IBM Rational Rose начинается с об- щего анализа проблемы и построения диаграммы вариантов исполь- зования, которая отражает функциональное назначение проектируе- мой программной системы. В качестве проекта далее будет рассматриваться модель систе- мы управления банкоматом. Достоинством этого проекта является то, что он не требует специального описания предметной области, по- скольку предполагает интуитивное знакомство читателей с особенно- стями функционирования банкомата. При этом разрабатываемая мо- дель системы управления банкоматом используется в качестве сквоз- ного примера, в рамках которого иллюстрируются особенности раз- работки различных диаграмм языка UML в среде IBM Rational Rose 2003. Назначение отдельных кнопок данной панели можно узнать также из всплывающих подсказок, которые появляются, если подвес- ти и задержать на некоторое время указатель мыши над той или иной кнопкой (табл. 2.1). На специальной панели инструментов по умол- чанию присутствует только часть кнопок с пиктограммами элемен- тов, которые могут быть использованы для построения диаграммы. Добавить кнопки с пиктограммами других графических элементов, например, таких как бизнес-вариант использования (business use case), бизнес-актер (business actor), сотрудник (business worker), или удалить ненужные кнопки можно с помощью настройки специальной панели инструментов. Открыть диалоговое окно настройки специальных панелей ин- струментов для диаграмм в среде IBM Rational Rose 2003 можно с помощью операции главного меню: Tools Options (Инструменты Параметры), раскрыв вкладку Toolbars (Панели инструментов) и на- жав соответствующую кнопку (например, Use Case diagram) в груп- пе опций Customize Toolbars (Настройка панелей инструментов). Это окно настройки также можно открыть с помощью операции кон- текстного меню Customize (Настройка) при позиционировании кур- сора на специальной панели инструментов (рис. 2.1). 12 Таблица 2.1. Назначение кнопок специальной панели инструментов для диа- граммы вариантов использования Графическое изображение Всплывающая подсказка Назначение кнопки Selection Tool Превращает изображение курсора в форму стрелки для последующего выделения элементов на диаграмме |