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 приводится вариант использования, описывающий одну из функций системы