ПР 10-12 по УП 02. Инструкция по выполнению заданий
 Скачать 155.91 Kb.
|
|
ИНСТРУКЦИЯ ПО ВЫПОЛНЕНИЮ ЗАДАНИЙ: Изучите теоретический материал, приведенный ниже Выполните задания практической части. Оформите отчет о выполнении практической работы Внесите соответствующие записи в дневник по УП. 02. Требования к отчету Отчёт по практической работе оформляется индивидуально каждым студентом, выполнившим необходимые практические задания. На первом листе отчета необходимо в колонтитуле указать ФИО и номер группы. В заглавии отчет должен содержать фразу: Отчёт по практической работе № __ Тема: «Название работы» Отчёт должен содержать следующие основные разделы: 1 Результаты: скриншоты, показывающие результаты выполнения заданий и, возможно, листинг программного кода (скопировать и вставить как текст в одну или две колонки (если код большой) шрифт 12, междустрочный интервал - одинарный)); 2 Ответы на контрольные вопросы Инструкционно-технологическая карта Практическая работа №10
Ход работы Прочитать теоретический материал. Выполнить задание. Составить отчет по выполненной работе. Сдать преподавателю и защитить отчет. ТЕОРЕТИЧЕСКИЙ МАТЕРИАЛ ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ СТРУКТУРНОМ ПОДХОДЕ Процесс проектирования программного обеспечения включает в себя определение структурных компонентов программной системы и связей между ними. Результат уточнения структуры может быть представлен в виде структурной схемы, которая дает достаточно полное представление о проектируемом программном обеспечении. На рис. 6 приведена структурная схема программного обеспечения автоматизированной информационной системы «Склад оптовой торговли».  Рисунок 6. Структурная схема программного обеспечения АИС «Склад оптовой торговли» Функциональная схема — это схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Схемы могут использоваться на различных уровнях детализации, при этом число уровней зависит от размеров и сложности задачи обработки данных. Уровень детализации должен быть таким, чтобы различные части и взаимосвязь между ними были понятны в целом. Схемы данных отображают путь данных при решении задач и определяют этапы обработки, а также различные применяемые носители данных. Схема данных состоит из следующих символов: ■ символы данных (символы данных могут также указывать вид носителя данных); ■ символы процесса, производимого с данными (символы процесса могут также указывать функции, выполняемые вычислительной машиной); ■ символов линий, указывающих потоки данных между процессами и (или) носителями данных; ■ специальные символы, используемые для облегчения написания и чтения схемы. Схемы программ отображают последовательность операций в программе. Схема программы состоит из следующих символов: ■ символы процесса, указывающие фактические операции обработки данных (включая символы, определяющие путь, которого следует придерживаться с учетом логических условий); ■ линейные символы, указывающие поток управления; ■ специальные символы, используемые для облегчения написания и чтения схемы. Схемы работы системы отображают управление операциями и поток данных в системе. Схема работы системы состоит из следующих символов: ■ символы данных, указывающие на наличие данных (символы данных могут также указывать вид носителя данных); ■ символы процесса, указывающие операции, которые следует выполнить над данными, а также определяющие логический путь, которого следует придерживаться; ■ линейные символы, указывающие потоки данных между процессами и (или) носителями данных, а также поток управления между процессами; ■ специальные символы, используемые для облегчения написания и чтения блок-схемы. Для изображения функциональных схем используют специальные обозначения, установленные ГОСТ 19.701—90 (http://docs.cntd.ru/document/gost-19-701-90-espd) ПРАКТИЧЕСКАЯ ЧАСТЬ Задание 1. Изучите функциональную схему программной системы, реализующей операцию продажи товара автоматизированной информационной системы «Склад оптовой торговли». представленную в приложении 3 страница 51-52. Задание 2. На основании технического задания и анализа требований к программному обеспечению в предыдущих работах разработать структурные и функциональные схемы программного обеспечения по своему варианту задания. Задание 3. Создайте консольное приложение на C# в Visual Studio, используя методические рекомендации (Приложение 6) Задание 3. Составить отчет о выполненной работе, содержащий скриншоты выполнения заданий и текстовые пояснения к построенным диаграммам КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Приведите пример структурной схемы ПО. 2. Для чего используют функциональные схемы? 3. Опишите основные элементы функциональных схем ПО. 4. В чем заключаются достоинства и недостатки использования функциональных схем? Инструкционно-технологическая карта Практическая работа №11
Ход работы Прочитать теоретический материал. Выполнить задание. Составить отчет по выполненной работе. Сдать преподавателю и защитить отчет. ТЕОРЕТИЧЕСКИЙ МАТЕРИАЛ ПРИМЕНЕНИЕ ОБЪЕКТНООРИЕНТИРОВАННОГО ПОДХОДА В АНАЛИЗЕ И ПРОЕКТИРОВАНИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Разработку спецификаций программного обеспечения начинают с анализа требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого программного обеспечения и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями. Аспекты поведения программного обеспечения были названы вариантами использования, или прецедентами (use cases). Не следует путать вариант использования с конкретными операциями будущей системы. Каждый вариант использования связан с некоторой целью, имеющей самостоятельное значение; например, для текстового редактора формирование оглавления — это вариант использования, а связывание заголовков со специальными стилями — операция, которую необходимо выполнить, чтобы стало возможно автоматическое построение оглавления. В зависимости от цели выполнения процедуры различают следующие варианты использования: ■ основные (базовые) — обеспечивают требуемую функциональность разрабатываемого ПО; ■ вспомогательные — обеспечивают выполнение необходимых настроек системы и ее обслуживание (например, архивирование информации и т.п.); ■ дополнительные — обеспечивают дополнительные удобства для пользователя (как правило, реализуются, если не требуют серьезных затрат каких-либо ресурсов ни при разработке, ни при эксплуатации). Графических средств языка UML на практике оказывается недостаточно для спецификации функциональных требований к программной системе. Следует отметить, что одним из требований языка UML является самодостаточность диаграмм для представления информации о моделях проектируемых систем. Однако изобразительных средств языка UML явно не хватает для того, чтобы учесть на диаграммах вариантов использования особенности функционального поведения сложной системы. С этой целью рекомендуется дополнять этот тип диаграмм текстовыми сценариями, которые уточняют или детализируют последовательность действий, совершаемых системой при выполнении ее вариантов использования. В контексте языка UML сценарий используется для дополнительной иллюстрации взаимодействия актеров и вариантов использования. Предлагаются различные способы представления или написания подобных сценариев. Один из таких шаблонов представлен на рисунке 1 и может быть рекомендован для применения на начальных этапах концептуального моделирования. В зависимости от уровня абстракции вариант использования может описываться кратко или более подробно. Краткая форма описания содержит: имя варианта использования, перечень действующих лиц (актеров) и тип варианта использования (основной, вспомогательный или дополнительный) и его краткое описание.  Рисунок 1. Шаблон для написания сценария отдельного варианта использования При написании сценариев вариантов использования важно понимать, что текст сценария должен дополнять или уточнять диаграмму вариантов использования, но не заменять ее полностью. В противном случае будут потеряны достоинства визуального представления моделей. Основные понятия. Диаграммы вариантов использования. Диаграммы вариантов использования позволяют наглядно представить ожидаемое поведение программной системы. Основными понятиями диаграмм вариантов использования являются: действующее лицо, вариант использования и связь. На рис. 2 приведены условные обозначения, которые применяют при изображении диаграмм вариантов использования.  Рисунок 2. Основные условные обозначения диаграмм вариантов использования; а — действующее лицо; б — вариант использования; в — связь Действующее лицо — внешняя по отношению к разрабатываемому программному обеспечению сущность, которая взаимодействует с ним в целях получения или предоставления какой-либо информации. Как уже упоминалось выше, действующими лицами могут быть пользователи, другое программное обеспечение или какие-либо технические средства. Вариант использования — некоторая очевидная для действующего лица процедура, решающая его конкретную задачу. Все варианты использования так или иначе связаны с требованиями к функциональности разрабатываемой системы и могут сильно различаться по объему выполняемой работы (рис. 3). Связь — взаимодействие действующих лиц и соответствующих вариантов использования. Варианты использования также могут быть связаны между собой. При этом фиксируют связи использования и расширения. Использование (uses (include)) подразумевает, что существует некоторый фрагмент поведения разрабатываемого ПО, который повторяется в нескольких вариантах использования. Этот фрагмент оформляют как отдельный вариант и указывают связь с ним типа «использование». Расширение (extends) применяют, если имеется два подобных варианта использования, различающиеся наличием в одном из них некоторых дополнительных действий. В этом случае дополнительные действия определяют как отдельный вариант использования, который связан с основным вариантом связью типа «расширение». Главное назначение диаграммы вариантов использования заключается в формализации функциональных требований к системе и возможности согласования полученной модели с заказчиком на ранней стадии проектирования. Любой из вариантов использования может быть подвергнут дальнейшей декомпозиции на множество подвариантов использования отдельных элементов, которые образуют исходную сущность.  Рисунок 3. Пример диаграммы вариантов использования для тестовой системы РЕКОМЕНДАЦИИ К РАЗРАБОТКЕ ДИАГРАММ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ. Как было отмечено ранее, одно из главных назначений диаграммы вариантов использования заключается в формализации функциональных требований к системе. Диаграмма вариантов использования может служить основой для согласования с заказчиком функциональных требований к системе на ранней стадии проектирования. Любой из базовых вариантов использования в последующем может быть подвергнут декомпозиции на частные варианты использования. При этом рекомендуется, чтобы общее количество актеров в модели не превышало 20, а вариантов использования — 50. В противном случае модель теряет свою наглядность и, возможно, заменяет собой одну из некоторых других диаграмм. Для разработки диаграммы вариантов использования рекомендуется соблюдать некоторую последовательность действий: ■ определить главных, или первичных, и второстепенных актеров; ■ определить цели главных актеров по отношению к системе; ■ сформулировать основные варианты использования, которые специфицируют функциональные требования к системе; ■ упорядочить варианты использования по степени убывания риска их реализации; ■ рассмотреть все базовые варианты использования в порядке убывания их степени риска; ■ выделить участников, интересы, предусловия и постусловия выполнения выбранного варианта использования; ■ написать успешный сценарий реализации выбранного варианта использования; ■ определить исключения или неуспех в выполнении сценария варианта использования; ■ написать сценарии для всех исключений; ■ выделить общие варианты использования и изобразить их взаимосвязи с базовыми со стереотипом uses (include); ■ выделить варианты использования для исключений и изобразить их взаимосвязи с базовыми со стереотипом extend; ■ проверить диаграмму на отсутствие дублирования вариантов использования и актеров. Семантика построения диаграммы вариантов использования должна определяться следующими особенностями рассмотренных выше элементов модели. Отдельный экземпляр варианта использования по своему содержанию является выполнением последовательности действий, которая инициализируется посредством экземпляра сообщения от экземпляра актера. В качестве отклика или ответной реакции на сообщение актера выполняется последовательность действий, установленная для данного варианта использования. При этом актеры могут генерировать новые сообщения для инициирования вариантов использования. Подобное взаимодействие будет продолжаться до тех пор, пока не закончится выполнение требуемой последовательности действий экземпляром варианта использования и указанный в модели экземпляр актера не получит требуемый экземпляр сервиса. Окончание взаимодействия означает отсутствие инициализации сообщений от актеров для базовых вариантов использования. Варианты использования могут быть дополнительно специфицированы примечаниями с текстом, которые в последующем могут стать прототипами операций и методов совместно с атрибутами. Дальнейшая разработка моделей связана с реализацией вариантов использования в виде графа деятельности посредством конечного автомата или любого другого механизма логического представления поведения, включающего предусловия и постусловия. Взаимодействие между вариантами использования и актерами может уточняться на диаграмме кооперации, когда описываются взаимосвязи между системой, содержащей эти варианты использования, и окружением или внешней средой этой системы. ПРАКТИЧЕСКАЯ ЧАСТЬ Задание 1. Изучите пример разработки диаграммы вариантов использования, представленный в приложении 3 страница 56-60 Задание 2. Провести анализ требований к программному обеспечению в соответствии с вариантом задания (вариант см. Приложение 5), применяя объектно-ориентированный подход и язык визуального моделирования UML разработать диаграмму вариантов использования. Оформить результаты, используя MS Visio или DIA Задание 3. Создайте приложение Windows Forms на C#, использую методические указания (Приложение 7) Задание 4. Составить отчет о выполненной работе, содержащий скриншоты выполнения заданий и текстовые пояснения к построенным диаграммам КОНТРОЛЬНЫЕ ВОПРОСЫ Охарактеризуйте понятие UML. Каковы преимущества использования UML? Инструкционно-технологическая карта Практическая работа №12
Ход работы Прочитать теоретический материал. Выполнить задание. Составить отчет по выполненной работе. Сдать преподавателю и защитить отчет. ТЕОРЕТИЧЕСКИЙ МАТЕРИАЛ Если диаграмма вариантов использования дает «вид сверху» на функциональность системы, диаграмма деятельности, напротив, позволяет подробно иллюстрировать отдельный вариант использования и его сценарии. В зависимости от степени детализации диаграммы деятельностей могут использоваться на разных этапах разработки. На этапе анализа требований и уточнения спецификаций диаграммы деятельностей позволяют конкретизировать основные функции разрабатываемого программного обеспечения. Под деятельностью в данном случае понимают задачу (операцию), которую необходимо выполнить вручную или с помощью средств автоматизации. Каждому варианту использования соответствует своя последовательность задач. В теоретическом плане диаграмма деятельности — это обобщенное представление алгоритма, реализующего анализируемый вариант использования. На диаграмме деятельность обозначается прямоугольником с закругленными углами (рис. 4 а). Диаграммы деятельности позволяют описывать альтернативные и параллельные процессы.  Рисунок 4. Условные обозначения диаграммы деятельностей: а — деятельность; б — выбор; в — линейки синхронизации; г — начало; д — конец Для обозначения альтернативных процессов используют ромб (рис. 4 б), условие указывают рядом, а альтернативы «да», «нет» — рядом с соответствующими выходами. С помощью этого же блока можно построить циклический процесс. Множественность активации деятельности обозначают символом «*», помещенным рядом со стрелкой активации деятельности, и при необходимости уточняют надписью вида «для каждой строки». Для обозначения параллельных процессов используют линейки синхронизации (рис. 4, в). Условные обозначения начала и окончания диаграммы деятельности даны на рис. 4., г и д. ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ Рассмотренные диаграммы деятельности используются для спецификации динамики поведения программных систем, время в явном виде в них не присутствует. Однако временной аспект поведения может иметь существенное значение при моделировании синхронных процессов, описывающих взаимодействия объектов. Именно для этой цели в языке UML используются диаграммы последовательности. Диаграмма последовательности системы — графическая модель, которая для определенного сценария варианта использования показывает динамику взаимодействия объектов во времени. Для построения диаграммы последовательности системы необходимо: ■ идентифицировать каждое действующее лицо (объект) и изобразить для него линию жизни; ■ из описания варианта использования определить множество системных событий и их последовательность; ■ изобразить системные события в виде линий со стрелкой на конце между линиями жизни действующих лиц и системы, а также указать имена событий и списки передаваемых значений. На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно измерение — слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни. Внутри прямоугольника записываются имя объекта и имя класса, разделенные двоеточием. При этом вся запись подчеркивается линией, что является признаком объекта, представляющим собой экземпляр класса (рис. 5).  Рисунок 5. Различные графические примитивы диаграммы последовательности Не исключается ситуация, когда имя объекта может отсутствовать на диаграмме последовательности. В этом случае указывается только имя класса, а сам объект считается анонимным. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия (объект 1 на рис. 5). Правее изображается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют порядок, определяемый степенью активности этих объектов при взаимодействии друг с другом. Второе измерение диаграммы последовательности — вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Другими словами, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа «раньше-позже». Линия жизни объекта служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. На диаграмме линия жизни изображается пунктирной вертикальной линией, ассоциированной с единственным объектом. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности. Построение диаграммы последовательности целесообразно начинать с выделения из всей совокупности тех и только тех классов, объекты которых участвуют в моделируемом взаимодействии. После этого все объекты наносятся на диаграмму с соблюдением некоторого порядка инициализации сообщений. Здесь необходимо установить, какие объекты будут существовать постоянно, а какие временно — только на период выполнения ими требуемых действий. Когда объекты определены, можно приступать к спецификации сообщений. При этом следует учитывать роли, которые сообщения играют в системе. ПРАКТИЧЕСКАЯ ЧАСТЬ Задание 1. Изучите пример разработки диаграммы деятельности, представленный в приложении 3 страница 63-67. Задание 2. Провести анализ требований к программному обеспечению в соответствии с вариантом задания (вариант см. Приложение 5), применяя объектно-ориентированный подход и язык визуального моделирования UML разработать диаграммы деятельности. Оформить результаты, используя MS Visio или DIA Задание 3. Изучите пример разработки диаграммы последовательности, представленный в приложении 3 страница 70-71. Задание 4. Провести анализ требований к программному обеспечению в соответствии с вариантом задания (вариант см. Приложение 5), применяя объектно-ориентированный подход и язык визуального моделирования UML разработать диаграммы последовательности. Оформить результаты, используя MS Visio или DIA Задание 5. Составить отчет о выполненной работе, содержащий скриншоты выполнения заданий и текстовые пояснения к построенным диаграммам КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Какие сущности описывают поведение системы? 2. Каковы типы сущностей в UML? 3. Перечислите виды диаграмм в UML.  PAGE13 | ||||||||||||||||||||||||