Лабораторная работа 2 анализ требований к программному обеспечению
Цель – научиться использовать UML-редактор StarUML для анализа требований к ПО
Задание
Ознакомиться с рабочим потоком анализа прецедента (технологическим процессом анализа требований к ПО) в соответствии с методологией Unified Process
Изучить средства языка UML, для анализа требований
Используя пакет StarUML,:
создать диаграммы классов анализа
реализовать прецеденты: уточнить диаграмму вариантов использования и диаграммы взаимодействий: диаграмму последовательностей и диаграмму коммуникаций
отредактировать спецификации этих диаграмм
Подготовить и защитить отчёт по лабораторной работе
Основные сведения
Анализ в большой степени пересекается с определением требований. Эти две деятельности часто идут рука об руку. Обычно необходимо провести некоторый анализ требований, чтобы сделать их более понятными и выявить все упущения или искажения [1,4,14].
В рабочем потоке UP Анализ прецедента (технологическом процессе анализа) создаются два ключевых артефакта:
классы анализа – ключевые понятия в бизнес-сфере;
реализации прецедентов – иллюстрируют, как экземпляры классов анализа могут взаимодействовать для реализации поведения системы, описанного прецедентами.
Входные данные Анализа прецедента:
бизнес-модель – в распоряжении разработчиков модели может быть (а может и не быть) бизнес-модель моделируемой системы. Если она уже есть, это превосходный источник требований.
модель требований
модель прецедентов
описание архитектуры – представление важных с архитектурной точки зрения аспектов системы. Может включать фрагменты UML-моделей, вставленные в пояснительный текст. Создается архитекторами на основании данных, полученных от аналитиков или проектировщиков.
Классы анализа – это классы, которые представляют четкую абстракцию предметной области (problem domain) и должны проецироваться на реальные бизнес-понятия (и быть аккуратно поименованы соответственно этим понятиям).
Напомним, что под классом понимается множество объектов, связанных общностью свойств, поведения связей и семантики. Любой объект является экземпляром (instance)класса[4].
Важно, чтобы все классы аналитической модели являлись классами анализа, а не классами, вытекающими из проектных соображений (области решения).
Аналитическую модель системы среднего размера и сложности включает от 50 до 100 классов анализа.
Диаграмма классов (анализа) является одной из важнейших диаграмм UML. Она используется для документирования программных систем, и основным ее компонентом является класс.
Класс на диаграмме изображается в виде прямоугольника, разделенного горизонтальными линиями на три части. В первой части указывается название класса. Как правило, имя класса состоит из одного, максимум двух слов. Вторая часть содержит перечень атрибутов класса, которые характеризуют тот или иной объект этого класса в модели предметной области. Третья часть содержит перечень операций, отражающих его поведение в модели предметной области (рис.2.1) [2].
Атрибут класса – поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства.
Рис. 2.1
Операция класса – это реализация услуги, которую можно запросить у любого объекта данного класса.
Слева от имен атрибутов и операций указываются модификаторы видимост, символы и значения которых представлены в таблице (рис. 2.2 ) [1,2].
Рис. 2.2
Между элементами диаграммы классов существуют различные виды связей. Основные типы связей представлены на рис. 2.3 [1,2,4,]
Рис. 2.3
Реализация прецедентов – важнейшая часть процесса анализа, которая показывают, как взаимодействуют классы, чтобы реализовать функциональность системы [1,4].
У каждого прецедента только одна реализация, поэтому, создание диаграммы реализаций прецедентов не привнесет никакой дополнительной информации. Реализации прецедентов обычно не отображаются на диаграммах – это неявная часть базы модели, включающая элементы, представленные на рис.2.4;.
Рис. 2.4
Детальное описание диаграмм классов анализа можно найти в большинстве книг по UML, которые приведены в списке литературы.
Кроме диаграмм классов можно создать или откорректировать ранее созданные диаграммы взаимодействий, демонстрирующие совместную работу и взаимодействие экземпляров этих классов анализа, направленные на реализацию части или всего поведения прецедента.
Кроме изученных в лабораторной работе № 1 диаграмм последовательностей и коммуникационные диаграммы, полезными могут быть диаграммы обзора взаимодействий и временные диаграммы.
Диаграммы обзора взаимодействий (interaction overview diagrams) показывают, как сложное взаимодействие реализуется рядом простых взаимодействий. Это особый случай диаграммы деятельности, в которой узлы ссылаются на другие взаимодействия. Они полезны для моделирования потока управления системы.[1] Временные диаграммы (timing diagrams) обращают внимание на фактическое время взаимодействия. Их основное назначение – помочь оценить временные затраты. [1]
Временные диаграммы и диаграммы обзора взаимодействий, к сожалению, не поддерживаются пакетом StarUML, поэтому на лабораторных работах не изучаются.
Объектно-ориентированное моделирование – итеративный процесс. Поэтому не надо удивляться, если при более глубоком моделировании будут выявлены новые требования или понадобится изменить существующие прецеденты. Все это – часть реализации прецедентов. Существующие документы должны соответствовать самой последней информации о системе. Необходимо обновлять модель прецедентов, модель требований и классы анализа, чтобы все они были согласованными