Практикум для выполнения лабораторных работ состоит из семнадцати лабораторных работ по дисциплинам Спецификация, архитектура и проектирование программных систем
 Скачать 2.9 Mb.
|
|
Программная инженерия Лабораторный практикум Москва Берлин 2021 УДК 004.432(075) ББК 32.973я73 П78 Программная инженерия : лабораторный практикум / П78 Д. Г. Лагерев [и др.]. — Москва ; Берлин : Директ-Медиа, 2021. — 156 с. ISBN 978-5-4499-2105-5 Содержатся семнадцать лабораторных работ по дисциплинам «Спецификация, архитектура и проектирование программных систем», «Технология разработки программного обеспечения». Практикум предназначен для студентов очной формы обучения по направлениям подготовки 09.03.04 «Программная инженерия», 09.03.01 «Информатика и вычислительная техника», 02.03.03 «Математическое обеспечение и администрирование информационных систем». УДК 004.432(075) ББК 32.973я73 ISBN 978-5-4499-2105-5 © Д. Г. Лагерев, Д. А. Коростелев, А. А. Азарченков, Е. В. Коптенок, текст, 2021 © Издательство «Директ-Медиа», оформление, 2021 Предисловие Практикум для выполнения лабораторных работ состоит из семнадцати лабораторных работ по дисциплинам «Спецификация, архитектура и проектирование программных систем», « Технология разработки программного обеспечения». В каждой лабораторной работе содержатся теоретические сведения, необходимые для выполнения работы, индивидуальные задания и контрольные вопросы. В практикуме приведен перечень литературы, необходи- мый для успешного освоения дисциплины. Лабораторные работы способствуют более глубокому изучению дисциплины, развивают у студентов практические навыки разработки программного обеспечения. Лабораторный практикум предназначен для студентов очной формы обучения по направлениям подготовки 09.03.04 «Программная инженерия», 09.03.01 «Информатика и вычис- лительная техника», 02.03.03 «Математическое обеспечение и администрирование информационных систем». 4 Лабораторная работа 1. Разработка технического задания Цель работы Целью лабораторной работы является изучение реко- мендаций стандартов на составление технического задания и получение практических навыков в разработке и структуриза- ции требований в пределах одной проблемной области. Теоретические сведения Стандарты разработки требований к ПО ГОСТ 19.201-78 ГОСТ 34.602-89 IEEE 830-1998 Recommended Practice for Software Re- quirements Specifications ( рекомендуемые методы специфи- кации требований к ПО). Данный стандарт описывает рекомендуемые принципы составления спецификации требо- ваний к программному обеспечению. Она основана на модели, в которой результат процесса спецификации программного обеспечения является однозначным и полным документом. Техническое задание (ТЗ, техзадание) — исходный до- кумент для проектирования сооружения или промышленного комплекса, конструирования технического устройства (прибо- ра, машины, системы управления и т. д.), разработки информа- ционных систем, стандартов либо проведения научно- исследовательских работ (НИР). Мастер ТЗ — бесплатная программа для создания техни- ческого задания к разработке программного обеспечения. Программа обеспечивает легкое создание профессионального ТЗ на разрабатываемую программу в режиме пошагового ма- стера в соответствии с ГОСТ. Ход работы При составлении технического задания требуется запол- нить и скорректировать все пункты, указанные в левой части окна. Важно помнить, что в шаблоне следует удалить все лиш- нее, не относящееся к Вашему проекту. В первом пункте необходимо ввести название програм- мы (рис. 1.1). Важно учитывать, что название «Курсовая рабо- 5 та» неправильно. Формулировку названия следует взять из темы курсовой работы. Рис. 1.1. Наименование программы Далее следует задать назначение и область применения программы (рис. 1.2). Стоит отметить, что защита курсовой работы не относится к данному пункту. Под назначением по- нимается та область деятельности, к которой применим про- граммный продукт. Рис. 1.2. Назначение и область применения программы Следующий пункт наиболее важный и сложный. Требова- ния к функциональным характеристикам содержат все требова- ния к функционалу и возможностям программы (рис. 1.3). Требования не должны быть противоречивыми и взаимно ис- ключающими. Более того, они должны быть полными. Например, для калькулятора должны быть подробно описано меню и огово- рены все вычисляемые функции, а также требования к интер- фейсу и способам вода и вывода информации. Требования к игре должны содержать описание способа управления, меню, правил игры и игрового процесса. Должны быть указаны все количе- ственные характеристики, например начисляемые очки и вели- чина бонусов, количество жизней героя, сила удара. Все возможные бонусы, виды врагов и т. д. должны быть оговорены. Важно отметить условие завершение игры (победа и поражение). Допускается оговорить возможность точного вычисления коли- чественных характеристик на этапе разработки и тестирования игры. 6 Рис. 1.3. Требования к функциональным характеристикам Требования к надежности программы не нуждаются в большом количестве изменений. Шаблонные требования мож- но оставить неизменными, но рекомендуется изучить. Воз- можно, они все-таки нуждаются в правках (рис. 1.4). Рис. 1.4. Требования к надежности программы Далее следует задать требования к квалификации пользо- вателей (рис. 1.5). Для неспециализированной программы до- статочно одного человека с минимальными навыками работы с ПК. Однако, некоторые игры требуют наличия двух человек. Рис. 1.5. Требования к квалификации пользователей Требования к составу и параметрам технических средств должны включать в себя требования к компьютеру, его техни- ческим характеристикам и операционной системе (рис. 1.6). 7 Рис. 1.6. Требования к составу и параметрам технических средств Требования к исходным кодам и языкам программирова- ния содержат информацию о средствах, с помощью которых создана программа (рис. 1.7). Рис. 1.7. Требования к исходным кодам и языкам программирования Очень важно удалить из требования те средства, которые не используются при написании программы, например систе- мы баз данных, серверы и различные специфические среды и платформы. Требования к защите информации и программ при раз- работке программы для курсовой работы не предъявляются, ели это не оговорено отдельно (рис. 1.8). Рис. 1.8. Требования к защите информации и программ 8 Стадии и этапы разработки программы включают в себя шесть пунктов (рис. 1.9). Рис. 1.9. Стадии и этапы разработки Каждый из этих пунктов подробно описывается в соот- ветствующих разделах технического задания (рис. 1.10). Рис. 1.10. Содержание работ по этапам В требованиях к приемке работы указывается условия защиты курсовой работы и порядок ее приема (рис. 1.11). Рис. 1.11. Общие требования к приемке работы 9 После завершения разработки технического задания, его следует экспортировать в удобный для распространения фор- мат, поскольку хранить и передавать документ, который мож- но открыть только при помощи специальной программы, неудобно. В меню выберете команду экспорта технического зада- ния (рис. 1.12). Рис. 1.12. Команда экспорта ТЗ в меню программы Появилось окно предварительного просмотра техниче- ского задания в формате текстового документа (рис. 1.13). Рис. 1.13. Предварительный просмотр экспортируемого технического задания 10 Далее необходимо нажать на кнопку «Экспорт» на панели задач (рис. 1.14). Рис. 1.14. Кнопка «Экспорт» на панели задач В появившемся окне следует выбрать путь сохраняемого файла, указать его имя и тип (рис. 1.15). Рис. 1.15. Сохранение файла с техническим заданием Индивидуальные задания В соответствии с выбранной темой и результатами, по- лученными при выполнении предыдущих работ разработать техническое задание по одной из приведенных форм с уточне- нием требований по соответствующему стандарту. Контрольные вопросы 1. Что такое техническое задание? 2. Какую информацию должно содержать техническое задание? 3. Для чего требуется составлять техническое задание при написании программ? 4. Какие ГОСТы на технические задания существуют? 5. Для чего применяется программа Мастер ТЗ? 6. Каковы условия распространения программы Мастер ТЗ? 12 Лабораторная работа 2. Разработка календарного плана проекта Цель работы Познакомиться с инструментами разработки календар- ного плана проекта. Теоретические сведения OpenProject — бесплатный аналог Microsoft Project. Дан- ное кроссплатформенное программное обеспечение предна- значено для планирования проектов и является очень хорошей заменой платного ПО. Проект состоит из совокупности взаимосвязанных работ. Работа отражает трудовой процесс. Каждая работа имеет конкретное содержание. Работа как трудовой процесс требует затрат времени и ресурсов. Под ресурсами обычно подразумеваются пользователи, включенные в план проекта, независимо от того, назначены ли им какие-либо задачи. Однако ресурсами также считается все, что используется для выполнения проекта, включая оборудование и другие материалы (например, компьютеры или веб-серверы). Диаграмма Гантта — это популярный тип столбчатых диаграмм (гистограмм), который используется для иллюстра- ции плана, графика работ по какому-либо проекту. Является одним из методов планирования проектов. По сути, диаграмма Гантта состоит из полос, ориентиро- ванных вдоль оси времени. Каждая полоса на диаграмме пред- ставляет отдельную задачу в составе проекта (вид работы), её концы — моменты начала и завершения работы, её протяжен- ность — длительность работы. Вертикальной осью диаграммы служит перечень задач. Кроме того, на диаграмме могут быть отмечены совокупные задачи, проценты завершения, указатели последовательности и зависимости работ, метки ключевых мо- ментов (вехи), метка текущего момента времени «Сегодня» и др. Ключевым понятием диаграммы Гантта является «Ве- ха» — метка значимого момента в ходе выполнения работ, общая граница двух или более задач. Вехи позволяют наглядно отобразить необходимость синхронизации, последовательно- сти в выполнении различных работ. 13 Ход работы Для начала следует создать новый проект (рис. 2.1). Рис. 2.1. Создание нового проекта В появившемся окне следует заполнить данные о новом проекте (рис. 2.2). Необходимо указать название проекта, авто- ра, дату начала проекта и краткие сведения. Рис. 2.2. Окно создания проекта После нажатия на кнопку «Ок» появится пустой проект. Внешний вид окна показан на рис. 2.3. 14 Рис. 2.3. Пустой проект Добавим в проект новую задачу. Для этого в первой строке введем ее название, дату начала и дату завершения (рис. 2.4). Заметим, что продолжительность выполнения задачи высчиты- вается автоматически. Если ввести только начальную дату и количество дней в поле «Продолжительность», дата окончания будет вычислена автоматически. Рис. 2.4. Создание новой задачи Добавим в проект еще одну задачу, в поле «Предшеству- ющие» впишем номер ранее созданной задачи — «1» (рис. 2.5). Таким образом, две задачи являются связанными. Рис. 2.5. Добавление предшествующей задачи Добавим еще несколько задач, соответствующих жизнен- ному циклу ПО (рис. 2.6). Рис. 2.6. Задачи проекта 15 Установим связи между задачами, как это показано на рис. 2.7. Рис. 2.7. Связанные задачи проекта Созданные задачи и их связи отобразились на Диаграмме Гантта (рис. 2.8). Рис. 2.8. Отображение связанных задач на Диаграмме Гантта Далее необходимо добавить к задачам исполнителей. Стоит отметить, что исполнители являются ресурсами проек- та. Перейдем к вкладке «Ресурсы», расположенной на боковой панели (рис. 2.9). Рис. 2.9. Переход в режим редактирования ресурсов 16 В диалоговом окне появится таблица с ресурсами проек- та. В рамках лабораторной работы нас интересуют только имена исполнителей. Добавим в проект двух исполнителей как это показано на рис. 2.10. Рис. 2.10. Добавление исполнителей в ресурсы проекта Назначим исполнителей проекта, вписав их имена в соот- ветствующее поле (рис. 2.11). Рис. 2.11. Назначение исполнителей задач В случае если мы попытаемся ввести имя несуществующе- го ресурса, программа выведет сообщение об ошибке, как это показано на рис. 2.12. Рис. 2.12. Ошибка при добавлении несуществующего ресурса Назначенные исполнители отобразятся на Диаграмме Гантта (рис. 2.13). Рис. 2.13. Отображение исполнителей на Диаграмме Гантта 17 В программе присутствует возможность фильтрации за- дач на Диаграмме Гантта, а также изменение масштаба отоб- ражения временной шкалы (рис. 2.14). Рис. 2.14. Изменение масштаба временной шкалы на Диаграмме Гантта Двойной клик мышью по задаче вызывает окно свойств этой задачи. Вкладка общие позволяет получить информацию о названии, продолжительности и проценте выполнения (рис. 2.15). Рис. 2.15. Вкладка «Общие» диалогового окна свойств задачи Вкладки «Предыдущие» и «Последующие» позволяют по- лучить информацию о связанных задачах. Интерес может представлять вкладка «Ресурсы», на которой будут отобра- жаться исполнители задачи. После завершения планирования проекта требуется со- хранить результаты работы. Индивидуальные задания Изучите теоретические сведения. Создайте новый проект по теме вашей дипломной. Выполните создание шести задач, соответствующих эта- пам разработки работы согласно этапам ЖЦПО. Сроки устано- вите самостоятельно. Назначьте задачи в соответствии с распределением ро- лей среди исполнителей. Назначьте предшествующие задачи. Отследите полученные результаты на Диаграмме Ганта. Сохраните изменения. Контрольные вопросы 1. Что такое OpenProject? 2. Что представляет собой проект в OpenProject? 3. Что представляет собой работа в OpenProject? 4. Что обычно подразумеваются под ресурсами? 5. Что такое Диаграмма Гантта? 6. Какие этапы присутствуют в календарном плане про- екта? 19 Лабораторная работа 3. Построение модели данных Цель работы Получить навыки разработки моделей данных информа- ционных систем. Теоретические сведения Цель моделирования данных состоит в обеспечении раз- работчика системы концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных (предметной области) является модель «сущность-связь» (ERM). Она была впервые введена Питером Ченом в 1976 г. Базо- выми понятиями ERM являются сущность, связь и атрибут. Сущность (Entity) — реальный либо воображаемый объ- ект, имеющий существенное значение для рассматриваемой предметной области. Каждая сущность должна иметь наименование, выра- женное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов, как «Постав- щик», «Сотрудник», «Заказ». Каждая сущность в модели изоб- ражается в виде прямоугольника с наименованием (рис. 3.1). Рис. 3.1. Графическое представление сущности Основной (неформальный) способ идентификации сущ- ностей — это поиск абстракций, описывающих физические или материальные объекты, процессы и события, роли людей, организации и другие понятия. Единственным формальным способом идентификации сущностей является анализ тексто- вых описаний предметной области, выделение из описаний имен существительных и выбор их в качестве «кандидатов» на роль абстракций. 20 Экземпляр сущности — это конкретный представитель данной сущности. Например, экземпляром сущности «Сотруд- ник» может быть «Сотрудник Иванов». Экземпляры сущностей должны быть различимы, т. е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности. Каждый экземпляр сущно- сти должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущ- ность должна обладать некоторыми свойствами: 1) иметь уникальное имя; к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами; 2) обладать одним или несколькими атрибутами, кото- рые либо принадлежат сущности, либо наследуются через связь; 3) обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности. Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой предметной области и предна- значенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т. д.). Экземпляр атрибута — это определенная характери- стика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называе- мым значением атрибута. В ERM атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущно- сти должен обладать единственным определенным значением для ассоциированного атрибута. Наименование атрибута должно быть выражено суще- ствительным в единственном числе (возможно, с характери- зующими прилагательными). Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты, как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т. п. 21 Атрибуты изображаются в пределах прямоугольника, определяющего сущность (рис. 3.2). Рис. 3.2. Сущность с атрибутами Виды атрибутов: − простой — состоит из одного элемента данных; − составной — состоит из нескольких элементов данных; − однозначный — содержит одно значение для одной сущности; − многозначный — содержит несколько значений для одной сущности; − необязательный — может иметь пустое (неопределен- ное) значение; − производный — представляет значение, производное от значения связанного с ним атрибута. Уникальным идентификатором называется неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточ- ность заключается в том, что удаление любого атрибута из уни- кального идентификатора нарушает его уникальность. Сущность может иметь несколько различных уникаль- ных идентификаторов, они изображаются на диаграмме под- черкиванием (рис. 3.3). Рис. 3.3. Сущность с уникальным идентификатором 22 Каждая сущность может обладать любым количеством свя- зей с другими сущностями модели. Связь (Relationship) — поиме- нованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущ- ности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот. Степенью связи называется количество сущностей, участ- вующих в связи. Связь степени 2 называется бинарной, степе- ни N — N-арной. Связь, в которой одна и та же сущность участвует в разных ролях, называется рекурсивной, или унарной. Пары чисел на диаграмме отражают две важные характе- ристики связи — мощность связи (второе число) и класс при- надлежности (первое число). Мощностью связи называется максимальное число эк- земпляров сущности, которое может быть связано с одним экземпляром данной сущности. Мощность связи может быть равна 1, N (любое число) и может быть конкретным числом. Класс принадлежности характеризует обязательность участия экземпляра сущности в связи. Класс принадлежности может принимать значение 0 (необязательное участие — экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть, и не связан ни с одним экземпляром) или 1 (обязательное участие — экземпляр одной сущности должен быть связан не менее чем с одним экземпляром другой сущности). Классы принадлежности на рис. 3.4 означают: каждый сотрудник обя- зательно работает в каком-либо отделе, а в некоторых отделах может и не быть сотрудников (рис. 3.4). Рис. 3.4. Обозначение сущностей и связи Связь может иметь один из следующих трех типов (в за- висимости от значения мощности): 1) один-к-одному (обозначается 1:1), показана на рис. 3.5. 23 Рис. 3.5. Связь типа 1:1 2) один-ко-многим (обозначается 1:N), показана на рис. 3.4. Многие-ко-многим (обозначается M:N), показана на рис. 3.6. Рис. 3.6. Связь типа m:n Существуют следующие виды идентификаторов: − первичный/альтернативный: сущность может иметь не- сколько идентификаторов (рис. 3.7). Один должен являться ос- новным (первичным), а другие — альтернативными. Первичный идентификатор на диаграмме подчеркивается. Альтернативные идентификаторы предваряются символами <1> для первого альтернативного идентификатора, <2> для второго и т. д. В кон- цептуальном моделировании данных различие первичных и альтернативных идентификаторов обычно не используется. В реляционной модели, полученной из концептуальной модели данных, первичные ключи используются в качестве внешних ключей. Альтернативные идентификаторы не копируются в качестве внешних ключей в другие таблицы; − простой/составной: идентификатор, состоящий из од- ного атрибута, является простым, из нескольких атрибутов — составным (рис. 3.7); Рис. 3.7. Составной альтернативный идентификатор 24 − абсолютный/относительный: если все атрибуты, со- ставляющие идентификатор, принадлежат сущности, то иден- тификатор является абсолютным. Если один или более атрибутов идентификатора принадлежат другой сущности, то идентификатор является относительным. Когда первичный идентификатор является относительным, сущность определя- ется как зависимая сущность, поскольку ее идентификатор зависит от другой сущности. В примере на рис. 3.8. идентифи- катор сущности «Строка-заказа» является относительным. Он включает идентификатор сущности «Заказ», что показано на рисунке подчеркиванием 1.1. Рис. 3.8. Относительный идентификатор Как и сущности, связи могут иметь атрибуты. В примере на рис. 3.9. для того, чтобы найти оценку студента, нужно знать не только идентификатор студента, но и номер курса. Оценка не является атрибутом студента или атрибутом курса; она является атрибутом обеих этих сущностей. Это атрибут связи между сту- дентом и курсом, которая в примере называется «Регистрация». Рис. 3.9. Связь с атрибутами Связь между сущностями в концептуальной модели дан- ных является типом, который представляет множество экзем- пляров связи между экземплярами сущностей. Для того чтобы идентифицировать определенный экземпляр сущности, ис- пользуется идентификатор сущности. Точно так же для опре- деления экземпляров связи между сущностями требуется 25 идентификатор связи. Так, в примере на рис. 3.9.идентифика- тором связи «Регистрация» является идентификатор студента и номер курса, поскольку вместе они определяют конкретный экземпляр связи студентов и курсов. |