Основные сведения. Цель –научиться использовать uml-редактор staruml для анализа требований к по

АНАЛИЗ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

ЛАБОРАТОРНАЯ РАБОТА 2

Цель – научиться использовать UML-редактор StarUML для анализа требований к ПО

ЗАДАНИЕ

1. Ознакомиться с рабочим потоком анализа прецедента (технологическим процессом анализа требований к ПО) в соответствии с методологией Unified Process

2. Изучить средства языка UML, для анализа требований

3. Используя пакет StarUML,:

- создать диаграммы классов анализа

- реализовать прецеденты: уточнить диаграмму вариантов использования и диаграммы взаимодействий: диаграмму последовательностей и диаграмму коммуникаций

- отредактировать спецификации этих диаграмм

4. Подготовить и защитить отчёт по лабораторной работе

Анализ в большой степени пересекается с определением требований. Эти две деятельности часто идут рука об руку. Обычно необходимо провести некоторый анализ требований, чтобы сделать их более понятными и выявить все упущения или искажения [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, поэтому на лабораторных работах не изучаются.

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

Дата добавления: 2015-04-30