- •З курсу
- •З курсу
- •Содержание
- •Часть 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. Классификация процессов совершенствования
12.3. Проектные паттерны
Попытки повторно использовать действующие компоненты постоянно ограничиваются конкретными решениями, принятыми системными разработчиками. Решения могут относиться к отдельным алгоритмам, используемым при реализации компонентов, к объектам и к типам данных в интерфейсах компонентов. Если решения противоречат конкретным требованиям к компонентам, то повторное использование компонентов либо невозможно, либо делает систему неэффективной.
Один из способов решения данной проблемы – повторное использование более абстрактных структур, не содержащих деталей реализации. Такие структуры разрабатываются специально для того, чтобы соответствовать определенному приложению. Первые реализации этого подхода привели к документированию и опубликованию фундаментальных алгоритмов, а затем к документированию абстрактных типов данных, таких как стеки, деревья и списки. Совсем недавно такой способ повторного использования обобщен в понятии паттерна.
Проектные паттерны (design patterns) появились из идей, выдвинутых Кристофером Александером (Alexander), который предложил удобные и эффективные обобщенные паттерны разработки конкретных проектов. Паттерн – это описание проблемы и метода ее решения, позволяющее в дальнейшем использовать это решение в разных условиях. Паттерн не является детальной спецификацией. Скорее, он представляет собой описание, в котором аккумулированы знания и опыт. Паттерн – гарантированное решение общей проблемы.
При создании ПО проектные паттерны всегда связаны с объектно-ориентированным проектированием. Чтобы обеспечить всеобщность, паттерны часто используют такие объектно-ориентированные понятия, как наследование и полиморфизм. Однако общий принцип использования паттернов одинаково применим при любом подходе к проектированию ПО.
Существует четыре основных элемента проектного паттерна.
1. Содержательное имя, которое является ссылкой на паттерн.
2. Описание проблемной области с перечислением всех ситуаций, в которых можно использовать паттерн.
3. Описание решений с отдельным описанием различных частей решения и их взаимоотношений. Это не описание конкретного проекта, а шаблон проектных решений, который можно использовать различными способами. В описании решений часто используются графические представления, которые показывают взаимоотношения между объектами и классами объектов в данном решении.
4. Описание "выходных" результатов – это описание результатов и компромиссов, необходимых для применения паттерна. Обычно используется для того, чтобы помочь разработчикам оценить конкретную ситуацию и выбрать для нее наиболее подходящий паттерн.
13. Проектирование интерфейса пользователя
Проектирование вычислительных систем охватывает широкий спектр проектных действий – от проектирования аппаратных средств до проектирования интерфейса пользователя. Организации-разработчики часто нанимают специалистов для проектирования аппаратных средств и очень редко для проектирования интерфейсов. Таким образом, специалистам по разработке ПО зачастую приходится проектировать и интерфейс пользователя. Если в больших компаниях в этот процесс вовлекаются специалисты по инженерной психологии, то в небольших компаниях услугами таких специалистов практически не пользуются.
Грамотно спроектированный интерфейс пользователя крайне важен для успешной работы системы. Сложный в применении интерфейс, как минимум, приводит к ошибкам пользователя. Иногда они просто отказываются работать с программной системой, несмотря на ее функциональные возможности. Если информация представляется сбивчиво или непоследовательно, пользователи могут понять ее неправильно, в результате чего их последующие действия могут привести к повреждению данных или даже к сбою в работе системы.
В 1982 году, во время выхода первой редакции этой книги, стандартным устройством взаимодействия между пользователем и программой был "беззвучный" буквенно-цифровой (текстовый) терминал, отображающий на черном поле символы зеленого или синего цвета. В то время интерфейсы пользователя были текстовыми или создавались в виде специальных форм. Сейчас почти все пользователи работают на персональных компьютерах. Все современные персональные компьютеры поддерживают графический интерфейс пользователя (graphical user interface – GUI), который подразумевает использование цветного графического экрана с высоким разрешением и позволяет работать с мышью и с клавиатурой.
Хотя текстовые интерфейсы еще достаточно широко применяются, особенно в наследуемых системах, в наше время пользователи предпочитают работать с графическим интерфейсом. В табл. 13.1 перечислены основные элементы GUI.
Таблица 13.1. Элементы графических интерфейсов пользователя
Элементы |
Описание |
Окна |
Позволяют отображать на экране информацию разного рода |
Пиктограммы |
Представляют различные типы данных. В одних системах пиктограммы представляют файлы, в других – процессы |
Меню |
Ввод команд заменяется выбором команд из меню |
Указатели |
Мышь используется как устройство указания для выбора команд из меню и для выделения отдельных элементов в окне |
Графические элементы |
Могут использоваться совместно с текстовыми
|
Графические интерфейсы обладают рядом преимуществ:
1. Их относительно просто изучить и использовать. Пользователи, не имеющие опыта работы с компьютером, могут легко и быстро научиться работать с графическим интерфейсом.
2. Каждая программа выполняется в своем окне (экране). Можно переключаться из одной программы в другую, не теряя при этом данные, полученные в ходе выполнения программ.
3. Режим полноэкранного отображения окон дает возможность прямого доступа к любому месту экрана.
На рис. 13.1 изображен итерационный процесс проектирования пользовательского интерфейса. Как отмечалось ранее, наиболее эффективным подходом к проектированию интерфейса пользователя является разработка с применением моделирования пользовательских функций. В начале процесса прототипирования создаются бумажные макеты интерфейса, затем разрабатываются экранные формы, моделирующие взаимодействие с пользователем. Желательно, чтобы конечные пользователи принимали активное участие в процессе проектирования интерфейса. В одних случаях пользователи помогут оценить интерфейс; в других будут полноправными членами проектной группы.
Рис. 13.1. Процесс проектирования интерфейса пользователя
Важным этапом процесса проектирования интерфейса пользователя является анализ деятельности пользователей, которую должна обеспечить вычислительная система. Не изучив того, что, с точки зрения пользователя, должна делать система, невозможно сформировать реалистический взгляд на проектирование эффективного интерфейса. Для анализа нужно (как правило, одновременно) применять различные методики, а именно: анализ задач, этнографический подход, опросы пользователей и наблюдения за их работой.