- •З курсу
- •З курсу
- •Содержание
- •Часть I. Инженерные основы программного обеспечения 10
- •Часть II. Требования к программному обеспечению 33
- •Часть III. Моделирование программного обеспечения 52
- •Часть IV. Технологии разработки программного обеспечения 124
- •Часть V. Письменная коммуникация. Документирование проекта Программного обеспечения 145
- •Часть VI. Управление проектом программного обеспечения 192
- •Предисловие
- •Часть I. Инженерные основы программного обеспечения
- •1. Введение в программную инженерию
- •1.1. Вопросы и ответы об инженерии программного обеспечения
- •1.2. Профессиональные и этические требования к специалистам по программному обеспечению
- •2. Системотехника вычислительных систем
- •2.1. Интеграционные свойства систем
- •2.2. Система и ее окружение
- •2.3. Моделирование систем
- •2.4. Процесс создания систем
- •2.5. Приобретение систем
- •3. Процесс создания программного обеспечения
- •3.1. Модели процесса создания программного обеспечения
- •3.2. Итерационные модели разработки программного обеспечения
- •3.3. Спецификация программного обеспечения
- •3.4. Проектирование и реализация программного обеспечения
- •3.5. Эволюция программных систем
- •3.6. Автоматизированные средства разработки программного обеспечения
- •4. Технологии производства программного обеспечения
- •Часть II. Требования к программному обеспечению
- •5. Требования к программному обеспечению
- •5.1. Функциональные и нефункциональные требования
- •5.2. Пользовательские требования
- •5.3. Системные требования
- •5.4. Документирование системных требований
- •6. Разработка требований
- •6.1. Анализ осуществимости
- •6.2. Формирование и анализ требований
- •6.3. Аттестация требований
- •6.4. Управление требованиям
- •7. Матрица требований. Разработка матрицы требований
- •Часть III. Моделирование программного обеспечения
- •8. Архитектурное проектирование
- •8.1. Структурирование системы
- •8.2. Модели управления
- •8.3. Модульная декомпозиция
- •8.4. Проблемно-зависимые архитектуры
- •9. Архитектура распределенных систем
- •9.1. Многопроцессорная архитектура
- •9.2. Архитектура клиент/сервер
- •9.3. Архитектура распределенных объектов
- •9.4. Corba
- •10. Объектно-ориентированное проектирование
- •10.1. Объекты и классы объектов
- •10.2. Процесс объектно-ориентированного проектирования
- •10.2.1. Окружение системы и модели ее использования
- •10.2.2. Проектирование архитектуры
- •10.2.3. Определение объектов
- •10.2.4. Модели архитектуры
- •10.2.5. Специфицирование интерфейсов объектов
- •10.3. Модификация системной архитектуры
- •11. Проектирование систем реального времени
- •11.1. Проектирование систем реального времени
- •11.2. Управляющие программы
- •11.3. Системы наблюдения и управления
- •11.4. Системы сбора данных
- •12. Проектирование с повторным использованием компонентов
- •12.1. Покомпонентная разработка
- •12.2. Семейства приложений
- •12.3. Проектные паттерны
- •13. Проектирование интерфейса пользователя
- •13.1. Принципы проектирования интерфейсов пользователя
- •13.2. Взаимодействие с пользователем
- •13.3. Представление информации
- •13.4. Средства поддержки пользователя
- •13.5. Оценивание интерфейса
- •Часть IV. Технологии разработки программного обеспечения
- •14. Жизненный цикл программного обеспечения: модели и их особенности
- •14.1. Каскадная модель жизненного цикла
- •14.2. Эволюционная модель жизненного цикла
- •14.2.1. Формальная разработка систем
- •14.2.2. Разработка программного обеспечения на основе ранее созданных компонентов
- •14.3. Итерационные модели жизненного цикла
- •14.3.1 Модель пошаговой разработки
- •14.3.2 Спиральная модель разработки
- •15. Методологические основы технологий разработки программного обеспечения
- •16. Методы структурного анализа и проектирования программного обеспечения
- •17. Методы объектно-ориентированного анализа и проектирования программного обеспечения. Язык моделирования uml
- •Часть V. Письменная коммуникация. Документирование проекта Программного обеспечения
- •18. Документирование этапов разработки программного обеспечения
- •19. Планирование проекта
- •19.1 Уточнение содержания и состава работ
- •19.2 Планирование управления содержанием
- •19.3 Планирование организационной структуры
- •19.4 Планирование управления конфигурациями
- •19.5 Планирование управления качеством
- •19.6 Базовое расписание проекта
- •20. Верификация и аттестация программного обеспечения
- •20.1. Планирование верификации и аттестации
- •20.2. Инспектирование программных систем
- •20.3. Автоматический статический анализ программ
- •20.4. Метод "чистая комната"
- •21. Тестирование программного обеспечения
- •21.1. Тестирование дефектов
- •21.1.1. Тестирование методом черного ящика
- •21.1.2. Области эквивалентности
- •21.1.3. Структурное тестирование
- •21.1.4. Тестирование ветвей
- •21.2. Тестирование сборки
- •21.2.1. Нисходящее и восходящее тестирование
- •21.2.2. Тестирование интерфейсов
- •21.2.3. Тестирование с нагрузкой
- •21.3. Тестирование объектно-ориентированных систем
- •21.3.1. Тестирование классов объектов
- •21.3.2. Интеграция объектов
- •21.4. Инструментальные средства тестирования
- •Часть VI. Управление проектом программного обеспечения
- •22. Управление проектами
- •22.1. Процессы управления
- •22.2. Планирование проекта
- •22.3. График работ
- •22.4. Управление рисками
- •23. Управление персоналом
- •23.1. Пределы мышления
- •23.1.1. Организация человеческой памяти
- •23.1.2. Решение задач
- •23.1.3. Мотивация
- •23.2. Групповая работа
- •23.2.1. Создание команды
- •23.2.2. Сплоченность команды
- •23.2.3. Общение в группе
- •23.2.4. Организация группы
- •23.3. Подбор и сохранение персонала
- •23.3.1. Рабочая среда
- •23.4. Модель оценки уровня развития персонала
- •24. Оценка стоимости программного продукта
- •24.1. Производительность
- •24.2. Методы оценивания
- •24.3. Алгоритмическое моделирование стоимости
- •24.3.1. Модель сосомо
- •24.3.2. Алгоритмические модели стоимости в планировании проекта
- •24.4. Продолжительность проекта и наем персонала
- •25. Управление качеством
- •25.1. Обеспечение качества и стандарты
- •25.1.1. Стандарты на техническую документацию
- •25.1.2. Качество процесса создания программного обеспечения и качество программного продукта
- •25.2. Планирование качества
- •25.3. Контроль качества
- •25.3.1. Проверки качества
- •25.4. Измерение показателей программного обеспечения
- •25.4.1. Процесс измерения
- •25.4.2. Показатели программного продукта
- •26. Надежность программного обеспечения
- •26.1. Обеспечение надежности программного обеспечения
- •26.1.1 Критические системы
- •26.1.2. Работоспособность и безотказность
- •26.1.3. Безопасность
- •26.1.4. Защищенность
- •26.2. Аттестация безотказности
- •26.3. Гарантии безопасности
- •26.4. Оценивание защищенности программного обеспечения
- •27. Совершенствование производства программного обеспечения
- •27.1. Качество продукта и производства
- •27.2. Анализ и моделирование производства
- •27.2.1. Исключения в процессе создания по
- •27.3. Измерение производственного процесса
- •27.4. Модель оценки уровня развития
- •27.4.1. Оценивание уровня развития
- •27.5. Классификация процессов совершенствования
11.3. Системы наблюдения и управления
В настоящее время можно выделить несколько классов стандартных систем реального времени: мониторинговые системы (системы наблюдения), системы сбора данных, системы управления и др. Каждому типу систем соответствует особая структура процессов, поэтому при проектировании системы, как правило, архитектуру создают по одному из существующих стандартных типов. Таким образом, вместо обсуждения общих проблем проектирования систем реального времени здесь лучше рассмотреть проектирование с помощью обобщенных моделей.
Системы наблюдения и управления – важный класс систем реального времени. Их основным назначением является проверка сенсоров (датчиков), предоставляющих информацию об окружении системы, и выполнение соответствующих действий в зависимости от поступившей от сенсоров информации. Системы наблюдения выполняют действия после регистрации особого значения сенсора. Системы управления непрерывно управляют аппаратными исполнительными механизмами на основании значений, получаемых от сенсоров.
Рассмотрим следующий пример.
Пусть в здании установлена система охранной сигнализации. В системе используется несколько типов сенсоров: датчики движения, установленные в отдельных комнатах; датчики на окнах первого этажа, которые подают сигнал, если разбивается окно; дверные датчики, фиксирующие открывание дверей. Всего в системе 50 датчиков на окнах, 30 на дверях и 200 датчиков движения.
Когда какой-либо датчик фиксирует присутствие постороннего, система автоматически вызывает местную полицию и, используя звуковой синтезатор, сообщает местоположение датчика (номер комнаты), от которого идет сигнал. В комнатах, расположенных возле активного датчика, включается световая сигнализация и звуковой аварийный сигнал. Система сигнализации обычно включается через сеть, но может работать и от батарей. Проблемы с электропитанием регистрируются специальной программой, контролирующей напряжение электросети. Если в сети регистрируется падение напряжения, программа переключает систему сигнализации на резервное питание от батарей.
В этом примере описана "мягкая" система реального времени, так как здесь нет жестких временных требований. В такой системе не нужно регистрировать события, происходящие с высокой скоростью, поэтому опрос датчиков может проводиться два раза в секунду.
Процесс проектирования начинается с описания апериодических входных сигналов, получаемых системой, и связанных с ними реакций системы. Здесь мы ограничимся упрощенным проектом, в котором не учитываются сигналы, порождаемые процедурами самопроверки, и внешние сигналы, генерируемые при тестировании системы или при ее выключении в случае ложной тревоги. В конечном счете система обрабатывает только два типа входных сигналов.
1. Отключение электропитания генерируется программой, контролирующей электрическую цепь. В ответ на этот сигнал система переключает сеть на резервное питание посредством подачи сигнала электронному прибору переключения питания.
2. Сигнал о вторжении является входным и генерируется одним из датчиков системы. В ответ на него система определяет номер комнаты, в которой находится активный датчик, вызывает полицию, инициируя звуковой синтезатор, и включает звуковой сигнал тревоги и световую сигнализацию здания в месте нарушения.
На следующем шаге процесса проектирования определяются временные ограничения для каждого входного и ответного сигналов системы. В табл. 11.1 перечислены эти временные ограничения. К разным типам датчиков, генерирующих входные сигналы, предъявлены разные временные требования.
Таблица 11.1. Временные ограничения на входные и ответные сигналы системы
Сигнал |
Временные ограничения |
Отключение электропитания
Сигнализация на двери
Сигнализация на окнах Датчик движения
Звуковой сигнал
Включение световой сигнализации
Связь
Синтезатор речи |
Переключение на питание от батарей должно произойти в течение 50 мс
Каждый сигнальный датчик на дверях проверяется дважды в секунду
Каждый датчик на окне проверяется дважды в секунду
Каждый датчик движения опрашивается дважды в секунду
Звуковой сигнал должен прозвучать через полсекунды после сигнала датчика Световая сигнализация должна включиться через полсекунды после сигнала датчика
Вызов в полицию должен начаться в течение 2 с после сигнала датчика Синтезированное сообщение должно быть готово через 4 с после сигнала датчика |
Рис. 11.6. Архитектура процессов системы охранной сигнализации
На следующем этапе проектирования распределяются системные функции по параллельным процессам. Периодически нужно опрашивать три типа датчиков, поэтому у каждого типа датчиков имеется связанный с ними процесс. Кроме этого, есть система управления прерываниями, контролирующая электропитание, система связи с полицией, синтезатор речи, система включения звуковой сигнализации и система, включающая световую сигнализацию возле датчика. Каждой системой управляет независимый процесс. На рис. 11.6 показана архитектура процессов системы.
На схеме, представленной на рис. 11.6, стрелки (с примечаниями), соединяющие отдельные процессы, обозначают потоки данных между процессами с указанием типа данных. Надписи над стрелками справа над каждым процессом указывают систему, управляющую данным процессом. На стрелках вверху указано минимальное значение частоты выполнения процесса.
Частота выполнения процессов определяется количеством датчиков и временными требованиями, предъявляемыми системе. Предположим, что в системе имеется 30 дверных датчиков, которые требуется проверять два раза в секунду. Следовательно, связанный с дверным датчиком процесс должен выполняться 60 раз в секунду (частота 60 Гц). Также 400 раз в секунду выполняется процесс, контролирующий датчик движения.
Апериодические процессы обозначены стрелками с пунктирными линиями. На этих линиях указаны события, которые вызывают данный процесс. Все основные исполнительные процессы (звуковой и световой сигнализации и др.) начинаются командой из процесса Система безопасности; им не нужны данные из других процессов. Процессу, управляющему электропитанием, также не нужны данные из других частей системы.
Поскольку данная система не содержит строгих временных требований, ее можно реализовать на языке Java. Конечно, в Java 2.0 нет никакой гарантии соответствия временным спецификациям. В нашей системе все датчики опрашиваются одинаковое количество раз, чего не бывает в реальных системах.
После определения архитектуры процессов системы начинается разработка алгоритмов обработки входных сигналов и генерации ответных сигналов. Как уже отмечалось ранее, этот этап проектирования необходимо выполнять как можно раньше, чтобы удостовериться, что система будет соответствовать временным требованиям. Если соответствующие алгоритмы оказываются сложными, может возникнуть необходимость в изменении временных ограничений. Обычно алгоритмы систем реального времени сравнительно просты. Они проверяют ячейки памяти, выполняют некоторые простые расчеты и управляют передачей сигнала. В примере системы сигнализации проектирование алгоритмов не рассматривается.
Последним этапом процесса проектирования является составление временного графика выполнения процессов. В нашем примере нет процессов со строгими сроками выполнения. Рассмотрим приоритеты процессов. Все процессы, опрашивающие датчики, имеют один и тот же приоритет. Процессу, управляющему электропитанием, необходимо назначить более высокий приоритет. Приоритеты процессов, управляющих системой сигнализации, и процессов, опрашивающих датчики, должны быть одинаковы.
Систему охранной сигнализации можно отнести скорее к системам наблюдения, чем к системам управления, так как в ней нет исполнительных механизмов, напрямую зависящих от значений датчиков. Примером системы управления может служить система управления отоплением здания. Система наблюдает за температурными датчиками, установленными в разных комнатах здания и переключает нагревательные приборы в зависимости от реальной температуры и температуры, установленной в термореле. Термореле, в свою очередь, контролирует отопительный котел.
Архитектура процессов такой системы показана на рис. 11.7; в общем виде она выглядит подобно системе сигнализации. Дальнейшее рассмотрение этого примера предлагается читателю в качестве упражнения.
Рис. 11.7. Архитектура процессов системы управления отоплением