3131

11

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

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

Необходимо обозначить участников проекта системы. Важно, чтобы заказчик выступал не в виде безликого подразделения или офиса — необходимо привести конкретные имена.

Документ описания требований Содержание документа

1.Предварительные замечания к проекту

1.1.Цели и рамки проекта

1.2.Деловой контекст

1.3.Участники проекта

1.4.Идеи в отношении решений

1.5.Обзор документа

2.Системные сервисы

2.1.Рамки системы

2.2.Функциональные требования

2.3.Требования к данным

3.Системные ограничения

3.1.Требования к интерфейсу

3.2.Требования к производительности

3.3.Требования к безопасности

3.4.Эксплуатационные требования

3.5.Политические и юридические требования

3.6.Другие ограничения

4.Проектные вопросы

4.1.Открытые вопросы

4.2.Предварительный план-график

4.3.Предварительный бюджет Приложения Глоссарий

12

Деловые документы и формы Ссылки

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

Разработать документ описания требования к своей предметной области.

Контрольные вопросы.

1.Что такое CASE-средство?

2.Приведите примеры применения CASE-средств.

3.Приведите примеры CASE-средств.

Практическая работа № 2 Моделирование компонентов информационных систем.

Модели основных функций организационно-технического управления

Целью работы является изучение интерфейса Rational Rose и принципы работы с ним.

Теоретический материал.

Rational Rose - это CASE-средство фирмы Rational Software Corporation (США), предназначенное для автоматизации этапов анализа и проектирования программного обеспечения, для генерации кодов на различных языках и выпуска проектной документации . Rational Rose использует методологию объ- ектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно - ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++,

Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Структура и функции

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

13

классов, состояний, сценариев, модулей, процессов.В составе Rational Rose можно выделить 6 основных структурных компонент:

-репозиторий,

-графический интерфейс пользователя,

-средства просмотра проекта (browser),

-средства контроля проекта,

-средства сбора статистики

-генератор документов.

К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ. Репозиторий представляет собой объектно-ориентированную базу данных.

Средства просмотра обеспечивают "навигацию" по проекту, в том числе: перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации. Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок.

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

Таким образом, Rational Rose^++ обеспечивает возможность повторного использования программных компонент.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

-диаграммы классов;

14

-диаграммы состояний;

-диаграммы сценариев;

-диаграммы модулей;

-диаграммы процессов;

-спецификации классов, объектов, атрибутов и операций;

-заготовки текстов программ;

-модель разрабатываемой программной системы.

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

Взаимодействие с другими средствами и организация групповой работы Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA. Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема. Для управляемой подмодели предусмотрены операции:

-загрузка подмодели в память;

-выгрузка подмодели из памяти;

-сохранение подмодели на диске в виде отдельного файла;

-установка защиты от модификации;

-замена подмодели в памяти на новую.

Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случае защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты от записи устанавливается для файлов, которые содержат подмодели, поэтому при считывании "чужих" подмоделей защита их от модификации сохраняется и случайные воздействия окажутся невозможными.

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

1.Запустить Rational Rose.

2.Посмотреть навигацию по проекту.

3.Создать любой элемент, дать ему название и комментарий к нему.

4.Сохранить проект.

15

Контрольные вопросы.

1.Что такое Rational Rose?

2.Опишите окно приложения и основные функции меню.

3.Что такое навигатор?

Практическая работа № 3 Спецификация требований. Модель вариантов использования

Целью работы является ознакомление с созданием функциональной модели

использования.

Теоретический материал.

Моделирование в Ration Rose проводится как спуск от концептуальной модели к логической, а затем к физической модели программной системы. Концептуальная модель выражается в виде диаграмм вариантов использования (Use - case diagram). Этот тип диаграмм служит для проведения итерационного цикла общей постановки задачи вместе с заказчиком.

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

программистами-профессионалами, разрабатывающими проект, и заказчиками проекта.

Внутри каждого варианта использования (прецедента) могут быть определены:

-вложенная диаграмма использования,

-диаграмма взаимодействия объектов,

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

-диаграмма классов,

-диаграмма перехода состояния.

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

16

управления проектами - обратную связь между менеджером проекта и

исполнителем.

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

1.Построить диаграмму прецедентов по разработанному техническому заданию.

2.Присвоить имя диаграмме согласно предметной области и решаемой

задаче.

3.Определить субъектов (актеров) и прецедентов и присвоить им имена согласно предметной области.

4.Определить ассоциации между ними.

5.Построить обобщения между субъектами и прецедентами.

Контрольные вопросы.

1.В чем смысл варианта использования?

2.Назначение вариантов использования.

3.Назовите основные компоненты диаграмм вариантов использования.

4.Что такое действующее лицо?

5.Какую роль могут играть действующие лица по отношению к варианту использования?

Практическая работа № 4 Спецификация требований. Диаграммы классов, прецедентов, ак-

тивности

Целью лабораторной работы является ознакомление с созданием логической модели информационной системы

Теоретический материал.

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

17

статистические связи, которые существует между ними. Имеется два основных вида статистических связей:

-ассоциации (например, менеджер может вести несколько проектов);

-подтипы (работник является разновидностью личности).

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

Ассоциации представляют собой связи между экземплярами классов (личность работает в компании, компания имеет ряд офисов). Любая ассоциация обладает двумя ролями. Например (рис. 1) - ассоциация между Исполнителем и Отчетом содержит две роли: одна от Исполнителя к Отчету; другая - от Отчета к Исполнителю. Роль также обладает множественностью. Пример - символ "0..*" над ассоциацией между Менеджером и Контрактом показывает, что с одним Менеджером связано много Контрактов. 0 - показывает, что Менеджер может не управлять контрактом; 1 - показывает, что любой Контракт может управляться только одним Менеджером.

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

Атрибуты во многом подобны ассоциациям. Разница между ними заключается в том, что атрибуты предполагают единственное направление навигации - от типа к атрибуту. На рисунке указаны атрибуты для классов Контракт и Отчет. В зависимости от степени детализации диаграммы обозначение атрибута может включать имя атрибута, тип и значение, присваемое по умолчанию. В синтаксисе UML атрибут обозначен: <признак видимости> <имя>: <тип> = <значение по умолчанию>. Признак видимости может принимать следующие значения:

-общий (public) - атрибут общий, доступен для всех классов клиентов;

-защищенный (protected) - атрибут защищенный, доступен только для подклассов и друзей класса;

-секретный (private) - атрибут собственный, доступен только для друзей

класса;

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

Операции представляют процессы, реализуемые классом. Существует соответствие между операциями и методами над классом. На рис. 3 приведены операции над классом Контракт Закрыть (), над классом Отчет - Добавить().

Нотации логического представления (диаграммы классов)

19

Диаграмма активности может использоваться для моделирования различных типов действий. Например, финансовая компания может использовать данный тип диаграмм для моделирования потоков финансовых документов, прохождения оплаты счетов или заказов. Компания, создающая программные продукты, отслеживать процесс разработки и создания программного обеспечения. Диаграммы активности (Activity diagram) - это специальная разновидность диаграмм состояния. Главное отличие между диаграммами активности и состояния в том, что в первом случае основное - действие, а во втором - статичное состояние.

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

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

Пример. Алгоритм получения отчета. Управление проектами.

Добавляются:

-Activity - значок активности. Похож на значок состояния State, который обозначает ожидание события, а значок Activity означает действие.

-Значки синхронизации.

-Decision - решение, позволяет показать зависимость от внешних условий или решений (аналогичен If case в языках программирования).

-Swimlanes - плавательные дорожки - моделирование действий различных объектов и связи между ними.

Можно моделировать бизнес-процесы организации, отражая на диаграмме различные подразделения и объекты, играющие важные роли в

20

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

Лабораторные задания.

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

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

a.Дать имя классу для однотипной группы объектов, например объекты Менеджеры можно поместить в класс Менеджер.

b.Назначить атрибут - ключ (идентификатор объекта), например для объекта Менеджер - это может быть Код менеджера.

c.Указать основную операцию над классом, например для класса Менеджер - Добавить().

2. Построить отношения между классами на основе ассоциаций а. Определить направление и множественность, указав нижние и

верхние границы.

2. Построить диаграмму активности на основе диаграммы классов и диаграммы состояния, разработанных на предыдущих занятиях.

1.Дать имя диаграмме.

2.Выбрать классы, для объектов которых будут строиться диаграммы состояний.

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

Контрольные вопросы.

1.Назначение диаграммы классов.

2.Для чего используется диаграмма классов на стадии анализа?

3.Назовите основные компоненты диаграммы классов.

4.Что собой представляет ассоциация?

5.В чем смысл множественной ассоциации?

б. Как описывается класс?

7.Значение характеристики атрибута ключ.

8.Что входит в описание атрибута?

9.Что такое признак видимости?

10.Что представляет собой операция класса?