Конспект лекций ТРПО

ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ПУТЕЙ СООБЩЕНИЯ
Кафедра «Информационные и вычислительные системы»
ТЕХНОЛОГИЯ РАЗРАБОТКИ
ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Конспект лекций
для студентов пятого курса специальности 220400 – Программное
обеспечение вычислительной техники и автоматизированных систем
составила доцент Довбуш Г. Ф.
Санкт-Петербург
2003
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
2
“ Математика делает то, что можно, так, как нужно,
тогда как информатика делает то,
что нужно, так, как можно ”.
Программистский фольклор.
Данный конспект лекций составлен для студентов четвёртого курса
специальности “Программное обеспечение вычислительной техники и
автоматизированных систем”. Автор предлагает изучить основы
технологии разработки программного обеспечения для решения научных и
прикладных задач.
В конспекте изложены методы, средства и рабочие процессы,
используемые для разработки сложных программных продуктов.
Основу материалов конспекта составляет объектно-ориентированный
подход создания программного обеспечения, начиная от анализа
требований и заканчивая сопровождением и модернизацией готовых
систем. Изучение дисциплины “Технология разработки программного
обеспечения” ориентировано на приобретение навыков объектноориентрованного подхода к раработке программных продуктов. Акцент
делается на этапах объектно-ориентированных анализа и проектирования.
В конспект включены объектные модели программных систем. Все модели
приведены в нотации унифицированного языка моделирования (Unified
Modeling Language – UML), который в ноябре 1997 года консорциум по
технологии манипулирования объектами (Object Management Group –
OMG) утвердил как международный стандарт.
В качестве инструмента автоматизации разработки программных проектов
рассматривается CASE-средство компании IBM Rational – Rational Rose
2001.
В данном курсе от студентов требуется знание основ объектноориентированного программирования (например, на C++, Java) и систем
управления базами данных (например, Oracle 9i) для реализации моделей
проектирования.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
3
СОДЕРЖАНИЕ
ВВЕДЕНИЕ ........................................................................................................................................................... 6
1 ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ .......................................................... 9
1.1 Специфика разработки программных средств ....................................................................................... 10
1.2 Жизненный цикл программных средств ................................................................................................. 11
1.3 МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ........................................................................................................ 14
1.4 УНИФИЦИРОВАННЫЙ ПРОЦЕСС РАЗРАБОТКИ ............................................................................ 17
1.4.1 Предмет технологии разработки программного обеспечения согласно RUP............................... 17
1.4.2 Основные цели RUP ........................................................................................................................... 18
1.4.3 Отличительные черты RUP ............................................................................................................... 19
1.4.4 Жизненный цикл RUP ....................................................................................................................... 23
1.5 ПОНЯТИЕ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ ........................................................................ 24
1.6 УПРАВЛЕНИЕ КАЧЕСТВОМ РАЗРАБОТКИ ...................................................................................... 26
1.6.1 Управление компанией ...................................................................................................................... 26
1.6.2 Управление продукцией .................................................................................................................... 26
1.6.3 Управление разработкой ................................................................................................................... 26
1.7 ОБЕСПЕЧЕНИЕ НАДЁЖНОСТИ ........................................................................................................... 28
1.7.1 Методы борьбы со сложностью ........................................................................................................ 29
1.7.2 Обеспечение точности перевода ....................................................................................................... 29
1.7.3 Преодоление барьера между пользователем и разработчиком ..................................................... 29
1.7.4 Контроль принимаемых решений ..................................................................................................... 30
2 ВВЕДЕНИЕ В УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ ...................................................... 31
2.1 ОПРЕДЕЛЕНИЕ, НАЗНАЧЕНИЕ И СФЕРА ПРИМЕНЕНИЯ UML ................................................... 32
2.2 КОНСТРУКТИВНЫЕ БЛОКИ UML ...................................................................................................... 34
2.2.1 Структурные сущности ..................................................................................................................... 34
2.2.2 Отношения .......................................................................................................................................... 41
2.2.3 Диаграммы .......................................................................................................................................... 51
2.3 ТРЁХУРОВНЕВАЯ МОДЕЛЬ ПРИЛОЖЕНИЯ .................................................................................... 63
2.3.1 Компоненты уровня представления ................................................................................................. 63
2.3.2 Бизнес-правила ................................................................................................................................... 63
2.3.3 Компоненты уровня управления данными ...................................................................................... 63
2.3.4 Распределённая вычислительная архитектура ................................................................................ 64
3 ПРОЕКТИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА ............................................................. 65
3.1 ЭВОЛЮЦИЯ ИНТЕРФЕЙСА ЧЕЛОВЕК-КОМПЬЮТЕР.................................................................... 67
3.2 ОСНОВНЫЕ ВОПРОСЫ ПРОЕКТИРОВАНИЯ ИНТЕРФЕЙСА ....................................................... 68
3.3 МОДЕЛИ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА .......................................................................... 69
3.4 ТРЕБОВАНИЯ К ПОЛЬЗОВАТЕЛЬСКОМУ ИНТЕРФЕЙСУ ............................................................. 71
3.5 ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ ИНТЕРФЕЙСА ............................................................................ 72
3.5.1 Контроль на стороне пользователя ................................................................................................... 72
3.5.2 Обратная связь .................................................................................................................................... 72
3.5.3 Эстетичность и удобство ................................................................................................................... 72
3.5.4 Согласованность ................................................................................................................................. 73
3.5.5 Настройка ............................................................................................................................................ 73
3.5.6 Терпимость к ошибкам ...................................................................................................................... 73
3.6 ПРАВИЛА ПРОЦЕССА РАЗРАБОТКИ ИНТЕРФЕЙСА ..................................................................... 74
3.7 КРИТЕРИИ КАЧЕСТВА ИНТЕРФЕЙСА .............................................................................................. 76
3.7.1 Простой – Simple ................................................................................................................................ 76
3.7.2 Эстетичный – Aesthetic ...................................................................................................................... 76
3.7.3 Продуктивный – Productive ............................................................................................................... 76
3.7.4 Настраиваемый – Customizable ......................................................................................................... 76
3.7.5 Другой – Other .................................................................................................................................... 76
4 ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД К РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
.............................................................................................................................................................................. 77
4.1 ПАКЕТЫ КЛАССИЧЕСКОЙ МОДЕЛИ СИСТЕМЫ ........................................................................... 78
4.2 МЕТОДОЛОГИИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ............................................... 82
4.2.1 Объектно-ориентированный анализ ................................................................................................. 82
4.2.2 Объектно-ориентированное проектирование .................................................................................. 90
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
4
4.2.3 Методы проектирования ................................................................................................................... 97
5 ОБЪЕКТНАЯ МЕТОДОЛОГИЯ – OBJECT METHODOLOGY ................................................................ 105
5.1 ОБЪЕКТНАЯ МОДЕЛЬ ......................................................................................................................... 107
5.2 ПРОЦЕДУРА МОДЕЛИРОВАНИЯ ...................................................................................................... 110
5.3 КОНЦЕПЦИИ ОБЪЕКТНОЙ МЕТОДОЛОГИИ ................................................................................. 111
5.3.1 Концептуальная целостность – Conceptual Integrity ..................................................................... 111
5.3.2 Гарантированный результат – Contract .......................................................................................... 111
5.3.3 Самодостаточность – Selfishness .................................................................................................... 112
5.3.4 Иерархия – Hierarchy ....................................................................................................................... 113
5.3.5 Согласованность – Seamlesness....................................................................................................... 113
5.4 МОДЕЛИ СИСТЕМЫ ............................................................................................................................ 115
5.4.1 Статическая модель системы .......................................................................................................... 115
5.4.2 Динамическая модель системы ....................................................................................................... 115
5.4.3 Функциональная модель системы .................................................................................................. 116
5.4.4 Физическая модель системы ........................................................................................................... 117
5.4.5 Статическая и динамическая модели ............................................................................................. 117
5.4.6 Статическая и функциональная модели ......................................................................................... 117
5.4.7 Динамическая и функциональная модели ..................................................................................... 118
6 ОСНОВНЫЕ ЭТАПЫ ЖИЗНЕННОГО ЦИКЛА ........................................................................................ 119
6.1 СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ ...................................................................................................... 120
6.2 ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПРОГРАММНОМУ СРЕДСТВУ .............................................. 122
6.3 СПЕЦИФИКАЦИЯ КАЧЕСТВА ........................................................................................................... 124
6.4 ФУНУЦИОНАЛЬНАЯ СПЕЦИФИКАЦИЯ ......................................................................................... 127
6.5 МЕТОДЫ КОНТРОЛЯ СПЕЦИФИКАЦИИ ТРЕБОВАНИЙ ............................................................. 129
6.6 АНАЛИЗ .................................................................................................................................................. 131
6.7 ПРОЕКТИРОВАНИЕ ............................................................................................................................. 133
6.7.1 Концептуальное проектирование ................................................................................................... 134
6.7.2 Логическое проектирование ............................................................................................................ 134
6.7.3 Физическое проектирование ........................................................................................................... 136
6.8 РЕАЛИЗАЦИЯ (КОДИРОВАНИЕ) И ЭВОЛЮЦИЯ ........................................................................... 138
6.9 СОПРОВОЖДЕНИЕ ............................................................................................................................... 141
6.10 ТЕСТИРОВАНИЕ ................................................................................................................................. 142
6.10.1 Определение требований ............................................................................................................... 144
6.10.2 Анализ ............................................................................................................................................. 144
6.10.3 Проектирование.............................................................................................................................. 144
6.10.4 Реализация ...................................................................................................................................... 145
6.10.5 Тестирование .................................................................................................................................. 145
6.10.6 Опытная эксплуатация ................................................................................................................... 146
6.10.7 Окончательная приёмка и сертификация ..................................................................................... 146
6.10.8 Сопровождение .............................................................................................................................. 147
7 ОРГАНИЗАЦИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ .................................................. 148
7.1 ГРУППА ПРОЕКТА И РОЛИ УЧАСТНИКОВ ГРУППЫ .................................................................. 149
7.1.1 Руководитель проекта – Program manager ...................................................................................... 149
7.1.2 Менеджер по маркетингу – Product manager ................................................................................. 149
7.1.3 Разработчик – Developer .................................................................................................................. 150
7.1.4 Тестер – Tester .................................................................................................................................. 151
7.1.5 Технический писатель – Writer ....................................................................................................... 151
7.1.6 Представитель группы технической поддержки – Logistic .......................................................... 151
7.1.7 Другие специалисты ........................................................................................................................ 152
7.2 МОДЕЛЬ ПРОЕКТНОЙ ГРУППЫ ....................................................................................................... 153
8 ДОКУМЕНТАЦИЯ ПРОЦЕССА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ....................... 156
8.1 ПОЛЬЗОВАТЕЛЬСКАЯ ДОКУМЕНТАЦИЯ ...................................................................................... 158
8.2 ДОКУМЕНТАЦИЯ ПО СОПРОВОЖДЕНИЮ .................................................................................... 160
9 АВТОМАТИЗАЦИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ........................................... 162
9.1 ОСОБЕННОСТИ И КОМПОНЕНТЫ CASE-СРЕДСТВ ..................................................................... 163
9.2 ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ CASE-СРЕДСТВА АНАЛИЗА И ПРОЕКТИРОВАНИЯ .... 165
9.3 СТРУКТУРНЫЕ CASE-СРЕДСТВА..................................................................................................... 167
9.4 CASE-СРЕДСТВА КОМПАНИИ IBM RATIONAL SOFTWARE ...................................................... 169
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
5
9.4.1 Средство визуального моделирования Rational Rose ................................................................... 169
9.4.2 Автоматизированное документирование Rational SoDA.............................................................. 170
9.4.3 Управление требованиями Rational RequisitePRO ........................................................................ 171
9.4.4 Управление запросами на изменение Rational ClearQuest ............................................................ 171
9.4.5 Измерение характеристик Rational Quantify .................................................................................. 172
9.4.6 Поиск ошибок исполнения Rational Purify .................................................................................... 173
9.4.7 Области кода, неподдающиеся тестированию Rational PureCoverage ........................................ 174
9.4.8 Визуальное тестирование Rational Visual Test .............................................................................. 174
9.4.9 Тестирование пользовательского интерфейса Rational Robot ...................................................... 175
9.4.10 Тестирование распределённых приложений Rational LoadTest ................................................. 175
9.4.11 Конфигурационный и версионный контроль Rational ClearCase ............................................... 175
ЗАКЛЮЧЕНИЕ ................................................................................................................................................. 177
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ........................................................................................ 179
PS ........................................................................................................................................................................ 183
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
6
Технология – совокупность производственных методов
и процессов в определённой отрасли производства,
а также научное описание способов производства.
С.И. Ожегов. Словарь русского языка. – М.: Русский язык, 1990
ВВЕДЕНИЕ
Хотя понятие технологии в русском языке имеет ясное определение,
понятие
технологии разработки программного обеспечения требует
некоторого уточнения, прежде всего из-за необходимости определения,
что следует считать продуктом этой технологии
Целью программирования является описание процессов обработки
данных. Данные – это представление фактов и идей в формализованном
виде, пригодном для передачи и переработки в некоем процессе, а
информация – это смысл,
который придаётся данным при
их
представлении. Обработка данных – это выполнение систематической
последовательности действий с данными. Данные представляются и
хранятся на носителях данных.
Совокупность носителей данных,
используемых при обработке данных, называют
информационной
средой. Набор данных, содержащихся в каждый момент времени в
информационной среде, называют состоянием этой информационной
среды. Процесс обработки данных
можно определить как
последовательность сменяющих друг друга состояний некоторой
информационной среды.
Описание
процесса
обработки
данных
–
это
определение
последовательности состояний заданной информационной среды. Если
необходимо,
чтобы по заданному описанию требуемый процесс
порождался автоматически на каком-либо компьютере, это описание
должно быть
формализованным.
Такое описание называется
программой. Программисту, прежде чем составить программу на удобном
для него языке программирования, приходится проделывать большую
подготовительную работу по уточнению постановки задачи, выбору
метода её решения, выяснению специфики применения требуемой
программы, прояснению общей организации разрабатываемой программы
и многое другое. Использование этой информации может существенно
упростить задачу понимания программы программистами, поэтому весьма
полезно её как-то фиксировать в виде документов.
Обычно программы разрабатываются в расчёте на то, чтобы ими могли
пользоваться люди, не участвующие в их разработке (их называют
пользователями). Для освоения программы пользователем требуется
определённая дополнительная документация.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
7
Программа или логически связанная совокупность программ обработки
данных на носителях данных, снабжённая необходимой программной
документацией, называется программным средством (ПС).
Программа позволяет осуществлять некоторую автоматическую обработку
данных на компьютере. Программная документация позволяет понять,
какие функции выполняет то или иное ПС, как подготовить исходные
данные и запустить требуемую программу, а также: что означают
получаемые результаты (или каков эффект выполнения этой программы).
Кроме того, программная документация помогает разобраться в самой
программе, что необходимо, например, при её модификации.
Таким образом, можно считать, что продуктом технологии разработки
программного обеспечения является программа, эффективно и надёжно
выполняющая требуемые функции на реальных компьютерах.
Под “программой” часто понимают программу, не содержащую ошибок.
Однако понятие ошибки в программе трактуется в среде программистов
неоднозначно. Согласно Майерсу считается, что в программе имеется
ошибка, если она не выполняет того, что разумно ожидать от неё
пользователю.
“Разумное ожидание” пользователя формируется на
основании документации по применению этой программы. Следовательно,
понятие ошибки в программе является существенно не формальным. В
этом случае правильнее говорить об ошибке в ПС. Разновидностью
ошибки в ПС является несогласованность между программами и
документацией по их применению. Выделяется в отдельное понятие
частный случай ошибки в ПС, когда программа не соответствует своей
функциональной спецификации (описанию, разрабатываемому на этапе,
предшествующему непосредственному программированию).
Такая
ошибка называется дефектом программы. Однако выделение такой
разновидности ошибки в отдельное понятие вряд ли оправданно, так как
причиной ошибки может оказаться сама функциональная спецификация,
а не программа.
В связи с тем, что задание на ПС обычно формулируется не формально,
а также из-за неформализованности понятия ошибки в ПС, нельзя
доказать формальными методами (математически) правильность ПС.
Нельзя показать правильность ПС и тестированием. Тестирование может
лишь продемонстрировать наличие в ПС ошибки. Поэтому понятие
“правильной программы” неконструктивно в том смысле, что после
окончания работы над созданием ПС невозможно убедиться, что цель
достигнута.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
8
Альтернативой “правильного” ПС является надёжное ПС. Надёжность ПС
– это его способность безотказно выполнять опредёленные функции при
заданных условиях в течение заданного периода времени с достаточно
большой вероятностью. При этом под отказом в ПС понимают проявление
в нём ошибки. Таким образом, надёжное ПС не исключает наличия в нём
ошибок – важно лишь, чтобы эти ошибки при практическом применении
этого ПС в заданных условиях проявлялись достаточно редко. Убедиться,
что ПС обладает таким свойством можно при его испытании путём
тестирования, а также при практическом применении. Таким образом,
фактически можно разрабатывать лишь надёжное, а не правильное ПС.
В соответствии с обычным значением слова “технология” под
технологией разработки программного обеспечения будем понимать
совокупность производственных процессов, приводящую к созданию
требуемого программного средства, а также описание этой совокупности
процессов.
Различают методы, средства и процедуры технологии разработки ПС.
Методы обеспечивают решение следующих задач:
1.
2.
3.
4.
5.
Планирование и оценка проекта.
Анализ системных и программных требований.
Проектирование структур данных и программных структур.
Кодирование.
Тестирование.
Средства обеспечивают автоматизированную поддержку методов. В
настоящее время широко используются CASE-средства (Computer Aided
Software Engineering), которые поддерживают автоматизацию этапов
анализа, проектирования, тестирования и реализации систем.
Процедуры соединяют методы и средства так, что они обеспечивают
непрерывную технологическую цепочку разработки ПС. Процедуры
определяют:
1.
2.
3.
4.
Порядок применения методов и средств.
Контроль за продвижением работ по проекту.
Контроль за изменениями.
Оценку рисков.
Разработка ПС состоит из последовательности процессов (основных,
вспомогательных и организационных). Каждый процесс этой
последовательности базируется на использовании каких-либо методов и
средств. Совокупность методов и средств, используемых для создания ПС,
часто называют парадигмами технологии программирования.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
9
1 ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ
Процесс создания программного средства (ПС), как и любая другая
интеллектуальная деятельность, основан на человеческих суждениях и
умозаключениях, то есть является творческим. Вследствие этого все
попытки автоматизировать процесс создания ПС имеют лишь
ограниченный успех. CASE-средства могут помочь лишь в реализации
некоторых этапов процесса разработки ПС. Главная причина
ограниченного применения автоматизированных средств – огромное
многообразие видов деятельности, связанных с разработкой программных
продуктов. Кроме того, разработчики используют разные подходы к
созданию ПС. Также различаются характеристики и возможности
создаваемых систем. Поэтому даже в одном коллективе разработчиков при
создании разных ПС могут использоваться различные подходы и
технологии.
Несмотря на то, что наблюдается огромное разнообразие подходов,
методов и технологий создания ПС, существуют фундаментальные
базовые процессы, без реализации которых не может обойтись ни одна
технология разработки ПС. К ним относятся:
1. Разработка спецификации ПС. Это фундамент любого программного
средства. Спецификация определяет все функции и действия, которые
будет выполнять разрабатываемая система.
2. Проектирование и реализация ПС. Это процесс непосредственного
создания ПС на основе спецификации.
3. Аттестация ПС. Разработанное программное средство должно быть
аттестовано на соответствие требованиям заказчика.
4. Эволюция
ПС.
Любые
программные
системы
должны
модифицироваться в соответствии с изменениями требований
заказчика.
Хотя не существует “идеального” процесса создания ПС, во многих
организациях-разработчиках
пытаются
его
усовершенствовать.
Совершенствовать процесс можно разными путями. Например, путём
стандартизации, которая уменьшит разнородность используемых
технологий и сделает экономически выгодной автоматизацию разработок.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
10
1.1 СПЕЦИФИКА РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ
Разработке ПС присущ ряд специфических особенностей.
1. Некоторое противостояние: неформальный характер требований к ПС
(постановка задачи) и понятия ошибки в нём, но формализованный
основной объект разработки – программы ПС. Тем самым разработка
ПС содержит определённые этапы формализации, а переход от
неформального к формальному существенно неформален.
2. Разработка ПС носит творческий характер (на каждом шаге
приходится делать какой-либо выбор, принимать какое-либо решение),
а не сводится к выполнению последовательности регламентированных
действий. Тем самым эта разработка ближе к процессу проектирования
каких-либо сложных устройств, но никак не к их массовому
производству. Этот творческий характер разработки ПС сохраняется до
самого её конца.
3. Особенность продукта разработки. ПС представляет собой некоторую
совокупность текстов (т.е.
статических объектов),
смысл же
(семантика) этих текстов выражается процессами обработки данных и
действиями пользователей, запускающих эти процессы (т.е. является
динамическим). Это предопределяет выбор разработчиком ряда
специфичных приёмов, методов и средств.
4. Ещё одна особенность продукта разработки. ПС при своём
использовании (эксплуатации) не расходуется и не расходует
используемых ресурсов.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
11
1.2 ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНЫХ СРЕДСТВ
Жизненный цикл программного средства – это совокупность процессов
(software process), которая отражает его различные состояния, начиная с
момента принятия решения о необходимости создания программного
средства и заканчивая его полным изъятием из эксплуатации.
Структура жизненного цикла в соответствии со стандартом ISO/IEC
12207 Международной организации по стандартизации (International
Standards Organization) и Международной комиссии по электротехнике
(International Electric engineering Commission) базируется на трёх
группах процессов:
1. Основные процессы.
2. Вспомогательные процессы.
3. Организационные процессы.
Каждый процесс характеризуется определёнными задачами и методами их
решения, исходными данными и результатами.
Основные процессы:
-
приобретение,
поставка,
разработка,
эксплуатация,
сопровождение.
Вспомогательные процессы (обеспечивающие выполнение основных
процессов):
-
документирование,
обеспечение качества,
управление конфигурацией,
верификация,
аттестация.
Организационные процессы:
-
управление проектами,
создание инфраструктуры проекта,
определение,
оценка и улучшение самого жизненного цикла,
обучение.
Жизненный цикл состоит из логически завершённых частей, называемых
стадиями. Каждая стадия порождает определённый набор документов и
технических решений.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
12
Различают следующие стадии жизненного цикла ПС: разработка ПС,
производство программных изделий (ПИ) и эксплуатация ПС.
Стадия производства
программных изделий
Стадия разработки
Стадия эксплуатации
Фаза применения
Этап внешнего
описания
Этап конструирования
Фаза сопровождения
Этап аттестации
Этап кодирования
Стадия разработки (development) ПС состоит из этапа его внешнего
описания, этапа конструирования, этапа кодирования (программирование в
узком смысле) и этапа аттестации ПС. Всем этим этапам сопутствуют
процессы документирования и управления (management) разработкой.
Этапы конструирования и кодирования часто перекрываются, иногда
довольно сильно. Это означает, что кодирование некоторых частей
программного обеспечения может быть начато до завершения этапа
конструирования.
Внешнее описание (Requirements document) ПС является описанием его
поведения с точки зрения пользователя с фиксацией требований
относительно его качества. Внешнее описание начинается с определения
назначения ПС и требований к нему со стороны заказчика.
Конструирование (design) ПС охватывает процессы: разработку
архитектуры, разработку структур программ и данных, а также их
детальную спецификацию.
Кодирование (coding) – создание текстов программ
программирования, их отладка с тестированием ПС.
на
языках
На этапе аттестации ПС производится оценка качества ПС, после
успешного завершения которого разработка ПС считается законченной.
Программное изделие (ПИ) – экземпляр или копия, снятая с
разработанного ПС. Изготовление ПИ – это процесс генерации и/или
воспроизведения (снятия копии) программ и программных документов ПС
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
13
с целью их поставки пользователю для применения по назначению.
Производство ПИ – это совокупность работ по обеспечению изготовления
требуемого количества ПИ в установленные сроки. Данная стадия в
жизненном цикле ПС является, по существу, вырожденной (не
существенной), так как представляет рутинную работу, которая может
быть выполнена автоматически и без ошибок. Этим она принципиально
отличается от стадии производства различной техники. В связи с этим в
литературе эту стадию, как правило, не включают в жизненный цикл ПС.
Стадия эксплуатации ПС охватывает процессы хранения, внедрения и
сопровождения ПС, а также транспортировки и применения ПИ по
своему назначению. Она состоит из двух параллельно проходящих фаз:
фазы применения ПС и фазы сопровождения ПС.
Применение (operation) ПС – это использование ПС для решения
практических задач на компьютере путём выполнения программ.
Сопровождение (maintenance) ПС – это процесс сбора информации о его
качестве в эксплуатации, устранения обнаруженных в нём ошибок, его
доработки и модификации, а также извещения пользователей о внесённых
в него изменениях.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
14
1.3 МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА
Под моделью жизненного цикла программного средства понимается
структура, определяющая последовательность выполнения стадий, и
взаимосвязи стадий на протяжении жизненного цикла.
Существующие модели определяют порядок исполнения этапов в ходе
разработки, а также критерии перехода от этапа к этапу. Наибольшее
распространение получили две модели жизненного цикла:
1. Каскадная модель (модель водопада) – Cascade Model (1970г.– 1985г.).
2. Спиральная модель – Spiral Model (1986г. – настоящее время).
1.3.1 Каскадная модель жизненного цикла
Анализ и планирование требований
Проектирование
Реализация
Тестирование и отладка
Эксплуатация и сопровождение
Каскадная модель предполагает переход на следующий этап после полного
окончания работ по предыдущему этапу, то есть представляет строго
упорядоченную последовательность этапов.
Данный подход хорошо зарекомендовал себя при создании систем, когда:
- в самом начале разработки можно достаточно точно и полно
сформулировать все требования;
- требования не меняются со временем;
- имеется большой опыт реализации подобных проектов;
- время реализации проекта не более года.
В категорию таких систем попадают, например, системы обработки
данных, расчётные системы и системы реального времени.
Основные преимущества применения каскадной модели заключаются в
следующем:
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
15
- на каждом этапе формируется законченный набор проектной
документации, отвечающий критериям полноты и согласованности;
- выполняемые в логической последовательности этапы работ позволяют
планировать сроки завершения всех работ и соответствующие затраты.
Реальный процесс создания программ никогда полностью не укладывается
в такую жёсткую схему, постоянно возникает потребность в возврате к
предыдущим этапам и уточнении или пересмотре принятых решений.
Недостатки каскадной модели:
- неприспособленность к изменениям требований к проекту;
- существенное запаздывание с получением результата;
- длительный период создания системы, который может привести к тому,
что реализация проекта морально устареет одновременно с
утверждением.
Для преодоления перечисленных выше проблем была предложена
спиральная модель жизненного цикла.
1.3.2 Спиральная модель жизненного цикла
Планирование
Анализ риска
Версии системы
Переходный период
Конструирование
В этой модели делается упор на начальные этапы жизненного цикла:
анализ требований и проектирование. Создаются прототипы будущей
системы. Каждый виток спирали соответствует версии проекта. Затем
уточняются цели и характеристики проекта, и производится более
детальная разработка. Углубляются и конкретизируются детали проекта, а
в результате – выбирается основной вариант. Главная задача – как можно
быстрее показать пользователям работоспособный продукт, активизируя
тем самым процесс уточнения и дополнения требований.
Основные преимущества спиральной модели:
- накопление и повторное использование программных средств, моделей
и прототипов;
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
16
- ориентация на развитие и модификацию программного обеспечения в
процессе проектирования;
- анализ издержек в процессе проектирования;
- приспособленность к изменениям требований к проекту.
Главная проблема при использовании спиральной модели заключается в
определении момента перехода на следующий этап. Для решения этой
проблемы обычно вводятся временнЫе ограничения на каждый из этапов
жизненного цикла. Переход осуществляется в соответствии с планом, даже
если не вся запланированная работа закончена. План, как правило,
составляется на основе личного опыта разработчиков.
Классификация моделей жизненного цикла достаточно условна, и реально
при работе над проектом используются и та, и другая. Выбор зависит от
многих факторов (требования к проекту, опыт разработчиков, имеющиеся
ресурсы и т.п.) и производится руководителем проекта.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
17
1.4 УНИФИЦИРОВАННЫЙ ПРОЦЕСС РАЗРАБОТКИ
Rational Unified Process (RUP) определяет:
-
кто делает,
когда делает,
что делает,
как достичь заданной цели.
1.4.1 Предмет технологии разработки программного обеспечения
согласно RUP
Включает следующие понятия: ПЕРСОНАЛ, ПРОЕКТ, ПРОДУКТ,
ПРОЦЕСС, УТИЛИТЫ.
Процесс
Шаблон
Персонал
Участники
Проект
Результат
Утилиты
Автоматизация
Продукт
Персонал
Это реальные люди, которые принимают участие в создании программного
обеспечения, а также заказчики, пользователи и другие заинтересованные
лица (например, продавцы программного обеспечения). В проектной
группе каждый из этих людей выполняет определённую роль: архитектора,
разработчика, тестера. Навыки реальных людей должны соответствовать
их ролям. Известный лозунг: “Кадры решают всё!” – вполне
соответствует процессу разработки программного обеспечения.
Проект
Проект представляет собой организационную сущность, при помощи
которой происходит управление разработкой программного обеспечения.
Проект планируется и управляется. Результатом проекта является
выпущенный продукт. Первая итерация завершается выпуском пилотного
проекта, который развивается путём последующих итераций.
Продукт
Продукт – это программное средство, предназначенное для передачи в
эксплуатацию и удовлетворяющее ряду требований. Важнейшими
требованиями являются:
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
-
18
код программ и база данных;
набор моделей (или спецификаций) для представления системы;
комплект документации к программному средству;
лицензионные соглашения.
Процесс
Процесс представляет собой способ организации разработки и
сопровождения программной системы. Он является шаблоном (только
лишь определением) полного набора действий, необходимых для
преобразования требований пользователей в программный продукт.
Процесс должен предоставить и обеспечить максимальные удобства для
деятельности каждого человека из персонала при создании ПС.
Утилиты
Это программы, используемые для автоматизации определённых в
процессе видов деятельности. Процесс определяет средства поддержки для
разработки программного обеспечения. Автоматизированный процесс
должен обеспечивать целостность проекта при параллельной работе всех
участников проектной группы. Средства автоматизации должны быть
просты в использовании и должны давать возможность максимально
использовать то, что уже сделано. В идеале, средства автоматизации
должны поддерживать весь жизненный цикл программной системы.
1.4.2 Основные цели RUP
В основе процесса разработки ПС лежит множество технологий: сред
разработки, операционных систем, языков программирования, сетей,
систем управления базами данных, компьютеров и т.п. При этом следует
использовать технологии, существующие во время использования
процесса, т.е. современные технологии.
Процесс опирается на огромное разнообразие видов деятельности
участников проектной группы, причём каждый вид деятельности
контролируется и управляется процессом.
Rational Unified Process – методология создания программных средств.
RUP поставляется в виде не обычного программного продукта, а в виде
on-line документации, оформленной в виде Web-страницы, что позволяет
его размещение во внутренней сети организации-разработчика.
Цели данной методологии заключаются в следующем:
1. Создавать отвечающее нуждам конечных пользователей программное
обеспечение в запланированные сроки и с запланированным бюджетом.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
19
2. Выпускать
программное
обеспечение,
пользуясь
принципом
промышленного подхода. То есть так, как поступают любые заводы и
фабрики: определяя стадии, потоки, уточняя обязанности каждого
участника проекта.
3. Контролировать всё происходящее в проекте посредством создания
специальных архивов.
4. Унифицировать документооборот, приведя его в соответствие со всеми
известными стандартами. Это значит, что начало, работа, и завершение
проекта сопровождаются унифицированными документами, которыми
должен пользоваться каждый участник проекта.
Для каждого потока работ RUP рекомендует инструментальное средство,
выполняющее соответствующую этому потоку работ функцию.
1.4.3 Отличительные черты RUP
К отличительным чертам унифицированного
программного обеспечения относятся следующие:
процесса
разработки
1. Итеративный подход к разработке – Controlled Iterative.
2. Функции как основа проекта – Use Case Driven.
3. Управление требованиями и изменениями требований – Requirements
Configuration and Change Management.
4. Приоритет архитектуры – Architecture Centric.
5. Способность к изменению конфигурации – Configurable Process.
6. Визуальное моделирование – Visual Modeling Techniques.
7. Объектно- и сервисно-ориентированное проектирование – Component
Based Development.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
20
Итеративный подход к разработке – Controlled Iterative
При разработке сложных ПС невозможно сразу определить все требования
и реализовать их в виде окончательного варианта.
Процесс выявления требований итеративный, и как следствие,
итеративным является процесс разработки программного обеспечения.
Итеративный подход предполагает постепенное проникновение в суть
проблемы путём последовательных уточнений и построение всё более
ёмкого решения на протяжении нескольких циклов.
Использование итеративного подхода позволяет выявить и устранить
связанные с проектом риски на самых ранних этапах разработки.
Функции как основа проекта – Use Case Driven
В основе построения ПС лежит исчерпывающее представление о его
назначении. Концепция функций ПС используется на всех стадиях
процесса разработки – от формулировки требований до поставки готового
ПС. Разработка ПС является управляемой функциями объектов
предметной области.
Понятия функций, актёров (инициаторов системных функций) и объектов
предметной области, а также сценариев их поведения (use cases)
составляют основу процесса определения требований (requirements) и
процесса моделирования предметной области (business modeling),
обеспечивая согласованность и управляемость процессом разработки.
Управление требованиями и изменениями требований
Requirements Configuration and Change Management
New or changed
Software
Engineering Process
–
Changed System
requirements
или определение
первоначальных
требований к системе
(initial development cycle)
или определение
изменённых требований
(evolution cycle)
Процесс разработки ПС – это развитие на основе или определения
первоначальных требований к системе (initial development cycle), или
определения изменённых требований (evolution cycle).
Использование итерационного процесса обеспечивает:
1. Управление требованиями (requirements management).
2. Контроль за изменениями требований (change control).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
21
Под управлением требованиями понимается формализованная процедура,
которая позволяет определять, структурировать и документировать
требования к ПС, однозначно понимаемые разработчиком и заказчиком.
Контроль за изменениями – процесс, гарантирующий фиксацию изменений
требований к ПС и отражение этих изменений в проектной документации
и в моделях.
Приоритет архитектуры – Architecture Centric
Архитектура системы лежит в центре внимания RUP. Основное внимание
уделяется раннему определению архитектуры ПС и формулированию
основных её особенностей.
В контексте разработки программного обеспечения термин “архитектура”
означает высокоуровневую структуру компонентов, интерфейсы между
ними, их взаимосвязи и взаимодействие.
Архитектура системы складывается из подсистем, классов, распределения
обязанностей и взаимодействия объектов, обеспечивающих выполнение
функций системы.
Хорошо спроектированная архитектура имеет следующие качества:
1.
2.
3.
4.
5.
6.
7.
Многоуровневая структура подсистем (модулей).
Слабое связывание модулей между собой.
Простота понимания.
Надёжность и масштабируемость.
Хорошая возможность повторного использования компонентов.
Учёт наиболее важных и критичных функций.
Хорошо продуманный интерфейс с системой и её подсистемами.
Способность к изменению конфигурации – Configurable Process
Ни одна существующая методология программирования не способна
удовлетворить требованиям всех организаций, занимающихся разработкой
программного обеспечения. RUP поддаётся конфигурированию, потому
что:
1. Обеспечивает концептуальное единство во множестве всех процессов
разработки.
2. Содержит рекомендации по конфигурированию для нужд конкретной
организации.
3. Масштабируется для использования как в совсем небольших
коллективах, так и в гигантских компаниях.
4. Адаптируется к различным ситуациям.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
22
Визуальное моделирование – Visual Modeling Techniques
Визуальным моделированием называется процесс графического
представления модели с помощью некоторого стандартного набора
графических элементов.
Визуальное моделирование не является “серебряной пулей”, способной раз
и навсегда решить все проблемы, однако его использование существенно
облегчает достижения таких целей как:
1. Повышение качества программного продукта.
2. Сокращение стоимости проекта.
3. Поставка системы в запланированные сроки.
Суть работы в RUP – это создание и сопровождение моделей, а не
бумажных документов. Это значит, что он повышает степень
информационного наполнения процесса разработки ПС, так как
ориентирован на модели. Визуальные модели ПС отображают его работу
на различных уровнях:
- на уровне взаимодействия между пользователем и системой;
- на уровне взаимодействия объектов внутри системы;
- на уровне взаимодействия между различными системами.
Каждая модель самодостаточна в том смысле, что участник проектной
группы, работающий с моделью, не нуждается в дополнительной
информации (например, из других моделей) для её понимания. К
основному набору моделей RUP относятся следующие модели:
1.
2.
3.
4.
5.
6.
Модель функций системы.
Модель анализа.
Модель проектирования.
Модель развёртывания (модель реализации).
Модель разработки (модель реализации).
Модель тестирования.
Модели 1- 5 трассируются как в прямом, так и в обратном направлении.
Объектнои
сервисно-ориентированное
Component Based Development
проектирование
–
RUP поддерживает объектно-ориентированные методики. Каждая модель
объектно-ориентированна. Модели основаны на понятиях объектов и
классов и отношений между ними. Моделирование базируется на
принципах абстракции и декомпозиции по объектам и классам.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
23
1.4.4 Жизненный цикл RUP
Унифицированный процесс циклически повторяется и базируется на
спиральной модели жизненного цикла.
Рождение
Смерть

Время
Циклы, оканчивающиеся релизом
Каждый цикл состоит из четырёх фаз:
1.
2.
3.
4.
Анализ и планирование требований.
Проектирование.
Построение.
Внедрение.
Каждая фаза, в свою очередь, далее подразделяется на итерации.
Время
Анализ и
планирование
требований
итерация
№1
итерация
№2
Проектирование


Построение


Внедрение
итерация
№n-1
итерация
№n
Релизы
Результатом каждого цикла является новый выпуск ПС, готовый к
поставке.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
24
1.5 ПОНЯТИЕ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ
Каждое ПС должно выполнять определённые функции, т.е. делать то, что
задумано. Хорошее ПС должно обладать ещё целым рядом свойств,
позволяющим успешно его использовать в течение длительного периода,
т.е. обладать определённым качеством.
Качество ПС – это совокупность его черт и характеристик, которые
влияют на его способность удовлетворять заданным потребностям
пользователей.
Это не означает, что разные ПС должны обладать одной и той же
совокупностью таких свойств в их высшей возможной степени. Этому
препятствует тот факт, что повышение качества ПС по одному из таких
свойств часто может быть достигнуто лишь ценой изменения стоимости,
сроков завершения разработки и снижения качества этого ПС по другим
его свойствам. Качество ПС является удовлетворительным, когда оно
обладает указанными свойствами в такой степени, чтобы гарантировать
успешное его использование.
Совокупность свойств ПС, которая образует удовлетворительное для
пользователя качество ПС, зависит от условий и характера эксплуатации
этого ПС, т.е. от позиции, с которой должно рассматриваться качество
этого ПС. Поэтому при описании качества ПС должны быть прежде
всего фиксированы критерии отбора требуемых свойств ПС. В настоящее
время критериями качества ПС являются:
-
функциональная пригодность,
надёжность,
применимость,
эффективность,
сопровождаемость,
переносимость (мобильность).
Функциональная пригодность – способность ПС выполнять набор
функций,
удовлетворяющих заданным потребностям пользователей.
Набор указанных функций определяется во внешнем описании ПС.
Надёжность – это способность ПС с достаточно большой вероятностью
безотказно выполнять определённые функции при заданных условиях в
течение заданного периода времени.
Применимость – это характеристики ПС, которые позволяют
минимизировать усилия пользователя по подготовке исходных данных,
применению ПС и оценке полученных результатов, а также вызывать
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
положительные
пользователя.
эмоции
определённого
25
или
подразумеваемого
Эффективность – это отношение уровня услуг, предоставляемых ПС
пользователю при заданных условиях, к объёму используемых ресурсов.
Сопровождаемость – это характеристики ПС, которые позволяют
минимизировать усилия по внесению изменений для устранения в нём
ошибок и по его модификации в соответствии с изменяющимися
потребностями пользователей.
Мобильность – это способность ПС быть перенесённым из одной среды
(окружения) в другую, в частности, с одного компьютера на другой.
Функциональная пригодность и надёжность являются обязательными
критериями качества ПС, причём обеспечение надёжности красной нитью
проходит по всем этапам и процессам разработки ПС. Остальные
критерии используются в зависимости от потребностей пользователей в
соответствии с требованиями к ПС.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
26
1.6 УПРАВЛЕНИЕ КАЧЕСТВОМ РАЗРАБОТКИ
Международная организация стандартизации (МОС) разработала систему
стандартов ISO 9001, которые регламентируют вопросы управления
качеством. Данный стандарт соотносится с моделью CMM (модель роста
возможностей – Capability Maturity Model) следующим образом:
- стандарт ISO 9001 используется как структура;
- модель CMM определяет детали требований к процессу разработки для
включения их в документы по управлению качеством.
Россия, являясь членом МОС, приняла стандарт ISO 9001 как свой
национальный стандарт.
Цель стандарта – построение системы сквозного управления качеством
(TQM – Total Quality Management), которая должна обеспечивать
качество всех этапов разработки.
В стандарте определён минимальный набор требований к управлению
качеством, который условно можно разбить на три части:
1. Требования к менеджменту компании.
2. Требования к контролю продукции.
3. Требования к процессу разработки.
1.6.1 Управление компанией
Менеджмент компании должен осознавать значение системы качества и
должен иметь цель – построить эффективную систему качества.
Руководство компании составляет организационную структуру, которая
обеспечивает контроль качества. Определяются процедуры периодических
проверок и обсуждений эффективности системы управления качеством.
1.6.2 Управление продукцией
Управление продукцией включает контроль над версиями систем, за
приобретением готовых пакетов и программ, а также управлением
продукцией, которая не удовлетворяет в данный момент требованиям
качества. Многие положения стандарта не относятся к программному
обеспечению (например, упаковка и хранение).
1.6.3 Управление разработкой
Это важнейшая часть стандарта для программистских организаций. Она
включает в себя требования по построению и документированию всего
процесса разработки программного обеспечения – от заключения
контракта (договора) до распространения готового продукта (здесь, кстати,
управление разработкой переходит в управление продукцией,
упоминавшееся ранее).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
27
По классификации ISO 9001 разработка программного обеспечения
относится к “специальным процессам” – таким процессам, в которых
дефекты продукта этого процесса могут быть незаметны до тех пор, пока
им не начнут пользоваться.
Следует заметить, что стандарт ISO 9001 не регламентирует сам процесс
разработки, который может быть совершенно разным в различных
организациях. Он стандартизует критерии соответствия процесса
требованиям сквозного контроля качества. Необходимое условие –
наличие документации, регламентирующей конкретный процесс в
конкретной организации.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
28
1.7 ОБЕСПЕЧЕНИЕ НАДЁЖНОСТИ
Обеспечение надёжности – основной мотив разработки программных
средств, который задаёт специфическую окраску всем технологическим
процессам разработки ПС. В технике известны четыре подхода к
обеспечению надёжности:
-
предупреждение ошибок;
самообнаружение ошибок;
самоисправление ошибок;
обеспечение устойчивости к ошибкам.
Цель подхода предупреждения ошибок – не допустить ошибок в готовых
ПС. Проведённое рассмотрение природы ошибок при разработке ПС
позволяет для достижения этой цели сконцентрировать внимание на
следующих вопросах:
-
борьба со сложностью,
обеспечение точности перевода,
преодоление барьера между пользователем и разработчиком,
обеспечение контроля принимаемых решений.
Предупреждение ошибок связано с организацией процессов разработки
ПС, т.е. с технологией программирования.
И хотя гарантировать
отсутствие ошибок в ПС невозможно, можно достигнуть приемлемого
уровня надёжности ПС.
Остальные три подхода связаны с организацией самих программ. Они
учитывают возможность ошибки в программах.
Самообнаружение ошибки в программе означает, что программа
содержит средства обнаружения отказа в процессе её выполнения.
Самоисправление ошибки в программе означает не только обнаружение
отказа в процессе её выполнения, но и исправление последствий этого
отказа, для чего в программе должны иметься соответствующие средства.
Обеспечение устойчивости программы к ошибкам означает, что в
программе содержатся средства, позволяющие локализовать область
влияния отказа программы, либо уменьшить его неприятные последствия,
а иногда предотвратить катастрофические последствия отказа.
Однако
эти подходы используются весьма редко (может быть,
относительно чаще используется обеспечение устойчивости к ошибкам).
Связано это, во-первых, с тем, что многие простые методы, используемые
в технике в рамках этих подходов, неприменимы в программировании,
например, дублирование отдельных блоков и устройств (выполнение двух
копий одной и той же программы всегда будет приводить к одинаковому
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
29
эффекту – правильному или неправильному). А, во-вторых, добавление в
программу дополнительных средств приводит к её усложнению (иногда –
значительному), что в какой-то мере мешает методам предупреждения
ошибок.
1.7.1 Методы борьбы со сложностью
Известны два общих метода борьбы со сложностью систем:
1. Обеспечение независимости компонент системы.
2. Использование в системах иерархических структур.
Обеспечение независимости компонент означает разбиение системы на
такие части, между которыми должно остаться по возможности меньше
связей.
Одним из воплощений этого метода является модульное
программирование.
Использование иерархических структур позволяет локализовать связи
между компонентами,
допуская их лишь между компонентами,
принадлежащими смежным уровням иерархии. Этот метод, по существу,
означает разбиение большой системы на подсистемы, образующих малую
систему.
Здесь существенно используется способность человека к
абстрагированию.
1.7.2 Обеспечение точности перевода
Обеспечение точности перевода направлено на достижение однозначности
интерпретации документов различными
разработчиками, а также
пользователями ПС.
Это требует придерживаться при переводе
определённой дисциплины. Майерс предлагает использовать общую
дисциплину решения задач, рассматривая перевод как решение задачи. В
соответствии с этим весь процесс перевода можно разбить на следующие
этапы:
1.
2.
3.
4.
Понять задачу.
Составить план (включая цели и методы решения).
Выполнить план (проверяя правильность каждого шага).
Проанализировать полученное решение.
1.7.3 Преодоление барьера между пользователем и разработчиком
Для того, чтобы ПС выполняло то, что пользователю разумно ожидать от
него, необходимо правильно понять, во-первых, чего хочет пользователь,
и, во-вторых, его уровень подготовки и окружающую его обстановку.
Поэтому следует привлекать пользователя в процессы принятия решений
при разработке ПС, – тщательно освоить особенности его работы (лучше
всего – побывать в его “шкуре”).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
30
1.7.4 Контроль принимаемых решений
Обязательным шагом в каждом процессе (этапе) разработки ПС должна
быть проверка правильности принятых решений. Это позволит
обнаруживать и исправлять ошибки на самой ранней стадии после её
возникновения, что существенно снижает стоимость её исправления и
повышает вероятность правильного её устранения.
С учётом специфики разработки ПС необходимо применять везде, где это
возможно,
- смежный контроль,
- сочетание как статических, так и динамических методов контроля.
Смежный контроль означает проверку полученного документа лицами,
не участвующими в его разработке:
- во-первых, со стороны автора исходного документа (для
контролируемого процесса),
- во-вторых, лицами, которые будут использовать полученный документ
в качестве исходного в последующих технологических процессах.
Такой контроль позволяет обеспечивать
полученного документа.
однозначность интерпретации
Сочетание статических и динамических методов контроля означает, что
нужно не только контролировать документ как таковой, но и проверять,
какой процесс обработки данных он описывает. Это отражает одну из
специфических особенностей ПС (статическая форма, динамическое
содержание).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
31
2 ВВЕДЕНИЕ В УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ
Нередко этапы создания ПС (анализ, проектирование и реализация)
выполняются разными людьми. Неизбежно возникает проблема
понимания между ними, одинаковой интерпретации результатов работы.
Общение в коллективе разработчиков можно обеспечить и с помощью
текстовой информации, но люди – зрительно-ориентированные существа.
Они легче понимают сложную информацию, если она представлена
визуально, нежели описана в тексте.
Важный вопрос визуального моделирования – выбор графической нотации
для описания различных аспектов системы.
Нотация представляет собой совокупность графических объектов, которые
используются в моделях. Она является синтаксисом языка моделирования.
В
качестве
нотации
унифицированный
процесс
использует
унифицированный язык моделирования UML – Unified Modeling
Language.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
32
2.1 ОПРЕДЕЛЕНИЕ, НАЗНАЧЕНИЕ И СФЕРА ПРИМЕНЕНИЯ UML
В ноябре 1997 года консорциум по технологии манипулирования
объектами (Object Management Group – OMG) объявил
UML
стандартом для создания моделей программного обеспечения.
В
настоящее время стандартом является версия UML 1.3.
UML – язык для визуализации, специфицирования, конструирования и
документирования компонентов программных средств.
UML – язык, а не метод. UML предоставляет возможность создавать и
разбираться в правильно построенных моделях, но не говорит какие
модели и когда нужно создавать.
UML – язык визуализации (зрительного восприятия). Для многих
программистов время между обдумыванием и написанием кода равно
нулю. Код получается прекрасный, но программист при этом моделирует в
уме. В связи с этим возникает несколько проблем, которые можно решить,
используя UML:
1. Проблема чтения кода. Существуют некоторые вещи в ПС, которые
невозможно понять по тексту программного кода (даже хорошо
прокомментированного). Например, невозможно напрямую постичь
путём непосредственного просмотра кодов возможную миграцию
объектов Web-системы. UML является графическим языком и,
следовательно, решает проблему.
2. Проблема потери информации. Если разработчик уничтожил часть кода
и никогда не записывал в каком-либо виде модель, а держал её только в
голове, тогда эта информация будет утрачена навсегда. Написание
моделей на UML обеспечивает восстановление информации по модели.
3. Проблема интерпретации модели. Как правило, в проектной группе
вырабатывается некоторый внутренний язык совершенно не понятный
извне. UML обладает корректно-определённой семантикой и, поэтому,
разные разработчики будут одинаково трактовать модель.
UML – язык специфицирования. UML позволяет определить все важные
решения по анализу, проектированию и реализации, которые принимаются
в процессе создания и внедрения ПС.
UML – язык конструирования. Созданные с его помощью модели могут
быть переведены на различные языки программирования. UML-модель
можно отобразить на такие языки, как C++, Java, Visual Basic и даже на
таблицы реляционной базы данных. Возможно как прямое (forward
engineering), так и обратное (reverse engineering) отображение.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
33
UML – язык документирования. При создании ПС создаётся много
вторичных по отношению к исполняемому коду продуктов: требования к
системе, архитектура системы, проект, исходный код, проектные планы,
тесты,
прототипы,
версии.
UML
предоставляет
возможности
документирования принятых решений.
UML предназначен, прежде всего, для разработки программных средств.
Его использование наиболее эффективно в следующих областях:
-
информационные системы масштабов предприятия;
транспорт, в том числе железнодорожный;
банковские и финансовые услуги;
распределённые Web-системы;
оборонная промышленность, авиация и космонавтика;
розничная торговля;
медицинская электроника;
телекоммуникации;
наука.
Сфера применения UML не ограничивается моделированием ПС.
Выразительность этого языка позволяет проводить бизнес-анализ
деятельности предприятия; моделировать документооборот в юридических
системах;
моделировать структуру и функционирование системы
обслуживания пациентов в больницах; осуществлять проектирование
аппаратных средств.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
34
2.2 КОНСТРУКТИВНЫЕ БЛОКИ UML
В UML задействованы три вида блоков:
1. Структурные сущности, понятия (things) – абстракции, являющиеся
основой модели.
2. Отношения (relationships) – обеспечивают связи между различными
сущностями.
3. Диаграммы (diagrams) – группируют представляющие интерес
совокупности (наборы) сущностей.
2.2.1 Структурные сущности
Структурные сущности (structural
статические части модели.
things)
–
представляют
собой
К структурным относятся следующие разновидности сущностей: актёр
(действующее лицо), вариант использования (системный сервис), класс,
компонент.
Актёр – actor
Актёр – это любая сущность, которая взаимодействует с системой извне.
Клиент
Актёры определяют всё то, что находится вне системы, и делятся на
четыре основных типа:
1. Физические личности. Они наиболее типичны, и имеются практически
в каждой системе. Например, в банковской системе к актёрам относятся
клиенты и обслуживающий персонал.
2. Другая система. Когда другая система становится действующим лицом,
предполагается, что она не будет меняться вообще. Актёры находятся
вне сферы действия того, что разрабатывается, и, следовательно, не
подлежит контролю со стороны ПС. Например, у банка имеется
кредитная система, которая используется для работы с информацией о
кредитных счетах клиентов. Банковская система должна иметь
возможность взаимодействовать с кредитной системой, в таком случае
последняя становится актёром. Если будет разрабатываться и кредитная
система в рамках того же самого проекта, то она не может быть
показана как актёр.
3. Время. Так как время не подлежит контролю, оно является актёром.
Время становится актёром, если от него зависит запуск каких-либо
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
35
процессов в системе. Например, банковская программная система
может каждую полночь выполнять служебные процедуры по
согласованию своей работы.
4. Электромеханические устройства. ПС может получать сигналы от этих
устройств для последующей обработки внутри ПС, а также может само
управлять работой электромеханических устройств.
Вариант использования – use case
Вариант использования (прецедент) – это документ с текстовым
описанием последовательности действий, которые должны быть
выполнены системой для актёра по его запросу.
Снять деньги со счёта
Под вариантом использования понимают функцию системы, которая
производит конкретный результат, значимый (полезный) для какогонибудь конкретного пользователя (участника-актёра).
Последовательности действий называют также потоками событий.
Для одного варианта использования может существовать несколько
потоков событий.
Например, для снятия денег со счёта может существовать такой поток:
1.
2.
3.
4.
5.
Клиент банка вставляет карту в прорезь банкомата.
Отвечает на вопрос о коде.
Система проверяет соответствие карты и кода.
Система проверяет наличие соответствующей суммы на счету клиента.
Клиент получает деньги.
Для этой же функции может существовать альтернатива для строки 3:
3 А. Введённый код не соответствует карте.
3.1.
3.2.
Система сообщает клиенту о неверном коде.
Система предлагает ввести другой код или завершить сеанс.
Для этой же функции может существовать альтернатива для строки 4:
4 А. Денег не достаточно для снятия такой суммы.
4.1.
4.2.
Система сообщает клиенту о невозможности снятия денег со счёта.
Система завершает сеанс работы с клиентом.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
36
Нормальная последовательность действий (без отклонений и без ошибок),
которая должна быть выполнена программной системой для достижения
конкретного результата, называется основным потоком событий.
Остальные потоки событий являются альтернативными.
Альтернативные потоки событий отражают отклонения от основного
потока событий, а также потоки ошибок.
Предполагается, что никакой поток событий не может быть прерван и
должен быть обязательно выполнен от начала до конца. В результате
участник-актёр или получает от системы результат выполнения функции
(по основному потоку событий), или система сообщает ему о
невозможности выполнения данной функции. Исключением в последнем
случае является альтернативный поток событий, который путём других
действий (отличных от действий основного потока событий) приведёт к
желаемому результату.
С основным потоком событий тесно связаны два понятия: предусловие и
постусловие.
Предусловие варианта использования – это другой прецедент, который
должен быть выполнен прежде, чем вариант использования начнёт свою
работу.
Не у всех вариантов использования бывают предусловия.
Постусловие – это прецедент, который должен быть выполнен после
завершения текущего варианта использования.
Не у всех вариантов использования бывают постусловия.
Класс – class
Класс – это описание набора объектов с общими атрибутами, операциями
и семантикой (смыслом).
Например, объекты “автомобиль” и “лошадь”, у которых определены
одинаковые атрибуты цена, наименование и скорость передвижения,
одинаковая обязанность перевозить грузы, могут относиться к одному
классу, если рассматриваются в задаче как транспортное средство, либо к
разным классам, что более естественно.
Объединение объектов в классы вводит в процесс разработки ПС
абстракцию. Цель абстракции – ограничить универсальность, всеобщность
понятия (вещи). При построении моделей надо искать не абсолютную
истину, а адекватность поставленной цели рассмотрения.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
37
Абстракция – это наиболее существенные характеристики объекта,
которые отличают его от всех других видов объектов и чётко определяют
особенности данного объекта с точки зрения дальнейшего анализа.
Абстракция концентрирует внимание на внешних свойствах объекта и
позволяет отделить существенные особенности поведения от деталей их
реализации. Такое разделение поведения от реализации называется
барьером абстракции, который основывается на двух принципах:
1. Принцип наименьшей выразительности, по которому абстракция
должна охватывать лишь самую суть объекта, не больше (но и не
меньше).
2. Принцип минимизации связей, когда интерфейс (спецификация)
объекта содержит только существенные аспекты поведения.
Следует заметить, что на разных этапах создания ПС разработчики имеют
дело с разными классами:
- на этапе анализа ПС классы – это концептуальные абстракции,
являющиеся частью предметной области;
- на этапе проектирования – логические (программные) абстракции;
- на этапе реализации – это классы выбранного для реализации
логических абстракций языка программирования.
Графически класс изображается в виде разделённого на три части
прямоугольника, в которых записаны его имя, атрибуты и операции:
Имя - Name
Счёт
№ счёта
Идентификационный номер
Сумма
Открыть()
Снять деньги()
Перевести деньги()
Проверить()
Атрибуты - Attributes
Операции - Operations
CAccount
AccountNumber
PIN
Balance
Open()
DeductFunds()
WithdrawFunds()
VerifyFunds()
Примеры классов и объектов:
Класс
Студент
Кафедра
Вуз
Деятельность
Объекты
Аксёнова Юлия, Сысоев Андрей
Информационные и вычислительные системы,
Автоматика и связь
ПГУПС, СПбГУ
обучение, НИР, производственная практика,
дипломное проектирование
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
38
Одна из целей разработки модели программной системы заключается в
том, что необходимо описать классы/объекты, составляющие в
совокупности проектируемую систему.
Основными характеристиками класса/объекта являются:
1. Уникальное имя. Позволяет отличить объекты друг от друга.
2. Атрибут – именованная характеристика или свойство класса. Каждый
атрибут имеет своё значение для каждого объекта. Среди атрибутов
следует различать условно постоянные атрибуты (статические) и
условно переменные атрибуты (динамические). Могут существовать
также производные атрибуты (вычисляемые), значения которых могут
быть определены при помощи значений постоянных и переменных
атрибутов объекта. Как правило, они не указываются в описании
объекта, потому что могут быть вычислены.
3. Состояние объекта – ситуация в ходе жизни объекта, в течение которой
он удовлетворяет некоторому условию, выполняет некоторую
деятельность или ожидает некоторого события. Выражается состояние
всеми текущими значениями объекта. При изменении значений
атрибутов меняется состояние объекта. Например,
имя: Петя Синичкин; средний балл: 2  состояние: двоечник
(условие – 2, деятельность – ничегонеделание, ожидает – чуда);
имя: Петя Синичкин; средний балл: 5  состояние: отличник
(условие – 5, деятельность – активно изучает дисциплины курса,
ожидает – получить профессию).
4. Поведение – это то, как объект действует и реагирует, то есть, как он
меняет своё состояние. Поведение выражается в терминах состояния
объекта и в терминах передачи сообщений. Состояние и поведение
объекта оба взаимосвязаны: поведение может изменять состояние.
Понятие “сообщение” совпадает с понятием “операция над объектом”.
5. Операция – действие, которое должен выполнить объект для
реализации своего поведения, или сервис, который может быть
востребован одним объектом у другого. Объекты в системе, как и в
реальном мире, не существуют изолированно, а подвергаются
воздействию или сами воздействуют на другие объекты. У каждой
операции есть свой объект-получатель, то есть объект, для которого
данная операция применяется. Операция может иметь дополнительные
аргументы, которые параметризуют операцию. Некоторые операции
могут приобретать разные формы в различных классах, такие операции
называются полиморфными.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
39
Стереотипные (универсальные) операции для всех объектов системы:
Создать и инициировать (create and initialize) данный объект.
Удалить (delete) данный объект.
Получить (get…) значение атрибута.
Установить (set…) значение атрибута.
Добавить связанный объект (add…) – добавить связь с другим
объектом.
- Исключить связанный объект (remove…) – исключить связь с
другим объектом.
-
Наиболее распространённые операции:
- Модификатор – операция, которая меняет состояние объекта.
- Запрос (селектор) – операция, которая считывает состояние объекта,
но не меняет состояние.
- Итератор – операция, которая позволяет организовать доступ ко всем
частям объекта-контейнера для последующего их использования в
строго определённой последовательности (например, просмотр
очереди).
- Преобразование – операция, производящая объект другого типа.
6. Метод – конкретная реализация операции для объектов данного класса.
Метод зависит только от объекта/класса получателя.
В начале моделирования ПС, как правило, определяют операции.
Впоследствии операции реализуются методами класса на выбранном языке
программирования.
Прежде, чем перейти к рассмотрению примера, несколько советов по
выбору имен:
Имя класса – существительное с префиксом 'C' (СTeacher, СStudent);
Имя объекта – существительное (Teacher, Student);
Операция-модификатор – активный глагол (select, move);
Операция-запрос – добавляется форма глагола 'to be' (IsSelected) или
выбирается подходящее по смыслу словосочетание (VerifyFunds).
Пример 1: Разработать класс для представления автомобилей для игры
“Ралли”.
Что можно выбрать в качестве атрибутов этого класса, с помощью чего
можно описать состояние объектов этого класса?
Атрибуты: марка автомобиля; текущее состояние спидометра; текущее
показание счётчика пройденного расстояния.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
40
Варианты поведения: ускорение (нажать педаль акселератора); замедление
(нажать педаль тормоза); узнать скорость.
CCar
Brand : String
Spead : Double
Mileage : Double
Accelerate()
Brake()
FindSpeed(time : Integer) : Double
TurnRight()
TurnLeft()
Пример 2: Класс кнопок
CButton
ButtonON : Boolean
ButtonOFF : Boolean
PushButton()
VetoPushButton()
IsButtonON() : Boolean
Компонент – component
Компонент – это физический элемент реализации с чётко определённым
интерфейсом, предназначенный для использования в качестве
заменяемой части системы.
Компонент изображается в виде прямоугольника с вкладками:
ATM
В отличие от классов, являющихся логическими абстракциями,
компоненты представляют собой физическую реализацию логических
абстракций системы. Любой компонент ПС может быть заменён другим
компонентом, который поддерживает точно такой же интерфейс.
Тщательно спроектированные компоненты не зависят от других
компонентов, а только от интерфейсов, которые те поддерживают.
К наиболее распространённым стереотипам компонентов относятся:
1. Исполнимый (executable) компонент – определяет компонент, который
может исполняться компьютером.
2. Библиотека (library) – определяет статическую или динамическую
объектную библиотеку.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
41
Компоненты имеют следующие особенности:
- Компоненты включают отношения тех классов системы, которые они
реализуют.
- Способ реализации компонентов зависит от того, как (с учётом
используемого языка программирования) они будут структурированы и
разбиты на файлы с исходными текстами программ.
2.2.2 Отношения
Отношением (Relationship) называется связь между отдельными
элементами модели программного средства (актёрами и прецедентами,
классами, компонентами).
Отношения между классами
Классы довольно редко существуют автономно. Как правило, они разными
способами взаимодействуют между собой. Это значит, – моделируя ПС,
необходимо не только идентифицировать сущности, но и описать, как
сущности соотносятся друг с другом.
Существует четыре типа отношений, которые могут быть установлены
между классами:
1. Ассоциации (Association).
2. Обобщения (Generalization).
Ассоциация – Association
3. Агрегации (Aggregation).
4. Зависимости (Dependency).
Ассоциация – это отношение между классами, отражающая некоторое
значимое и полезное отношение между ними.
Ассоциация показывает, что объекты одного класса неким образом
связаны с объектами другого класса.
Изображается ассоциация в виде обыкновенной линии:
CBank
serves
CPerson
Ассоциации может быть присвоено имя, описывающее природу
отношения. В качестве имени ассоциации, как правило, указывается
глагол.
При генерации кода Rational Rose помещают в классы соответствующие
дополнительные атрибуты. Например, для представленной ассоциации
serves класс CBank получит атрибут CPerson *serves, чтобы знать, кого
он обслуживает, а класс CPerson – атрибут CBank *serves, чтобы
определить, в каком банке у него открыт счёт.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
42
Использование имени необязательно и рекомендуется тогда, когда между
двумя классами существует несколько ассоциаций.
FliesIn
CFlight
CAirport
FliesFrom
Если классы связаны ассоциацией, то это значит, что объекты классов
могут передавать друг другу сообщения.
Ассоциации, связывающие два класса, называются бинарными.
Бинарные
ассоциации
могут
быть
двунаправленными
или
однонаправленными. Вполне допустимы случаи, когда оба конца
ассоциации относятся к одному и тому же классу. Это означает, что с
объектом некоторого класса разрешается связать другие объекты из того
же класса. Такого рода отношения называются рефлексивными.
rules
CEmployee
Можно создавать n-арные ассоциации, которые связывают сразу несколько
классов, однако это редко бывает необходимым.
Поскольку ассоциации могут иметь двунаправленный характер, для их
уточнения вводится понятие роли.
Роль – это один конец ассоциации.
У бинарной ассоциации две роли, каждая из которых может иметь имя
роли.
Имя роли – это уникальное название, которое идентифицирует один конец
ассоциации.
Роли обеспечивают путь просмотра ассоциации как пересечение одного
объекта на одном конце ассоциации с набором связанных с ним объектов
на другом конце ассоциации. Графически роли изображаются следующим
образом:
CBank
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
+Client
CPerson
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
43
В зависимости от нужд проектируемой системы можно использовать
имена ролей либо на одном из концов ассоциации, либо на обоих, так как
имя роли обеспечивает только одну сторону ассоциации. Использование
имени роли проще и менее путано, чем имя ассоциации. Имена ролей
обязательны для обозначения соединения между двумя объектами одного
и того же класса.
+Chief
CEmployee
+Worker
Существует два полезных правила:
1. Все имена ролей, относящиеся к классу, должны быть уникальны.
2. Никакое имя роли не должно совпадать с названием атрибута исходного
класса.
Важным понятием для ассоциации является её мощность (Multiplicity), в
литературе встречается также термин кратность.
Мощность ассоциации определяет, сколько объектов одного класса может
относиться к одному объекту связанного класса.
Мощность ограничивает число связанных объектов. Различают три случая
мощности ассоциации:
1. Один ко многим. Это значит, что один объект может иметь много
связанных с ним объектов другого класса. Например, в классе CBank
один объект банк обслуживает в классе CPerson много клиентов.
+Client
CBank
1
CPerson
1..*
2. Один к одному. Это значит, что с каждой стороны ассоциации имеется
ровно по одному объекту. Это так называемая узкая ассоциация,
которая встречается не часто. Например, если клиент банка может
иметь только один кредит, то между объектами классов CPerson и
CMortgage будет установлена ассоциация “один к одному”.
+Client
CBank
1
CPerson
1..*
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
CMortage
1
1
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
44
3. Многие ко многим. Этот случай самый запутанный из всех трёх. Один
банк (1) может обслуживать много клиентов (M). В свою очередь
каждый клиент (1) может иметь счета во многих (N) банках.
+Client
CBank
1..*
CPerson
1..*
Обобщение – Generalization
Обобщение – это такое отношение между классами, когда один класс
повторяет свойства и поведение другого класса.
Обобщение выражает отношение общего и частного, иногда его называют
отношением “является” (is-a). Общая часть атрибутов и операций
сосредотачивается в одном классе и наследуется специализированными
классами.
Служащие
ФИО
Номер паспорта
Принять()
Уволить()
Водители
Секретари
Номер водительских прав
Скорость печатания
Назначить маршрут()
Инженеры
Учёная степень
Квалификация
Включить в проект()
Класс, от которого наследуются свойства и поведение, называется
суперклассом. Специализированные классы называются подклассами.
Нотация обобщения – треугольник, вершина которого направлена к
суперклассу. Символ треугольника ставится даже в том случае, когда у
суперкласса всего-навсего один подкласс.
Выделение суперкласса и подклассов позволяет с одной стороны
обеспечить использование общих свойств и поведения, а с другой стороны
атрибуты
и
операции
суперкласса
могут
быть
дополнены,
модифицированы или даже скрыты в его подклассах.
Обобщение не является связью между разными объектами, для него
не указываются роли и мощность.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
45
Для выявления обобщений можно разворачивать структуру наследования
сверху вниз или снизу вверх. В первом случае необходимо искать классы,
у которых имеется несколько разновидностей (например, для класса
служащий можно выделить подклассы: служащий с почасовой оплатой и
служащий, получающий оклад). При построении структуры снизу вверх
следует искать классы, имеющие между собой что-то общее.
Не существует строгого ограничения в числе уровней наследования,
однако создаваемая структура должна быть управляемой. Иерархия со
слишком большим количеством уровней может стать плохо управляемой,
поскольку каждое изменение верхнего уровня немедленно отразиться во
всех производных классах. Как правило, ограничиваются тремя уровнями
иерархии.
Отношение обобщения в языке программирования C++ реализуется с
помощью механизма наследования. Базовый класс можно рассматривать
как более высокий уровень абстракции по сравнению с классом-потомком.
Агрегация – Aggregation
Люди вводят абстракции в двух измерениях:
1. Вид – is-a.
2. Часть – part of или has.
Первая абстракция – это обобщение. Например, тепловоз является видом
локомотива. Известно, что тепловоз имеет части: дизель, тяговый
генератор, секции, тележки.
Дизели
Тепловозы
Секции
Тяговые
генераторы
Тележки
Агрегация является усовершенствованной формой
представляет связь между целым и его частями.
ассоциации
и
В UML агрегация отображается с помощью ромбовидного символа,
помещённого на стороне составного объекта.
Один класс может участвовать в нескольких отношениях агрегации с
другими классами (как в приведённом примере).
Агрегация позволяет отразить сложную структуру составного объекта,
состоящего из других объектов.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Тепловозы
46
Топливные
насосы
Дизели
Поршни
На этом рисунке второй класс Дизели – часть первого класса Тепловозы,
третий класс Топливные насосы – часть второго класса Дизели. Из чего
следует, что третий класс Топливные насосы – часть первого класса
Тепловозы.
Отношение агрегации обладает свойством транзитивности.
Агрегация асимметрична: если объект второго класса является частью
первого, то объект первого – это не часть второго.
Примеры агрегации:
факультет – кафедры
кафедра – группы
рецепт – части рецепта
заказ – строки заказа
документ – абзацы – предложения
специальность – специализации
Агрегация, так же как и ассоциация, может быть рефлексивной.
Рефлексивная агрегация предполагает, что один объект класса состоит из
нескольких других объектов того же класса.
Кушанье
Например, комбинируя ингредиенты для приготовления пищи, можно
получить ингредиенты для других блюд. Комбинация из уксуса, соли и
сахара даёт ингредиент маринад. Комбинация маринада и свежих огурцов
даёт ингредиент маринованные огурцы. И т.п.
Мощность со стороны составного объекта обычно единица. Считается, что
составной объект является владельцем своих частей, и что эти части
можно расположить в иерархии древовидной структуры. Такая форма
агрегации при построении моделей стандартна.
Существует несколько рекомендаций для выявления агрегации:
1. В физическом или логическом смысле очевидно наличие отношения
“целое-часть”.
2. Время жизни частей ограничено временем жизни целого, то есть между
целым и его частями существует зависимость создания/удаления.
Например, отношение между классами Факультет и Кафедры. При
удалении всех объектов класса Кафедры класс Факультет теряет
смысл. Следовательно, между классами отношение агрегации. Если
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
47
рассматривать отношение между классами Банк и Клиент, то можно
увидеть, что класс Банк всё ещё имеет смысл даже тогда, когда объекты
класса Клиент удалены. Значит, между классами простая ассоциация.
3. Некоторые свойства составного объекта распространяются и на его
части. Например, место их расположения (Группа – Студенты).
4. Операции, применяемые к составному объекту, одновременно
осуществляются и над его частями. Например, запись, перемещение и
разрушение.
Самый полезный критерий: наличие зависимости создания/удаления
между целым и его частями. Если удаляется целое, то необходимо удалить
все его части. Если удаляются части, то целое не может существовать.
В языке программирования C++ агрегация реализуется при помощи
механизма включения, который ещё называют композицией. Класс
составного объекта включает в себя указатели на объекты других классов в
качестве атрибутов.
При генерации кода для агрегации автоматически создаются
поддерживающие её дополнительные атрибуты. Так класс Тепловозы
получит следующие атрибуты: Дизели *theДизели; Тележки
*theТележки и т.д. Кроме того, в заголовочный файл класса Тепловозы
будут включены следующие строки: class Дизели; class Тележки и т.д.
Зависимость – Dependency
Зависимость – это отношение использования между двумя элементами
модели. Изменение в одном элементе (независимом) может повлиять на
другой (зависимый) элемент.
Отношение зависимости между классами показывает, что один класс
ссылается на другой или объекты одного класса знают о существовании
объектов другого класса.
Арендатор
Дом
В UML отношение зависимости между классами изображается пунктирной
стрелкой, направленной в сторону независимого класса. Например, класс
Арендатор зависит от класса Дом.
Для реализации отношения зависимости существует три возможности:
1. Независимый класс (Дом) можно сделать глобальным, и тогда
зависимый класс (Арендатор) будет знать о его существовании.
2. Объект независимого класса (Дом) можно объявить как локальную
переменную внутри операции зависимого класса (Арендатор).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
48
3. Объект независимого класса (Дом) можно передавать операциям
зависимого класса (Арендатор) в качестве параметра.
Арендатор
Дом
Купить(theДом) : Дом
При наличии зависимости необходимо следовать одному из этих трёх
подходов. Третий подход наиболее предпочтителен.
Главное отличие зависимостей от ассоциаций состоит в том, что
зависимости всегда однонаправленные, а ассоциации могут быть
двунаправленными.
При генерации кода на языке C++ для отношения зависимости между
классами не добавляются новые атрибуты, но создаются специфические
для языка операторы, необходимые для поддержки зависимости.
Например, в файл реализации Арендатор.cpp будет включена строка
#include "Дом.h", а в заголовочный файл Арендатор.h – class Дом.
Следует заметить, что между подсистемами и компонентами системы
могут существовать только отношения зависимости и никакие другие.
Квалификатор ассоциации – Qualifier
Это значение, выбирающее уникальный объект из группы объектов,
которые связаны с ним в ассоциации.
Квалифицированные ассоциации аналогичны понятию “ассоциативные
массивы (associative arrays)” в языках программирования.
Квалификатор позволяет снизить мощность ассоциаций “один-ко-многим”,
“многие-ко-многим”.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
49
При помощи квалификатора проектируют индексы. Если на одном конце
ассоциации находится поисковая структура (например, хэш-таблица или
B-дерево), то следует объявить как квалификатор индекс, по которому
производится поиск. Обычно кратность на исходном конце ассоциации
будет “много”, а на целевом – 0…1.
Класс-ассоциация – Association Class
Это элемент модели, который сочетает в себе свойства как ассоциации,
так и класса.
Класс-ассоциацию можно считать или ассоциацией со свойствами класса,
или классом со свойствами ассоциации.
Класс-ассоциация позволяет дополнительно определять для ассоциаций
атрибуты и операции.
В случае мощности отношения “многие-ко-многим” становится
невозможным однозначно установить связи между объектами на концах
такого отношения.
В этом случае рекомендуется использовать класс-ассоциацию.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
50
Отношения между актёрами и вариантами использования
Отношение между актёром и вариантом использования называют
коммуникативной ассоциацией (communicate association). Отношение
может быть либо двухсторонним (от актёра к функции и от функции к
актёру), либо односторонним (от актёра к функции или от функции к
актёру). Направление показывает, кто является инициатором (актёр или
функция).
Клиент
Снять деньги со счёта
Следует заметить, что не имеет смысла связывать друг с другом актёров,
поскольку они действуют вне системы.
Между прецедентами существует два типа отношений зависимости:
1. Отношение включения (include relationship).
2. Отношение дополнения (extend relationship).
Отношение включения между двумя прецедентами создаётся тогда, когда
один прецедент использует другой. Различные прецеденты могут иметь
одинаково функционирующие фрагменты. Такие фрагменты обычно
помещают в отдельный прецедент, чтобы не повторять несколько раз.
Например, действия по аутентификации пользователя или проверке
определённого состояния объекта могут использоваться многими
прецедентами системы. Отношение включения направлено от базового
прецедента к общему прецеденту.
Регистратор
Регистрирует
студентов
Проверяет
успеваемость
Отношение дополнения используется для отражения:
- дополнительных режимов;
- режимов, которые запускаются только при определённых условиях
(например, сигнал тревоги);
- альтернативных потоков, которые запускаются по выбору актёров.
Отношение дополнения направлено от дополнительного прецедента к
базовому прецеденту.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
51
Добавить дисциплину
Регистратор Формирует каталог
дисциплин
Удалить дисциплину
Отношения между компонентами
Между компонентами существуют только отношения зависимости.
Если компонента зависит от второй, а вторая от первой, между ними будет
существовать два отношения зависимости.
<<subsystem>>
Ректорат
<<subsystem>>
<<subsystem>>
Кафедра
Факультет
2.2.3 Диаграммы
Диаграмма – это графическое представление набора элементов,
изображаемое чаще всего в виде связанного графа с вершинами
(сущностями) и рёбрами (отношениями).
Основные типы диаграмм UML:
-
диаграмма Вариантов Использования (Use case diagram);
диаграмма Последовательности (Sequence diagram);
диаграмма Классов (Class diagram);
диаграмма Состояний (Statechart diagram);
диаграмма Компонентов (Component diagram);
диаграмма Размещения (Deployment diagram).
Различные типы диаграмм будут рассматриваться на примере
программной системы банковского автомата (Automated Teller Machine –
ATM).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
52
Диаграмма Вариантов Использования – Use case diagram
Диаграмма вариантов использования отображает взаимодействие между
действующими лицами, которые получают или передают информацию в
данную систему, и системными функциями.
Из Use case diagram можно получить довольно много информации о
системе, так как она описывает общую функциональность системы.
Пользователи,
менеджеры
проектов,
аналитики,
разработчики,
специалисты по контролю качества и все, кого интересует система в
целом, могут понять, что система должна делать.
В представлении Use Case View данная диаграмма отражает требования к
системе с точки зрения пользователя. К основным элементам диаграммы
относятся:
- бизнес-актёр (business actor) – пользователь системы,
- бизнес-функция (business use case) – подлежащая автоматизации
производственная функция пользователя,
- отношения (association, dependency) – наборы однотипных связей
между пользователями и функциями.
В представлении Logical View диаграмма отражает требования к системе с
точки зрения разработчика и детализирует диаграмму из представления
Use Case View. К основным элементам диаграммы относятся:
- актёр (actor) – абстрактный пользователь системы;
- функция (use case) – законченная последовательность действий,
которая должна быть выполнена системой для актёра по его запросу;
- отношения association и dependency.
Функция (business use case, use case) – это документ, который
описывает последовательность связанных с актёром событий (а не
отдельное событие). Данная последовательность использует программную
систему для совершения требуемого процесса.
Каждый use case определяет относительно большой завершённый
процесс, состоящий из многих шагов, и реализуется как неделимая
транзакция, которая не может быть прервана никаким другим use case.
После того, как система выполнит функцию (сервис), она должна
вернуться в исходное состояние, в котором готова к выполнению новых
запросов.
Рекомендации по идентификации функций
Системные функции можно классифицировать по следующим видам:
1. Регистрация важной информации. Например, учёт и/или регистрация.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
53
2. Ведение дела. Например, контроль и оценка состояния чего-либо на
основе значений его атрибутов, поддержка необходимых в процессе
трудовой деятельности действий, различные вычисления, сортировка и
поиск.
3. Анализ результатов бизнеса. Например, подсчёт экономических
показателей деятельности, оценка производительности труда.
4. Взаимодействие с другой системой. Например, приём и отправка
сообщений системе более высокого уровня.
вариантов
использования для АТМ
Use case diagram Диаграмма
для системы
ATM
Перевести деньги
Банковский
служащий
Положить деньги на счёт
Изменить идентификационный
номер
Клиент
Снять деньги со счёта
Произвести оплату
Кредитная
система
Показать баланс
В примере клиент банка инициирует различные функции: Снять деньги
со счёта; Перевести деньги; Положить деньги на счёт; Показать
баланс; Произвести оплату; Изменить идентификационный
номер. Банковский служащий может инициировать функцию Изменить
идентификационный номер. От функции Произвести оплату стрелка
идёт к кредитной системе. Стрелка, направленная от прецедента к актёру,
показывает, что прецедент предоставляет актёру некоторую информацию.
Потоки событий
К каждому варианту использования должен быть прикреплён текстовый
файл с описанием потоков событий: основного и альтернативных.
Основной поток событий содержит последовательность действий, которые
должны произойти для того, чтобы привести к конкретному (значимому)
результату для конкретного действующего лица.
Остальные потоки событий являются альтернативными. Альтернативные
потоки событий отражают отклонения от основного потока событий,
расширения основного потока событий, а также потоки ошибок.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
54
Предполагается, что никакой поток событий не может быть прерван и
должен быть обязательно выполнен от начала до конца.
В результате участник-актёр или получает от системы результат
выполнения функции (по основному потоку событий), или система
сообщает ему о невозможности выполнения данной функции.
Примеры описания потоков событий приведены в 2.2.1 и в задании к
Лабораторной работе № 2.
Диаграмма Последовательности – Sequence diagram
Как правило, диаграмма последовательности иллюстрирует одно
единственное действие, происходящее в рамках прецедента. Если use
case достаточно прост, то диаграмма может отражать весь поток событий.
Набор диаграмм последовательности отображает во
последовательность действий, реализующих системный сервис.
времени
Создание диаграммы последовательности проходит в два этапа:
1. Сначала на диаграмме отображаются:
- объекты, которые участвуют в выполнении действия;
- сообщения, которые посылают объекты друг другу, для выполнения
действия.
2. Затем на полученной диаграмме:
- объекты соотносятся с классами;
- сообщения соотносятся с операциями.
В верхней части диаграммы изображаются актёр и объекты (классы).
Стрелки соответствуют сообщениям (операциям).
Глядя на эту диаграмму, пользователи знакомятся со спецификой своей
работы. Аналитики видят поток действий. Разработчики – объекты,
которые надо создать, и их операции. Специалисты по контролю качества
поймут детали процесса и смогут разработать тесты для их проверки.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
55
Sequence diagram для системы ATM
Последовательность снятия
1000 руб. со счёта.
Снять деньги со счёта
Экран АТМ
Устройство чтения
карточки
Счёт Марка
Касовый
аппарат
Клиент Марк :
Клиент
1: Получить карточку устройством чтения
2: Чтение номера карточки
3: Инициализация экрана
4: Открытие счёта
5: Запрос идентификационного номера
6: Ввод идентификационного номера (777)
7: Проверка идентификационного номера (777)
8: Запрос транзакции
9: Выбор транзакции (снять деньги)
10: Запрос требуемой суммы
11: Ввод суммы (1000руб.)
12: Снятие денег (1000руб.)
13: Проверка суммы (1000 руб.)
14: Вычет суммы (1000 руб.)
15: Выдача наличных (1000 руб.)
16: Вернуть карточку клиенту
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
56
Диаграмма Классов – Class diagram
Диаграмма классов определяет типы объектов системы (классы) и
различного рода статические связи, которые существуют между ними
(ассоциации, обобщения, агрегации, зависимости).
Существует три различные точки зрения на диаграмму классов:
концепция, спецификация, реализация.
1. Концептуальная точка зрения. Диаграмма классов отображает понятия
предметной области и не имеет никакого отношения к реализующему её
программному обеспечению. Диаграмма классов содержит классы без
атрибутов и операций, а также отношения между классами. Эти
диаграммы полезны, когда проект находится в стадии анализа.
2. Точка зрения спецификации. Моделирование спускается на уровень
программного обеспечения, но рассматриваются только интерфейсы
классов, а диаграмма по-прежнему не имеет отношения к
реализующему её программному обеспечению. На диаграмме будут
показаны логические абстракции с атрибутами и операциями (классы
пользовательского интерфейса, классы управления, классы-сущности),
а также уточнённые ассоциации между классами. Диаграммы с точки
зрения спецификации полезны на стадии проектирования системы.
3. Точка зрения реализации. Моделирование спускается на уровень
реализации, и в этом случае логические абстракции проектирования
будут представлены на диаграмме классами выбранного объектноориентированного языка программирования. Данные диаграммы
используются
только
в
том
случае,
когда
необходимо
проиллюстрировать конкретный способ реализации.
Основное применение диаграмм классов заключается в описании
архитектуры ПС. Следует помнить, что не надо строить модели всего на
свете. Самая большая опасность, связанная с диаграммами классов,
заключается в том, чтобы слишком рано не погрязнуть в деталях
реализации. С этим можно бороться, если сфокусировать внимание на
концептуальной точке зрения и точке зрения спецификации,
ограничившись основными классами и ассоциациями между ними.
Для представления архитектуры системы разрабатывается столько
диаграмм классов, сколько требуется. С их помощью разработчики могут
видеть и планировать архитектуру ещё до фактического написания кода.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
57
Class diagram для системы ATM
Концептуальная модель
ATMScreen
Account
CardReader
CashDispenser
Диаграмма Состояний – Statechart diagram
В большинстве случаев диаграмма состояний строится для единственного
класса и отражает динамику поведения единственного объекта.
На диаграмме состояний отображают жизненный цикл одного объекта,
начиная с момента его создания и заканчивая разрушением. Она
определяет все возможные состояния, в которых может находиться
конкретный объект, а также процесс смены состояний объекта в результате
влияния некоторых событий.
Состояние (State) – это ситуация в жизни объекта, на протяжении которой
он удовлетворяет некоторому условию, осуществляет определённую
деятельность или ожидает какого-то события.
Состояние изображается в виде прямоугольника с закруглёнными углами.
Например, для класса Account
ATMAccount
можно выделить состояния:
Состояниясистемы
объектов класса
Счёт
открыт
Счёт
закрыт
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
Счёт
превышен
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
58
Существуют два специальных состояния объекта: начальное и конечное.
Начальное состояние
Конечное состояние
Начальным (Start) называется состояние, в котором объект находится
сразу же после своего создания.
Конечным (Stop) называется состояние, в котором объект находится
непосредственно перед уничтожением.
Начальное состояние обязательно. На диаграмме состояний может быть
только одно начальное состояние. Конечные состояния не являются
обязательными, их может быть сколько угодно.
Находясь в конкретном состоянии, объект может выполнять определённые
действия. Например, он может осуществлять некоторые вычисления или
посылать сообщение другому объекту. В состоянии объекта различают
входное действие, деятельность и выходное действие.
Счёт превышен
entry/ Временно заморозить счёт
do/ Послать уведомление клиенту
exit/ Разморозить счёт
1. Входное действие (Entry action) – непрерываемое действие, которое
выполняется при переходе объекта в данное состояние. Например, при
переходе в состояние “Счёт превышен”, выполняется действие
“Временно заморозить счёт”.
2. Деятельность (Activity) – реализуемое объектом действие, когда он
находится в данном состоянии. Например, в состоянии “Счёт
превышен” следует послать уведомление клиенту. Следует заметить,
что деятельность – это прерываемое поведение, поскольку она может
быть прервана переходом объекта в другое состояние.
3. Выходное действие (Exit action) – осуществляется как составная часть
процесса выхода объекта из данного состояния. Так, при выходе
объекта Account из состояния “Счёт превышен” (независимо от того,
куда он переходит) выполняется действие “Разморозить счёт”. Как и
входное, выходное действие является непрерываемым.
От одного состояния объекта к последующему состоянию проводится
переход.
Переход (Transition) – это перемещение из одного состояния в другое.
На диаграмме все переходы изображают в виде стрелки, начинающейся в
первоначальном состоянии и заканчивающейся в последующем состоянии.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
59
Счёт
открыт
Переход
Клиент требует закрыть счёт / Сохранить дату закрытия счёта
Событие
Действие
Счёт
закрыт
При переходе из первого состояния во второе объект выполняет некоторое
действие Action (Сохранить дату закрытия счёта) под воздействием
определённого события Event (Клиент требует закрыть) и
выполнении заданного условия Guard conditions.
Событие (Event) – это то, что вызывает переход из одного состояния в
другое.
Действие (Action) – это атомарное вычисление, которое приводит к смене
состояния или возврату значения.
Ограждающее условие (Guard conditions) определяет, когда переход
может быть выполнен, а когда нет.
Таким образом, диаграмма Состояний представляет собой автомат (State
Machine), включающий состояния, переходы, события и действия.
Диаграмма состояний служит для спецификации состояний объекта,
меняющихся при различном обороте событий. Данная диаграмма является
динамической, и особенно важна для моделирования систем реального
времени, поскольку она показывает упорядоченное по событиям поведение
объекта.
Диаграммы состояний хорошо использовать для описания поведения
некоторого объекта в нескольких различных вариантах использования.
Они не пригодны для описания поведения взаимодействующих объектов.
Не следует строить диаграммы состояния для каждого класса системы, это
будет почти всегда пустой тратой времени.
Многие разработчики считают, что управляющие объекты обладают
именно таким поведением, которое полезно изображать с помощью
состояний.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
60
Состояния
класса
Accountсистемы ATM
Statechart diagram
дляобъектов
класса
Account
Снять деньги[ отрицательный баланс ]
Счёт превышен
entry/ Временно заморозить счёт
do/ Послать уведомление клиенту
exit/ Разморозить счёт
Счёт
открыт
Сделать вклад[ положительный баланс ]
Клиент требует закрыть / Сохранить дату закрытия счёта
Счёт закрыт
Проверить баланс[ отрицательный баланс 30 дней ]
entry/ Выдать кредитную карточку
Диаграмма Компонентов – Component diagram
Диаграммой компонентов называется диаграмма, на которой показаны
компоненты системы и связи между ними.
Ранее говорилось, что компонент представляет физически заменяемую
часть системы. Следовательно, можно утверждать, что
Компонент – это отдельный программный модуль со своим интерфейсом.
Единственный тип отношений между компонентами – это зависимости.
Во многих отношениях компоненты подобны классам, но между ними есть
существенные различия:
1. Компоненты представляют собой физические сущности, а классы –
логические абстракции.
2. Компоненты представляют собой физическую реализацию логических
абстракций и, следовательно, находятся на другом уровне абстракции.
3. Компоненты могут обладать только операциями, доступными через их
интерфейсы. Классы могут обладать операциями и атрибутами.
Получающийся при компиляции исполняемый .exe файл является
компонентом системы. К моменту генерации кода необходимо соотнести
каждый из классов с соответствующими компонентами.
На диаграмме компонентов можно показать структуру исходного кода.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
61
Component diagram для системы ATM
Диаграмма компонентов сервера АТМ
ATMSerwer.exe
Account.h
CardReader.h
Account.cpp
CardReader.cpp
Диаграмма компонентов клиента АТМ
ATM.exe
ATMScreen.h
ATMScreen.cpp
CashDispenser.h
CashDispenser.cpp
Диаграмма Размещения – Deployment diagram
Диаграмма размещения отражает физические взаимосвязи
программными и аппаратными элементами системы.
между
Диаграмма размещения показывает структуру исполняемого программного
обеспечения в отличие от диаграммы компонентов, которая показывает
структуру исходного кода.
Данная диаграмма является хорошим средством для того, чтобы показать
маршруты перемещения компонентов в распределённой системе.
Каждый узел на диаграмме размещения представляет собой тип
вычислительного устройства, в большинстве случаев процессор.
Аппаратура может быть простым устройством или датчиком, а может быть
и большим компьютером.
Компоненты ПС размещаются на узлах системы.
Соединения между узлами показывают коммуникационные каналы, с
помощью которых взаимодействуют системные аппаратные средства.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
62
Deployment diagram для системы ATM
Диаграмма размещения АТМ
Сервер банковской
базы данных
Принтер
Сервер
Oracle
<<локальная сеть>>
ATMServer.exe
Региональный
сервер АТМ
<<закрытая сеть>>
1 клиентская
станция
<<закрытая сеть>>
ATM.exe
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
125 клиентская
станция
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
63
2.3 ТРЁХУРОВНЕВАЯ МОДЕЛЬ ПРИЛОЖЕНИЯ
Архитектура программной системы диктует способ, которым она
создаётся, и то, каким образом отдельные компоненты распределены в
рамках системы.
Большинство ПС разрабатываются на основе популярного трёхзвенного
архитектурного стиля (Three-tiered Architecture), состоящего из трёх
базовых типов компонент:
1. Уровень представления (User Service).
2. Уровень логики приложения или бизнес-правила (Business Service).
3. Уровень управления данными (Data Service).
Согласно этому стилю архитектуры приложений, все классы приложения
делятся на службы пользовательского интерфейса, управления данными и
бизнес-правила.
2.3.1 Компоненты уровня представления
Содержат логику приложения, которая получает входные данные от
внешнего источника, и предоставляет информацию внешнему источнику.
В большинстве случаев в качестве внешнего источника выступает
конечный пользователь, хотя это может быть также некоторое устройство
автоматизированного ввода-вывода.
Компоненты уровня представления осуществляют навигацию пользователя
через приложение, и (как опцию) контроль ограничений для вводимой
информации.
2.3.2 Бизнес-правила
Компоненты данного уровня содержат логику приложения, которая
управляет функциями и процессами, выполняемыми ПС. Эти функции и
процессы вызываются или компонентами уровня представления (когда
пользователь запрашивает информацию) или другими системными
функциями. В общем, компоненты логики приложения выполняют
некоторый тип манипулирования данными.
2.3.3 Компоненты уровня управления данными
Эти компоненты содержат логику, которая по существу является
интерфейсом с системой управления хранилищем данных. Например, с
системой управления базами данных (СУБД), иерархической файловой
системой, либо с другим источником данных типа внешней программной
системы. Функции этого уровня вызываются компонентами логики
приложения, хотя в простых приложениях они могут вызываться
непосредственно компонентами уровня представления.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
64
2.3.4 Распределённая вычислительная архитектура
1. Может существовать любое количество компонентов каждого типа
внутри одной программной системы.
2. Компоненты могут разделяться любым числом прикладных систем.
3. Каждый компонент разрабатывается с использованием оптимального
для его структуры инструментального средства.
4. Компоненты взаимодействуют друг с другом на основе абстрактного
интерфейса, который скрывает основную функцию, выполняемую
компонентом.
5. Компоненты физически могут размещаться на одной или более
аппаратных системах.
6. Распределённая вычислительная инфраструктура должна обеспечивать
размещение, защиту, и услуги связи для компонентов приложения.
Использование оптимального инструмента для разработки
Уровень
представления
Бизнес-правила
Абстрактный интерфейс
Уровень
управления
данными
Абстрактный интерфейс
Распределённая вычислительная инфраструктура
Заменяемые компоненты
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
65
3 ПРОЕКТИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
Интерфейс пользователя (User Interface) – процедуры, определяющие
взаимодействие пользователя с программной системой или сетью.
Задачей интерфейса пользователя (именуемого также человеко-машинным
интерфейсом) является обеспечение максимальных удобств при работе с
прикладными процессами. Среди множества вариантов интерфейса
человек-компьютер есть два принципиально отличных вида:
1. “вспоминай-и-набирай” – это язык команд, которые сначала надо
вспомнить, потом набрать и выполнить.
2. “смотри-и-выбирай” (look and feel) – это язык всевозможных меню и
пиктограмм, в котором следует выбрать необходимое, после чего
произойдет соответствующее действие.
С ростом сложности решаемых задач неудобства языка команд стали
очевидны. Для преодоления сложности и монотонности процесса общения
пользователя с системой был предложен графический интерфейс
(Graphical User Interface – GUI).
В настоящее время всё большее значение получает использование речи в
интерфейсе пользователя. Говорящая система может:
- указывать пользователю на ошибки и подсказывать пути их устранения;
- сообщать о возникающих ненормальных ситуациях;
- давать справки из информационных систем.
Графический
интерфейс
пользователя
является
обязательным
компонентом большинства современных программных средств. К нему
предъявляются высокие требования как с чисто инженерной, так и с
художественной стороны разработки, а при его разработке ориентируются
на возможности человека.
В среде MS Windows/NT графический интерфейс строится в виде системы
спускающихся меню с использованием в качестве средства манипуляции
мыши и клавиатуры. Работа пользователя осуществляется с экранными
формами, содержащими объекты управления, панели инструментов с
пиктограммами режимов и команд обработки.
Базовый WUI-стиль (Web User Interface) использует визуальные или
текстовые гиперссылки для навигации в рамках приложения. В
зависимости от структуры гиперссылок навигация приводит к
отображению Web-страниц в иерархии приложения внутри одного GUIокна (броузера). Броузер обеспечивает меню для Web-приложения. К
наиболее распространённым элементам WUI-интерфейса относятся
баннеры (заголовки), навигационные панели и гиперссылки.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
66
Баннер представляет собой визуальный заголовок, отображаемый вверху
Web-страницы.
Навигационная панель – это список вариантов выбора гиперссылок,
обеспечивающих доступ к информации.
Гиперссылка представляет собой вариант выбора, который отображает
следующую страницу информации или перемещает фокус отображения на
другую область той же страницы.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
67
3.1 ЭВОЛЮЦИЯ ИНТЕРФЕЙСА ЧЕЛОВЕК-КОМПЬЮТЕР
Можно идентифицировать четыре качественно отличных друг от друга
поколения:
1. В 50-е и в начале 60-х годов компьютеры работали, в основном, в
пакетном режиме, используя перфокарты для ввода и устройство
построчной печати для вывода. Можно утверждать, что не было смысла
говорить о пользовательском интерфейсе, так как не существовало
самого понятия “интерактивного пользователя” в современном смысле
этого слова.
2. C начала 60-х до начала 80-х годов господствовал режим разделения
времени на мейнфреймах и мини-компьютерах с использованием
алфавитно-цифровых
дисплеев,
когда
пользователи
могли
взаимодействовать с компьютером путём ввода с клавиатуры команд с
параметрами. Этот тип взаимодействия захватил и век персональных
компьютеров с MS DOS и операционной системой Unix.
3. Ещё в 70-е годы в научно-исследовательском центре Xerox PARC были
созданы графические интерфейсы пользователя. Эти интерфейсы
принято обозначать аббревиатурой WIMP (Windows – Icons – Menus
– Pointing device), что отражает задействованные интерактивные
сущности – окна, пиктограммы, меню и позиционирующее устройство
(обычно мышь). Именно интерфейсы этого типа, завоевавшие
популярность вместе с Macintosh в 1984 году и позднее скопированные
в MS Windows, доминируют и по сей день.
4. Сегодня на повестке дня новые формы, которые иногда называют postWIMP-интерфейсы. Они не используют меню, формы и панели
инструментов. Вместо них при задании операций и операндов упор идет
на
обучающие
примеры,
жесты
и
распознавание
речи.
Соответствующие исследования начались в 90-х годах, но пока ещё
post-WIMP-интерфейсы не получили широкого распространения.
Большинство современных пользовательских интерфейсов основываются
на имитации процессов и явлений, а также использовании алгоритмов,
знакомых каждому человеку из его обыденной жизни.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
68
3.2 ОСНОВНЫЕ ВОПРОСЫ ПРОЕКТИРОВАНИЯ ИНТЕРФЕЙСА
Следует заметить, что создание пользовательских интерфейсов – это
сложная задача, требующая знаний в разных областях. Авторами наиболее
удачных интерфейсов являлись специалисты в области психологии,
вычислительной техники и графики.
Несмотря на изобилие инструментальных средств создания GUI,
стандартные правила их разработки отсутствуют. Для успешного создания
GUI необходим тесный контакт с будущими пользователями системы.
Главная задача проектирования интерфейса пользователя – создать
описание для реальной реализации системы: специфицировать требуемые
окна, их элементы и навигационные детали.
Процесс разработки интерфейса включает решение следующих вопросов:
1. Уточнение требований к ПС и его функциональных возможностей.
2. Изучение оборудования и настольных программ типичного
пользователя.
Необходимо
понять,
насколько
часто
будет
использоваться данное ПС (например, несколько раз в неделю или в
час) и какой объём работ должен выполнять пользователь.
3. Выбор элементов пользовательского интерфейса. Это итерационный
процесс. Обычно, прежде чем выпустить продукт, приходится создавать
от 20 до 30 интерфейсов пользователя. Сначала проектируется
интерфейс для реализации наиболее критичных функций ПС, и для него
выбираются элементы интерфейса. По мере обучения пользователи
могут самостоятельно выбирать остальные элементы.
4. Постоянное согласование предложенных решений с мнением
пользователей. Важно знать, что пользователям больше всего
понравилось из увиденного ими, и что они хотели бы получить ещё.
5. Учёт мнения пользователей-новичков. Следует ориентироваться не на
опытных пользователей, а на новичков, так как первые сами разберутся
с новым продуктом, а вторые – вряд ли. Важно обсуждать принятые
решения с каждым пользователем приложения.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
69
3.3 МОДЕЛИ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
Возможны следующие способы моделирования интерфейса пользователя:
1. Использовать простое дерево, дающее полезную информацию о том,
как организована навигация в пользовательском интерфейсе.
2. Представить интерфейс в виде диаграмм классов, разбивая окна на
более мелкие части, используя обобщение и агрегацию. UMLдиаграммы моделируют структуру интерфейса: вводимые данные и
операции над ними, а также отношения между окнами интерфейса.
Пользовательский интерфейс функции
"Регистрировать заказ товара"
Табличный просмотр
<<command button>> Добавление строки
<<command button>> Редактирование строки
<<command button>> Удаление строки
<<command button>> Поиск
<<message box>> Условие поиска
Добавить строку таблицы()
Редактировать строку таблицы()
Удалить строку таблицы()
Найти строки()
Сортировать()
Заказ
<<column>> Номер заказа : Count
<<column>> Дата заказа : Date
Строка заказа
<<column>> Название товара : String
<<column>> Количество : Count
<<column>> Еденица измерения : String
<<column>> Сумма за единицу товара : Double
<<column>> Общая сумма : Double
Редактирование
<<command button>> Сохранение
<<command button>> Отмена
Сохранить строку()
Отменить сохранение строки()
Открыть форму редактирования()
Закрыть форму редактирования()
Редактирование заказа
<<edit>> Номер заказа
<<edit>> Дата заказа
Редактирование строки заказа
<<combo box>> Название товара
<<edit>> Количество
<<list box>> Еденица измерения
<<edit>> Сумма за единицу товара
<<edit>> Общ ая сумма
3. Представить динамику взаимодействия между пользователем и
системой, используя UML-диаграммы деятельностей (Activity diagram)
для моделирования навигации по окнам. Из всех допустимых элементов
диаграммы используются состояния (State) и деятельности (Activity).
Последний способ предполагает использование стереотипов состояний
(окон) и стереотипов видов деятельности (элементов управления окном).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
70
Стереотипы состояний (окна) – State
Главное окно:
Вторичное окно:
Типы данных окон:
Панель в главном окне
Диалоговое окно
Текстовое поле
Окно просмотра строк
Окно сообщений
Комбинированное окно
Окно просмотра деревьев Папка со вкладками
Спиновое окно
Web-страница
Колонка
Строка
Группа полей
Виды деятельности (элемент управления окном) – Activity
Фрагмент пользовательского интерфейса функции
"Регистрировать заказ"
<<Главное окно>>
Просмотр заказов
<<toolbox button / menu item>>
Добавление
<<toolbox button / menu item>>
Редактирование
<<toolbox button / menu item>>
Поиск
<<toolbox button / menu item>>
Удаление
<<Диалог>>
<<Диалог>>
Добавить / Редактировать заказ
Удалить заказ
<<command button>>
<<command button>>
OK
Сохранить
<<command button>>
Очистить
<<command button>>
Cancel
<<command button>>
Cancel
-
Пункт выпадающего меню
Пункт всплывающего меню
Кнопка панели инструментов
Командная кнопка
Двойной щелчок мышью
Выбор из списка
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
- Клавиша клавиатуры
- Функциональная
клавиша
клавиатуры
- Комбинация клавиш клавиатуры
- Бегунок полосы прокрутки
- Кнопка закрытия окна
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
71
3.4 ТРЕБОВАНИЯ К ПОЛЬЗОВАТЕЛЬСКОМУ ИНТЕРФЕЙСУ
Среди множества важных требований существует их общий набор,
который необходимо учитывать при проектировании интерфейса
пользователя. Согласно этому набору интерфейс должен обеспечить:
-
действия пользователя;
настройку интерфейса;
интерактивную среду (диалоги);
прямые манипуляции;
возврат, где это возможно, где невозможно – запрос подтверждения;
подсказки, необходимые пользователю при использовании системы;
соответствующее раскрытие возможностей;
простое восстановление при ошибках.
Кроме того, пользовательский интерфейс должен:
- использовать метафоры, знакомые пользователю;
- являться внутренне непротиворечивым: одинаковые действия должны
иметь одинаковый интерфейс;
- устранять возможные ошибки пользователя, где это возможно;
- сопровождать визуальными репликами действия пользователя.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
72
3.5 ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ ИНТЕРФЕЙСА
Принципы служат разработчикам основанием для построения интерфейса.
3.5.1 Контроль на стороне пользователя
Основной смысл этого принципа в том, пользователь инициирует действия
ПС. Если в результате этого действия контроль переходит к приложению,
то пользователь получает обратную связь (например, в виде индикатора
состояния).
Выбран 2 пункт меню
Процедура 1
Меню
Процедура 2
Выбран 1 пункт меню
Диалог
Обращение к диалогу
3.5.2 Обратная связь
Данный принцип дополняет принцип контроля на стороне пользователя.
Для обратной связи необходимо встроить в систему интерфейса
визуальные или аудио-подсказки для каждого события, инициируемого
пользователем. В большинстве случаев указатель в форме песочных часов
или индикатор ожидания представляют достаточный уровень обратной
связи, чтобы понять, что приложение что-то делает. Иногда может
потребоваться вывод поясняющего сообщения.
3.5.3 Эстетичность и удобство
Эстетичность влияет на зрительное восприятие системы.
Удобство касается лёгкости, простоты, эффективности, надёжности и
продуктивности в использовании интерфейса.
Именно в решении этих вопросов разработчики пользовательских
интерфейсов нуждаются в помощи художника-графика и эксперта по
социальной психологии.
Необходимо избегать сложных структур представления информации на
экране. В сложных приложениях простота интерфейса достигается:
1. С помощью подхода “Разделяй и властвуй!” за счёт
последовательного раскрытия информации таким образом, что она
отображается только тогда, когда в ней возникает необходимость, и,
возможно, в разных окнах.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
73
2. С помощью “правила шести” из области психологии: “Большинство
людей за один раз может запомнить не более шести понятий”.
Например, в одну линейку меню включать не более шести понятий,
каждое из которых содержит не более шести опций.
3.5.4 Согласованность
Принцип согласованности имеет два аспекта:
1. Соответствие информационной технологии пользователя.
2. Соответствие существующим стандартам программирования.
Интерфейс должен предоставлять пользователю привычную и понятную
ему среду, содержать пункты меню, соответствующие функциям
обработки данных и расположенные в естественной последовательности
использования.
К существующим стандартам программирования относятся стандарты по
расположению объектов на экране и последовательному использованию
элементов интерфейса в рамках ПС. Это значит, что необходимо сохранять
стандартизованное назначение графических объектов и по возможности их
месторасположение на экране. Элементы, общие для различных меню и
диалогов, следует размещать в одном месте. Например, кнопки OK и
Cancel должны всегда располагаться одинаково относительно друг друга и
занимать одно и то же место в различных диалоговых окнах.
3.5.5 Настройка
Настройка интерфейса – это задача приспособления ПС к требованиям
различных пользователей.
Группе пользователей-новичков интерфейс может предложить явную
помощь и дополнительные сообщения, указывающие на потенциальную
опасность некоторых событий.
Индивидуальный пользователь может настроить интерфейс под личные
нужды. Например, изменить размеры колонки при просмотре строк с
последующим сохранением этих изменений. При обращении к этому же
диалогу в будущем изменённые данные учитываются.
3.5.6 Терпимость к ошибкам
Интерфейс должен разрешать пользователям экспериментировать и
совершать ошибки, проявляя толерантность к ним. Данный принцип
подразумевает многоуровневую систему отмены операций. Следует
заметить, что этот принцип трудно поддаётся реализации. Пользователь,
который снял (и потратил) деньги с банковского счёта, не имеет
возможности отменить эту операцию!
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
74
3.6 ПРАВИЛА ПРОЦЕССА РАЗРАБОТКИ ИНТЕРФЕЙСА
Все разработчики по-разному подходят к организации процесса создания
пользовательского интерфейса.
Прежде всего, нужно соблюдать фундаментальное правило разработчика:
“Пользователи интерфейса должны принимать участие во всех этапах его
создания, начиная с выработки основной концепции”.
Создание системы начинается с этапа выяснения функций программного
продукта. Разработка интерфейса начинается позже, после чёткого
определения функций системы. Неудачный интерфейс, конечно, не
обязательно приводит к фатальным последствиям, но в некоторых случаях
может стать причиной крупных неприятностей. Перед создателем GUI
(WUI) открывается волнующая перспектива войти в историю проектной
группы “Рембрандтом по пользовательским интерфейсам”.
Вот четыре правила процесса разработки пользовательского интерфейса:
1. Понять назначение ПС во всех деталях. В процессе проектирования
интерфейса необходимо спрашивать у пользователей о функциях, к
которым они больше обращаются, выделяя те из них, которые
используются чаще всего, и определяют стандартный поток операций.
Например, чтобы лучше понять стиль работы и личные привычки
пользователей, Брюс Тогназзини (Bruce Tognazzini) из компании Sun
Microsystems проводит с ними целые рабочие дни. Полученный опыт
позволяет разработать логическую основу создаваемого интерфейса.
2. Создание интерфейса – это работа сбалансированной группы. Для
удачного интерфейса требуется не одиночка, а хорошая команда. В
идеале в создании интерфейса должны принимать участие специалисты
трёх областей:
- аналитик, который выясняет мнение пользователей об основных
элементах интерфейса и специфицирует их;
- проектировщик интерфейса;
- создатель графики.
В работе даже небольшой группы должны непременно принимать
участие хотя бы консультанты по разработке интерфейсов и
графическим средствам.
3. За создание проекта интерфейса должен отвечать один человек. Один
опытный сотрудник должен быть назначен экспертом по интерфейсу и
посредником между рабочей группой и пользователями, но он не
должен участвовать в программировании интерфейса и самой системы.
Он обязательно должен отвечать за связь с пользователями и может
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
75
заниматься проверкой удобства интерфейса, созданием документации,
обучением пользователей и поддержкой.
4. Проверка, создание прототипа и снова проверка. Даже если совершенно
точно определено назначение продукта, невозможно угадать все
потребности пользователей. Создание прототипа позволяет снизить
затраты на реализацию проекта. Следует использовать итерационный
цикл проектирования; включать тестирование интерфейса как часть
всего процесса создания системы; учитывать замечания пользователей.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
76
3.7 КРИТЕРИИ КАЧЕСТВА ИНТЕРФЕЙСА
Мнение пользователей о том, что некий пользовательский интерфейс
“хороший”, то есть лучше другого, зависит от небольшого количества
бросающихся в глаза характеристик, которые не зависят от стиля
пользовательского интерфейса.
Критерии качества пользовательского интерфейса обозначаются
аббревиатурой SAPCO (Simple – Aesthetic – Productive – Customizable
– Other).
3.7.1 Простой – Simple
Интерфейс – это не ракетно-космическая установка.
Хороший интерфейс не требует использования справочной системы, чтобы
начать выполнять с её помощью простые задачи конечных пользователей.
Пользователь нуждается лишь в объяснении того, как достичь результата.
3.7.2 Эстетичный – Aesthetic
Интерфейс производит приятное впечатление.
Хороший интерфейс
визуализацию.
широко
использует
графический
дизайн
и
3.7.3 Продуктивный – Productive
Интерфейс минимизирует усилия пользователя.
Хороший интерфейс избегает сложной иерархии окон и/или экранов, а
также ненужных действий с мышью и клавиатурой. Он соответствует
решаемой задаче, снисходителен к пользователю и не “наказывает” его за
небольшие ошибки.
3.7.4 Настраиваемый – Customizable
Интерфейс предоставляет выбор пользователю.
Хороший интерфейс обладает свойством приспособляемости.
обеспечивает множественные представления, шрифты и цвет.
Он
3.7.5 Другой – Other
Интерфейс работает!
Существует бесчисленное множество других критериев, большинство из
которых – разновидности уже названных. Например, лёгкость,
эффективность, надёжность и т.д. Главный критерий из других
заключается в том, что интерфейс делает то, что от него ожидает
пользователь.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
4 ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
77
К
РАЗРАБОТКЕ
“Мы либо тонем, либо выплываем вместе с объектами!”
Э. Йордон
Сегодня ни у кого не возникает сомнения в том, что объектноориентированный подход является наиболее прогрессивным при
разработке ПС. К преимуществам этого подхода относятся следующие
положительные качества:
1. Сложность ПС принимает форму иерархии. Сложные ПС состоят из
взаимозависимых подсистем (модулей), которые в свою очередь также
могут быть разбиты на подсистемы, вплоть до самого низкого уровня.
2. Выбор “примитивных” компонент, из которых строится ПС,
относительно произволен и оставляется на усмотрение разработчиков.
3. Внутрикомпонентные связи обычно сильнее межкомпонентных связей,
что позволяет относительно независимо разрабатывать каждый модуль.
4. Иерархические системы состоят из немногих типов подсистем, которые
комбинируются в различных сочетаниях.
5. Любая работающая сложная система получается только как развитие
работающей простой системы.
6. Компоненты могут повторно использоваться в различных системах.
7. Гибкая архитектура объектно-ориентированных систем легко поддаётся
модификации.
Несмотря на перечисленные достоинства, объектно-ориентированная
парадигма (как способ создания высокоуровневых проектов) подвергается
критике по следующим причинам, которые относят к её недостаткам:
1. Усложнение методологии. Для успешного использования объектноориентированного подхода требуется наличие определённого уровня
квалификации у специалистов. Для небольших проектов более
эффективным может оказаться применение структурного подхода,
когда декомпозиция ПС осуществляется не по классам, а по функциям.
2. Сложность реализации. Программная реализация на объектноориентированном языке программирования, как правило, приводит к
построению требовательного к ресурсам приложения.
3. Высокая стоимость инструментальных средств для автоматизации
процесса разработки систем.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
78
4.1 ПАКЕТЫ КЛАССИЧЕСКОЙ МОДЕЛИ СИСТЕМЫ
Каждый класс ПС в точности соответствует одному из пакетов модели: HI,
PD, DM, SI.
Проблемная область
(Problem Domain)
Взаимодействие с человеком
(Human Interaction)
Взаимодействие систем
(System Interaction)
Управление данными
(Data Management)
Пакет HI (Human Interaction) содержит классы, обеспечивающие
отображение, ввод и вывод информации, т.е. интерфейс пользователя.
Чаще всего – это окна и отчёты.
Пакет PD (Problem Domain) содержит логические программные классы
(абстракции), точно соответствующие моделируемой предметной области
и нейтральные по отношению к реализации (независимые от реализации).
Они знают или не знают совсем о классах других пакетов.
Пакет DM (Data Management) представляет классы, обеспечивающие
интерфейс между классами предметной области и СУБД или системой
управления файлами. Эти классы отвечают за доступ к хранимым данным
и выполняют все необходимые операции над ними. Чаще всего они
соответствуют классам PD, которые нужно постоянно хранить во внешней
памяти, поддерживать и искать.
Пакет SI (System Interaction) содержит классы, которые поддерживают
интерфейс между классами предметной области и другими системами
(внешними по отношению к данной системе) или устройствами.
Этот шаблон предлагает общее решение для любых ПС, причём
разделение классов на пакеты не означает их обязательного физического
разделения. Практическое применение этого шаблона для решения
конкретных задач позволяет получить типовые решения типичных
проблем в контексте решаемой задачи.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
79
Пусть разрабатывается информационная система. В качестве хранилища
данных используется база данных. Система реализуется на основе
технологии клиент/сервер. Данная технология предполагает, что
объекты клиента и объекты сервера будут разделены физически, т.е. будут
находиться в разных исполняемых модулях. Согласно основным
принципам технологии клиент/сервер объекты, реализующие интерфейс
пользователя выносятся в отдельный программный модуль Клиент.
Объекты оставшихся трёх пакетов (PD, SI, DM) помещаются в
программный модуль Сервер, через который пользователи и получают
доступ к информации. Шаблон приобретёт следующий вид:
Client
Client
Client
HI
HI
HI
Server
SI
PD
DM
Современные условия эксплуатации ПС предполагают не только
централизованный доступ к данным программы одной предметной
области, но и централизацию доступа в пределах всего предприятия
(корпоративный уровень). А это означает, что в пределах корпоративной
информационной системы может существовать несколько пакетов PD для
каждой предметной области. Кроме того, некоторые классы могут
дублироваться в различных пакетах. Таким образом, логично выделить
пакеты PD с базовыми классами для групп предметных областей
(возможно, такой пакет будет один) в отдельные программные модули, а
оставшиеся в пакетах предметных областей классы разместить в других
программных модулях. Такой каркас программной системы представляет
её в виде многоуровневого сервера архитектуры клиент/сервер.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
80
Если во всех программах используется один и тот же формат баз данных
(не только одна СУБД, но и одинаковые правила построения структуры),
тогда все операции с данными в этих базах данных будут происходить
единообразно. А это означает, что нет необходимости реализации
нескольких серверов DM. Кроме того, некоторые данные будут общими
для различных PD. Таким образом, можно сделать вывод о необходимости
реализации только одного пакета-сервера DM.
Вывод о разделении классов SI можно сделать на основе изучения
назначения классов этих пакетов. Их основная функциональность –
поддержка интерфейса с другими системами. Можно выделить основные
виды таких систем:
- системы, реализованные другими разработчиками;
- ранее разработанные системы;
- системы, по каким-либо причинам реализованные на основе других
моделей данных, не имеющие собственной базы данных и т.п.
Отличительная черта этих систем – несовместимость формата базы данных
с принятым в проектируемой системе. Можно сделать вывод, что для
обмена данными с каждой из таких систем необходимо реализовывать
свой пакет SI.
Общий шаблон диаграммы пакетов системы корпоративного уровня имеет
следующий вид:
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
81
Такая организация общей архитектуры программной системы упрощает
моделирование (в рамках каждого пакета), а также повышает вероятность
повторного использования как модулей, так и отдельных классов.
Данный шаблон применим при разработке приложений масштаба
предприятия. Необходимость формулировки проекта программной
системы в таком виде может возникать на этапах развития общего проекта
автоматизации предприятия (при разработке приложений для второй,
третьей и т.д. предметных областей). На этапе проектирования и
реализации первого приложения достаточно воспользоваться упрощённым
шаблоном:
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
82
4.2 МЕТОДОЛОГИИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА
Объектно-ориентированный подход к разработке ПС базируется на трёх
основополагающих методологиях:
1. Объектно-ориентированный анализ (Object Oriented Analysis).
Предполагает исследование предметной области с точки зрения
объектов реального мира и определяет задачи, которые необходимо
решить, а также границы ПС и требования к нему.
2. Объектно-ориентированное проектирование (Object Oriented Design).
Акцентирует внимание на программных классах и ищет логические
пути решения поставленных анализом задач.
3. Объектно-ориентированное программирование (Object Oriented
Programming). Обеспечивает реализацию классов проектирования на
выбранном языке программирования для получения конкретных
результатов.
Объектно-ориентированный анализ и проектирование логически приводят
к объектно-ориентированной декомпозиции на различных уровнях
абстракции. При изменении уровня абстракции изменяется декомпозиция.
Происходит итеративный процесс совершенствования модели ПС.
4.2.1 Объектно-ориентированный анализ
Объектно-ориентированный анализ (ООА) направлен на создание моделей
реального мира. Разработанные модели анализа служат основой для
последующего проектирования системы.
ООА – методология, при которой требования к системе воспринимаются с
точки зрения пользователей и объектов, выявленных в автоматизируемой
предметной области.
Цель анализа – направить разработку ПС в соответствии с желаниями
заказчика и пользователей. Для этого необходимо максимально точно
описать ПС с такой степенью детализации, чтобы было понятно, что
приложение должно делать и чего оно делать не должно.
ООА решает три основные задачи:
Формализация требований, предъявляемых к ПС (определение
назначения системы и создание модели функций системы). Требования
обычно корректируются на протяжении всего времени работы над
проектом.
2. Выявление объектов, которые составляют словарь (глоссарий)
предметной области.
3. Создание структур, которые обеспечивают взаимодействие объектов
для удовлетворения поставленных требований.
1.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
83
Результатом анализа является определение назначения системы и список
расставленных по приоритету требований к будущей системе, который
должен включать:
1. Описание выполняемых системой функций. Выделяются наиболее
приоритетные из них, требующие проработки в первую очередь.
2. Описание информационных потребностей. Выделяются отдельные
элементы пользовательского интерфейса: окна, отчёты.
3. Определение масштабов (границ) проекта. Предметная область
сокращается до разумных размеров.
4. Совокупность условий, при которых предполагается эксплуатировать
систему. К таким условиям могут относиться: аппаратные и
программные ресурсы; внешние условия функционирования системы;
состав имеющих к ней отношение людей и работ.
5. Ограничения в процессе разработки. Например, сроки выполнения
этапов жизненного цикла, обеспечение защиты информации.
Важно, чтобы требования отражали знания и опыт пользователей, поэтому
они обязательно должны быть согласованы с будущими пользователями и
документированы.
Документирование
обеспечивает
не
только
контрольную точку, но и помогает сделать проект более точным.
Определение назначения системы
Определение назначения системы должно состоять из одного предложения
длиной не более 25 слов, содержащего подлежащее, сказуемое и прямое
дополнение.
Подлежащим всегда должна быть система. Например, "Эта система…",
"Система ATM…" или "Система АРЕНДАТОР …"
Сказуемое описывает целевое предназначение функций, которые будет
выполнять система. Например, "Эта система помогает…", "Система
ATM обслуживает…" или "Система АРЕНДАТОР облегчает…".
Другие глаголы: поддерживает, управляет, повышает, и т.п.
Дополнение показывает объект, для которого работает система. Например,
"Эта система помогает диспетчеру товарной конторы
работать более эффективно при расчёте с заказчиком",
"Система ATM обслуживает клиентов банка, пользующихся
банковскими автоматами" или "Система АРЕНДАТОР облегчает
управление арендой недвижимости".
Формулировка назначения должна быть настолько короткой и прозрачной,
насколько можно. Максимальное упрощение формулировки поможет
чётко выдержать главное направление дальнейшей детализации. Все
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
84
детали оговариваются позже при определении функций, предназначенных
для достижения главной цели.
Сформулировав назначение, следует получить одобрение будущих
пользователей и убедить их в том, что детальное описание они получат на
следующем этапе.
Определение основных функций
Необходимо сначала ограничиться только самыми важными задачами.
Следует помнить, что сформулированные функции не должны
перекрываться, то есть две разные функции не должны решать одну и ту
же задачу.
При идентификации системных
следующей классификацией:
функций
можно
воспользоваться
1. Регистрация важной информации. Например, учёт и/или регистрация.
2. Ведение дела. Например, контроль и оценка состояния чего-либо на
основе значений его атрибутов, поддержка необходимых в процессе
трудовой деятельности действий, различные вычисления, сортировка и
поиск.
3. Анализ результатов бизнеса. Например, подсчёт экономических
показателей деятельности, оценка производительности труда.
4. Взаимодействие с другой системой. Например, приём и отправка
сообщений системе более высокого уровня.
Например, для системы АРЕНДАТОР:
-
регистрировать и хранить договоры аренды;
отслеживать выполнение текущих эксплуатационных работ;
генерировать счета для арендаторов;
выдавать информацию об аренде каждого объекта недвижимости.
При использовании UML на уровне представления (Use Case View)
полезно строить диаграммы вариантов использования (Use case diagram)
для идентификации актёров, системных сервисов и представления
входных и выходных документов.
Пример
В примере рассматривается вариант вузовской информационной системы
РЕГИСТРАТОР.
Назначение системы:
Система РЕГИСТРАТОР помогает секретарю
правильные записи об учебных дисциплинах.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
факультета
вести
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
85
Общие требования:
Система должна отражать организационную структуру Вуза, а также
должна позволять регистрировать студентов разных курсов для
прослушивания предметов, которые читают преподаватели Вуза.
Определение действующих лиц и функций системы:
Актёр – секретарь факультета, который будет работать с данной системой.
Варианты использования:
1. Секретарь должен регистрировать информацию о студентах. Какие
дисциплины, читаемые преподавателями определённого факультета
Вуза, посещают студенты.
2. Секретарь должен регистрировать информацию о преподавателях.
Какие дисциплины читают преподаватели Вуза студентам факультета.
Система РЕГИСТРАТОР
Регистрировать информацию о
преподавателях
Секретарь
Регистрировать информацию о
студентах
Выделение объектов и классов:
Для определения классов, которые потребуются для системы, можно
воспользоваться следующими рекомендациями:
1. Перечислить всех кандидатов в объекты, которые есть в описании
задачи. Как правило, это имена существительные. Например, для
системы РЕГИСТРАТОР к таким кандидатам можно отнести
следующие объекты: Вуз (University); Студент (Student); Курс
(Course);
Дисциплина
(Subject);
Преподаватель
(Teacher);
Регистрация (Registration).
2. Добавить кандидатов в объекты из анализа предметной области:
Факультет (Department), Декан (Dean); Староста (Leader).
3. Отказаться от всех ненужных и неправильных объектов согласно
следующим критериям:
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
86
3.1 Избыточные объекты: если два объекта выражают одну и ту же
информацию, сохранить объект с более подробным описанием
(Предмет – название читаемого предмета, Дисциплина – название
читаемого предмета, количество лекционных часов, количество часов
лабораторных занятий, количество часов практических занятий).
3.2 Несоответствующие объекты: если объект имеет немного или
ничего, чтобы решить проблему, этот объект должен быть устранён
(Староста).
3.3 Неопределённые объекты: объекты с неточно определяемыми
свойствами должны быть устранены.
3.4 Атрибуты: названия, которые описывают конкретные объекты с
нечётко выраженным поведением, должны быть заявлены как
атрибуты, а не как объекты (Курс).
3.5 Операции: если название описывает операцию, которая применяется
к объектам, и эта операция не может быть выполнена отдельно от
объектов, то это не объект и эту операцию следует инкапсулировать в
классе объекта (Регистрация).
3.6 Роли: название объекта должно отражать его характер, а не роль,
которую он играет в ассоциации (Декан).
3.7 Элементы реализации: все объекты, отдалённые от реальной
проблемы, должны быть устранены из модели анализа.
Подготовка словаря системы
Словарь системы (Глоссарий) – это центральное хранилище относящихся к
системе абстракций.
Глоссарий рекомендуется составлять в алфавитном порядке. Сначала в
него помещаются все существенные классы этапа анализа, названные
именами, которые отражают их смысл. По мере проектирования в
Глоссарий заносятся описания программных классов (их атрибутов,
операций) и ассоциаций между классами.
Словарь данных состоит из трёх основных граф, в которые заносятся:
термин, точное его описание, обозначение в системе. Для атрибутов
добавляются графы: тип и значение по умолчанию. Для операций – тип и
аргументы, адресный объект.
Словарь системы постепенно уточняется путём:
1. Введения новых абстракций.
2. Исключения лишних абстракций.
3. Объединения схожих абстракций.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
87
Создание Глоссария даёт три существенных выигрыша:
1. Единая терминология. Работа с ним помогает выработать
общепринятую и исчерпывающую терминологию, которой можно и
нужно пользоваться на протяжении всей работы над проектом.
2. Оглавление. Словарь является естественным оглавлением ко всем
материалам проекта и можно в произвольном порядке обратиться к
любому из них.
3. Обобщение. Он позволяет посмотреть на весь проект единым взглядом,
что может привести к открытию новых общностей, которые в
противном случае могли бы быть упущены.
Пример (продолжение)
Глоссарий (на данный момент) системы РЕГИСТРАТОР:
Термин
Описание
Обозначение
Вуз
Заведение, в котором студентами изучаются различные
учебные предметы.
University
Дисциплина
Учебный предмет, преподаваемый в Вузе.
Subject
Преподаватель
Работник Вуза, ведущий какой-либо предмет.
Teacher
Студент
Обучающийся в Вузе человек.
Student
Факультет
Учебно-научное и административное подразделение Вуза.
Department
Создание структуры
Создание структуры предполагает идентификацию возможных отношений
(ассоциаций) между классами предметной области с точки зрения
реального мира.
Любая зависимость между двумя или более классами – это ассоциация.
Ссылка одного класса на другой – это ассоциация.
В качестве названия ассоциации обычно выбирается глагол или глагольная
фраза. Ассоциации могут обозначать:
1. Физическое расположение. Один объект является частью другого
(Кафедра – Факультет).
2. Направленные действия. Один объект воздействует на другой. Для
данной системы реально такой ассоциации нет. В системе
диспетчерского управления железнодорожного транспорта главный
диспетчер диспетчерского круга направляет деятельность поездных
диспетчеров, давая им соответствующие указания. Например,
пропустить легковесный поезд с повышенной скоростью в одном пакете
с пассажирским поездом; сократить стоянку на станции; пропустить
поезд по неправильному пути на двухпутном участке.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
88
3. Связь. Один объект связан с другим (Преподаватель – Дисциплина).
4. Права владения. Один объект является хозяином другого (Декан –
Факультет).
5. Удовлетворение некоторого условия. Один объект запрашивает
состояние другого объекта. Например, если вагон неисправный, то
отправить его в ремонтный парк.
В общем случае, ассоциации предполагают участие равноправных классов,
следовательно, навигацию можно осуществлять как в одном, так и в обоих
направлениях.
Исключение составляют отношения обобщения и зависимости. Эти
отношения применяются при моделировании классов, которые находятся
на разных уровнях абстракции или имеют различную значимость.
Обобщение и зависимость – односторонние ассоциации.
Обобщение. Класс В специализация класса А. Суперкласс А не осведомлён
о подклассе В, подкласс В знает о классе А.
Зависимость. Класс А зависит от класса В. Класс В может ничего “не
знать” о классе А.
Идентификация ассоциаций производится следующим образом:
1. Определить ассоциацию для каждой пары классов, между объектами
которых надо будет осуществлять навигацию. Это взгляд на
ассоциацию с точки зрения данных.
2. Если объекты одного класса должны будут взаимодействовать с
объектами другого иначе, чем в качестве параметров операции, следует
между этими классами определить ассоциацию. Это взгляд на
ассоциацию с точки зрения поведения.
3. Для каждой из определённых ассоциаций задать кратность и имена
ролей (особенно если это помогает понять модель).
4. Если один из классов ассоциации структурно или организационно
представляет собой целое в отношении классов на другом конце
ассоциации, выделяющих его части, пометить такую ассоциацию как
агрегацию.
Пример (продолжение)
Идентификация отношений для системы РЕГИСТРАТОР:
1. Вуз – Факультет. Один Вуз состоит из одного или более факультетов.
2. Вуз – Студент. В Вузе может быть любое количество студентов, и
каждый студент может обучаться в одном или нескольких Вузах. Вузы
в какой-то степени определяются своими студентами и факультетами. В
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
3.
4.
5.
6.
7.
89
то же время студенты и факультеты вообще не могут существовать без
связи со своим Вузом, и в какой-то мере он формирует их облик.
Студент – Дисциплина. Студенты посещают дисциплины. Каждый
студент может посещать любое число дисциплин, и на каждую
дисциплину может приходить любое количество студентов.
Дисциплина – Преподаватель. Преподаватель читает дисциплину. Для
каждой дисциплины должен быть хотя бы один преподаватель. Каждый
преподаватель может вести любое количество дисциплин, в том числе и
ни одного.
Факультет – Дисциплина. На факультете могут изучать одну или более
дисциплин, и каждая дисциплина изучается на одном или более
факультетах.
Факультет – Преподаватель. Каждый преподаватель работает на
одном или нескольких факультетах, и на каждом факультете должен
быть хотя бы один преподаватель.
Факультет – Преподаватель. Каждым факультетом управляет только
один преподаватель – декан. Преподаватель может быть деканом только
одного факультета, причём некоторые преподаватели не являются
деканами.
В итоге идентифицированы структурные отношения для системы
РЕГИСТРАТОР, как показано концептуальной модели:
Концептуальная диаграмма классов системы РЕГИСТРАТОР
работает на
состоит из
Вуз
1..*
1
Факультет
1..*
обучается в
1..*
1..*
связан
+декан
0..*
Студент
1..*
посещает
0..*
Дисциплина
0..*
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
читает
0..*
1..*
Преподаватель
1..*
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
90
4.2.2 Объектно-ориентированное проектирование
Объектно-ориентированное проектирование (Object-Oriented Design –
OOD) направлено на создание моделей программных сущностей.
Основой для создания моделей проектирования служат модели реального
мира, полученные на этапе анализа.
OOD – методология, при которой требования к системе воспринимаются с
точки зрения программных объектов и классов.
OOD так же, как и ООА использует принципы объектной абстракции и
декомпозиции, и решает следующие основные задачи:
1.
2.
3.
4.
Определение логических программных объектов.
Определение атрибутов и операций логических программных объектов.
Создание статической логической модели системы.
Создание динамической логической модели системы.
Важно понимать, что на этапе проектирования главная задача –
разработать логическое решение поставленных задач. Для этого
необходимо определить программные сущности и логику их
взаимодействия для удовлетворения предъявляемых к системе требований.
Конкретный язык программирования здесь ещё не так важен. Его выбор во
многом будет определяться полученными моделями проектирования.
Наиболее существенным аспектом проектирования является создание
диаграмм классов, которые будут отражать спецификации программных
классов и их отношений, для последующей программной реализации.
Важно помнить, что классы проектирования – это описания, а не классы
языка программирования и они разрабатываются до конкретной
реализации.
Определение программных объектов
Большинство классов, которые должны участвовать в программном
решении, определены в концептуальной диаграмме классов этапа анализа
и занесены в Глоссарий системы. Может получиться так, что не все классы
станут программными сущностями. Например, в системе розничной
торговли в качестве классов были выделены Кассир и Покупатель.
Покупатель в реальной жизни взаимодействует с кассиром, однако, при
этом его связь с программным обеспечением отсутствует. Этот процесс
осуществляется только кассиром. Следовательно, программным классом
останется только Кассир. С другой стороны, система будет должна
инициировать определённые события, поэтому там появятся классы
управления для поддержки этих событий.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
91
После исследования классов предметной области следует подумать о
системных классах. К системным классам могут относиться:
1. Классы для управления последовательностью событий, происходящих в
системе. Как правило, для каждого варианта использования существует
(как минимум) свой управляющий класс.
2. Классы, моделирующие сущности предметной области.
3. Классы безопасности для обеспечения защиты данных.
4. Классы отчётов и документов, если эти концептуальные сущности
играют важную роль в проектируемой системе.
5. Классы обслуживания (утилиты) для поддержки в программной системе
общих для вариантов использования процессов.
Пример (продолжение)
Для системы РЕГИСТРАТОР в качестве управляющего класса определён
класс с одноимённым названием.
После идентификации программных сущностей концептуальная модель
примет следующий вид:
Диаграмма классов системы РЕГИСТРАТОР
has
Registrar
University
consist of
Department
is connected
trained in
Subject
works on
teaches
attends
+dean
Teacher
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
Student
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
92
Определение атрибутов
Атрибут – это свойство объекта (например, имя, вес, скорость или цвет).
Вряд ли атрибуты полностью описаны в постановке задачи, так что
следует извлечь их из знания предметной области и реального мира, а
также из анализа программной сущности объекта.
На атрибуты, как и на диаграммы классов, можно посмотреть с трёх точек
зрения: концепции, спецификации и реализации. Например, атрибут name
для объекта Teacher:
Уровень концепции. Наличие
преподаватели обладают именами.
атрибута
указывает
на
то,
что
Уровень спецификации. Атрибут указывает на то, что объект Teacher
может сообщить своё имя и обладает некоторым механизмом определения
имени.
Уровень реализации на языке C++. Объект Teacher содержит поле
(элемент данных) name, соответствующее имени преподавателя.
При определении атрибутов важно учитывать следующие обстоятельства:
1. Атрибут должен отражать существенное и важное свойство объекта.
Все детали могут быть добавлены позже.
2. Каждый атрибут должен иметь подходящее название. Названия
атрибутов обычно соответствуют существительным.
3. Атрибут не должен быть объектом.
4. Атрибут не должен быть атрибутом реализации (например, указатель).
5. Атрибут не обязательно указывает на свойство объекта реального мира
(например, статус объекта).
После идентификации кандидатов в атрибуты необходимо устранить
ненужные и неправильные атрибуты по следующим критериям:
1. Если сущность более важна, чем значение, то это объект, а не атрибут.
Например, если система занимается составлением расписания курсов
для Вуза, то лекции, практические занятия, семинары, экзамены – это
отдельные объекты, а не атрибуты класса расписание.
2. Если значение атрибута зависит от специфического контекста, то
заявите атрибут как роль. Например, декан.
3. Идентификаторы реализации не должны быть заявлены как атрибуты.
Например, если для какого-либо запроса нужно определить
промежуточное значение, то переменную, которая определяет это
значение, не следует объявлять в качестве атрибута.
4. Если свойство зависит от наличия связи, то это свойство является
атрибутом связи, а не атрибутом объекта. Например, в банковской
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
93
системе клиент банка может иметь или не может иметь кредит
(Существует связь Клиент – имеет кредит – Банк). Из этого не
следует, что необходимо вводить атрибут для класса Клиент вроде
имеющий кредит. Об этом знает ассоциация имеет кредит.
5. Если атрибут описывает внутреннее состояние объекта, которое
является невидимым внешней стороной, его следует устранить.
Например, если в системе вообще отсутствуют операции,
использующие значение какого-либо атрибута, это значит, что без него
вполне можно обойтись. Вообще все незначительные атрибуты,
которые вряд ли затронут большинство операций, должны быть
исключены.
6. Атрибут, который не связан со всеми другими атрибутами, может
указывать на класс, который должен быть разбит на два разных класса.
Например, имя, адрес, год рождения, номер кредитной карточки.
В зависимости от степени детализации диаграммы классов обозначение
атрибута может включать имя атрибута, тип и значение по умолчанию.
Пример (продолжение)
Для системы РЕГИСТРАТОР определены следующие атрибуты классов:
Имя класса
Имя атрибута
UniversityName
UniversityAddress
Department DepartmentName
SubjectName
Subject
hours
name
University
Teacher
Student
TeacherID
rank
name
StudentID
gradeYear
Комментарий
Название Вуза
Адрес Вуза
Название факультета
Название дисциплины
Общее количество часов
Фамилия, имя, отчество
преподавателя
Идентификационный номер
преподавателя
Звание преподавателя
Фамилия, имя, отчество студента
Идентификационный номер
студента
Год обучения
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
94
Упрощение классов путём обобщения
После идентификации атрибутов можно проанализировать классы на
предмет отношения обобщения. Идентифицировать суперкласс и
подклассы можно двумя различными способами:
1. Снизу вверх (восходящее наследование). Похожие по смыслу
атрибуты разных классов могут являться признаком для определения
суперкласса, чтобы совместно использовать общие
особенности.
Некоторые атрибуты или даже классы, вероятно, придётся слегка
переопределить, но не следует этим увлекаться. Если обобщение ясно
из анализа предметной области, то стоит его использовать. Если
возникают сомнения, то специально не нужно тратить время на поиски
общих свойств. Важно ещё и то, что похожими должны быть не только
атрибуты, но и поведение объектов этих классов.
2. Сверху вниз (нисходящее обобщение). Такое обобщение часто так
же очевидно из предметной области. Можно усовершенствовать
существующие классы в специализированные подклассы. Однако и
здесь следует избегать чрезмерного усовершенствования.
Кроме одиночного наследования, для увеличения случаев совместного
использования можно воспользоваться множественным наследованием.
Однако, множественное наследование приводит к возрастанию сложности
концептуального восприятия, а также сложности реализации.
При проектировании справедливы соглашения о том, что следует по
возможности избегать множественного наследования, а в отношениях
обобщения не выделять более трёх уровней иерархии классов. В
противном случае будет достаточно сложно модифицировать систему в
дальнейшем.
Пример (продолжение)
Для системы РЕГИСТРАТОР атрибут name является общим для классов
Teacher и Student. Определяется суперкласс Person с атрибутом name,
который будет общим для подклассов Teacher и Student. В каждом из
этих подклассов, которые являются специализированными версиями
суперкласса Person, определены уточняющие атрибуты.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
95
Диаграмма классов приобретает следующий вид:
Определение операций
Одной из главных задач логического проектирования является задача
определения ответственностей классов. Определение операций – это и есть
назначение ответственностей.
Операции – это некоторые сервисы (действия), которые один класс
предоставляет другому, либо самому себе.
Определение операций фокусирует внимание разработчиков на
идентификации полного и удобного для применения набора действий,
который позволит выполнить предъявляемые к проектируемой системе
требования. При выяснении того, какие операции надо обеспечить, следует
стремиться к простоте.
Можно выделить несколько общих соображений определения операций:
1. Следует определить минимальный набор операций, который требует
представляющая класс концепция. Как правило, эти операции при
реализации становятся методами (функциями-членами).
2. Добавить к этому набору операции, которые необходимы для удобства.
Включать следует только самые важные из них.
3. Подумать об общности в именовании и функциональности для всех
классов программы.
4. Не думать о реализации операций, а только о спецификации.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
96
Легко добавить все операции, которые могут когда-нибудь пригодится. Но,
чем больше операций, тем вероятнее, что они останутся
неиспользованными, и тем вероятнее, что они затруднят реализацию и
дальнейшее развитие системы. Например, функции, часто читающие и
записывающие состояние объекта, жёстко ограничивают реализацию
класса и лимитируют возможность его перепроектирования. Они
понижают уровень абстракции. Объявление функции виртуальной
критически влияет на использование класса и на отношение между
классами. Класс с виртуальной функцией потенциально действует как
интерфейс к ещё не определённому классу, а виртуальная функция
подразумевает зависимость от ещё не определённого класса.
Выбирая операции, полезно придерживаться такой последовательности:
1.
2.
3.
4.
Запросы: операции, не изменяющие состояние объекта.
Модификаторы: операции, меняющие состояние объекта.
Преобразования: операции, производящие объект другого типа.
Итераторы: операции, служащие для доступа к хранящимся в
контейнере объектам или для их использования.
Основные операции, которые выполняются всеми объектами класса, в
диаграммах классов, как правило, не показывают. Эти операции
обязательно показывают в диаграммах последовательности и диаграммах
состояний. К основным операциям относятся следующие:
Создать и инициировать (create and initialize…) новый объект.
Удалить (delete…) данный объект.
Получить (get…) значение атрибута.
Установить (set…) значение атрибута.
Добавить связанный объект (add…) – добавить связь с другим
объектом.
6. Исключить связанный объект (remove…) – исключить связь с другим
объектом.
1.
2.
3.
4.
5.
Объектно-ориентированные языки программирования обеспечивает
поддержку понятий конструкторов, деструкторов, операций копирования и
преобразования, поддержку запросов и модификаторов в форме функцийчленов.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
97
Пример (продолжение)
Для системы РЕГИСТРАТОР определены операции, которые показаны на
диаграмме классов:
Диаграмма классов системы РЕГИСТРАТОР
Registrar
University
UniversityName
UniversityAddress
has
addRecPerson()
addRecStudent()
addRecTeacher()
addRecSubject()
addDepartment()
addStudent()
consist of
Subject
Department
DepartmentName
is connected
addTeacher()
addSubject()
getDepartment()
works on
Teacher
SubjectName
hours
addStudent()
getSubjcet()
addTeacher()
teaches
attends
+dean
Student
StudentID
gradeYear
Person
name
TeacherID
rank
getTeacher()
RegisrarWindow
addRecTeacher()
addRecStudent()
trained in
getStudent()
SubjectWindow
StudentWindow
addSubject()
display()
selectSubject()
display()
addStudent()
selectStudent()
4.2.3 Методы проектирования
Почти все методы проектирования имели оригинальные графические
нотации, и нашли поддержку в виде соответствующих CASE-средств.
Назрела необходимость в унификации если не подходов, то хотя бы
нотаций. Основа для этого – согласие между приверженцами разных
методов относительно основных элементов, которые и должны
моделироваться как составная часть OOD. Прежде всего, это статические
структуры классов и динамические взаимодействия объектов в сценариях.
Попытка унификации привела к появлению UML, при создании которого
авторы соединили идеи трёх методов:
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
98
1. OMT (Object Modeling Technique) – технология объектного
моделирования, разработанная в 1991 году Джеймсом Рамбо (James
Rumbaugh) в научно-исследовательском центре General Electric.
2. Booch’93 – метод визуального моделирования Гради Буча (Grady
Booch).
3. OOSE (Object-Oriented Software Engineering) – метод, также
известный под названием Objectory, Ивара Якобсона (Ivar Jacobson),
1992 год.
По сложившейся практике, наряду со смысловыми названиями (или вместо
них), методы получали имена своих создателей. Среди них:
1. CRC (Class-Responsibility-Collaborations) – Класс-ОтветственностьСотрудничество. Уорд Каннингхем (Cunningham) и Кент Бек (Beck),
разработчики языка Smalltalk в Портленде (Орегон), 1989 год.
2. RDD (Responsibility-Driven Design) – Проектирование по
обязательствам. Ребекка Вирс-Брок (Wirfs-Brock), 1989 год.
3. OOA/D (Object-Oriented Analysis and Design) – Объектноориентированный анализ и проектирование. Питер Коад (Coad) и
Эдвард Йордон (Yourdon), 1991, 1996 год.
4. Shlaer/Mellor (Object-Oriented Systems Analysis and Recursive
Design) – Рекурсивное проектирование. Салли Шлаер и Стивен
Меллор.
О единой методологии говорят с осторожностью как о методологии
будущего. В настоящее время наиболее естественным является
применение набора моделей, входящих в UML (модели вариантов
использования, анализа, проектирования, реализации, тестирования,
развёртывания), так как этот язык стандартизирован, широко используется
и постоянно развивается. Стандарт UML открыт для обсуждения и
развивается при участии ведущих технологических фирм: IBM (IBM
Rational), Microsoft, Hewlett-Packard, Oracle, Platinum Technology и
других. Использование единого языка моделирования позволяет
специалистам разных стран “говорить” на одном языке, а стандартизация
моделей облегчает интеграцию средств моделирования с другими
инструментами создания программных систем.
Проектирование по обязательствам, CRC-cards
В конце 80-х годов в исследовательских лабораториях фирмы Tektronix в
Портленде (штат Орегон) известные программисты и специалисты по
языку Smalltalk Уорд Каннингхем и Кент Бек предложили достаточно
простой метод.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
99
Модель системы разрабатывается на основе текстуального анализа
спецификаций и требований к системе. Из них выделяются
существительные и глаголы. Существительные становятся кандидатами в
объектные классы, а глаголы – в операции для этих классов.
Для каждого класса:
1. Определяются его обязанности и соответственно роли, которые играют
объекты данного класса.
2. Определяются действия, выполняемые при реализации той или иной
роли класса.
3. Обязанности объединяются в контракты, определяющие набор
запросов, которые объекты могут поддерживать.
4. Контракты уточняются путём создания протоколов, в которых
определяются аргументы и возвращаемые значения.
Для описания классов или подсистем используются CRC-карты (Class –
Responsibility – Collaboration). CRC-карты – удобное средство
разработчика в процессе определения атрибутов и операций с объектами
системы, а также для моделирования отношений. Они представляют собой
небольшие карточки размером 4х6 см, в верхней части которой
записывается имя класса, справа – ответственности, слева – сотрудники.
Пример CRC-карты для класса Заказ:
Имя класса
Ответственности
ЗАКАЗ
Проверить наличие Строка заказа
товаров
Определить цену
Строка заказа
Проверить оплату
Клиент
Отправить по адресу
доставки
Сотрудники
Небольшой размер карточки выбран намеренно, чтобы описание было
предельно кратким. Наиболее распространённая ошибка заключается в
формировании
слишком
длинных
списков
низкоуровневых
ответственностей. Все ответственности должны легко помещаться на
карточке. Карточка, содержащая более трёх-четырёх ответственностей
сомнительна. В этом случае следует либо разбить класс на части, либо
рассматривать ответственности на более высоком уровне.
Ответственность
(Responsibility)
–
высокоуровневое
описание
выполняемых классом операций.
Сотрудничество (Collaborations) – показывает классы, которые должны
кооперироваться с данным классом для реализации операций.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
100
Сотрудничество даёт представление о связях между классами на
достаточно высоком уровне абстракции.
Акцент на ответственности класса и отсутствие сложной нотации делает
их особенно полезными. Карточки компактны, их легко разложить на
столе, оставив пустые места там, где, по всей видимости, нужны
дополнительные классы. CRC-карты не оставляют шансов для того, чтобы
погрязнуть в деталях реализации, что крайне важно при проектировании
системы.
CRC-карты не являются составной частью официального UML, но многие
разработчики используют их вместе с языком моделирования.
Метод проектирования по обязательствам не затрагивает вопросов анализа
предметной области и составления технического задания. При
проектировании строится одна модель – это модель классов.
Метод Коада/Йордона (OOA/D)
Данный метод представляет систему в виде многоуровневой модели.
Выделяется пять уровней анализа:
1.
2.
3.
4.
5.
уровень объектов-классов;
уровень атрибутов;
уровень служб;
структурный уровень;
уровень тематических групп.
К пяти уровням анализа добавляется четыре компонента проектирования,
каждый из которых включает те же пять уровней анализа:
1.
2.
3.
4.
компонент предметной области (Problem Domain – PD);
компонент взаимодействия с человеком (Human Interaction – HI);
компонент взаимодействия систем (System Interaction – SI);
компонент управления данными (Data Management – DM).
Компоненты модели используются для разбиения классов на осмысленные
свободно соединяемые подмножества.
Каждый класс в точности соответствует одному из компонентов модели:
HI, PD, DM, SI. Такая организация классов упрощает моделирование (в
рамках каждого компонента), а также повышает вероятность их
повторного использования.
Компонент Problem Domain содержит логические программные объекты,
точно соответствующие моделируемой предметной области и нейтральные
по отношению к реализации (независимые от реализации). Они знают или
не знают совсем об объектах других компонентов.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
101
Компонент Human Interaction содержит объекты, обеспечивающие
интерфейс между людьми и объектами предметной области (интерфейс
пользователя). Чаще всего – это специальные окна и отчёты.
Компонент Data Management представляет объекты, обеспечивающие
интерфейс между объектами предметной области и базой данных или
системой управления файлами. Эти объекты чаще всего соответствуют тем
объектам PD, которые нужно постоянно хранить во внешней памяти,
поддерживать и искать.
Компонент System Interaction содержит объекты, которые поддерживают
интерфейс между объектами предметной области и другими системами
(внешними по отношению к данной системе) или устройствами.
Разработка модели состоит из пяти основных этапов:
1. Определение классов и объектов на основе анализа предметной области
и выделение основных понятий, формирующих программную систему.
2. Идентификация структур, определяющих два типа отношений между
классами: обобщение-специализация и целое-часть.
3. Выделение субъектов системы – групп классов и объектов,
объединённых по принципу облегчения понимания модели; на этом
этапе могут использоваться структуры, определённые ранее.
4. Определение атрибутов – для каждого объекта определяется
характеризующая его информация (что знает объект о себе самом).
5. Определение операций (какие другие объекты знает объект и что делает
для них и для себя самого).
Основной акцент метода ставится на информационную структуру системы.
Несомненным достоинством метода является простая нотация и лёгкость
освоения для людей, не имеющих большого опыта в объектноориентированном программировании. Существуют также стратегии,
шаблоны и образцы для построения объектных моделей Питера Коада,
Дэвида Норта и Марка Мейфилда, которые подробно описаны в книге этих
авторов “Объектные модели. Стратегии, шаблоны и приложения”. Нотация
метода отличается от UML-нотации, однако, между ними имеется
малосущественная разница.
Метод Шлаер/Меллора (Рекурсивное проектирование)
Метод назван по имени его авторов – Салли Шлаер и Стивена Меллора.
Основой метода является интегрированный набор моделей, которые можно
верифицировать, то есть проверять их корректность. Набор включает в
себя:
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
102
1. Информационные модели. Информационная модель – это объектная
модель, которая описывает объекты предметной области и отношения
между ними.
2. Модели состояний. Модель состояний – описывает жизненный цикл
каждого объекта, включённого в информационную модель. Модели
состояний не строятся для неизменяемых объектов.
3. Модели спецификации действий. Модель спецификаций действий
описывает действия при переходе объектов из одного состояния в
другое согласно модели состояний.
Все три модели основаны на строгих формальных методах:
- Информационная модель базируется на реляционной модели данных.
- Модель состояний – это конечный автомат.
- Спецификация действий выражается на формализуемом языке.
Информационная
модель
Состояние клиента
Действия
при переходе
от Сост. 1 к Сост. 2
Сост. 1
Клиент
Банкомат
Сост. 2
Состояние банкомата
Действие включить
Включен
Действие выключить
Выключен
Информационные модели
Модели состояний
Спецификации действий
Данные, которые должны быть обработаны, находятся в информационной
модели. Последовательность обработки представлена в модели состояний.
Действия определены в спецификациях действий.
Благодаря хорошо изученным формализмам, имеется возможность
проверить корректность поведения системы, то есть провести
верификацию:
- Статическая проверка заключается в проверке соответствия моделей
набору формальных правил и в проверке целостности и
непротиворечивости этих моделей.
- Динамическая проверка заключается в эмуляции работы системы.
Процесс применения метода начинается с разделения предметной области
на домены – независимые функциональные области.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
103
Домены взаимодействуют друг с другом согласно архитектуре C/S
(“клиент-сервер”), то есть домен опирается на сервисы других доменов для
выполнения своих операций.
В результате разбиения задачи на домены строится диаграмма доменов, в
которой отображаются состав доменов и их отношения. Отношения между
доменами в методе Шлаер/Меллора называются переходниками (bridge).
Диаграмма доменов дополняется текстовым описанием всех доменов и
переходников.
Анализ начинается с прикладного домена, который определяет точку
зрения пользователя на систему. На основе предметного домена
разрабатываются сервисные домены. Последовательность разработки
определяется отношением “клиент/сервер”. До тех пор, пока не закончен
анализ клиента, не начинается анализ сервера.
Итеративно этот процесс продолжается до тех пор, пока анализ системы не
достигнет реализационных доменов: операционной системы и языков
программирования, то есть готовых программных систем.
Последним доменом является архитектурный домен, который определяет
дизайн системы. Характерной особенностью метода Шлаер/Меллора
является то, что архитектура разрабатывается независимо от анализа
предметной области, хотя и зависит от неё и от вида решаемой задачи.
При проектировании по методу Шлаер/Меллора строятся четыре вида
диаграмм:
1. Диаграмма класса, которая показывает внешний интерфейс каждого
класса.
2. Диаграмма структуры класса, которая показывает внутреннюю
структуру операций класса.
3. Диаграмма наследования, которая отображает структуру наследования
между классами.
4. Диаграмма
зависимостей,
которая
отображает
отношения
использования (вызовы методов) и “дружественные” (friend) отношения
между классами.
Как видно из описания различных методов, все они имеют много общего:
общие конструкции при моделировании, три взаимно-ортогональные
представления проектируемой системы: статическое, динамическое,
функциональное. Различие заключается в акцентах, которые ставятся на
динамические или функциональные представления системы. Язык
моделирования UML объединил наиболее распространённые методы
моделирования
программных
систем.
Следует
отметить,
что
поддерживающие
рассмотренные
методы
CASE-средства
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
104
модифицируются с тем, чтобы можно было пользоваться UML для
построения моделей (например, BridgePoint и DesignPoint компании
Project Technology, поддерживающие метод Шлаер/Меллора).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
105
5 ОБЪЕКТНАЯ МЕТОДОЛОГИЯ – OBJECT METHODOLOGY
Методология – совокупность методов и приёмов к процессу разработки
(прежде всего к анализу и проектированию) программных средств.
Объектная методология:
1. Заключается в объектной декомпозиции, причём статическая структура
системы описывается в терминах объектов и связей между ними, а
поведение системы описывается в терминах обмена сообщениями
между объектами.
2. Базируется на трёх связанных, но различных точках зрения, каждая из
которых фиксирует важные аспекты системы: статические,
динамические и функциональные.
3. Предполагает существование методов и приёмов, связанных с понятием
объекта.
Моделирование системы проводится как поуровневый спуск от
концептуальной модели к логической, а затем к физической модели
программной системы.
Начало создания любой модели – это описание проблем, наиболее
вероятно, на естественном языке. Конец создания модели представляет
собой формальную модель, которая позволяет решить поставленные
проблемы.
Модель должна отображать наиболее существенные аспекты программной
системы.
Метод объектного моделирования с использованием UML предполагает
построение набора моделей в процессе разработки ПС:
1. Модель анализа определяет требования пользователей и ориентирована
на предметную область.
2. Модель проектирования определяет требования к архитектуре
программной системы и ориентирована на поиск программного
решения. В традиционном жизненном цикле модель проектирования
играет роль посредника между анализом и реализацией.
3. Модель реализации определяет языковую поддержку. Модель
реализации всецело зависит от конкретного языка программирования.
Каждая из этих моделей может быть представлена статическими,
динамическими и функциональными моделями ПС.
Статическая (Объектная) модель предполагает декомпозицию на классы.
Объектная модель расширяется динамической и функциональной
моделями.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
106
Динамическая модель отражает изменения во внутреннем состоянии
объектов/классов.
Динамическая
модель
расширяется
моделью
управления.
Модель управления представляет взаимодействие специальных объектов
управления (управления событиями, параллельное управление) для
поддержания функций системы.
Функциональная модель отражает взаимодействие объектов/классов
(потоки данных).
Критерии оценки модели:
1. Однозначность. Отсутствие двусмысленности.
2. Абстрактность. Устранение избыточных деталей.
3. Согласованность. Отсутствие противоречивости.
Создание всех моделей должно быть направлено на создание надёжных
продуктов и возможность повторного использования компонентов.
Модели разработки программной системы имеют огромное значение для
создания модели тестирования системы.
Основной моделью объектной методологии является объектная модель.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
107
5.1 ОБЪЕКТНАЯ МОДЕЛЬ
Объектная модель представляет статику системы и используется для
описания структуры системы, графически представляя содержащиеся в
ней элементы посредством диаграмм объектов и диаграмм классов.
В диаграммах объектов определяются:
- атрибуты, которые имеют конкретные значения;
- связи между различными объектами.
В диаграммах классов определяются:
- атрибуты и операции для каждого класса;
- отношения между различными классами.
Значение по
умолчанию
Адресат
Объектная
модель
Аргумент
Тип
результата
имеются для
Тип
Атрибут
Операция
Метод
Диаграмма
классов
Описание
имеет
Класс
Диаграмма
объектов
описывает
представляет
описывает
Объект
имеются для
имеет
представляет
Значение
Связь
Имя
роли
имеет
состоит из
Ассоциация
Роль
Агрегация
Квалификатор
Мощность
Упорядочение
имеет
Атрибуты
ассоциации
Обобщение
Дискриминатор
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
108
Общая, независимая от конкретных данных, концепция объектной модели,
представлена метамоделью.
Некоторые пояснения к метамодели:
Объект должен принадлежать классу.
Значение атрибута существует только для объекта.
Связь существует только между объектами.
Описание (и метод) существует только для класса, без него он не может
существовать.
5. Ассоциация существует только между классами.
6. Роли ассоциации принадлежат классу, иначе они не могут
существовать.
7. Атрибуты ассоциации принадлежат классу, иначе они не могут
существовать.
1.
2.
3.
4.
При создании объектной модели важно знать и учитывать следующие
факторы:
1. Объекты имеют идентичность в описании свойств и поведения,
которыми они обладают. Объекты различаются конкретными
значениями свойств и присущим им конкретным поведением.
2. Объекты класса должны обладать не только общими атрибутами и
общими операциями, но и общей семантикой.
3. Атрибуты класса имеют свои значения для каждого объекта.
4. Для описания класса следует использовать самые существенные и
характерные для объектов атрибуты и операции.
5. Одна и та же операция может применяться во многих различных
классах. Каждый из этих классов имеет метод для реализации этой
операции. Важно, чтобы все методы для одной и той же операции
имели одинаковую сигнатуру: количество и тип аргументов, тип
результата.
6. Операции, которые только вычисляют функциональное значение (не
имеют никаких внешних эффектов), а также операции без параметров
(кроме операций с объектами-адресатами), могут рассматриваться как
вычисляемые атрибуты.
7. Каждая ассоциация в диаграмме классов соответствует
набору
однотипных связей между объектами этих классов (в диаграмме
объектов). Точно так же каждый класс соответствует набору объектов.
8. Атрибуты ассоциации – это свойства связей в ассоциации.
9. Роль – это один конец ассоциации. Бинарная ассоциация имеет две
роли, каждая из которых может иметь имя роли. Имя роли – это
уникальное название, которое опознает один конец ассоциации.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
109
10. Обобщение – это отношение между классами типа is-a. Общая
сущность, которую называют суперклассом (или родителем) связана
отношением обобщения с уточняющей её разновидностью, называемой
подклассом
(или
потомком).
Обобщение
характеризуется
дискриминатором.
Дискриминатор (discriminator) показывает признак, указывающий, по
какому свойству объектов сделано обобщение.
Как правило, дискриминатор не именуется. Благодаря отношению
обобщения от подкласса к суперклассу подкласс наследует свойства и
поведение своего суперкласса.
11. Агрегация – отношение между классами типа part of или has (целоечасть). Различают две формы агрегации: слабая (простая) и сильная
(композиция). Простая агрегация только позволяет отличить “целое” от
“части” и не накладывает никаких ограничений на соотношение времён
жизни целого и его частей. Композиция – это форма агрегации с чётко
выраженным отношением владения, причём время жизни целого и его
частей совпадают. Целое в композиции управляет созданием и
уничтожением своих частей.
12. Ассоциация может иметь: мощность (количество объектовучастников), упорядочение (сортировка объектов-участников) и
квалификатор. Квалификатор (qualifier) – это значение, выбирающее
уникальный объект из группы объектов, которые связаны с ним в
ассоциации. Квалификатор позволяет снизить мощность ассоциаций
“один ко многим”, “многие ко многим”.
13. В ассоциации между двумя классами сама ассоциация может иметь
свойства. В этом случае говорят о классе-ассоциации. Классассоциация (Association Class) – это элемент модели, который
сочетает в себе свойства как ассоциации, так и класса.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
110
5.2 ПРОЦЕДУРА МОДЕЛИРОВАНИЯ
Насколько известно, существует только один подход к созданию
объектной модели. Однако, автор этого подхода Джеймс Рамбо
(J.Rumbaugh) делает различие между объектным моделированием и
расширенным объектным моделированием. В данном курсе подробно
рассматривается только первая часть, потому что обсуждаемые в этой
части концепции (объекты, классы, ассоциации, агрегация и обобщение)
наиболее важны. Концепции второй части объясняют тонкости объектного
моделирования, которое обычно используются при создании очень
сложных программных систем и прикладных программ. К ним относятся:
композиция, абстрактные и конкретные классы; множественное
наследование; метаданные (данные о данных); ограничения.
В объектной методологии при построении объектной модели программной
системы необходимо выполнить следующие шаги:
1. Выделить классы и объекты на выбранном уровне абстракции.
2. Подготовить словарь данных – выяснить семантику объектов и классов.
3. Идентифицировать связи между объектами и ассоциации между
классами (включая агрегацию).
4. Идентифицировать атрибуты и операции классов
спецификации интерфейсов и реализации классов.
–
создать
5. Упростить классы, используя обобщение.
6. Проверить существование путей доступа для вероятных запросов.
7. Выполнить итерации и совершенствование модели.
8. Сгруппировать классы в пакеты.
Г. Буч (G. Booch) называет процедуру моделирования микропроцессом
объектно-ориентированной
разработки
программных
систем.
В
микропроцессе традиционные этапы жизненного цикла программных
продуктов умышленно перемешаны. Ежедневно разработчиками
производится анализ, проектирование, программирование и тестирование
системы на выбранном уровне абстракции. Именно микропроцесс является
основой для развития архитектуры программной системы. Из множества
альтернативных решений, полученных в микропроцессе разработки,
складывается окончательное решение, которое и обеспечивает успех или
провал всего проекта.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
111
5.3 КОНЦЕПЦИИ ОБЪЕКТНОЙ МЕТОДОЛОГИИ
5.3.1 Концептуальная целостность – Conceptual Integrity
Объектная методология предполагает высокоуровневую структуру ПС,
которая представляет собой сеть сотрудничающих агентов-объектов.
Причём, на всех этапах разработки: анализа, проектирования и реализации.
Концептуальная целостность обеспечивается наличием только двух типов
отношений между классами:
1. Поставщик – Клиент
2. Родитель – Наследник
Благодаря именно этим почти драконовским ограничениям становится
возможным уйти от таких понятий, как “основная программа”,
“глобальные переменные”, “проектирование сверху-вниз” и т.п.,
предполагающих, что система обязательно имеет некий центр.
Наличие только двух типов отношений делает возможным повторное
использование образцов проверенных временем классов, о которых всё
уже точно известно. Следование образцам обеспечит успех.
5.3.2 Гарантированный результат – Contract
Наиболее уязвимый аспект архитектуры системы – отношения между
клиентами и поставщиками.
Контракты – это чёткое выражение отношений между объектамиклиентами и объектами-поставщиками.
Контракты должны ясно выражать ожидания и обещания каждой стороны.
Для клиента формулируются предусловия, для поставщика – постусловия.
Например, предусловием может быть наличие у клиента прав доступа,
постусловием – поставщик передал клиенту информацию.
Предусловия – это такие условия, которые должны быть выполнены
прежде, чем поставщик начнёт свою работу для клиента.
Постусловия – это такие условия, которые должны быть выполнены после
завершения работы поставщика.
Контракты позволяют:
1. Инициировать взаимодействие в нужный момент.
2. Организовать взаимодействие в нужном контексте.
3. Гарантированно получить нужный результат.
Если клиент гарантирует удовлетворение предусловий (успешно
выполнить все лабораторные работы, посещать лекции, читать литературу
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
112
по специальности), тогда поставщик гарантирует выполнение постусловия
(поставит отличную оценку без экзамена).
Большинство коммерческих объектно-ориентированных языков не
предлагают явных средств для реализации контрактов. Соответственно,
этот критический для построения надёжных систем принцип используется
в практике разработки не слишком часто. Тем не менее, Бьёрн Страуструп
рассматривает некоторые возможности языка C++ для поддержки
контрактов. К ним относятся: инварианты; утверждения; предусловия и
постусловия для методов. Подробнее познакомиться с этим нужно в книге
Б. Страуструпа “Язык программирования С++”, 3-е издание, Бином, 1999;
глава
24.
Хороший
стиль
программирования
предполагает
документирование контрактов хотя бы в комментариях.
Внеклассное чтение: внимательно прочитать и пересказать содержимое
файла “Контрактное программирование.doc”.
5.3.3 Самодостаточность – Selfishness
Самодостаточность (selfishness – эгоизм, себялюбие), как замечает Б.
Мейер, это наиболее известная, но наименее понимаемая часть объектной
методологии. Обычно используются более привычные термины –
“сокрытие информации” или “инкапсуляция”.
Объект-поставщик раскрывает клиентам только часть своих свойств,
причём в идеале именно в том объёме, который необходим.
Большинство программистов привыкло считать, что этот механизм введён,
прежде всего, для защиты поставщика от несанкционированного
клиентского доступа, дабы тот не прознал тайны реализации, или не
испортил её. Подобная точка зрения имеет мало общего с существом
объектной методологии. На самом деле сокрытие информации является
принципиальным для защиты не поставщика, а клиента. Дело в том, что
как автор объекта-клиента, Вы, в принципе, не хотите знать ни о каких
деталях, свойственных поставщику. Это вопрос выживания в борьбе со
сложностью. Принцип “эгоистической самодостаточности” гласит: “Меня
не интересует, кто ты; просто скажи мне, что ты можешь
сделать для меня”.
Для защиты поставщика от несанкционированного доступа клиента
объект-поставщик должен сам об этом позаботиться (самостоятельно
проявлять инициативу в нужный момент). Принцип Голливуда гласит: “Не
звоните нам, мы сами с Вами свяжемся”.
Благодаря самодостаточности объектная методология решает три
существенные проблемы, связанные: с повторным использованием
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
113
модулей, с происходящими в ней изменениями, с увеличением размеров
системы.
5.3.4 Иерархия – Hierarchy
Критический вопрос при применении объектной методологии заключается
в том, какие объекты (классы и их экземпляры) использовать в конкретной
разработке, то есть, как классифицировать объекты.
Классификацией является создание иерархий с наследованием.
Эта классификация отображает реальный неупорядоченный мир в
упорядоченный мир объектов. Попутно обнаруживаются общности в
ключевых абстракциях объектов и в реализующих поведение механизмах.
Для разработчика объектно-ориентированной системы основной единицей
декомпозиции является класс, а не алгоритм. Критично и то, что желаемое
поведение всей системы достигается с помощью взаимодействия
множества объектов, принадлежащих различным классам, которые могут
разрабатываться разными людьми.
Для опытной команды разработчиков существует эмпирически выявленная
закономерность:
- 70% классов относительно легко идентифицировать уже на стадии
анализа;
- 25% классов возникают на стадиях проектирования и программной
реализации;
- необходимость в остающихся 5% классов часто выявляется только на
этапе поддержки и сопровождения системы.
Основными видами иерархии сложных систем являются:
1. Иерархия по составу, которая определяет структуру объектов и
использует отношение типа part of, has (целое-часть).
2. Иерархия по типу, которая определяет структуру классов и использует
отношение обобщения is a (является).
5.3.5 Согласованность – Seamlesness
Суть идеи согласованности (бесшовности, связности, цельности –
seamlessness) в том, что существует чёткое структурное соответствием
между моделями на различных этапах разработки от определения
требований
до
программной
реализации
(моделями
анализа,
проектирования и реализации).
Структурное соответствие обеспечивается выбранным уровнем абстракции
и декомпозицией.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
114
Модели реализации создаются на базе моделей проектирования. Модели
проектирования – на базе моделей анализа. Это называется трассируемость
(traceability).
Модели анализа могут быть непосредственно подвергнуты сравнению с
моделями реализации – свойство обратимости (reversibility).
Трассируемость и обратимость гарантируют согласованное изменение
моделей в прямом и обратном направлениях.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
115
5.4 МОДЕЛИ СИСТЕМЫ
Физическая модель тесно связана с тремя моделями: статической,
динамической и функциональной. Три перечисленные модели делят
программную систему на ортогональные, но взаимосвязанные,
представления, каждое из которых описывает один аспект системы и
содержит ссылки на другие модели.
Физическая модель
реализация
данные
методы
Функциональная модель
Статическая модель
Динамическая модель
упорядочение
Статическая модель обеспечивает необходимую основу ПС. Эта модель
определяет исходную структуру работы динамической и функциональной
моделей.
В конце проектирования эти три модели дают реализацию (физическую
модель), которая включает данные (статическая модель), упорядочение
(динамическая модель) и методы (функциональная модель).
5.4.1 Статическая модель системы
Статическая модель системы отражает наличие и расположение классов и
компонентов системы.
При использовании UML статическая модель представляется диаграммами
классов, которые обеспечивают необходимую основу ПС, и фиксируют её
внутреннюю структуру. Эти диаграммы определяют основные элементы,
из которых будет строиться система и их возможные отношения.
Элементы системы объединяются в компоненты, что специфицируется в
диаграммах компонентов.
Все диаграммы вместе определяют статическую структуру системы.
Статическая модель тесно связана
динамической и функциональной.
с
двумя
другими
моделями:
5.4.2 Динамическая модель системы
Динамическая модель представляет аспекты управления системой,
временнЫе аспекты и поведение системы.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
116
Как правило, динамика системы проектируется вместе с её статикой. Она
может строиться и после того, как построена и согласована статическая
модель, в которой уже распределены обязанности между классами.
В динамической модели:
1. Определяется структура управления при помощи описания
последовательности операций во времени. Эти операции происходят в
ответ на внешние стимулы, то есть инициируются либо актёрами, либо
активными программными классами (т.е. классами управления),
которые посылают сообщения. Операции в диаграммах отражаются без
того
- где они работают (статическая модель),
- что эти операции делают (функциональная модель),
- как они реализованы (физическая модель).
При использовании UML временнЫе аспекты отображаются
диаграммами последовательностей.
2. Фиксируются изменения, происходящие с объектами, для чего
создаются диаграммы состояний для классов.
3. Фиксируются изменения, происходящие со связями между объектами
во время работы системы. Это может быть отражено в диаграммах
состояний для вариантов использования.
Главные концепции динамического моделирования – события (внешние
стимулы), и состояния (значения и связи с объектом).
5.4.3 Функциональная модель системы
В функциональной модели показывают различные производимые классами
системы операции (вычисления) и функциональную структуру данных.
Функциональная модель содержит четыре компонента:
1. Операции – преобразование данных.
2. Участники операций – производители и потребители значений.
3. Хранилища данных – создатели задержки между созданием и
использованием данных.
4. Потоки данных – отношения между операциями, участниками и
хранилищами данных.
Функциональная модель, таким образом, описывает атрибуты операций и
возвращаемые значения, а также описывает хранение данных. Для каждой
операции могут быть построены UML-диаграммы последовательности,
кооперации и деятельности.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
117
Хранилища данных и потоки данных, отношения между значениями при
вычислении моделируют в диаграммах потоков данных – Data Flow
Diagram. Эти диаграммы показывают потоки значений от внешних входов
через операции и внутренние хранилища данных к внешним выходам.
Диаграммы потоков данных – предмет изучения дисциплины “Базы
данных”. Функциональную модель системы в данной дисциплине будем
сводить к операциям вычисления значений по всевозможным запросам, а
хранение данных определять структурой данных в оперативной памяти.
5.4.4 Физическая модель системы
Физическая модель системы отражает использованные программные и
аппаратные средства для реализации системы, а также расположение
компонентов реализации системы по аппаратным устройствам.
Элементы реализации специфицируются в UML-диаграммах классов,
компонентов, развёртывания (размещения).
5.4.5 Статическая и динамическая модели
Динамическая модель определяет:
1. Допустимые последовательности изменений состояний объектов класса
из статической модели. В динамической модели состояния связаны со
значениями атрибутов объектов и конкретных связей объектов. Если
имеют место существенные различия между состоянием объектов
выделенного класса, то объекты следует моделировать как различные
классы.
2. Сообщения, которые могут посылать объекты друг другу для того,
чтобы управлять системой и менять состояние объектов. Сообщения
могут быть представлены операциями-модификаторами в статической
модели.
Такие отношения из статической модели, как обобщение и агрегация, так
же применяются к динамической модели.
Обобщение
состояния
подсостояний объектов.
подразумевает
выделение
однотипных
Агрегация состояния – это составное состояние, то есть соединение частей
более чем одного подсостояния.
5.4.6 Статическая и функциональная модели
Все четыре компонента функциональной модели (операции, участники,
хранилища и потоки данных) могут быть связаны со статической моделью.
1. Операции в функциональной модели показывают то, что должно быть
реализовано в методах.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
118
2. Участники – это объекты из статической модели, которые связаны по
операции. Как правило, один входной объект является поставщиком
(сервером) и один выходной объект является потребителем (клиентом).
Другие входные объекты – это параметры операции.
3. Хранилища данных – это структуры данных, которые сохраняют
атрибуты объектов статической модели.
4. Потоки данных – это движение значений атрибутов из статической
модели.
Движение к участникам – это операции над объектами (например,
модификаторы, запросы).
Движение от участников – это операции с объектами (например,
преобразование объектов, возврат значений).
Движение к хранилищу – это запросы к хранилищу на получение данных.
Движение от хранилища данных – это получение данных из хранилища и,
как правило, модификация данных.
5.4.7 Динамическая и функциональная модели
Взаимодействие между этими двумя моделями заключается в следующем:
- динамическая модель определяет операции (без рассмотрения того, как
они будут выполняться) и рассматривает состояния, когда операции уже
выполнены;
- функциональная модель определяет то, как выполнить операции, и
какие параметры для этого необходимы.
Однако имеется различие между операциями с участниками и операциями
с хранилищем данных. Поскольку участники – это активные объекты, то
динамическая модель обязательно должна определять, когда они
действуют, а функциональная – как они действуют. Хранилища данных –
пассивные объекты (они только отвечают на модификацию и запросы).
Для больших систем хранилище данных не что иное, как база данных.
Организация, динамика и функциональность базы данных моделируются
отдельно, но об этом Вы знаете из дисциплины “Базы данных”.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
119
6 ОСНОВНЫЕ ЭТАПЫ ЖИЗНЕННОГО ЦИКЛА
Традиционные этапы стадии разработки жизненного цикла:
1. Определение требований. Является внешним описанием ПС и должно
учитывать функции ПС и критерии его качества.
2. Конструирование. Создаёт архитектуру для реализации.
3. Кодирование. Заключается в реализации проектных моделей.
В течение всей стадии разработки осуществляется тестирование, которое
предполагает непрерывную верификацию моделей, модулей, подсистем и
всей системы в целом.
За стадией разработки ПС следует внедрение – передача готового
программного продукта в эксплуатацию.
Итерации – это не что иное, как эволюция. Управление эволюцией в ходе
эксплуатации – это сопровождение.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
120
6.1 СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ
Разработка ПС начинается с этапа формулирования требований к нему. На
данном этапе, исходя из довольно смутных пожеланий заказчика,
необходимо получить документ, достаточно точно определяющий задачи
разработчиков ПС. Этот документ часто называют спецификацией
требований (или внешним описанием ПС).
Очень часто требования к ПС путают с требованиями к процессам его
разработки (к технологическим процессам). Последние включать во
внешнее описание не следует, если только они не связаны с оценкой
качества ПС. В случае необходимости требования к технологическим
процессам можно оформить в виде самостоятельного документа, который
будет использоваться при управлении (руководстве) разработкой ПС.
Спецификация требований
играет роль точной постановки задачи,
решение которой должно обеспечить разрабатываемое ПС. Более того,
она должна содержать всю информацию, которую необходимо знать
пользователю для применения ПС. Спецификация требований является
исходным документом для трёх параллельно протекающих процессов:
1. Разработки текстов (проектированию и кодированию) программ,
входящих в ПС.
2. Разработки документации по применению ПС.
3. Разработки существенной части комплекта тестов для проверки ПС.
Ошибки и неточности в спецификации трансформируются в ошибки
самой ПС и обходятся особенно дорого по двум причинам:
1. Они делаются на самом раннем этапе разработки ПС.
2. Они распространяются на три параллельных процесса.
Это требует особенно серьёзных мер по их предупреждению.
Формирование внешнего описания ПС представляет собой довольно
длительный и трудный итерационный процесс взаимодействия между
заказчиком и разработчиком. Трудности, возникающие в этом процессе,
связаны с тем, что пользователи часто плохо представляют, что им на
самом деле нужно: использование компьютера в “узких” местах
деятельности пользователей может на самом
деле
потребовать
принципиального изменения всей технологии этой деятельности (о чём
пользователи, как правило, и не догадываются). Кроме того, проблемы,
которые необходимо отразить в определении требований, могут не иметь
определённой формулировки, что приводит к постепенному изменению
понимания разработчиками этих проблем. В связи с этим определению
требований часто предшествует процесс системного анализа, в котором
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
121
выясняется, насколько целесообразно и реализуемо “заказываемое” ПС,
как повлияет такое ПС на деятельность пользователей
и какими
особенностями оно должно обладать. Для прояснения действительных
потребностей пользователей приходится разрабатывать упрощённую
версию требуемого ПС, называемую прототипом ПС. Анализ “пробного”
применения прототипа позволяет иногда существенно уточнить
требования к ПС.
В спецификации требований выделяют две самостоятельные части:
1. Функциональная спецификация.
2. Спецификация качества.
Функциональная спецификация описывает поведение программного
средства и определяет функции, которые должно выполнять ПС.
Спецификация качества формулирует требования к качеству ПС. Эти
требования должны быть сформулированы так, чтобы разработчику были
ясны цели, которые он должен стремиться достигнуть при разработке.
Спецификация качества, как правило, включает и требования к
технологическим процессам разработки.
Она, в отличие от
функциональной спецификации, реализуется неформально и играет роль
тех ориентиров, которые в значительной степени определяют выбор
подходящих альтернатив при реализации функций ПС, а также определяет
стиль всех документов и программ разрабатываемого ПС. Тем самым,
спецификация качества играет решающую роль в обеспечении требуемого
качества ПС.
Обычно разработка спецификации качества предшествует разработке
функциональной спецификации, так как некоторые требования к качеству
ПС могут предопределять включение в функциональную спецификацию
специальных функций, например, защиты от несанкционированного
доступа к некоторым объектам информационной среды.
Таким образом, структуру спецификации требований можно выразить
формулой:
Спецификация требований =
спецификация качества ПС + функциональная спецификация ПС
Таким образом, спецификация требований определяет, что должно делать
ПС и какими свойствами оно должно обладать, но не отвечает на вопрос,
как должно быть устроено это ПС, и как обеспечить требуемые свойства.
Спецификация требований достаточно точно и полно определяет задачи,
которые должны решить разработчики ПС, и должна быть понятна
заказчикам ПС.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
122
6.2 ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПРОГРАММНОМУ СРЕДСТВУ
Исходным документом для составления спецификации требований
является определение требований к ПС – задание, выражающее в
абстрактной форме потребности пользователя. Требования в общих чертах
определяют замысел ПС, характеризуют условия его использования.
Неправильное понимание потребностей пользователя трансформируются
в ошибки спецификации требований. Поэтому разработка ПС начинается
с создания документа, достаточно полно характеризующего потребности
пользователя и позволяющего разработчику адекватно воспринимать эти
потребности.
Определение требований
представляет собой смесь фрагментов на
естественном языке, различных таблиц и диаграмм. Такая смесь, должна
быть понятной
пользователю,
который не знает специальных
программистских обозначений. Обычно в определении требований не
содержится формализованных фрагментов. Формализация этих требований
составляет содержание дальнейшей работы коллектива разработчиков.
Неправильное понимание требований заказчиком, пользователями и
разработчиками связано обычно с различными взглядами на роль
требуемого ПС в среде его использования. Поэтому важной задачей при
создании определения требований является установление контекста
использования ПС, включающего связи между этим ПС, аппаратурой и
людьми. Лучше всего этот контекст в определении требований
представить в графической форме (в виде диаграмм) с добавлением
описаний сущностей используемых объектов (блоков ПС, аппаратуры,
персонала и т.п.) и характеристики связей между ними.
Известны три способа определения требований к ПС:
1. Управляемый пользователем.
2. Контролируемый пользователем.
3. Независимый от пользователя.
В управляемой пользователем разработке определения требований к ПС
определяются заказчиком, представляющим организацию пользователей.
Это происходит обычно в тех случаях, когда организация пользователей
(заказчик) заключает договор на разработку требуемого ПС с коллективом
разработчиков и требования к ПС являются частью этого договора. Роль
разработчика ПС в создании этих требований сводится, в основном, в
выяснении того, насколько понятны ему эти требования с
соответствующей критикой рассматриваемого документа. Это может
приводить к созданию нескольких редакций этого документа в процессе
заключения указанного договора.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
123
В контролируемой пользователем разработке требования
к
ПС
формулируются разработчиком при участии представителя пользователей.
Роль пользователя в этом случае сводится к информированию
разработчика о своих потребностях в ПС и контролю за тем, чтобы
формулируемые требования действительно выражали его потребности в
ПС.
В конечном счете, разработанные требования,
как правило,
утверждаются представителем пользователя.
В независимой от пользователя разработке требования к ПС определяются
без какого-либо участия пользователя (на полную ответственность
разработчика). Это происходит обычно тогда, когда разработчик решает
создать ПС широкого применения в расчёте на то, что разработанное им
ПС найдет спрос на рынке программных средств.
С точки зрения обеспечения надёжности ПС наиболее предпочтительным
является контролируемая пользователем разработка.
Следует помнить, что именно на этапе определения требований лежит
ключ к успеху всего проекта!
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
124
6.3 СПЕЦИФИКАЦИЯ КАЧЕСТВА
Разработка спецификации качества сводится к построению своеобразной
модели качества разрабатываемой ПС. В этой модели должен быть
перечень всех тех достаточно элементарных свойств, которые требуется
обеспечить в разрабатываемом ПС, и которые в совокупности образуют
приемлемое для пользователя качество ПС. При этом каждое из этих
свойств должно быть в достаточной степени конкретизировано с учётом
возможности оценки его наличия у разработанного ПС.
Для конкретизации качества ПС по каждому из критериев используется
стандартизованный набор достаточно простых свойств, которые называют
примитивами качества ПС. Некоторые из примитивов
могут
использоваться по нескольким критериям.
В таблице приводится
зависимость критериев качества от примитивов качества ПС.
Критерии качества
Функциональность
Надёжность
Применимость
Эффективность
Сопровождаемость
Мобильность
Примитивы качества
Завершённость
Завершённость Точность
Автономность
Устойчивость
Защищённость
Документированность по применению
Информативность документации
Коммуникабельность
Устойчивость
Защищённость
ВременнАя эффективность
Эффективность по памяти
Эффективность по устройствам
Изучаемость1
Документированность по разработке
Информативность документации
Понятность
Структурированность
Удобочитаемость
Модифицируемость2
Расширяемость
Структурированность
Модульность
Независимость от устройств
Автономность
Структурированность
Модульность
Изучаемость – это характеристики ПС, которые позволяют минимизировать усилия по изучению и
пониманию программ и документации ПС.
2
Модифицируемость – это характеристики ПС, которые упрощают внесение в него необходимых
изменений и доработок.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
1
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
125
Ниже даются определения используемых примитивов качества ПС.
Завершённость – свойство, характеризующее степень обладания ПС всеми
необходимыми частями и чертами, требующимися для выполнения своих
явных и неявных функций.
Точность – мера, характеризующая приемлемость величины погрешности
в выдаваемых программами ПС результатах с точки зрения
предполагаемого их использования.
Автономность – свойство, характеризующее способность ПС выполнять
предписанные функции без помощи других компонент программного
обеспечения.
Устойчивость – свойство, характеризующее способность ПС продолжать
корректное функционирование, несмотря на задание неправильных
(ошибочных) входных данных.
Защищённость – свойство,
характеризующее
способность
ПС
противостоять преднамеренным или нечаянным деструктивным
(разрушающим) действиям пользователя.
Документированность по применению – свойство, характеризующее
наличие, полноту, понятность, доступность и наглядность учебной,
инструктивной и справочной документации, необходимой для применения
ПС.
Информативность – свойство, характеризующее наличие в составе ПС
информации, необходимой и достаточной для понимания назначения ПС,
принятых предположений, существующих ограничений, входных данных
и результатов работы отдельных компонент, а также текущего состояния
программ в процессе их функционирования.
Коммуникабельность – свойство, характеризующее степень, в которой
ПС облегчает задание или описание входных данных, а также
обеспечивает выдачу полезных сведений в форме и с содержанием,
простыми для понимания.
ВременнАя эффективность – мера, характеризующая способность ПС
выполнять возложенные на него функции за определённый отрезок
времени.
Эффективность по памяти – мера, характеризующая способность ПС
выполнять возложенные на него функции при определённых
ограничениях на используемую память.
Эффективность по устройствам – мера, характеризующая экономичность
использования устройств для решения поставленной задачи.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
126
Документированность по разработке – свойство,
характеризующее
наличие и полноту документации, отражающей требования к ПС и
результаты различных этапов разработки данной ПС, а также обоснование
принятых проектных решений.
Понятность – свойство, характеризующее степень, в которой ПС позволяет
изучающему его лицу понять его назначение, сделанные допущения и
ограничения, входные данные и результаты работы его программ, тексты
этих программ и состояние их реализации. Этот примитив качества
синтезирован из таких примитивов ISO, как согласованность, самодокументированность, чёткость и, собственно, понятность.
Структурированность – свойство, характеризующее программы ПС с
точки зрения организации взаимосвязанных их частей в единое целое
определённым образом (например, в соответствии с принципами объектноориентированного программирования).
Удобочитаемость – свойство, характеризующее лёгкость восприятия
текста программ ПС (отступы, фрагментация, комментарии).
Расширяемость – свойство,
характеризующее способность ПС к
использованию бОльшего объёма памяти для хранения данных или
расширению функциональных возможностей отдельных компонент.
Модульность – свойство,
характеризующее ПС с точки зрения
организации его программ из таких дискретных компонент, что изменение
одной из них оказывает минимальное воздействие на другие компоненты.
Независимость от устройств – свойство, характеризующее способность ПС
работать на разнообразном аппаратном обеспечении (различных типах,
марках, моделях компьютеров).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
127
6.4 ФУНУЦИОНАЛЬНАЯ СПЕЦИФИКАЦИЯ
С учётом назначения функциональной спецификации ПС и тяжёлых
последствий неточностей и ошибок в этом документе, функциональная
спецификация должна быть математически точной. Это не означает, что
она должна быть формализована настолько, что по ней можно было бы
автоматически генерировать программы, решающие поставленную задачу.
Это означает лишь то, что она должна базироваться на понятиях,
построенных как математические объекты, и утверждениях, однозначно
понимаемых разработчиками ПС. Достаточно часто функциональная
спецификация формулируется на естественном языке. Тем не менее,
использование математических методов и формализованных языков при
разработке функциональной спецификации весьма желательно.
Функциональная спецификация состоит из трех частей:
1. Описание внешней информационной среды, к которой должны
применяться программы разрабатываемой ПС.
2. Определение функций ПС, определённых на множестве состояний
этой информационной среды (такие функции называют внешними
функциями ПС).
3. Описание нежелательных (исключительных) ситуаций, которые могут
возникнуть при выполнении программ ПС, и реакций на эти
ситуации, которые должны обеспечить соответствующие программы.
В первой части должны быть определены на концептуальном уровне все
используемые каналы ввода и вывода и все информационные объекты, к
которым будет применяться разрабатываемое ПС, а также существенные
связи между этими информационными объектами. Примером описания
информационной среды может быть концептуальная схема базы данных
или описание сети датчиков и приборов, которой должна управлять
разрабатываемая ПС.
Во второй части вводятся обозначения всех определяемых функций,
специфицируются все входные данные и результаты выполнения каждой
определяемой функции, включая указание их типов и заданий всех
соотношений (или ограничений), которым должны удовлетворять эти
данные и результаты. И, наконец, определяется семантика каждой из этих
функций, что является наиболее трудной задачей функциональной
спецификации ПС. Обычно эта семантика описывается неформально на
естественном языке – примерно так, как это делается при описании
семантики многих языков программирования. Эта задача может быть в
ряде случаев существенно облегчена при достаточно чётком описании
внешней информационной среды, если внешние функции задают какиелибо манипуляции с её объектами.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
128
В третьей части должны быть перечислены все существенные с точки
зрения внешнего наблюдателя (пользователя) случаи, когда ПС не сможет
нормально выполнить ту или иную свою функцию. Например,
- при обнаружении ошибки во время взаимодействия с пользователем;
- при попытке применить какую-либо функцию к данным, не
удовлетворяющим соотношениям, указанным в её спецификации;
- при получении результата, нарушающего заданное ограничение.
Для каждого такого случая должна быть определена (описана) реакция ПС.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
129
6.5 МЕТОДЫ КОНТРОЛЯ СПЕЦИФИКАЦИИ ТРЕБОВАНИЙ
Разработка внешнего описания обязательно должна завершаться
проведением тщательного и разнообразного контроля правильности
внешнего описания. Целью этого процесса является найти как можно
больше ошибок, сделанных на этом этапе. Учитывая, что результатом
этапа является, как правило, ещё неформализованный текст, то здесь на
первый план выступают психологические факторы контроля. Можно
выделить следующие методы контроля, применяемые на этом этапе:
-
статический просмотр,
смежный контроль,
пользовательский контроль,
ручная имитация.
Первый метод предполагает внимательное прочтение текста внешнего
описания
разработчиком с целью проверка его полноты и
непротиворечивости, а также выявления других неточностей и ошибок.
Смежный контроль спецификации качества сверху – это её проверка со
стороны разработчика требований к ПС,
а смежный контроль
функциональной спецификации – это её проверка разработчиками
требований к ПС и спецификации качества. Смежный контроль
внешнего описания снизу – это его изучение и проверка разработчиками
архитектуры ПС и текстов программ, а также разработчиками
документации по применению и разработчиками комплекта тестов.
Пользовательский контроль
внешнего описания выражает участие
пользователя (заказчика) в принятии решений при разработке внешнего
описания и его контроле. Если разработка требований к ПС велась под
управлением пользователя, то пользовательский контроль внешнего
описания, по существу, означает его смежный контроль сверху. Однако,
если представителю пользователя оказывается трудно самостоятельно
разобраться во внешнем описании, создается специальная
группа
разработчиков, выполняющая роль пользователя (и взаимодействующая
с ним) для проведения такого контроля.
Ручная имитация выражает своеобразный динамический контроль
внешнего описания, точнее говоря, функциональной спецификации ПС.
Для этого необходимо подготовить исходные данные (тесты) и на
основании функциональной спецификации осуществить имитацию
поведения (работы) разрабатываемого ПС. При этом эту имитацию
осуществляет специально назначенный разработчик, выполняющий, по
существу, роль будущих программ ПС. Разновидностью такого контроля
является имитация за терминалом. В этом случае данные вводятся в
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
130
компьютер человеком, играющим роль пользователя, и передаются с
помощью несложной программы на другой терминал, за которым сидит
разработчик, выполняющий роль программ ПС. Полученные результаты
передаются через компьютер на первый терминал.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
131
6.6 АНАЛИЗ
Анализ направлен на описание задачи. Описание должно быть полным,
непротиворечивым, пригодным для чтения и обозрения всеми
заинтересованными сторонами, реально проверяемым.
Эта стадия требует очень тесного контакта разработчиков с
пользователями, так как возможные неточности и ошибки, вероятнее
всего, приведут к краху проекта. Пользователи могут и должны объяснить
ожидаемые действия системы для конкретных пользователей в ответ на
конкретные события.
Анализ объясняет, что делает система, а не то, как она это делает. Целью
анализа является формализация требований – преобразование общих
знаний о требованиях к системе в точные (по возможности) определения.
С точки зрения объектно-ориентированного подхода цель анализа –
представление модели поведения системы. В анализе ищется модель
реального мира путём выявления объектов и их взаимодействия.
Выявленные объекты формируют словарь предметной области.
При использовании UML строятся диаграммы вариантов использования,
диаграммы взаимодействия для объектов и сообщений между ними,
описываются потоки событий.
На стадии анализа по возможности точно определяются:
1. Функции системы и их распределение между аппаратурой и
программным обеспечением.
2. Пользовательский интерфейс и распределение функций между
человеком и системой.
3. Описание кандидатов в программные объекты системы (Глоссарий).
4. Описание кандидатов в информационные объекты системы
(Глоссарий).
5. Требования к базе данных (если предполагается её использование).
6. Необходимые аппаратные ресурсы.
7. Результатом анализа являются технические задания (функциональные
спецификации) и документирование работ по проекту.
С этапом анализа тесно связан основной вид деятельности – анализ
предметной области. Прежде чем взяться за создание нового ПС, обычно
изучают уже существующие. Вначале такой анализ ведёт к расширению
требований к системе и её функциональных характеристик. Хочется
реализовать всё лучшее, что есть у конкурентов, воплотить сотни
замечательных идей. Но тут наступает самое время вспомнить о здравом
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
132
смысле. Результатом сравнительного анализа может быть один из двух
выводов:
1. Новый продукт не надо проектировать, а следует повторно
использовать или адаптировать существующий проект.
2. Точно понять, чем новый продукт будет отличаться от существующих
систем, и насколько он будет конкурентоспособен.
Степень совершенства анализа будет измеряться его полнотой и
простотой. Хороший анализ выявит все первичные сценарии и, как
правило, важнейшие вторичные сценарии поведения системы. Это
помогает всему коллективу разработчиков единым взглядом увидеть
будущую систему, а также найти шаблоны поведения классов в результате
выявления общностей в различных сценариях.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
133
6.7 ПРОЕКТИРОВАНИЕ
Процесс проектирования не должен предшествовать анализу, но должен
начинаться сразу же после появления некоторой приемлемой модели
поведения системы.
Проектирование объясняет, как ПС будет удовлетворять предъявленным к
нему требованиям.
Цели проектирования:
1. Создание внутренней архитектуры для реализации системы.
2. Выработка единых приёмов, которыми должны пользоваться различные
элементы системы.
При создании программной
факторы:
1.
2.
3.
4.
5.
6.
архитектуры
учитываются
следующие
Функциональные возможности системы.
Эффективность и производительность системы.
Повторное использование.
Понимаемость.
Экономические и технологические ограничения.
Эстетическое восприятие.
При объектно-ориентированном подходе с использованием UML
архитектура описывается в логическом представлении (Logical View),
представлении
компонентов (Component View) и развёртывания
(Deployment View) путём построения следующих диаграмм:
пакетов (чтобы показать, как классы группируются в категории);
классов (чтобы показать статику системы);
взаимодействия (чтобы показать динамические аспекты системы);
компонентов (чтобы показать, как представлены логические абстракции
системы в реальных программных компонентах);
- развёртывания (чтобы отобразить, как взаимосвязаны программные и
аппаратные компоненты системы).
-
Выработка общих приёмов – это документирование механизмов, которые
проявляются во всей системе.
Обычно эти механизмы повторно используются в различных проектах.
Например, управляющие классы; классы обнаружения и обработки ошибок
(их можно определить, исследуя контракты классов предметной области),
управление памятью, хранение и представление данных.
В проектировании различают: концептуальное, логическое и физическое
проектирование ПС.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
134
6.7.1 Концептуальное проектирование
Концепция – это ведущая идея, конструктивный принцип ПС.
Концептуальное
проектирование
фактически
определения архитектуры будущей системы.
является
началом
Концептуальный проект определяет подход (или альтернативные подходы)
к построению системы.
Результатом концептуального проектирования является:
1. Уточнение архитектурного стиля (одно-, двух- или трёхзвенная
архитектура).
2. Выделение относительно обособленных подсистем (групп функций
системы) без детализации их функциональности.
3. Уточнение
возможных
подходов
к
созданию
(объектноориентированный подход, структурный подход).
4. Принятие решений об использовании сетевых технологий и баз данных.
5. Определение критериев эффективности системы (использование
ресурсов, временнЫе характеристики, быстродействие и т.п. производительность).
6. Принятие решений о целесообразности применения новых технологий
разработки и инструментальных средств автоматизации разработки ПС.
Концептуальное проектирование полезно завершать созданием прототипа,
который
содержит
пользовательский
интерфейс
и
отражает
функциональные возможности системы без их реализации. Прототип
полезен по ряду причин:
1. Он обеспечивает инструмент связи между всеми участниками
проектной группы.
2. Он помогает определить поток процессов, происходящих в системе.
3. Он привлекает пользователей к участию в разработке проекта.
При выработке концепции важно создать структуру приложения,
подобрать подходящую команду для разработки, получить прототип и
оценить его, принять решение и приступить к созданию конечного
продукта. Прототип зачастую пишется на одном языке, а конечный
продукт создаётся на другом. Концептуальный прототип можно положить
в копилку идей, а лучше всего – выбросить (не выбрасывайте
концептуальный проект!).
6.7.2 Логическое проектирование
Логическое проектирование уточняет требования к системе и может
добавить новые, которые не были выявлены ранее. При необходимости
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
135
корректируется концептуальная модель. Важно применять понятия
предметной области, для которой создаётся система, а также конкретно
определить логику решения поставленных задач. При анализе и создании
логического проекта все участники больше сосредоточены на деталях
системы и её особенностях. Каждая задача рассматривается подробно.
Если требуется, для каждой элементарной функции создаётся прототип:
экран, диалог, отчёт (для устранения неясности и неоднозначности).
Устанавливаются и/или уточняются требования к данным. Всё
документируется.
Основной целью логического проектирования является создание
программных
абстракций
(предметной
области,
управления,
вспомогательных служб), а также создание структуры данных.
Логическая модель состоит из
подмоделей – данных и объектов:
двух
относительно
независимых
1. Логическая модель данных (logical data model) – представляет
атрибуты объектов, которыми система управляет, и описывает правила
поддержки (хранения) этих объектов.
2. Логическая модель объектов (logical object model) – представляет
правила, которые работают на объектах данных; данная модель
отражает то, как эти объекты сгруппированы в классы и как различные
объекты взаимодействуют между собой, чтобы обеспечить
функциональность системы.
Логическое проектирование заключается в принятии решений
относительно организации ПС, структуры данных и внешнего дизайна.
Решения относительно организации системы
1. Каковы составляющие систему структурные элементы и их
интерфейсы.
2. Каково поведение этих элементов во взаимосвязи.
3. Как выбранные структурные и поведенческие элементы объединяются в
подсистемы.
4. Каков архитектурный стиль организации элементов (например, User
Service, Business Service, Data Service).
Решения относительно структуры данных
1. Каков способ объединения, взаимосвязи и взаиморасположения
элементов данных (простые переменные различного типа или
огромные массивы, которые организованы в базе данных).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
136
2. Каков доступ к элементам данных (общедоступные или же их чтение и
изменение может строго регулироваться; доступ просто по имени или
через специально написанные функции).
3. Каков способ хранения данных (оперативная память или постоянный
носитель).
Решения относительно внешнего дизайна
Каков эстетический облик программного продукта.
Результатом объектно-ориентированного подхода будут модели отдельных
подсистем, коопераций и компонент ПС, включая динамические модели.
Логический проект документируется и утверждается, чтобы гарантировать,
что зафиксированные в концептуальной модели требования полностью и
правильно отражены в логической модели.
Прототип после логического проектирования содержит вариант
пользовательского интерфейса и отражает поведение будущего ПС, но он
по-прежнему не выполняет никакой реальной работы.
6.7.3 Физическое проектирование
Физическое
проектирование
проектирования.
является
завершающей
Физическая модель системы определяет конкретную
аппаратную платформу, на которой реализуется система.
стадией
программно-
Физическое проектирование отвечает на следующие вопросы:
1. Какие программные средства будут использоваться, чтобы можно было
создавать, отлаживать, интегрировать и расширять систему.
2. Каковы компоненты (исполняемые файлы, динамические библиотеки,
справочные системы, html-страницы) ПС.
3. Как будут использоваться физические ресурсы аппаратуры, базы
данных, операционной системы и услуг для размещения компонент.
4. Использование каких ресурсов является более эффективным (например,
локальная машина или Internet).
5. Как могут быть реализованы требования к внешним сбоям (например, к
отключению сетевых серверов или ненадёжное подключение к
Internet).
Физическое проектирование направлено на формирование реальной
программной архитектуры и отражает конфигурацию ПС.
Выявленные на данном этапе компоненты системы дают возможность
составить план работ для всего коллектива участников создания системы с
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
137
учётом приоритетов этих компонентов. Приоритетность, как правило,
выясняется вместе с экспертами в предметной области.
Физическая архитектура должна быть способна поддерживать
конфигурацию пользователя, обеспечивать доступ к функциональным
возможностям системы, обеспечивать защиту информации и безопасность
работы с ней, а также предоставлять возможность лёгкой модификации
системы. Возможность модификации напрямую зависит от полученной в
результате проектирования архитектуры, которая должна быть простой и
хорошо документированной.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
138
6.8 РЕАЛИЗАЦИЯ (КОДИРОВАНИЕ) И ЭВОЛЮЦИЯ
На данном этапе разработанные ранее логические и физические модели
системы реализуются в виде реальных программных объектов, объектов
пользовательского интерфейса, баз
данных и других программных
объектов.
Цель реализации и эволюции – создание компонентов и итеративное
совершенствование реализации для получения готового ПС.
Этот этап, как правило, включает следующее:
1. Создание исходного кода с постоянным тестированием (самим
разработчиком) и обязательным документированием. Отладка в
реальности гораздо длиннее, чем кодирование.
2. Уточнение технического задания разработчиком (он вправе внести
изменения).
3. Проведение экспериментов и уточнение архитектуры системы (но не
изменение!).
4. Художественное конструирование пользовательского интерфейса (если
таковой необходим) дизайнером: компоновка объектов интерфейса,
экранных форм, панелей инструментов, пиктограмм и т.п.
5. Тестирование программных компонентов аналитиком и руководителем
проекта с целью проверки их работоспособности и соответствия
техническим заданиям. После исправления разработчиком ошибок за
приемлемое время проводится повторное тестирование.
6. Автоматизация процесса установки системы – создание разработчиком
инсталляционной программы с помощью специальных средств
(например, InstallShield).
7. Документирование исходного кода и создание всевозможных
руководств (программиста, администратора) и инструкций (по
установке системы, пользователя).
На стадии реализации наконец-то станет ясно, насколько эффективны
проведённые анализ и проектирование. С первой попытки вряд ли
получится полная функциональная система. Само собой разумеется, чем
раньше будет получена реализованная версия системы, тем большее
количество времени останется, чтобы установить те раздражающие
проблемы, которые неожиданно возникают.
Процесс реализации неразрывно связан с эволюцией, которая и является
процессом разработки программы.
В процессе эволюции создаётся серия исполнимых релизов (версий
программной системы).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
139
Эволюция предполагает возможность экспериментов для исследования
альтернативных подходов. Для проекта, требующего 12-18 месяцев на
разработку от начала до конца, создаётся 6-9 релизов, то есть один релиз
каждые два месяца.
Эволюционный
процесс
сосредоточен,
прежде
всего,
на
функциональности, а также на локальной эффективности: требования ко
времени, памяти и т.п.
При объектно-ориентрованном подходе при эволюции могут возникнуть
следующие изменения:
1. Добавление нового класса или новой ассоциации между классами. При
добавлении нового класса нужно посмотреть, куда он попадёт в
существующей структуре (пакет, компонент). При добавлении новой
ассоциации убедиться, что она удовлетворяет какому-либо шаблону
взаимодействия (для этого может понадобиться дополнительный анализ
предметной области).
2. Изменение реализации класса. При стабильном интерфейсе можно
выполнить реализацию методов любым способом. БОльше времени
придётся потратить, если операция не была инкапсулирована в классе.
3. Изменение представления класса. Для языка программирования C++ –
это защищённые и закрытые члены класса. Представление класса может
измениться при желании получения более эффективных с точки зрения
скорости и памяти экземпляров класса. Эти изменения могут привести к
значительным затратам:
- изменение суперкласса потребует корректировки подклассов;
- изменение поставщика потребует корректировки всех клиентов из-за
изменения логики поведения поставщика;
- клиенты сами могут быть поставщиками, следовательно, будет
необходимо проверить всю цепочку классов.
4. Изменение иерархии классов. Эти изменения происходят довольно
часто при создании иерархии классов на ранних этапах разработки,
потому что позволяют получить более лаконичную программу. Однако,
следует вовремя остановиться на каком-то уровне стабилизации, иначе
потребуются значительные затраты (см. п. 3). Затраты связаны, как
правило, с изменениями наследственных связей:
- добавление новых абстракций;
- перемещение общих обязанностей в классы верхнего уровня
иерархии.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
140
5. Изменение интерфейса класса. Это необходимо, так как с первого раза
не бывает “правильного” определения класса. Интерфейс изменяют для
того, чтобы:
-
добавить новый атрибут;
добавить новую операцию;
удалить операцию (довольно редко);
переопределить метод.
Все перечисленные выше изменения приведут к перекомпиляции
программы. Для маленьких систем это не проблема. Для больших систем
перекомпиляция может занять значительное количество времени.
Например, программа в сотни тысяч строк может компилироваться почти
половину суток машинного времени. Но и это не так страшно, как
страшны изменения в архитектуре программной системы, которые могут
погубить весь проект.
Есть тесная взаимосвязь между изменениями классов и архитектурой. Если
вносится слишком много изменений в классах и в их иерархии – это сигнал
к тому, что у системы неудачная архитектура. Следовательно, перед
следующим релизом необходимо уточнить программную архитектуру,
чтобы избежать ошибок.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
141
6.9 СОПРОВОЖДЕНИЕ
Сопровождение – это деятельность по управлению эволюцией системы в
ходе её эксплуатации.
Этап эксплуатации и сопровождения предусматривает следующие виды
деятельности:
1. Контроль функционирования. В ходе эксплуатации могут возникать
ошибки, связанные с работой системы, поэтому необходим постоянный
контроль с целью составления списка системных проблем и
упорядочивания их по приоритетам.
2. Внесение требуемых изменений. В соответствии со списком изменений
разработка эволюционного релиза системы.
3. Модернизация функций.
4. Расширение возможностей системы.
При сопровождении постоянно вносятся усовершенствования в
существующую систему и устранение ошибок до тех пор, пока её
архитектура выдерживает изменения, или пока разработка новой системы
не станет дешевле, чем поддержание существующей в рабочем состоянии.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
142
6.10 ТЕСТИРОВАНИЕ
При планировании работ по тестированию ПС из огромного количества
возможных тестов выбирается малая, но реально выполнимая часть. И как
бы тщательно ни выполнились эти отобранные тесты, все до единой
ошибки всё равно не найти. Даже если в программе действительно не
останется ошибок, об этом никогда не узнать: ведь этого нельзя ни
доказать, ни проверить.
Что означает полностью протестировать программу? Это значит, что до
окончания тестирования в ней не должно остаться ни одной не выявленной
ошибки. Будут ли ошибки исправлены – это уже другой вопрос, но все
имеющиеся проблемы должны быть известны и правильно поняты.
Существует три причины, по которым полное тестирование не может быть
выполнено никогда:
1. Слишком большое количество всех возможных комбинаций входных
данных. Следует проверить:
- Все допустимые входные значения. Например, для сложения двух
целых двухзначных чисел существует 39 601 различных пар чисел, а
для четырёхзначных чисел это количество – 399 960 001.
- Все недопустимые входные значения. Например, как будет
реагировать программа на нажатие пользователем на специальные
символы, управляющие клавиши или их комбинации, то есть, как
программа отвечает на любые действия пользователя, чтобы он ни
ввёл.
- Все способы редактирования входных данных. Например, если
программа позволяет редактировать вводимые значения, нужно
убедиться, что она это делает правильно, то есть, она может
изменять любой введённый символ.
- Реакцию программы на ввод в каждый момент её работы. Например,
попробовать ввести данные, когда программа их совсем не ждёт,
пока она обрабатывает предыдущие данные, выводит результат или
сообщение. ВременнАя уязвимость – это очень серьёзный вопрос.
Для различных комбинаций входных данных все тесты
физически не могут быть выполнены. Необходимо проверить
все четыре типа ввода (допустимый, недопустимый, с
редактированием и несвоевременный), тщательно подобрав
тестируемые данные. Если не выполнить хотя бы один из
перечисленных типов тестов, тестирование будет неполным.
2. Слишком большое количество всех возможных последовательностей
выполнения кода программы. При каждом сеансе работы программы
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
143
можно отследить последовательность выполнения её операторов от
запуска до завершения. Последовательности могут отличаться
фрагментами кода или их порядком. В 1979 году Майерс описал
простую программу, в которой был цикл и несколько операторов if.
Путей у этой программы 100 триллионов. Для проверки понадобится
миллион лет. Огромное количество путей существует в любой, самой
простенькой программе, а сколько их может быть в программной
системе из 400 тыс. строк? Следовательно, любой пропущенный путь
останется источником проблем.
Физически невозможно проверить все пути выполнения
программы.
Для
серьёзного
тестирования
необходимо
проанализировать листинг программы (чтобы получить реальное
представление о ходе её работы), использовать эвристические
стратегии, которые позволяют не наверняка, но с наибольшей
вероятностью локализовать и выявить существенные ошибки
программы (Эвристика – теоретически не обоснованное правило,
но позволяющее сократить количество переборов в пространстве
поиска).
3. Пользовательский
интерфейс
(включающий
все
возможные
комбинации действий пользователя и его перемещений по программе)
сложен для полного тестирования. Программа соответствует
спецификации, если она в точности делает то, что указано в
спецификации. Но спецификация, как дело рук человеческих, может
содержать ошибки. Поэтому, можно утверждать, что созданная по
неверной спецификации программа неверна. Как и любые другие
проблемы, все ошибки пользовательского интерфейса выявить
невозможно. Основой работы компьютера является логика.
Следовательно, сразу же встают проблемы времени и количества
всевозможных условий.
Физически невозможно проверить все возможные действия
пользователя. Для тестирования пользовательского интерфейса
необходимо как можно раньше уточнить его спецификации,
проверить
его
понятность
и
удобство,
проверить
соответствующее раскрытие возможностей.
Всех ошибок всё равно не найти. Для чего же тестируют программы?
Программное средство тестируют для того, чтобы найти в нём ошибки.
Ошибки ищут для того, чтобы их исправить.
Если тест позволил выявить проблему, значит, он успешный. Тест, не
выявивший проблем, – это потеря времени.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
144
Майерс приводит интереснейшую аналогию. Вы приходите к врачу, и он
проводит ряд анализов. Однако врач ничего не находит и утверждает, что
Вы здоровы. Если Вы действительно больны, врач некомпетентен, и он
неважный диагност. При тестировании диагност – это Вы, а программа
(абсолютно наверняка) – больной пациент. Значит, обязательно надо
найти, что с ней не так!
Главные ответы тестирования:
1. Показать пригодность системы для пользователя.
2. Показать полноту документации к системе.
3. Показать точность полученных результатов.
Тестирование проводится на всех этапах жизненного цикла. Чем раньше
будут выявлены проблемы, тем выше вероятность создания качественного
программного обеспечения в установленные сроки. Результаты
тестирования каждого из этапов могут привести как к уточнению, так и к
значительному пересмотру существующих планов.
6.10.1 Определение требований
- адекватность (действительно такой продукт нужно создавать);
- полнота (не упущены жизненно-необходимые функции, или наоборот
можно ослабить какие-либо требования);
- совместимость (логическая несовместимость требований означает
противоречивость, психологическая – концептуальные разногласия);
- выполнимость (может быть, нужно более быстрое аппаратное
обеспечение, больший объём памяти, более высокая пропускная
способность, большее разрешение и т.п.);
- правильная расстановка приоритетов (абсолютная безупречность,
требовательность к ресурсам, готовность конкурировать с другими
продуктами).
6.10.2 Анализ
- соответствие проекта требованиям (формализация требований);
- соответствие спецификаций требованиям (по функциям и по данным);
- простота, гибкость и функциональность пользовательского интерфейса.
6.10.3 Проектирование
- добротность проекта (будет ли на его основе создан эффективный,
компактный, лёгкий в сопровождении программный продукт);
- полнота (описаны ли все взаимосвязи между модулями и данными);
- реалистичность (сможет ли продукт работать быстро, достаточны ли
аппаратные и программные ресурсы, удачно ли выбраны
инструментальные средства разработчиков);
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
145
- добротность подсистемы обработки ошибок (все возможные условия
возникновения ошибок должны быть продуманы и описаны в проекте).
6.10.4 Реализация
Технология тестирования этапа кодирования называется тестированием
“стеклянного ящика” – glass box. Различают структурное и
функциональное тестирование:
1. Структурное тестирование (тестирование “белого ящика” – white box)
предполагает знание исходного кода и полный доступ к нему. Как
правило, тестирует программист-кодировщик, а само тестирование
является неотъемлемой частью процесса программирования. При этом
учитываются следующие аспекты:
- направленность тестирования (тестирование по компонентам);
- полный охват кода (когда и какие фрагменты кода работают в
данный момент времени);
- управление потоком (какая функция и когда должна выполняться в
программе, какова последовательность выполнения функций);
- отслеживание целостности данных (какая часть программы меняет
данные и каким образом);
- внутренние граничные точки (в исходном коде есть точки, скрытые
от взгляда извне, например, для выполнения определённого действия
может быть использовано много разных способов, о конкретном
способе знает только программист);
- тестирование, определяемое выбранным алгоритмом (например,
алгоритм сортировки данных, о котором нужно знать до начала
тестирования).
2. Функциональное тестирование (тестирование “чёрного ящика” – black
box) предполагает, что внутренняя структура программы неизвестна.
Тестер ищет интересные с его точки зрения входные данные и условия,
которые могут привести к нестандартным результатам. Программа
исследуется извне, то есть с точки зрения пользователя. Именно этому
типу тестирования посвящается большая часть времени. Оно позволяет
выявить проблемы и критические точки в программной системе,
которые были упущены программистом.
6.10.5 Тестирование
Данный этап жизненного цикла программного обеспечения связан с
проверкой качества всего проекта в комплексе в соответствии с теми
критериями, которые были определены на предыдущих этапах. Для этого
существует специальный тип тестирования, который принято называть
регрессионным тестированием.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
146
У этого термина два значения, объединённых общей идеей повторного
использования разработанных тестов:
1. Тест обнаружил ошибку, и программист её исправил. Снова проводится
тот же тест, чтобы убедиться, что ошибки больше нет. Это и есть
регрессионное тестирование.
2. После исправления ошибки проводится стандартная серия тестов для
проверки целостности всей программы. Цель тестирования уже другая:
убедиться, что, исправляя одну часть программы, программист не
испортил другую.
В первом значении этого термина регрессионное
используется на этапе реализации проекта.
тестирование
6.10.6 Опытная эксплуатация
Программа достаточно стабильна, и документация в порядке. Время для
обратной связи с пользователем – это бета-тестирование. На данном
этапе жизненного цикла с программой работают потенциальные
пользователи. Как правило, на бета-тестирование уходит не менее трёх
недель.
6.10.7 Окончательная приёмка и сертификация
Если программная система разрабатывалась по договору (контракту), для
приёмки клиенты проводят собственные тесты. Для небольших систем
тестирование может быть неформальным. Для больших – следует
убедиться, что система абсолютно безупречно прошла серию приёмочных
тестов, то есть провести формальное тестирование.
Сертификация всегда проводится сторонней фирмой. Сертификационное
тестирование может быть как коротким и поверхностным, так и более
тщательным. При этом проверяется соответствие программы требованиям
и соответствие процесса разработки ПС стандартам. Ниже перечислены
основные международные и основные отечественные стандарты.
Международные стандарты – ISO 12207, ISO 9001.
Отечественные стандарты:
ГОСТ 19.201-78. Техническое задание.
ГОСТ 19.202-78. Спецификация.
ГОСТ 19.301-79. Программа и методика испытаний.
ГОСТ 19.503-79. Руководство системного программиста.
ГОСТ 19.504-79. Руководство программиста.
ГОСТ 28195-89. Оценка качества ПС. Общие положения.
РД 50-34.698-90 – Методические указания. Информационная технология.
Автоматизированные системы. Требования к содержанию документов.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
147
При сертификации приёмочное тестирование может не проводиться.
6.10.8 Сопровождение
На этапе сопровождения ПС в работе тестера не будет ничего особенного.
Необходимо делать то же самое, что уже делалось во время
функционального и системного тестирования. Если есть серия
регрессионных тестов, которые к тому же частично автоматизированы, то
останется только повторять их после каждого изменения программы.
Если этап сопровождения предполагает перенос системы с одной
аппаратной или программной платформы на другую, то проводится
адаптационное тестирование.
Адаптационное тестирование включает в себя:
- общее функционирование (регрессионные тесты);
- клавиатура (если она специфическая, то в работе с ней могут быть
отклонения от стандарта);
- терминал (отображение графики, проблемы со шрифтами, цветом);
- номер версии и идентификация системы (номер версии ПС везде
изменён; правильность идентификации аппаратуры и операционной
системы);
- диски (правильность работы с файлами, так как ёмкость и формат
дисков могут отличаться);
- обработка ошибок операционной системой (как ПС защищает себя от
ошибок и странностей операционной системы);
- установка (инсталляционная программа должна правильно определять
аппаратную и программную конфигурацию системы, тестировать
инсталляционную программу следует особенно тщательно; следует
установить продукт в системах с различной конфигурацией, в сети,
поверх предыдущей версии);
- совместимость (если на исходном компьютере продукт совместим с
программой Икс, то при переносе на новый компьютер он также должен
быть совместим с ней);
- интерфейс (в различных графических средах (Windows, Mac, Motif)
действуют различные соглашения о пользовательском интерфейсе;
перейдя в новую среду, ПС должно выглядеть естественно);
- другие изменения (спросить у программиста, что он изменил в
программе для адаптации, и тщательно протестировать все изменения).
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
148
7 ОРГАНИЗАЦИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Серьёзные программные продукты редко разрабатываются одиночками.
Обычно этим занимаются группы людей, иногда довольно
многочисленные.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
149
7.1 ГРУППА ПРОЕКТА И РОЛИ УЧАСТНИКОВ ГРУППЫ
Связанные с жизненным циклом процессы разнообразны по своей сути, не
говоря о том, что сами проекты очень трудны, включают много отдельных
требующих программного решения задач и предполагают наличие
специальных знаний. Можно называть сообщества людей, работающих над
проектом, по-разному: группа, подразделение, бригада или команда, но
миссия одна – создание качественного продукта в условиях ограничений
на время и ресурсы.
Проектная группа (development team) – сообщество работающих над
проектом людей, объединённых с целью создания качественного
программного продукта в ограниченные сроки в рамках отведённого
бюджета.
В такой группе у каждого сотрудника своя роль. Существует стандартный
набор функций, выполняемых членами проектной группы. Для простоты
предполагается, что каждая роль принадлежит отдельному сотруднику. На
практике в большинстве организаций сотрудники часто выполняют по
несколько функций.
7.1.1 Руководитель проекта – Program manager
Software development manager, Project manager, Producer.
Руководитель проекта отвечает за разработку качественного продукта в
срок и в рамках установленного бюджета.
Основные виды деятельности:
планирование работы и составление бюджета;
принятие критичных для хода проекта решений;
ведение графика проекта и обеспечение соблюдения сроков;
координирование работ (управление взаимоотношениями) проектной
группы;
- управление функциональными спецификациями (техническими
заданиями).
-
7.1.2 Менеджер по маркетингу – Product manager
Product marketing manager.
Менеджер по маркетингу отвечает за соответствие продукта фирменному
стилю своей компании и за маркетинговую деятельность после выпуска
продукта.
Вопросы, связанные с рекламой, распространением новых версий,
обучением продавцов и дилеров, расчётом рентабельности продукта,
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
150
определением потребностей рынка программных продуктов и т.п. (т. е.
маркетингом), в изучение данной дисциплины не входят.
7.1.3 Разработчик – Developer
Разработчиков, как правило, бывает несколько.
Разработчики отвечают за удовлетворённость заказчика.
Разработчик архитектуры – Architect
Архитектор отвечает за архитектуру продукта, которая понятна, проста,
эффективна, надёжна и поддаётся модификации.
Задачи архитектора:
- Определение общей внутренней архитектуры кода и данных.
- Определение принципов обмена данными между связанными
компонентами.
- Определение стратегии разработки повторно используемых компонент.
- Составление плана тестирования “чёрного ящика” на самом верхнем
уровне.
- Разработка тестов, проверяющих соответствие кода техническому
заданию.
Аналитик предметной области – Software analyst
Subject matter.
Аналитик отвечает за правильность понимания решаемых задач.
Задачи аналитика:
- Обеспечение связи между заказчиком и проектной группой.
- Понимание того, что хотят пользователи.
- Понимание того, как выразить желания пользователя в терминах,
понятных участникам проектной группы.
- Разработка логики работы программного продукта.
- Составление рабочих спецификаций (детальных технических заданий).
Специалист по пользовательскому интерфейсу – User interface
designer
Разработчик интерфейса отвечает за удобство
соответствие пользовательского интерфейса.
и
функциональное
Обычно интерфейс пользователя создаёт сбалансированная группа из
специалистов по психологии, эргономике, компьютерной графике и
программированию, но всю полноту ответственности несёт только один
человек.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
151
Программист – Programmer
Программист отвечает за надёжный и полный продукт.
Программисты занимаются разработкой определённой части продукта,
которая относится к внутренней архитектуре.
Задачи программиста:
-
Создание продукта, удовлетворяющего техническому заданию.
Тестирование продукта (обеспечение качества кода).
Обеспечение срока разработки кода.
Обеспечение установки программного продукта.
7.1.4 Тестер – Tester
Тестер отвечает за согласованный и надёжный продукт.
Тестер может относиться к группе разработчиков. Тестер обеспечивает то,
что все особенности продукта будут известны до выпуска завершающей
версии.
Задачи тестера:
- Разработка стратегии и плана тестирования каждого этапа жизненного
цикла.
- Верификация на каждом этапе жизненного цикла (деталей продукта,
используемой терминологии, функциональных спецификаций, кода,
пользовательского интерфейса).
- Комплексное тестирование проекта.
- Документирование результатов тестирования.
7.1.5 Технический писатель – Writer
Технический писатель отвечает за продукт, который можно использовать и
сопровождать.
Задачи представителей группы документирования:
- Разработка документации (всевозможные инструкции и руководства),
которая помогает сделать программное обеспечение понятным для
пользователей и всех разработчиков.
- Ведение глоссария (определение единой терминологии).
- Обучение пользователей (ответы на вопросы и предоставление
необходимой информации).
7.1.6 Представитель группы технической поддержки – Logistic
Technical support.
Логистик отвечает за гладкое внедрение продукта.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
152
Это может быть один человек или руководитель целой группы
сотрудников, который непосредственно контактирует с пользователями.
Задачи представителя группы технической поддержки:
- Обеспечение готовности заказчика к внедрению (контроль
своевременности выполнения подготовительных работ, проверка
наличия необходимой инфраструктуры).
- Администрирование локальной сети (если необходимо).
- Отслеживание запросов на расширение функциональных возможностей.
7.1.7 Другие специалисты
В разработке проектов могут принимать участие специалисты по базам
данных, по защите информации, по сетям, по аппаратному обеспечению,
по надёжности, по эргономике (они знают, как спроектировать удобный и
полезный продукт), эксперты и инженеры по знаниям, а также юристы,
бухгалтеры и т.д.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
153
7.2 МОДЕЛЬ ПРОЕКТНОЙ ГРУППЫ
Под моделью проектной группы понимают структуру, позволяющую
отслеживать постоянно меняющиеся требования в проекте, который ведёт
группа проекта.
Модель группы проекта:
- вводит понятие роли для всех участников группы;
- даёт чёткое определение зон ответственности каждой роли;
- определяет активность роли в течение всего жизненного цикла.
Модель построена вокруг идеи маленькой группы участников,
работающих в тесной взаимосвязи, каждый из которых выполняет свои
роли. В модели определены шесть ролей:
1.
2.
3.
4.
5.
6.
Менеджер по маркетингу – Product manager.
Руководитель проекта – Program manager.
Разработчик – Developer.
Тестер – Tester.
Технический писатель – Writer.
Логистик – Logistic.
Разработчик
Менеджер по
маркетингу
Руководитель
проекта
Логистик
Тестер
Технический писатель
Характеристики группы проекта:
1. Общение каждого с каждым, причём каждый делает реальную работу.
2. Общие для всех членов группы цели и планы.
3. Каждый понимает как проблемы пользователя, так и проблемы
разработчика.
4. Каждый несёт ответственность за свою работу, в том числе и перед
группой.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
154
В этой модели отсутствует иерархия участников группы, потому что
вопрос “кто кому подчинён” теряет смысл. Однако существует несколько
моментов, на которые также следует обращать внимание:
- большая численность группы проекта может требовать очень много
времени на общение, чтобы реализовать характеристику под номером 1;
- высшее руководство имеет ограниченный контроль над процессами
внутри группы;
- участники группы должны полностью понимать и принимать свои роли.
Для очень больших проектов состав разработчиков разбивается на
подгруппы, деятельность которых координируется. Подгруппы могут быть
функциональными, или, в свою очередь, тоже могут быть разбиты на ещё
меньшие подгруппы. Это даёт возможность организовать параллельную
работу над проектом. Каждая группа от самого высокого до самого
низкого уровня состоит не более чем из пяти-семи человек. Группы
работают в тесном контакте друг с другом и обеспечивают процессы
жизненного цикла.
Следует отметить, что модель группы проекта никак не соотносится с
организационной структурой организации-разработчика. На практике
часты случаи, когда в одной проектной группе работают люди из разных
организаций, подчиняющиеся разным руководителям. За каждым членом
проектной группы закрепляется конкретная роль, для которой строится
специфический план работ, который затем входит в общий план проекта
как составная часть.
Для небольших проектов некоторые роли могут быть совмещены, и могут
выполняться одним человеком:
Разработчик
Менеджер по маркетингу
Технический писатель Логистик
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
Руководитель
проекта Тестер
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
155
Как правило, в основной состав проектной группы входят аналитик,
разработчик и тестер.
Разработчик
Аналитик
Тестер
р
Остальные роли не менее важны, однако выполняющие эти роли
участники могут одновременно работать над несколькими проектами
одновременно (технический писатель, логистик, менеджер по маркетингу).
Количество участников определяется как сложностью проекта, так и
масштабами организации (например, в Microsoft на каждого разработчика
по два тестера). Естественно, что каждая организация-разработчик имеет
свою модель группы проекта, и свою методологию создания программных
продуктов, которые в конечном итоге и определяют корпоративную
культуру организации.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
156
8 ДОКУМЕНТАЦИЯ ПРОЦЕССА РАЗРАБОТКИ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
При разработке программного средства (ПС) создаётся большой объём
разнообразной документации. Она необходима:
- как средство передачи информации между разработчиками ПС,
- как средство управления разработкой ПС,
- как средство передачи пользователям информации, необходимой для
применения и сопровождения ПС.
На создание этой документации приходится большая доля стоимости ПС.
Документацию процесса разработки можно разбить на две группы:
1. Документы управления разработкой ПС – process documentation.
2. Документы, входящие в состав ПС – product documentation.
Документы управления разработкой ПС
Протоколируют процессы разработки и сопровождения ПС, обеспечивая
связи внутри коллектива разработчиков и между коллективом
разработчиков и менеджерами (managers) – лицами, управляющими
разработкой. Эти документы могут быть следующих типов:
- Планы, оценки, расписания. Эти документы создаются менеджерами
для прогнозирования и управления процессами разработки и
сопровождения.
- Отчёты использования ресурсов в процессе разработки. Создаются
менеджерами.
- Стандарты. Эти документы предписывают разработчикам, каким
принципам, правилам, соглашениям они должны следовать в процессе
разработки ПС. Эти стандарты могут быть как международными или
национальными, так и специально созданными для организации, в
которой ведётся разработка данного ПС.
- Рабочие документы. Это основные технические документы,
обеспечивающие связь между разработчиками. Они содержат фиксацию
идей и проблем, возникающих в процессе разработки, описание
используемых стратегий и подходов, а также рабочие (временные)
версии документов, которые должны войти в ПС.
- Заметки и переписка. Эти документы фиксируют различные детали
взаимодействия между менеджерами и разработчиками.
Документы, входящие в состав ПС
Описывают программы ПС как с точки зрения их применения
пользователями, так и с точки зрения их разработчиков и сопроводителей
(в соответствии с назначением ПС). Здесь следует отметить, что эти
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
157
документы будут использоваться не только на стадии эксплуатации ПС (в
её фазах применения и сопровождения), но и на стадии разработки для
управления процессом разработки (вместе с рабочими документами). Во
всяком случае, они должны быть проверены (протестированы) на
соответствие программам ПС. Эти документы образуют два комплекта с
разным назначением:
1. Пользовательская документация ПС.
2. Документация по сопровождению ПС.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
158
8.1 ПОЛЬЗОВАТЕЛЬСКАЯ ДОКУМЕНТАЦИЯ
Она необходима, если программное средство предполагает какое-либо
взаимодействие с пользователями.
Пользовательская документация ПС (user documentation) объясняет
пользователям, как они должны действовать, чтобы применять данное ПС.
Эти документы частично затрагивают вопросы сопровождения ПС, но не
касаются вопросов, связанных с модификацией программ.
К пользовательской документации относятся документы, которыми
руководствуется пользователь:
- при инсталляции ПС (при установке ПС с соответствующей настройкой
на среду применения);
- при применении ПС для решения своих задач;
- при управлении ПС (например, когда данное ПС взаимодействует с
другими системами).
В связи с этим следует различать две категории пользователей ПС:
1. Конечные пользователи ПС – end-user.
2. Администраторы ПС – system administrator.
Конечный пользователь использует ПС для решения своих задач (в своей
предметной области). Это может быть инженер, проектирующий
техническое устройство, или кассир, продающий железнодорожные
билеты с помощью ПС. Он может и не знать многих деталей работы
компьютера или принципов программирования.
Администратор управляет использованием ПС конечными пользователями
и осуществляет сопровождение ПС, не связанное с модификацией
программ. Например, он может регулировать права доступа к ПС между
конечными пользователями, поддерживать связь с поставщиками ПС или
выполнять определённые действия, чтобы поддерживать ПС в рабочем
состоянии, если это включено как часть работы ПС в другую систему.
Состав пользовательской документации зависит от категории
пользователей, на которые ориентировано данное ПС, и от режима
использования документов. Под категорией здесь понимается контингент
пользователей ПС, у которого есть необходимость в определённой
пользовательской документации ПС. Удачный пользовательский документ
существенно зависит от точного определения категории, для которой он
предназначен. Пользовательская документация должна содержать
информацию,
необходимую для каждой категории. Под режимом
использования документа понимается способ, определяющий, каким
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
159
образом используется этот документ. Обычно пользователю достаточно
больших программных систем требуются либо документы для изучения
ПС (использование в виде инструкции), либо для уточнения некоторой
информации (использование в виде справочника).
Можно считать типичным следующий
документации для достаточно больших ПС:
состав
пользовательской
1. Общее функциональное описание ПС. Даёт краткую характеристику
функциональных возможностей ПС. Предназначено для пользователей,
которые должны решить, насколько необходимо им данное ПС.
2. Руководство по инсталляции ПС. Предназначено для системных
администраторов. Этот документ должен детально предписывать, как
устанавливать систему в конкретной среде. Он должен содержать
описание носителя, на котором поставляется ПС, представляющие ПС
файлы, а также требования к минимальной конфигурации аппаратуры.
3. Инструкция по применению ПС. Документ предназначен для конечных
пользователей. Содержит необходимую информацию по применению
ПС, которая организована в удобной для изучения форме.
4. Справочник по применению ПС. Этот документ предназначен для
конечных пользователей. Содержит необходимую информацию по
применению ПС, организованную в удобной для избирательного поиска
отдельных деталей форме.
5. Руководство по управлению ПС. Предназначено для системных
администраторов. Оно должно описывать сообщения, генерируемые,
когда ПС взаимодействует с другими системами, и как реагировать на
эти сообщения. Кроме того, если ПС использует системную аппаратуру,
этот документ может объяснять, как сопровождать эту аппаратуру.
Как уже говорилось ранее, разработка пользовательской документации
начинается сразу после создания внешнего описания. Качество этой
документации может существенно определять успех ПС. Она должна быть
достаточно проста и удобна для пользователя (в противном случае это ПС
вообще не стоило создавать).
Поэтому, хотя черновые варианты
(наброски) пользовательских документов создаются основными
разработчиками ПС, к созданию их окончательных вариантов часто
привлекаются профессиональные технические писатели. Кроме того, для
обеспечения качества пользовательской документации разработан ряд
стандартов, в которых предписывается порядок разработки этой
документации,
формулируются требования к каждому виду
пользовательских документов и определяются их структура и содержание.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
160
8.2 ДОКУМЕНТАЦИЯ ПО СОПРОВОЖДЕНИЮ
Эта документация необходима, если ПС предполагает изучение того, как
оно устроено (сконструировано), и модернизацию его программ.
Документация по сопровождению ПС (system documentation) описывает
ПС с точки зрения его разработки.
Как уже отмечалось, сопровождение – это продолжающаяся разработка.
Поэтому в случае необходимости модернизации ПС к этой работе
привлекается специальная группа разработчиков-сопроводителей. Этой
группе придётся иметь дело с документацией, которая определяла
деятельность проектной группы основных разработчиков ПС, – с той лишь
разницей, что эта документация для разработчиков-сопроводителей будет
“чужой” (она создавалась другими людьми). Группа разработчиковсопроводителей должна будет изучать эту документацию:
- для того, чтобы понять строение и процесс разработки
модернизируемого ПС;
- внести в эту документацию необходимые изменения, повторяя в
значительной степени технологические процессы, с помощью которых
создавалось первоначальное ПС.
Документация по сопровождению ПС можно разбить на две группы:
1. Документация, определяющая строение программ и структур данных
ПС и технологию их разработки.
2. Документация, помогающая вносить изменения в ПС.
Документация первой группы содержит итоговые документы каждого
технологического этапа разработки ПС. Она включает следующие
документы:
1. Внешнее описание ПС (Requirements document).
2. Описание архитектуры ПС (Description of the system architecture),
включая внешнюю спецификацию каждой её программы.
3. Для каждой программы ПС – описание её модульной структуры,
включая внешнюю спецификацию каждого включённого в неё модуля.
4. Для каждого модуля – его спецификация и описание его строения
(Design description).
5. Тексты модулей на выбранном языке программирования (Program
source code listings).
6. Документы установления достоверности ПС (Validation documents),
описывающие, как устанавливалась достоверность каждой программы
ПС и как информация об установлении достоверности связывалась с
требованиями к ПС. Эти документы включают прежде всего
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
161
документацию по тестированию (схема тестирования и описание
комплекта тестов), но могут включать и результаты других видов
проверки ПС, например, доказательства свойств программ.
Документация второй группы содержит:
Руководство по сопровождению ПС (system maintenance guide), которое
- описывает известные проблемы в ПС;
- описывает, какие части системы являются аппаратно- и программнозависимыми;
- описывает, как развитие ПС принято в расчёт при его конструировании.
Общая проблема сопровождения ПС – обеспечить, чтобы все его
представления оставались согласованными, когда ПС изменяется. Чтобы
этому помочь, связи и зависимости между документами и их частями
должны быть зафиксированы в базе данных управления конфигурацией.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
162
9 АВТОМАТИЗАЦИЯ РАЗРАБОТКИ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
При разработке сложных программных продуктов группой участников
важно решать такие вопросы, как:
1. Организация взаимодействия разработчиков, создающих систему.
2. Осуществление контроля над версиями системы.
3. Организация безопасного хранения компонент, создающихся в процессе
работы над системой.
4. Организация повторного использования компонент.
5. Обеспечение интеграции инструментов, используемых разработчиками.
Для разработки ПС используются модели. Для построения моделей
используются визуальные средства моделирования, которые позволяют:
1. Выполнить декомпозицию ПС, разбив её на составные части
(подсистемы) с целью удобства понимания человеком.
2. Описать систему в наглядной для человека графической форме с
применением стандартной нотации (например, UML).
3. Показать различные аспекты ПС (например, функционирование – Use
case View, логическую организацию – Logical View, физическую
структуру – Component View, Deployment View).
4. Найти необходимые решения, относящиеся к программной реализации
(например, сценарии взаимодействия объектов Sequence Diagrams,
параллельные потоки Activity Diagrams, потоки данных Collaboration
Diagrams).
5. Спроектировать базу данных.
6. Выявить повторно используемые программные компоненты, что даёт
возможность сократить объём кодирования.
7. Выполнять построение моделей из программного кода и базы данных
при проектировании унаследованных систем (Reverse engineering).
Основанный на моделях подход применяется как в объектноориентированной технологии, так и в структурной. Для каждой из этих
технологий определён свой набор инструментальных средств.
Однако, создание ПС – это не только построение модели. Чем сложнее и
шире проект, тем в большей степени он требует инструментальной
поддержки всех этапов жизненного цикла программного обеспечения.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
163
9.1 ОСОБЕННОСТИ И КОМПОНЕНТЫ CASE-СРЕДСТВ
Computer-Aided Software Engineering – система автоматизированной
разработки программ, или CASE-средство.
Обычно к CASE-средствам относят любое программное средство,
автоматизирующее один процесс или совокупность процессов жизненного
цикла программного обеспечения.
Современные
особенности:
CASE-средства
имеют
следующие
характерные
1. Наличие графических средств для описания и документирования
систем, обеспечивающих удобный интерфейс с разработчиком и
развивающих его творческие возможности.
2. Интеграция отдельных компонентов, обеспечивающая управляемость
процессом разработки систем.
3. Использование специальным образом организованного хранилища
(репозитория) проектных метаданных (артефактов).
Комплекс средств, поддерживающих полный ЖЦ ПС (интегрированное
CASE-средство), содержит следующие компоненты:
1. Репозиторий, который обеспечивает:
- хранение версий проекта и его отдельных частей;
- синхронизацию
поступления
информации
от
разработчиков при коллективной разработке;
- контроль данных на полноту и непротиворечивость.
различных
2. Графические средства анализа и проектирования, которые
обеспечивают создание и редактирование моделей (диаграмм,
сценариев) ПС.
3. Средства разработки приложений, включая системы программирования
и управления базами данных (генерацию исходных кодов по моделям
на различных языках программирования; генерацию схем баз данных
для Систем Управления Базами Данных (СУБД); связь между средством
проектирования, системой программирования и СУБД).
4. Средства
конфигурационного
управления.
Конфигурационным
управлением называется деятельность по систематическому учёту и
контролю внесения обоснованных изменений в программный продукт.
Система конфигурационного управления даёт возможность:
-
отследить, какие существуют объекты в проекте,
в каких состояниях они находятся,
как загружены исполнители,
как выполняются задания и т.п.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
5.
6.
7.
8.
164
Средства документирования.
Средства тестирования.
Средства управления проектом.
Средства реинжиниринга (трансформации унаследованного ПС в новое
ПС).
По используемой технологии создания систем можно классифицировать
CASE-средства на объектно-ориентированные и структурные. Основными
компонентами и тех, и других средств автоматизации являются средства
анализа и проектирования.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
165
9.2 ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ CASE-СРЕДСТВА АНАЛИЗА
И ПРОЕКТИРОВАНИЯ
Мировым лидером средств анализа и проектирования объектноориентированных систем является продукт Rational Rose фирмы IBM
Rational Software (США). Это CASE-средство предназначено для
автоматизации этапов анализа и проектирования.
Работа в Rational Rose заключается в проектировании определённого
вида диаграмм, задавая при этом все свойства, отношения и
взаимодействие элементов модели друг с другом.
При разработке любой системы возникает проблема взаимопонимания
исполнителя и заказчика. Имея такой инструмент, как Rose, аналитик
всегда может показать заказчику не абстрактное словесное описание
процесса, а его конкретную модель (на экране персонального компьютера
или в печатном виде – неважно). Значит, Rose позволит быстрее
согласовать с заказчиком все детали планируемой системы. Результатом
моделирования является файл с моделью, которую аналитик передаёт
следующему звену сотрудников – программистам, которые дополняют
полученную логическую модель системы моделями конкретных классов
для конкретного языка программирования.
Для моделирования объектно-ориентированное средство Rose использует:
1. Унифицированный язык моделирования (Unified Modeling Language –
UML).
2. Объектную модель программных компонентов (Component Object
Model – COM).
3. Технику объектного моделирования (Object Modeling Technique –
OMT).
4. Метод визуального моделирования Г. Буча' 93 (Booch'93).
Богатый набор возможностей Rose предоставляет разработчикам:
1.
2.
3.
Проектирование систем с кодогенерацией. Позволяет модель
преобразовать в описание на конкретном языке программирования.
Поддерживаются языки: С++, Ada, Java, Basic, XML (eXtensible
Markup Language), Oracle. Также к Rose сторонними компаниями
разрабатываются специальные мосты к не входящим в стандартную
поставку языкам, например, к Delphi.
Обратное проектирование (реинжиниринг), когда готовую систему
(например, на C++) или базу данных (на Oracle) “закачивают” в Rose
с целью получения наглядной визуальной (структурной) модели.
Возвратное проектирование (Round-trip engineering), которое
сочетает возможности первых двух подходов, когда создаётся система,
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
166
а по прохождении некоторого времени эволюционного периода
(доработок)
подвергается
вновь
реинжинирингу
и
вновь
кодогенерации.
В данное время Rational Rose поставляется в следующих редакциях:
1. Rose DataModeler – позволяет проектировать системы и базы данных
без возможности кодогенерации. Продукт направлен на архитекторов и
аналитиков.
2. Rose RealTime – узкоспециализированная версия для систем
реального времени, способная проводить 100% кодогенерацию и
реинжиниринг только для языков С и C++. Имеет неполный набор
диаграмм. Продукт направлен только на программистов.
3. Rose Enterprise – наиболее полная версия, включает в себя все
вышеописанные возможности. Продукт направлен на архитекторов,
аналитиков, программистов.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
167
9.3 СТРУКТУРНЫЕ CASE-СРЕДСТВА
Сущность структурного подхода к разработке ПС заключается в её
декомпозиции на автоматизируемые функции: система разбивается от
функциональных подсистем до конкретных процедур.
Принципы объектно-ориентированного подхода: "разделяй и властвуй"
(разбиение сложных проблем на множество лёгких для понимания задач) и
иерархическое упорядочение (организация составных частей системы в
древовидные структуры с добавлением новых деталей на каждом уровне) –
сохраняются так же и при структурном подходе. Однако при этом подходе
анализируются не объекты и их взаимодействие, а алгоритмы
выполняемых системой функций и отношения между данными при
выполнении этих функций.
Структурный подход чаще
проектировании баз данных.
всего
используется
при
анализе
и
Почти все CASE-средства структурного анализа и проектирования систем
используют следующие модели:
1. Data Flow Diagrams (DFD) – диаграммы потоков данных совместно со
словарями данных и спецификациями процессов.
2. Entity-Relationship Diagrams (ERD) – диаграммы “сущность-связь”.
3. State Transition Diagrams (STD) – диаграммы переходов состояний.
Логическая диаграмма потоков данных (DFD) показывает внешние по
отношению к системе источники и приёмники данных. Структуры потоков
данных и определения их компонентов хранятся в словаре данных.
Диаграмма “сущность-связь” (ERD) раскрывает модель хранилища данных
и обеспечивает стандартный способ определения данных и отношений
между ними. Здесь идентифицируются важные для данной предметной
области сущности (объекты), свойства этих сущностей (атрибуты) и их
отношения с другими сущностями (ассоциации).
Диаграмма переходов состояний (STD) является средством описания
поведения системы, зависящего от реального времени. При этом
учитывается начальное состояние (стартовая точка для системного
перехода); переход (перемещение системы из одного состояния в другое);
условие (событие или события, вызывающие переход); действие
(операция, которая может иметь место при выполнении перехода).
Известным CASE-средством структурного анализа и проектирования
является Silverrun – средство американской фирмы Silverrun
Technologies Inc. Silverrun состоит из четырёх модулей, каждый из
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
168
которых является самостоятельным продуктом и может использоваться без
связи с остальными модулями:
1. Business Process Modeler (BPM) строит модели в виде диаграмм
потоков данных.
2. Entity-Relationship eXpert (ERX) обеспечивает построение моделей
данных “сущность-связь”.
3. Relational Data Modeler (RDM) позволяет создавать детализированные
модели “сущность-связь”, предназначенные для реализации в
реляционной базе данных.
4. Workgroup Repository Manager (WRM) применяется как словарь
данных для хранения общей для всех моделей информации.
Для автоматической генерации схем баз данных у Silverrun существуют
мосты к наиболее распространенным СУБД: Oracle, DB2, SQL Server,
MS Access. Кроме того, имеются программные мосты к объектноориентированному CASE-средству Rational Rose, разработанные
российской фирмой Аргуссофт.
В России многими разработчиками информационных систем используются
CASE-средства BPWin и ERWin фирмы Platinum technology, которые
предназначены для анализа, проектирования и кодогенерации. Фирма
Platinum имеет программные мосты с Rational Rose для связывания
модели данных с объектной моделью. В книжных магазинах есть книга:
Маклаков С.В. BPWin и ERWin. CASE-средства разработки
информационных систем. – М.: ДИАЛОГ-МИФИ, 1999. Книга
содержит описание методов структурного анализа и проектирования
моделей данных. Подробно на конкретных примерах рассмотрено
применение CASE-технологий и CASE-средств для автоматизации этапов
анализа, проектирования и кодогенерации информационных систем.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
169
9.4 CASE-СРЕДСТВА КОМПАНИИ IBM RATIONAL SOFTWARE
Процесс создания программного обеспечения весьма и весьма сложный.
Определённые неудобства разработчикам доставляют меняющиеся
требования пользователей к системе, разрастающиеся не по дням (а по
часам) операционные системы. Разработчикам приходится, в буквальном
смысле слова “держать нос по ветру”, анализируя все веяния, переводя их
в машинный код. В результате код программы разрастается, штат
разработчиков тоже, а время на выпуск каждого нового релиза
сокращается. Тем самым складывается очень интересная ситуация, когда
выпуск ПС не поспевает не только за требованиями пользователей, но и за
выходом очередных аппаратных и программных новинок. Если же продукт
успел выйти вовремя, то, как правило, содержит много ошибок, поскольку
не все компании держат огромный штат квалифицированных тестеров. А
если ко всему вышеперечисленному ещё добавить возрастающую
интернационализацию, когда команды разработчиков разбросаны по всей
планете! Объектно-ориентированный подход и языки программирования,
обладая многими достоинствами (conceptual integrity, contract,
selfishness, hierarchy, seamlesness, encapsulation, inheritance,
polymorphism), сами по себе всё равно не могут решить проблему
скоростной разработки.
По статистике (исследования компании Standish Group CHAOS) только
26% проектов заканчиваются успешно (читай: “вовремя”), то есть только
четверть всего задуманного воплощается в жизнь. Анализ деятельности
наиболее успешных компаний и анализ их секретов успеха позволил
создать общую рекомендацию для всех других. Компания IBM Rational
Software
постоянно
занимается
исследованиями
в
области
Информационных Технологий с целью выработки оптимального пути в
создании программного обеспечения. Девиз компании: “Строй
быстрее, надёжней, качественней…” Основа всего, что выпускает
компания – универсальный процесс (RUP – Rational Unified Process).
9.4.1 Средство визуального моделирования Rational Rose
Rose – средство визуального моделирования бизнес-процессов, анализа
требований и проектирования на основе трёхуровневой архитектуры
компонентов. CASE-средство Rational Rose является продуктом №1 в
программном списке IBM Rational Software (см. 9.2).
Первый этап жизненного цикла полностью поддерживается Rose.
Следующим шагом на пути построения грамотного ПС является
построение документооборота в соответствии со всеми возможными
стандартами, чтобы документы целиком и полностью отражали реальное
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
состояние дел. Инструментом автоматизации
занимается следующий продукт Rational SoDA.
170
документооборота
9.4.2 Автоматизированное документирование Rational SoDA
Результатом почти любой деятельности является документ или отчёт
заранее установленного образца. Всю работу по написанию может взять на
себя технический писатель, но ему будет очень трудно “вынимать” из
моделей спецификации и комментарии, перенося в текстовый редактор, –
это неправильный подход. На решение всех проблем с документооборотом
направлен инструмент Rational SoDA.
Основная обязанность Rational SoDA – подготовить отчёт по заранее
установленному шаблону.
Данные для отчёта могут быть взяты из любого продукта Rational.
Например, готовый документ по имеющейся в Rose модели. Набор
отчётов, поддерживаемых SoDA, таков: Rational Rose, Requisite PRO,
ClearCase и TeamTest.
SoDA является макросом для MS Word. Система вызовов (и меню)
интегрирована в MS Word и позволяет генерировать шаблоны на базе
имеющихся файлов. SoDA допускает использование как стандартных
шаблонов, так и созданных пользователем при помощи специального
мастера (Wizard), также встроенного в систему меню MS Word.
Продукт обязателен для использования в составе любого проекта. Также
особенную направленность продукт имеет на разработчиков и
постановщиков задач.
Рассмотренные три программных продукта (RUP, Rose, SoDA)
полностью
покрывают
потребности
архитекторов,
аналитиков,
программистов и технических писателей. Правда, вырванные из контекста
процесса разработки, они не обеспечивают полноценной поддержки
жизненного цикла разработки. Для этого универсальный процесс
рекомендует использование следующих продуктов: RUP, SoDA,
Requisite PRO и ClearQuest.
ПС любых размеров невозможно строить в отрыве от консультаций с
заказчиком. Подобные консультации ведут к постоянному уточнению
функций системы (изменению требований). Если пользоваться объектноориентированным подходом и инструментальным средством Rational
Rose, то (с точки зрения компании) 90% функций будет оговорено на
самом начале пути разработки. Следовательно, все изменения не будут
носить шоковый характер. IBM Rational Software предлагает набор
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
171
инструментальных средств для того, чтобы превратить внесение новых
требований в обыденный безболезненный процесс.
9.4.3 Управление требованиями Rational RequisitePRO
RequisitePRO – это инструмент, который поддерживает обновления и
отслеживает изменения в требованиях для всего коллектива
разработчиков, представляя их в удобном виде для чтения, обсуждения и
изменений.
Для каждого требования:
- поддерживается расширяемый набор атрибутов, что позволяет
характеризовать требования в соответствии с представлениями
пользователя;
- назначается конкретный исполнитель;
- хранится его история, позволяющая отследить, какие изменения были
внесены в требование, кем, когда и почему;
- устанавливается приоритет, по которому требования сортируются.
RequisitePRO позволяет:
1. Централизованно организовать все документы и данные, относящиеся
к требованиям: требования заказчика, дизайн подсистем, сценарии,
структурные и функциональные спецификации, планы тестирования.
2. Визуально определять схожие требования в рамках одного или
нескольких проектов. Это даёт возможность применения готовых
апробированных решений в новом проекте.
3. Задать связи между требованиями. Это позволяет легко проследить,
какие требования следует подвергнуть анализу (и, возможно,
пересмотру) при модификации некоторого конкретного требования или
атрибута. Тем самым упрощается процесс внесения изменений.
4. Упростить общение между разработчиками путём предоставления
общего доступа ко всем требованиям проекта, либо к их части.
Продукт направлен на всех участников проекта.
9.4.4 Управление запросами на изменение Rational ClearQuest
Из-за постоянных изменений в проекте жизненно необходимо знать
статистику того, что менялось, кем и в какое время, причём иметь полный
объём необходимой информации в какой-либо базе данных (например, под
управлением СУБД Oracle).
ClearQuest – Windows- и Web- размещаемый продукт, который помогает
коллективу разработчиков отслеживать и управлять всеми действиями по
изменению программного обеспечения в течение всего жизненного цикла.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
172
Запросы на изменения проходят цикл из нескольких состояний (States):
1. Только что поданный запрос находится в состоянии “Подан”
(Submitted).
2. После передачи запроса сотруднику он переходит в состояние
“Назначен” (Assigned).
3. Начало работы над запросом переводит его в состояние “Открыт”
(Open), и вся команда может видеть, что кто-то обрабатывает запрос.
4. Когда запрос проверяется, он проходит стадию “Проверка” (Verify).
5. Когда запрос закрыт, он переходит в состояние “Закрыт” (Resolved).
Таким образом, любой участник проекта (от подчинённого до
руководителя) может пользоваться базой в собственных целях (смотреть
и/или составлять собственные запросы).
Данный продукт через World Wide Web поддерживает связь внутри
команд, разделённых территориально.
Продукт направлен на всех участников команды.
Итак, рассмотрены пять программных продуктов, четыре из которых
необходимы на протяжении всего цикла разработки программной системы
(RUP, ClearQuest, RequisitePRO, SoDA) и один, необходимый на самых
ответственных этапах проектирования и кодогенерации (Rose). Все
вышеперечисленные продукты основные, но только ими в процессе
разработки не обойтись.
Для получения качественного кода разработчик должен лишить код
ошибок и настроить его на максимальную производительность, затем
передать код тестерам для выявления логических (высокоуровневых)
ошибок.
Следующие три программы помогут разработчику существенно повысить
качество кода, снизив при этом время, необходимое на детальную
проработку кода.
9.4.5 Измерение характеристик Rational Quantify
Quantify – средство для сбора и анализа информации о
производительности созданного программного продукта, позволяющее
измерить характеристики приложения и его компонентов.
Средство ориентировано на разработчиков, программирующих на C/C++,
Basic и Java, и помогает определять и устранять узкие места в
производительности программного обеспечения.
Данный продукт:
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
173
1. Генерирует в табличной форме список всех вызываемых функций в
процессе работы приложения, указывая временнЫе характеристики
каждой из них.
2. Предоставляет полную статистику по всем вызовам (внешним и
внутренним), невзирая на размеры тестируемого приложения и время
его тестирования. Сбор данных осуществляется посредством
технологии OCI (Object Code Insertion). Суть способа состоит в
подсчёте всех машинных циклов путём вставки счётчиков в код для
каждого
функционального
блока.
Все
циклы
приложения
просчитываются реально, а не при помощи произвольных выборок, как
в большинстве пакетов тестирования. Уникальность данного подхода
заключается в том, что тестируются все используемые компоненты
(например, библиотеки DLL), а также в том, что для анализа совсем
необязательно иметь исходные тексты тестируемого приложения.
3. Запоминает все предыдущие вызовы и даёт их сравнительную оценку.
Например, при многократных перекомпиляциях приложения.
4. Имеет возможность перенести в Microsoft Excel статистическую
информацию по вызовам, где можно построить как графики, так и
сводные таблицы для разных запусков программы.
Продукт ориентирован на разработчиков.
9.4.6 Поиск ошибок исполнения Rational Purify
Purify – это средство поиска ошибок исполнения (run-time) для
приложений и компонентов языков C/C++ и разрешения проблем,
связанных с утечками памяти.
Многие программные продукты замыкают на себя во время работы все
системные ресурсы без большой на то необходимости, что может привести
готовую систему к краху в самый ответственный момент. Возникновение
подобного рода ошибок достаточно трудно отследить стандартными
средствами.
В общих чертах работа Purify сводится к выводу детальнейшей статистики
об использовании памяти приложением. Программа собирает данные о
любых потерях в памяти. Например, невозвращение блока, не
использование указателей, остановка исполнения программы с выводом
состояния среды при возникновении ошибки run-time.
Purify предоставляет возможность не только видеть предупреждения и
ошибки, но и переходить к соответствующему исходному тексту. Такая
возможность существует только для внутренних вызовов, поскольку
исходные тексты динамических библиотек пока недоступны.
Продукт ориентирован на разработчиков.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
174
9.4.7 Области кода, неподдающиеся тестированию Rational
PureCoverage
PureCoverage – средство, основным и единственным назначением
которого является выявление участков кода, пропущенных при
тестировании приложения.
Разработчики могут учесть это и более тщательно выполнять проверку.
Провести тестирование абсолютно всех функций разработчик не может,
так как невозможно на 100% быть уверенным в том, что всё оттестировано.
PureCoverage собирает статистику о тех участках программы, которые во
время тестирования не были пройдены (выполнены). Подобные строки
подсвечиваются красным цветом, чётко указывая на наличие чёрных дыр в
программе в виде не оттестированного кода. Дополнительно программа
считает так называемые активно исполнявшиеся строки – хиты.
Следовательно, разработчик может оценить, сколько раз исполнилась
каждая строка, составляющая функцию. Имея подобную статистику,
проще выявить не исполнившиеся строки и проанализировать причину, по
которой они не получили управления.
Продукт направлен на разработчиков.
От тестирования кода программы переходят к функциональному
тестированию. Это следующий этап в разработке ПС, когда определены
все требования к ней, когда написана какая-то работоспособная версия
программы или отдельного сегмента.
Следующие три основные программы тестирования направлены на
высокоуровневое тестирование. Каждая из программ не просто позволяет
что-то тестировать, а способна создавать специальные скрипты (сценарии)
для последующего повторного тестирования.
9.4.8 Визуальное тестирование Rational Visual Test
Visual Test является автоматизированным инструментом тестирования,
который обеспечивает надёжное функциональное тестирование.
Visual Test имеет интерфейс, сходный с Visual Studio от компании
Microsoft. С его помощью можно тестировать:
-
32-битное Windows-приложение;
компонент ActiveX,
DLL-библиотеку;
Web-приложение.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
175
Основу Visual Test составляет производный от Visual Basic расширенный
язык программирования Test Basic, с сотнями специфических для теста
функций, специальных конструкций для облегчения тестирования и
открытой архитектурой, которая делает этот язык расширяемым.
Продукт ориентирован на тестеров и разработчиков.
9.4.9 Тестирование пользовательского интерфейса Rational Robot
Robot – инструментальное средство функционального тестирования,
базирующееся на объектно-ориентированной технологии, предназначенное
для тестирования графического интерфейса (GUI-тестирования).
Программа способна работать в двух режимах: ручном и автоматическом.
В ручном режиме пользователь сам задаёт на специальном языке сценарий
тестирования (скрипт).
В автоматическом режиме пользователь тестирует приложение, а Robot
автоматически генерирует необходимый скрипт для дальнейшего
повторного тестирования. Скрипты можно редактировать, отлаживать и
настраивать.
Продукт ориентирован на тестеров и разработчиков.
9.4.10 Тестирование распределённых приложений Rational LoadTest
LoadTest – средство автоматизированного тестирования характеристик
распределённых сетевых приложений на платформах Windows и Unix.
При этом тестировании типично используется нагрузка сервера большИм
количеством виртуальных пользователей. Например, можно установить
таймер для одного пользователя, чтобы определить какое количество
времени займёт выполнение запроса, когда тысячи других пользователей
посылают запросы на тот же самый сервер в то же самое время.
Таким образом, становится возможным при использовании данной
программы проверять на производительность систему архитектуры C/S
(клиент/сервер).
Продукт направлен на тестеров, разработчиков, Web-разработчиков.
Осталось рассмотреть только связующее звено – программный продукт,
который бы использовался на всех этапах проекта: от идеи и до внедрения.
9.4.11 Конфигурационный и версионный контроль Rational ClearCase
ClearCase является средством конфигурационного и версионного
контроля, который сохраняет всю историю каждого файла проекта с целью
возможного сравнения изменений (включая миграцию файлов между
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
176
независимыми проектами) и позволяет получать последние версии
редактируемых файлов на протяжении всего жизненного цикла.
Данный продукт:
1. Управляет рабочим пространством.
2. Обеспечивает единую среду, инструментальные средства и подход к
работе.
3. Обеспечивает доступ каждому участнику проекта, как ко всем файлам
проекта, так и только к определённой его части. Для достижения
подобного эффекта ClearCase использует систему настраиваемых
фильтров, скрывающих ненужную информацию.
4. Позволяет осуществить параллельную разработку.
5. Позволяет отдельному участнику проекта выходить из общего состава
разработки, забирая работу “на дом”, а после всех внесённых изменений
вернуть версии снова в проект. При этом ClearCase осуществит
автоматическое слияние версий.
6. Позволяет
объединять
географически
удалённые
команды
разработчиков посредством MultiSite (специального модуля, который
осуществляет передачу текущего состояния проекта на указанный сайт).
7. Имеет механизмы интеграции с другими средствами разработки
(например, Oracle), с различными дополнительными генераторами
отчётов (например, MS Word) и пр.
Продукт ориентирован на всех участников команды: руководителей,
менеджеров, разработчиков, аналитиков, тестеров, технических писателей.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
177
ЗАКЛЮЧЕНИЕ
while ( программирование == искусство ) {
удовольствие++;
ошибки--;
компактность++;
удобство сопровождения++;
качество++;
зарплата++;
}
// счастливая жизнь на долгие времена
Кнут Д., 1992
Широкое использование вычислительных средств в различных
предметных областях привело к тому, что …
Современные компьютерные программы решают самые различные задачи
по содержанию и по значению…
Программные средства являются непосредственной производительной
силой…
В результате внедрения прогрессивных современных
возможно повышение производительности труда…
технологий
Затраты на программные средства составляют значительную долю
стоимости обработки информации и систем управления…
Кризис программного обеспечения…
Проблемы создания программного обеспечения сложных систем и
товарных программ давно стали актуальными для людей, связанных с
разработкой и управлением разработками программ. В предложенном
Вашему вниманию курсе обсуждались как весьма общие проблемы
создания программных средств, так и некоторые частные вопросы анализа
и проектирования этих систем. Пользоваться хорошим программным
обеспечением легко, разрабатывать его намного сложнее. Дж. Фокс
пишет: “Разработка программного обеспечения – это
выпущенный из “волшебной” лампы джинн, который
скитается по свету и повсюду отравляет жизнь
разработчикам систем”. Одной из главных причин большого числа
трудностей в деле разработки стал постоянный и значительный рост
сложности (и масштабов) проводимых программистами работ.
Следовательно, обязательно должна была появиться дисциплина,
связанная с исследованием знаний, методов и средств создания
программного обеспечения. …И назвали эту дисциплину “Технология
разработки программного обеспечения”.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
178
Технология разработки программного обеспечения включает в себя три
компонента, которые почти невозможно отделить один от другого: наука,
ремесло и мифы.
Научный компонент объясняет, что следует делать и чего следует избегать
в программировании. Он подразумевает анализ требований и целей
программирования, приведение широкого круга концепций к нескольким
простым; показывает, как можно достичь множества целей, применяя
строго определённые правила построения к простейшим основным
конструктивным элементам.
Ремесло программирования – это традиция, передаваемая от мастера к
ученикам; оно представляет собой правила программирования;
подразумевает применение инструментов автоматизации процесса
создания (если они есть).
Мифы описывают
программирования.
ритуалы
и
фантазии,
окружающие
процесс
При изучении технологии разработки программного обеспечения нельзя
ограничиваться ни одним из этих компонентов: как ни стремиться
ограничиться чистой наукой, элементы ремесла слишком важны, чтобы
ими можно было пренебречь, а сказания помогают установить контакты с
пользователем (да и поднимают порой настроение!).
По сути дела, одной из самых главных целей дисциплины является
изучение и внедрение таких методов проектирования и реализации
программ, которые облегчают задачу сопровождения программы.
Лёгкость сопровождения – это одно из тех качеств программы,
которые нельзя добавить к программе после её завершения.
Программированием очень редко занимаются ради него самого. Большей
частью
это
профессиональное
обслуживание,
предоставляемое
пользователю за плату. Разработка программного обеспечения – это
многогранная деятельность, связанная не только с работой на
вычислительной машине. Большая программная система никогда не может
быть отлажена до конца, даже после длительного тестирования и
использования. Разрабатывать программное обеспечение очень и очень
трудно. Но это всё Вам уже хорошо известно…
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
179
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Амриш К., Ахмед Х. Разработка корпоративных Java-приложений с
использованием J2EE и UML. / Пер. с англ. – М.: Вильямс, 2002.
2. Боггс У., Боггс М. UML и Rational Rose. / Пер. с англ. – М.: ЛОРИ, 2000.
3. Боэм Б. Инженерное проектирование
/ Пер. с англ. – М.: Радио и связь, 1985.
программного обеспечения.
4. Боэм Б., Браун Дж., Каспар Х. и др. Характеристики качества
программного обеспечения. / Пер. с англ. – М.: Мир, 1981.
5. Брукс Ф. Мифический человеко-месяц или как создаются программные
системы./ Пер. с англ. – СПб.: Символ-Плюс, 1999.
6. Брукшир Дж. Гленн. Введение в компьютерные науки. Общий обзор.
/ Пер. с англ. – 6-е изд. – М.: Вильямс, 2001.
7. Буч Г. Объектно-ориентированный анализ и проектирование с
примерами приложений на C++./ Пер. с англ. – 2-е изд. – М.: Бином,
СПб.: Невский диалект, 1998.
8. Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство
пользователя. / Пер. с англ. – М.: ДМК, 2000.
9. Вендров А. М. Проектирование программного обеспечения
экономических информационных систем: Учебник. – М.: Финансы и
статистика, 2000.
10.Вендров А. М. CASE-технологии. Современные методы и средства
проектирования информационных систем. – М.: Финансы и статистика,
1998.
11.Волкова В.Н. Искусство формализации: От математики – к теории
систем и от теории систем – к математике. – СПб.: СПбГТУ, 1999.
12.Гайсарян С. С. Объектно-ориентированные технологии проектирования
прикладных программных систем. – Центр Информационных
Технологий, http://citmgu.ru, 1998.
13.Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приёмы объектноориентированного проектирования. Паттерны проектирования. / Пер. с
англ. – СПб.: Питер, 2000.
14.Гома Х. UML. Проектирование систем реального времени,
параллельных и распределённых приложений. / Пер. с англ. – М.: ДМК
Пресс, 2002.
15.Грегори К. Использование Visual С++ 6. Специальное издание. / Пер. с
англ. – М., СПб., Киев: Вильямс, 2000.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
180
16.Зиглер К. Методы проектирования программных систем. / Пер. с англ. –
М.: Мир, 1985.
17.Информационные технологии на железнодорожном транспорте:
Учебник для вузов ж.-д. трансп./ Э.К. Лецкий, В.И. Панкратов, В.В.
Яковлев и др. – М.: УМК МПС России, 2000.
18.Йордан Э., Аргила К. Структурные модели в объектноориентированном анализе и проектировании. / Пер. с англ. – М.: ЛОРИ,
1999.
19.Калбертсон Р., Браун К, Кобб Г. Быстрое тестирование. / Пер. с англ. –
М.: Вильямс, 2002.
20.Калянов Г. Н. CASE структурный системный анализ. – М.: ЛОРИ, 1996.
21.Канер С. и др. Тестирование программного обеспечения. / Пер. с англ. –
Киев.: ДиаСофт, 2000.
22.Кантор М. Управление программными проектами. / Пер. с англ. – М.:
Вильямс, 2002.
23.Кармайкл Э., Хейвуд Д. Быстрая и качественная разработка
программного обеспечения. / Пер. с англ. – М.: Вильямс, 2003.
24.Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование.
/ Пер. с англ. – М.: ДМК, 2001.
25.Керниган Б. В., Пайк Р. Практика программирования. / Пер. с англ. –
СПб.: Невский диалект, 2001.
26.Комплекс отраслевых руководящих методических материалов на
информационные
системы
на
железнодорожном
транспорте.
Требования к составу, содержанию и оформлению документов при
создании информационных систем/ МПС. – М., 2000.
27.Коналлен Д. Разработка Web-приложений с использованием UML. /
Пер. с англ. – М.: Вильямс, 2001.
28.Коуд П., Норт Д., Мейфилд М. Объектные модели. Стратегии, шаблоны
и приложения. / Пер. с англ. – М.: ЛОРИ, 1999.
29.Крачтен Ф. Введение в Rational Unified Process. . / Пер. с англ. – 2-е
изд. – М.: Вильямс, 2002.
30.Ларман К. Применение UML и шаблонов проектирования. / Пер. с англ.
– 2-е изд. – М.: Вильямс, 2002.
31.Ларман К. Применение UML и шаблонов проектирования. / Пер. с англ.
: Учеб. пособие – М.: Вильямс, 2001.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
181
32.Леоненков А. В. Самоучитель UML. – СПб.: БХВ-Петербург, 2001.
33.Лефингвел Д., Уидриг Д. Принципы работы с требованиями к
программному обеспечению. Унифицированный подход. / Пер. с англ. –
М.: Вильямс, 2002.
34.Липаев В.В. Системное проектирование сложных программных средств
для информационных систем. – М.: СИНТЕГ, 1999.
35.Липаев
В.
В.
Надёжность
программных
средств.
Серия
“Информатизация России на пороге XXI века”. – М.: СИНТЕГ, 1998.
36.Липаев В.В. Проектирование программных средств. – М.: Высшая
школа, 1990.
37.Липаев В.В. Тестирование программ. – М.: Радио и связь, 1986.
38.Майерс Г. Надёжность программного обеспечения. / Пер. с англ. – М.:
Мир, 1980.
39.Маклаков С.В. BPWin и ERWin. CASE-средства
информационных систем. – М.: ДИАЛОГ-МИФИ, 1999.
разработки
40.Мацяшек Л. Анализ требований и проектирование систем. Разработка
информационных систем с использованием UML. / Пер. с англ. – М.:
Вильямс, 2002.
41.Морган М. Java 2. Руководство разработчика.: Учебное пособие./ Пер. с
англ. – М.: Вильямс, 2000.
42.Microsoft Corporation Принципы проектирования и разработки
программного обеспечения: Учебный курс MCSD/ Пер. с англ. – М.:
Русская редакция, 2000.
43.Ожегов С.И. Словарь русского языка. – М.: Русский язык, 1990.
44.Орлов С. А. Технологии разработки программного обеспечения:
Учебник. – СПб.: Питер, 2002.
45.Рамбо Дж., Якобсон А., Буч Г. UML: специальный справочник. / Пер. с
англ. – СПб.: Питер, 2002.
46.Раскин Д. Интерфейс: новые направления в проектировании
компьютерных систем. / Пер. с англ. – СПб.: Символ-Плюс, 2003.
47.Скотт К. UML. Основные концепции. / Пер. с англ. – М.: Вильямс,
2002.
48.Соммервилл И. Инженерия программного обеспечения. / Пер. с англ. –
2-е изд. – М.: Вильямс, 2002.
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
182
49.Страуструп Б. Язык программирования C++/ Пер. с англ. – 3-е изд. –
СПб.; М.: Невский Диалект – БИНОМ, 1999.
50.Торрес Р. Практическое руководство по проектированию и разработке
пользовательского интерфейса. / Пер. с англ. – М.: Вильямс, 2002.
51.Трофимов С.А. CASE-технологии: практическая работа в Rational Rose.
– М.: БИНОМ, 2001.
52.Фаулер М., Скотт К. UML. Основы. / Пер. с англ. – СПб.: СимволПлюс, 2002.
53.Фаулер М., Скотт К. UML в кратком изложении. Применение
стандартного языка объектного моделирования./ Пер. с англ. – М.: Мир,
1999.
54.Фаулер М. Рефакторинг. Улучшение существующего кода. / Пер. с англ.
– СПб.: Символ-Плюс, 2003.
55.Фокс Дж. Программное обеспечение и его разработка. – М.: Мир, 1985.
56.Фридман А.Л. Основы объектно-ориентированной
программных систем. – М.: Финансы и статистика, 2000.
разработки
57.Черемных С.В. и др. Структурный анализ систем: IDEF-технологии. –
М.: Финансы и статистика, 2001.
58.Шаллоуей А., Тротт Д. Шаблоны проектирования. Новый подход к
объектно-ориентированному анализу и проектированию. / Пер. с англ. –
М.: Вильямс, 2002.
59.Шлеер
С.,
Меллор
С.
Объектно-ориентированный
анализ:
моделирование мира в состояниях. / Пер. с англ. – К.: Диалектика, 1993.
60.Шмуллер Д. Освой самостоятельно UML за 24 часа. / Пер. с англ. – 2-е
изд. – М.: Вильямс, 2003.
61.Элиенс А. Принципы объектно-ориентированной разработки программ. /
Пер. с англ. – 2-е изд. – М.: Вильямс, 2002.
62.Якобсон А., Буч Г., Рамбо Д. Унифицированный процесс разработки
программного обеспечения. / Пер. с англ. – СПб.: Питер, 2002.
63.www.rational.com
64.www.interface.ru
65.www.citforum.ru
66.www.booksites.net/maciaszek
67.www.bettersoftwarefaster.com
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
183
PS
Если усердно работать 8 часов в день, можно выйти в
начальники и работать 12 часов в день.
Роберт Фрост
Ничего не делать – отличное занятие. Но какая огромная
конкуренция!
NN
То, что стоит делать, стоит делать хорошо.
Никола Пуссен
Ужас при мысли об отложенной работе возрастает
пропорционально квадрату времени, на которое она
откладывается.
Янина Пихорская
На работе зря времени не трать: береги каждую потерянную
минуту!
Михаил Генин
Если с первого раза не удалось, попробуйте прочитать
инструкцию.
Роберт Орбен
Бывает, что всё удается. Не пугайтесь, это пройдёт.
Жюль Ренар
Человеку свойственно ошибаться, но для нечеловеческих
ляпов нужен компьютер.
Пол Эрлих
Г. Ф. Довбуш, ПГУПС, кафедра ИВС, 2003/2004