Файл: Методические указания по выполнению практических работ учебной дисциплины мдк 03. 01 Технология разработки программного обеспечения.docx

Порядок выполнения работы

Построение диаграммы Последовательности

1. В проводнике по моделям должны отображаться все классы и диаграммы, созданные ранее.

Построим диаграмму последовательности для варианта использования «Обеспечить покупателя информацией». Для этого добавим на диаграмму последовательности линии жизни и соотнесем объекты с актерами, инициирующими вариант использования «Обеспечить покупателя информацией», и с необходимыми классами.

Для добавления диаграммы последовательности в проект MS Visio выполните следующие действия:

1. В проводнике по моделям найдите ветку «Основной пакет».

2. Нажмите по ней правой кнопкой мыши > Создать …

3. В контекстном меню выберите пункт «Схема последовательностей».

Добавим сообщения, которыми обмениваются объекты для исполнения варианта использования.

Если объект имеет операцию (посмотреть в практическом занятии №8 «Диаграммы классов» наличие операции у класса, которому принадлежит объект).

1. Из группы фигур «Последовательности UML» добавить три фигуры типа «Линия жизни объекта». Для изменения названия необходимо дважды щелкнуть левой кнопкой мыши по фигуре. Откроется окно свойств объекта и, если в данном файле нет ранее созданных классов, окно создания нового класса. В данном примере необходимо создать три класса «Товар», «Каталог товаров» и «Заказ» и соответственно три объекта с такими же названиями.

2. С помощью поиска фигур найти фигуру «Актер» и добавить ее в рабочую область. Двойным щелчком левой кнопки мыши задать имя «Клиент».

3. Добавить фигуру «Линия жизни» и соедините ее начало с фигурой «Клиент».

4. Протянуть все линии жизни вниз листа.

5. Добавить фигуры «Сообщение» и соединить, руководствуясь следующими принципами:

5.1. Соединить фигурой «Сообщение» линию жизни клиента с линией жизни объекта товар. Двойным щелчком по сообщению открыть окно свойств и выбрать операцию запросить товар.

5.2. Соединить фигурой «Сообщение» линию жизни клиента с линией жизни объекта заказ. Двойным щелчком по сообщению открыть окно свойств и выбрать операцию сформировать заказ.

5.3. Соединить фигурой «Сообщение» линию жизни объекта товар с линией жизни объекта каталог товаров. Двойным щелчком по сообщению открыть окно свойств и выбрать операцию проверить наличие.

5.4. Соединить фигурой «Сообщение (возврат)» линию жизни объекта товар и линию жизни клиента. Двойным щелчком по сообщению открыть окно свойств и задать текст сообщения «Предоставить информацию».

---

6. Добавить фигуры «Активация» и расположить их на диаграмме.



При построении диаграмм последовательностей можно вносить коррективы в диаграмму классов. Если объект класса получает новую операцию, то она добавляется в соответствующий класс на диаграмме классов как метод.

Построим диаграмму последовательности для варианта использования «Согласовать условия оплаты». Действия по построению диаграммы аналогичны построению диаграммы последовательности для варианта использования «Обеспечить покупателя информацией».



Построим диаграмму последовательности для варианта использования «Заказать товар со склада». Действия по построению диаграммы аналогичны построению предыдущих диаграмм последовательностей.



Построим диаграмму последовательности для системы продажи товаров по каталогу.



В соответствии с индивидуальным вариантом, построить диаграммы последовательности. Перечень индивидуальных вариантов приведен в приложении А.

Отчет по практическому занятию выполняется в формате MS Word, который содержит экранные формы моделей согласно заданию.

Форма отчета:

Диаграмма Последовательности с описанием процесса построения диаграммы.

Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО»

Литература:

1. Черткова, Е. А. Программная инженерия. Визуальное моделирование программных систем: учебник для СПО / Е. А. Черткова. —2-е изд., испр. и доп. — М.: Издательство Юрайт, 2017. — 168 с. — (Серия: Профессиональное образование). - URL://www.urait.ru
Раздел 1. Технология разработки программного обеспечения

---

Тема 1.4. Моделирование деятельности организации средствами UML

Практическое занятие 8.

Тема: Разработка диаграммы классов для автоматизации анализируемого бизнес-процесса организации.

Цель работы: изучение основ создания диаграмм классов на языке UML, получение навыков построения диаграмм классов, применение приобретенных навыков для построения объектно-ориентированных моделей определенной предметной области.

Продолжительность занятия: 2 часа.

Оснащение: Персональный компьютер, программа Microsoft Word, MS Visio, методические указания к практическим занятиям.

Методические указания по выполнению работы: изучить краткие теоретические материалы из лабораторной работы №6; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе

Порядок выполнения работы

В соответствии с индивидуальным вариантом, построить диаграмму классов. Перечень индивидуальных вариантов приведен в приложении Б.

Отчет по практическому занятию выполняется в формате MS Word, который содержит экранные формы моделей согласно заданию.

Форма отчета:

Диаграмма Классов с описанием процесса построения диаграммы.

Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО»

Литература:

1. Черткова, Е. А. Программная инженерия. Визуальное моделирование программных систем: учебник для СПО / Е. А. Черткова. —2-е изд., испр. и доп. — М.: Издательство Юрайт, 2017. — 168 с. — (Серия: Профессиональное образование). - URL://www.urait.ru
Раздел 1. Технология разработки программного обеспечения

Тема 1.5. Организация процесса тестирования программного обеспечения

Практическое занятие 9.

Тема: Тестирование и отладка программных модулей средствами MS Studio.

Цель работы: ознакомится с методами и видами тестирования ПО и провести тестирование разрабатываемого программного продукта.

Продолжительность занятия: 2 часа.

Оснащение: Персональный компьютер, программа Microsoft Word, MS Visio, Visual Studio, методические указания к практическим занятиям.

Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе

---

Теоретические сведения

Тестирование программного обеспечения

Тестирование (software testing) – деятельность, выполняемая для оценки и улучшения качества программного обеспечения. Эта деятельность, в общем случае, базируется на обнаружении дефектов и проблем в программных системах.

Тестирование программных систем состоит из динамической верификации поведения программ на конечном (ограниченном) наборе тестов (set of test cases), выбранных соответствующим образом из обычно выполняемых действий прикладной области и обеспечивающих проверку соответствия ожидаемому поведению системы.

Сегодня тестирование рассматривается как деятельность, которую необходимо проводить на протяжении всего процесса разработки и сопровождения и является важной частью конструирования программных продуктов.

В области знаний “Качество программного обеспечения” (Software Quality) техники управления качеством четко разделены на статические (без выполнения кода) и динамические (с выполнением кода). Обе эти категории важны. Данная область знаний - “Тестирование” – касается динамических техник.

Тестирование тесно связано с областью знаний “Конструирование” (Software Construction). Более того, модульное (unit-) и интеграционное тестирование все чаще рассматривают как неотъемлемый элемент деятельности по конструированию.

В литературе, посвященной программной инженерии, встречается множество терминов, описывающих нарушение функционирования программных систем – недостатки (faults), дефекты (defects), сбои (failures), ошибки (errors) и др. Соответствующая терминология описана в IEEE Std. 610-90 “Глоссарии терминов по программной инженерии”. Важно четко разделять причину нарушения работы прикладных систем, обычно описываемую терминами недостаток или дефект, и наблюдаемый нежелательный эффект, вызываемый этими причинами – сбой. Термин ошибка, в зависимости от контекста, может описывать и как причину сбоя, и сам сбой. Тестирование позволяет обнаружить дефекты, приводящие к сбоям. Необходимо понимать, что причина сбоя не всегда может быть однозначно определена. Не существует теоретических критериев, позволяющих гарантированно определить какой именно дефект приводит к наблюдаемому сбою.

Ключевые вопросы (Key Issues) тестирования ПО:

Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования.

Эффективность тестирования/Цели тестирования. Тестирование – это наблюдение за выполнением программы, запущенной в целях тестирования с заданными параметрами, по заданному сценарию или с другими заданными начальными условиями или целями тестирования. Эффективность теста может быть определена только в контексте заданных условий.

---

Тестирование для идентификации дефектов. Данный случай тестирования подразумевает успешность процедуры тестирования, если дефект найден. Это отличается от подхода в тестировании, когда тесты запускаются для демонстрации того, что программное обеспечение удовлетворяет предъявляемым требованиями и, соответственно, тест считается успешным, если не найдено дефектов.

Проблема оракула. “Оракул”, в данном контексте, любой агент (человек или программа), оценивающий поведение программы, формулируя вердикт - тест пройден или нет.

Теоретические и практические ограничения тестирования. Теория тестирования выступает против необоснованного уровня доверия к серии успешно пройденных тестов. Основная причина этого в том, что полное (всеобъемлющее) тестирование недостижимо для реального программного обеспечения.

Проблема неосуществимых путей. Эта сложнейшая проблема автоматизированного тестирования связана с тем, что путь, по которому выполняются потоки работ тестируемой программной системы, не могут быть заданы входными параметрами.

Тестируемость. Это понятие может подразумевать две различных идеи. Первая описывает степень легкости описания критериев покрытия тестами для заданной программной системы. Вторая определяет возможность вероятность, возможность статистического измерения того, что при тестировании проявится сбой программной системы. Обе интерпретации этого понятия одинаково важны для тестирования.

Уровни тестирования. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий.

Модульное тестирование (Unit testing). Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию.

Интеграционное тестирование (Integration testing). Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями.

Классические стратегии интеграционного тестирования – “сверху-вниз” и “снизу-вверх” – используются для традиционных, иерархически структурированных систем и их сложно применять, например, к тестированию слабосвязанных систем, построенных в сервисно- ориентированных архитектурах (SOA).

---