- •1.Виды, взаимосвязь и свойства требований
- •1.1.Что такое «требование»?
- •1.2.Виды требований
- •1.2.1.Функциональные требования
- •1.2.2.Нефункциональные требования
- •1.2.2.1.Нефункциональные требования к продукту
- •1.2.2.2.Нефункциональные требования к процессу
- •1.2.2.3.Внешние нефункциональные требования
- •1.5.Вопросы для самоконтроля
- •2.Определение образа и границ проекта
- •2.1.Анализ предметной области
- •2.2.Анализ осуществимости
- •2.3.Определение целей и области действия
- •2.4.Документирование образа и границ проекта
- •2.5.Вопросы для самоконтроля
- •3.Выявление требований
- •3.1.Определение способа сбора и анализа требований
- •3.1.1.Источники возникновения требований
- •3.1.2.Заинтересованные в проекте лица
- •3.2.Опрос (интервью)
- •3.2.1.Подготовка
- •3.2.2.Проведение опроса
- •3.2.3.Определение последующих действий
- •3.3.Совместные семинары
- •3.4.”Мозговой штурм”
- •3.4.1.Роли во время сеансов
- •3.4.2.Правила проведения сеанса
- •3.4.3.Подготовка к сеансу
- •3.4.4.Проведение сеанса
- •3.4.5.Обработка результатов сеанса
- •3.5.Сценарии
- •3.5.1.Сценарии событий
- •3.5.2.Варианты использования
- •3.5.3.Применение модели msc uml
- •3.6.Выявление требований на основе различных точек зрения. Метод vord
- •3.6.1.Идентификация точек зрения
- •3.6.2.Структурирование точек зрения
- •3.6.3.Документирование и отображение системы точек зрения
- •3.7.Этнографический подход
- •3.8.Вопросы для самоконтроля
- •4.Разработка системных требований
- •4.1.Детализация требований пользователей
- •4.2.Системные модели
- •4.2.1. Модели потоков данных
- •4.2.2.Модели конечных автоматов
- •4.2.3.Модели данных
- •4.3.Прототипы
- •4.3.1.Роль прототипов при разработке требований
- •4.3.2.Виды прототипов
- •4.4.Разработка прототипов
- •4.4.1.Экспериментальное прототипирование
- •4.4.2.Эволюционное прототипирование
- •4.4.3.Риски прототипирования
- •4.5.Системные требования
- •4.5.1.Структурированный естественный язык
- •4.5.2.Языки описания программ
- •4.5.3.Графические нотации
- •4.6.Документирование системных требований
- •4.7.Вопросы для самоконтроля
- •5.Документирование требований
- •5.1.Спецификация требований
- •5.2.Состав спецификации требований
- •5.3.Рекомендации по разработке требований
- •5.4.Стандартные шаблоны спецификации
- •5.5.Вопросы для самоконтроля
- •6.Анализ спецификации требований
- •6.1.Оценка качества спецификации требований
- •6.1.1.Характеристики качества спецификации
- •6.1.2.Аттестация требований
- •6.2.Экспертиза спецификации
- •6.3.Прототипирование
- •6.4.Автоматизированный анализ
- •6.5.Тестирование требований
- •6.6.Вопросы для самоконтроля
- •7.Управление требованиями
- •7.1.Причины изменений требований
- •7.2.Принципы управления требованиями
- •7.3.Управление изменениями
- •7.4.Управление версиями
- •7.5.Управление связями требований
- •7.6.Риски, связанные с требованиями
- •7.6.1.Риски этапа выявления требований
- •7.6.2.Риски этапа анализа и спецификации требований
- •7.6.3.Риски управления требованиями
- •7.7.Вопросы для самоконтроля
- •8.Case-средства для управления требованиями
- •8.1.Выбор case-средств для управления требованиями
- •8.2.Уровень зрелости и используемые инструменты
- •8.2.1.Моделирование требований
- •8.2.2.Трассировка требований
- •8.2.3.Управление версиями
- •8.3.Возможности case-средств управления требованиями
- •8.3.1. Средства idf-моделирования
- •8.3.2.Средства uml
- •8.4.Вопросы для самоконтроля
- •Список литературы
4.2.2.Модели конечных автоматов
Модели конечных автоматов используются для моделирования поведения системы, которая реагирует на внутренние или внешние события. Эта модель показывает состояние системы и события, которые служат причиной перехода системы в следующее состояние, не описывая поток данных внутри системы.
Популярность конечных автоматов состоит в том, что данная техника развивается уже достаточно давно, и теоретические результаты были с успехом использованы при решении многих практических задач. В частности, системы автоматизации проектирования, спецификации и программирования, основанные на конечных автоматах и их модификациях, активно развиваются и применяются десятки лет. Особенно часто конечные автоматы применяются в конкретных предметных областях, где можно обойтись без использования универсальных моделей вычислимости. В результате очень многие пользователи, инженеры и программисты хорошо знакомы с конечными автоматами и применяют их без затруднений. Наконец, важным практическим обстоятельством является тот факт, что автоматы очень легко программируются средствами обычных языков программирования.
Модель конечного автомата системы предполагает, что в каждый момент времени она находится в некотором устойчивом состоянии. При получении входного сигнала (события) система может изменить свое состояние или остаться в прежнем состоянии.
Пример 4.2.
На рис. 4.3 приведена диаграмма конечного автомата, описывающего процесс «Принять программу в архив».
Рис. 4.3
Система находится в начальном состоянии и ожидает запроса. После его получения она переходит в состояние «Контроль запроса», где выясняет, имеет ли разработчик полномочия для сдачи программы в архив. Если полномочий недостаточно или программа уже находится в архиве, то система возвращается в начальное состояние.
4.2.3.Модели данных
Во многих случаях программные системы содержат или используют базы данных, поэтому определение логической структуры данных является одной из важных задач моделирования систем.
ER-диаграммы
Наиболее широко используется моделирование данных типа “сущность – связь – атрибут”, определяющее структуру данных, их атрибуты и отношения между ними [9].
Для разработки моделей данных, обеспечивающих стандартный способ определения данных и отношений между ними, служат диаграммы “сущность-связь” (Entity-Relationship Diagrams, ER-диаграммы). ER-диаграммы позволяют идентифицировать сущности (объекты, важные для предметной области), свойства сущностей – атрибуты – и связи (отношения) между сущностями.
Под сущностью (entity) в ER-диаграммах понимается множество экземпляров реальных или абстрактных объектов (людей, предметов, событий и т.д.). Любой объект системы может быть представлен только одной уникально идентифицированной сущностью, имя которой должно отражать тип (класс) объектов, а не его конкретный экземпляр. Связь (relation) – это именованное отношение между двумя и более сущностями, а атрибут (attribute) – любая характеристика сущности, причем множество значений всех атрибутов должно однозначно идентифицировать экземпляр сущности. Более подробно описание ER-диаграмм и методика их использования для моделирования структур данных приведены в [9], а мы ограничимся примером.
Пример 4.3.
На рис. 4.4. приведена диаграмма, описывающая запрос на запись программы в архив. Разработчик может дать несколько запросов, каждый из которых содержит не менее одной программы. Каждая программа расположена на отдельном носителе, содержание, которого определяется ведомостью.
Рис. 4.4
Словарь данных
Недостатком ER-диаграмм является их недостаточная детализация данных, поэтому они часто дополняются более подробным описанием, которые собираются в словари данных.
Словарь данных позволяет:
определить механизм управления именами, позволяющий избежать дублирования;
связать различные этапы проектирования системы.
Словарь данных содержит описание именованного объекта (сущности, потока данных, хранилища), включающего в себя определение его атрибутов, структуры – для сложных объектов, – а также дополнительные сведения, например, единицы измерения и диапазоны изменения атрибутов, цель определения такого объекта, сведения о его разработчике и времени создания и т.д.