Формирование требований к программному обеспечению

1  Тема  –  формирование требований к программному обеспечению.

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

3  Задание

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

Методология  Unified Process (UP) является открытый обобщенный продукт, а RUP – специальным коммерческий подклассом, который одновременно и расширяет, и переопределяет возможности UP. Но в RUP и UP по-прежнему остается больше общего, чем различного. Главное их отличие не в семантике или идеологии, а в полноте и детализации. Основные рабочие потоки (технологические процессы) объектно-ориентированного анализа и разработки совершенно аналогичны,

К пяти основным рабочим потокам относятся:

1)  определение требований – сбор данных о том, что должна делать система;

2)  анализ – уточнение и структурирование требований;

3)  проектирование – реализация требований в архитектуре системы;

4)  реализация – построение программного обеспечения;

5)  тестирование – проверяется, отвечает ли реализация требованиям.

3.2   Выявить и специфицировать границы разрабатываемой системы, действующие лица (актеров) и варианты использования (прецеденты)

Действующие лица (акторы, экторы)-  роли, выполняемые людьми или сущностями (другие системы или время),  исполь­зующими систему.(риунок 1)

Рисунок 1 Актор

Граница системы - прямоугольник, очерчивающий прецеденты для обозначения края, или границы, моделируемой системы.(рисунок 2)

Рисунок 2 Граница системы

Варианты использования (прецеденты, - то, что актеры могут делать с системой, функции выполняемые системой.(рисунок 3)

Рисунок 3 Прецендент

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

Средства StarUml:

- объекты;

- проекты;

- диаграммы;

- акторы;

- системная граница.

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

-  новый проект

Рисунок 4 Создание проекта

Рисунок 5 Выбор подхода проекта

-  диаграмму вариантов использования :

Для наглядного представления вариантов использования (прецедентов) применяются диаграммы вариантов использования (диаграммы прецедентов). Такие диаграммы показывают, какие действующие лица, изображённые фигуркой, инициируют варианты использования, изображённые овалом.(рисунок7)

Цель построения диаграмм вариантов использования — доку­ментирование функциональных требований к системе в самом общем виде, поэтому они должны быть предельно простыми.

Рисунок 6 Создание диаграммы варианты использования (прецендентов)

 Рисунок 7 Диаграммы варианты использования (прецендентов)

-  диаграмму последовательностей:

Диаграммы последовательности отражают временную после­довательность событий, происходящих в рамках варианта ис­пользования.(рисунок 9)

Рисунок 8 Создание диаграммы последовательности

Рисунок  9 Диаграмма последовательности

-  диаграмму коммуникаций

Диаграммы коммуникации  отображают поток событий варианта использования и концентрируют внимание на связях между объектами.(рисунок 11)

Для  диаграммы коммуникаций в StarUML доступны следующие элементы: объект, связь, рекурсивная связь, сообщение и рамка.

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

Рисунок 10 Создание диаграммы коммуникаций

Рисунок 11 диаграмма коммуникаций

4  Вывод

Мы научились работать в определенном подходе проекта Rational Approach в программе StarUML. Изучили средства объектно-ориентированного языка моделирования такие как:

- объекты;

- проекты;

- диаграммы;

- акторы;

- системная граница.

Изучили некоторые горячий синтаксис генерации позволяющие  сгенерировать модельный элемент и указанное отношения.