Лабораторная работа 1

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

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

ЗАДАНИЕ

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

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

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

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

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

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

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

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

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

ОСНОВНЫЕ СВЕДЕНИЯ

Спецификация требований к программному обеспечению (Software requirements specification, SRS) включает модель требований (Requirements model) и модель прецедентов (Use case model, модель вариантов использования). Эти две модели являются разными, но тем не менее взаимодополняющими способами представления требований, предъявляемых к системе. В модель требований входят функциональные требования (требования, определяющие, что должна делать система) и нефункциональные требования (требования, выражающие ограничения системы, не относящиеся к ее функциональности) [1,4,5,7-9].

Моделирование прецедентов - это другой, дополнительный способ выявления и документирования требований. Кроме того, модель прецедентов является основным источником объектов и классов. Это основные исходные данные для моделирования классов [1,2,4,6].

В этой модели четыре компонента:

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

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

варианты использования (прецеденты, спецификации функциональных возможностей системы) - то, что актеры могут делать с системой, функции выполняемые системой. Приемлемая норма –это когда средней сложности приложение имеет от 20 до 50 прецедентов [6];

отношения - значимые связи между актерами и прецедентами.

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

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

• Не моделируйте связи между действующими лицами. По определению действующие лица находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции.

• Не соединяйте стрелкой два варианта использования непосредственно. Диаграммы данного типа описывают только сами варианты использования, а не порядок их выполнения. Для отображения порядка выполнения вариантов использования применяют диаграммы деятельности.

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

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

Моделирование вариантов использования не сводится только к рисованию диаграмм. Для последующего проектирования системы требуются более конкретные детали. Эти детали описываются в документе, называемом «сценарий варианта использования» или «поток событий» (flow of events). Целью потока событий является подробное документирование процесса взаимодействия действующего лица с системой, реализуемого в рамках варианта использования (прецедента). В потоке событий должно быть описано все, что служит удовлетворению запросов действующих лиц [1,2,4,6,7].

Рис.1.1

В языке UML_стандарта для спецификации прецедента не существует. Однако широко используется шаблон, приведенный на рис. 1.1. Есть и более сложные шаблоны (например, шаблон Видение RUP), но желательно придерживаться максимальной простоты.. Подробное описание разделов этого шаблона приведено в [1, стр.101, 4, стр. 181].

Диаграмм прецедентов, как и сценариев, ими определяемых, недостаточно, чтобы создать модель поведения системы. Как мы уже не раз упоминали, прецеденты говорят, что делает система, но не говорят, как. Об этом говорят сценарии, но в текстовой форме, что делает их довольно сложными для восприятия. На помощь приходят диаграммы взаимодействий, которые визуализируют сценарии. [2, 6].

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

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

Информационное (informative) сообщение — сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния.

Сообщение-запрос (interrogative) — сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.

Императивное (imperative) сообщение — сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.

Двумя наиболее часто используемыми видами диаграмм взаимодействия являются диаграммы последовательности (sequence diagram) и коммуникации (communication diagram) [1, 4-7].

Диаграммы последовательности отражают временную последовательность событий, происходящих в рамках варианта использования. На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается, как минимум, именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию, и, кроме того, можно показать самоделегирование (self-delegation) — сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

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

Диаграммы последовательностей также очень полезны в выявлении классов и методов. Классы легко можно определить как имена существительные экземпляров объектов, а методы являются сообщениями, которые в них вызываются [6].

Не все объекты, показанные на диаграмме, явно присутствуют в потоке событий. Там, например, может не быть форм для заполнения, но их необходимо показать на диаграмме, чтобы позволить действующему лицу ввести новую информацию в систему или просмотреть ее. В потоке событий, скорее всего, также не будет и управляющих объектов (control objects). Эти объекты управляют последовательностью событий в варианте использования.

Диаграммы коммуникации (в старших версиях UML- кооперативные диаграммы) отображают поток событий варианта использования и концентрируют внимание на связях между объектами. На ней представлена та же информация, которая была и на диаграмме последовательности, но диаграмма коммуникации по-другому описывает поток событий. Из нее легче понять связи между объектами, однако труднее уяснить последовательность событий.

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

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

Детальное описание диаграмм взаимодействия можно найти в [1,стр.275, 2, стр.61, 4, стр.103].

ТЕХНОЛОГИЯ РАБОТЫ

Дата добавления: 2016-01-05; просмотров: 102; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 123 4 5 6 7 8 9 10 Следующая ⇒

Мы поможем в написании ваших работ!