/
Author: Амблер Скотт
Tags: компьютерные технологии программирование программное обеспечение
ISBN: 5-94723-545-5
Year: 2005
Text
БИБЛИОТЕКА ПРОГРАММИСТА
Скотт Амблер
ЭКСТРЕМАЛЬНОЕ ..ЖРАММИРОВАНИЕ
I ИНФИЦИРОВАННЫЙ ПРОЦЕСС
РАЗРАБОТКИ
Облегченные методы моделирования
в контексте гибких проектов
Идеи, принципы и методики
эффективного моделирования
и Написание документации
м Организация сеансов моделирования
и работа в команде
ф WILEY С&ППТЕР
wiley.com
Scon W. Ambler
AGILE MODELING:
EFFECTIVE PRACTICES
FOR EXTREME
PROGRAMMING
©WILEY
wiley.com
i
Скотт Амблер
БИБЛИОТЕКА П РОГРАМ МИСТА
мим w I MriFar I ЖI X Хмм XIII Vr X X X w X XTX м X Чг X
ГИБКИЕ ТЕХНОЛОГИИ:
ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ
И УНИФИЦИРОВАННЫЙ ПРОЦЕСС
РАЗРАБОТКИ
^ППТЕР
Москва Санкт-Петербург - Нижний Новгород Воронеж
Новосибирск • Ростов-на-Дону - Екатеринбург Самара
Киев Харьков - Минск
2005
ББК 32.973-018
УДК 681.3.06
А61
&
Амблер С.
А61 Гибкие технологии: экстремальное программирование и унифицированный процесс
разработки. Библиотека программиста. — СПб.: Питер, 20'05. —412 с.: ил.
ISBN 5-94723-545-5
Книга посвящена гибкому моделированию — процессу, базирующемуся на практической
деятельности и описывающему принципы построения полезных моделей. Она начинается с рас-
смотрения идей, принципов и методологии гибкого моделирования и описания методик, которые
повысят вашу производительность. Кроме того, в этой книге переосмысливаются некоторые
важные вопросы разработки программного обеспечения, такие как написание документации,
организация сеансов моделирования, подбор команды, занимающейся моделированием, примене-
ние UML. Как видно из названия книги, в ней детально рассматриваются вопросы эффективного
моделирования в ХР-проектах.
Книга рассчитана на разработчиков или специалистов по моделированию, которые хотят
повысить свой профессиональный уровень.
ББК 32.973-018
УДК 681.3.06
Права на издание получены по соглашению с Wiley.
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного
разрешения владельцев авторских прав.
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не
менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную
точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги.
ISBN 0-471-20282-7 (англ.)
.ISBN 5-94723-545-5
© 2002 by Scott Ambler
© Перевод на русский язык ЗАО Издательский дом «Питер», 2005
© Издание на русском языке, оформление ЗАО Издательский дом «Питер», 2005
Содержание
Вступление...........................................................13
Предисловие......................................................... 15
Что такое гибкое моделирование?................................15
Что вы найдете в этой книге?...................................15
Чего вы не найдете в этой книге?...............................16
Кто я такой?.................................................. 16
Кто вы?....................................................... 17
Кто мне помогал?...............................................17
От издательства................................................18
Часть I • Введение в гибкое моделирование............................19
Глава 1 • Введение................................................. 20
Введение в гибкую разработку программного обеспечения..........23
Манифест гибкой разработки программного обеспечения............23
Принципы гибкой разработки программного обеспечения............25
Гибкое моделирование.......................................... 26
Специалисты по гибкому моделированию — кто они?..........29
Краткий обзор гибкого моделирования......................30
Что такое гибкие модели?.................................31
Чем является и чем не является гибкое моделирование?.....35
Учебный пример SWA Online.................................. 37
Краткое содержание этой книги . . . .^.........................38
6 Содержание
Глава 2 • Ценности гибкого моделирования.............................. 39
Общение..........................................................40
Простота.........................................................41
Обратная связь...................................................43
Смелость........................................................ 44
Смирение.........................................................47
Вдали от мамы и яблочного пирога.................................47
Глава 3 • Базовые принципы.............................................49
Главная цель — программное обеспечение...........................50
Еще одна цель — продолжать проект................................50
Путешествуйте налегке............................................51
Добивайтесь простоты........................................... 52
Ожидайте изменений.............................................. 52
Изменения должны быть небольшими.................................53
Модель должна решать конкретную задачу...........................54
Множество моделей................................................55
Вам нужен набор методик..........................................58
Качественная работа..............................................58
Быстрая обратная связь...........................................59
Повышайте отдачу от ресурсов, полученных от заинтересованных лиц.61
Почему это базовые принципы?.....................................61
Глава 4 • Дополнительные принципы......................................62
Содержание важнее формы..........................................62
Учитесь друг у друга.............................................65
Знай свои модели.................................................65
Приспосабливаем по месту ........................................65
Открытые и доброжелательные контакты.............................66
Доверяйте человеческим инстинктам........,.......................67
Выгода от применения этих принципов .............................67
Глава 5 • Базовые методики.............................................68
Методики итеративного и инкрементного моделирования . . . .......69
Применяйте нужный артефакт (артефакты)................... 69
Создавайте несколько моделей параллельно...................70
Переходите от одного артефакта к другому................. 74
Моделируйте постепенно................................... 75
Методики эффективной работы в группе.............................76
Моделируйте в группе.......................................76
Активное участие заинтересованных лиц......................77
Совместное владение . . ..,............................... 79
Демонстрируйте модели открыто..............................79
Упрощающие методики..............................................80
- Содержание
7
Создавайте простое содержание...............................80
, Изображайте модели просто...................................81
Используйте простейшие инструментальные средства......... .82
Методики подтверждения правильности работы....................... 83
Учитывайте тестируемость.....;............................ 83
Подтверждайте модель кодом..................................83
Глава 6 • Дополнительные методики......................................85
Методики, повышающие продуктивность.............................. 85
Применяйте стандарты моделирования..........................86
Не увлекайтесь паттернами...................................88
Используйте имеющиеся ресурсы............................... 88
Методики гибкого подхода к документации.....................89
Избавляйтесь от временных моделей........................... 89
Формализуйте модели соглашения.............................. 90
Совершенствуйте только в случае необходимости. .......... .90
Методики, ориентированные на мотивацию...........................94
Моделируйте, чтобы понять.................................... . 94
Моделируйте, чтобы общаться.................................94
Просто хорошие идеи.............................................. 95
Умейте пользоваться инструментальными средствами............96
Рефакторинг................................................ 96
Сначала тест, потом программа...............................96
Как планировать применение методик AM............................97
Глава 7 • От хаоса к порядку: как объединены методики AM..............98
Базовые методики................................................98
Методики эффективной работы в группе..........: . . ....^ . . 99
Методики итеративного и инкрементного моделирования........100
Методики, которые позволяют упрощать.......................101
Методики подтверждения правильности работы.................101
Дополнительные методики.........................................102
Методики, имеющие отношение к документации.................102
Методики мотивации.................,.......................102
Методики, повышающие продуктивность........................102
Как категории соотносятся -друг с другом . .....................103
Хаос и порядок: упорядочивание..................................105
Забегая вперед............................................. . Юб
Часть II • Гибкое моделирование на практике...........................107
Глава 8 • Общение................................................... 109
Как мы общаемся?................................................109
Факторы, влияющие на общение.....................................НО
8 Содержание
Общение и гибкое моделирование.................................. 112
Эффективное общение . ............................................ИЗ
Глава 9 • Учимся культуре гибкого моделирования.......................115
Преодолевайте заблуждения 6 моделировании........................115
Заблуждение № 1: модель = документация.....................115
Заблуждение № 2: вы можете все продумать с самого начала....116
Заблуждение № 3: моделирование предполагает крупномасштабный
программный процесс.................................. 117
Заблуждение № 4: вы должны «заморозить» требования.......117
Заблуждение № 5: ваш дизайн высечен в камне..............117
Заблуждение № 6: вы должны использовать CASE-средства.....118
Заблуждение № 7: моделирование — пустая трата времени.....118
Заблуждение № 8: все вращается вокруг моделирования данных. . . . 119
Заблуждение № 9: все разработчики знают, как моделировать.121
Отдавайте предпочтение малому....................................121
Умерьте пыл!.............ч.......................................122
Четко соблюдайте права и обязанности............................ 123
Продумайте презентацию заинтересованным лицам.....................125 .
Глава 10 • Используем простейшие средства.............................128
Гибкое моделирование с помощью простых средств...................129
Преимущества простых средств......\........................130
Недостатки простых средств.................................131
Когда следует использовать простые средства? >ч............131
Технология в помощь простым средствам..................... 132
Эволюция модели................................................. 134
Гибкое моделирование с помощью CASE-средств......................139
Выбираем CASE-средство.................................... 139
Избавляемся от заблуждений, связанных с CASE-средствами....141
Генерируемый исходный код..................................142
Генерируемая документация..................................143
Используйте возможности представления информации.................144
Какое средство, такая и модель...................................145
Практическое применение простейших средств.......................146
Глава И • Рабочее место гибкого разработчика..........................147
Помещение для гибкой разработки ,................................147
Эффективные рабочие зоны ..:.....................................151
Как это осуществить? . . ........................................151
Глава 12 • Группы гибкого моделирования ..............................153
Берем несколько хороших разработчиков.......................... 153
Специалисты или универсалы?................................155
Содержание
9
Признайте, что в гибком моделировании нет «Я»...................158
Потребуйте от всех активного участия............................159
Моделируйте в группе.......................-....................160
Как это осуществить?............................................162
Глава 13 • Сеансы гибкого моделирования..............................164
Продолжительность сеанса моделирования.......................... 164
Типы сеансов моделирования......................................166
Участники сеансов моделирования................................ 168
Формальность сеансов моделирования..............................171
Как это осуществить?............................................173
Глава 14 • Гибкая документация........................?..............175
Зачем нужна документация?....................................... 176
Когда модель становится постоянной?.............................180
Компромиссы, связанные с документацией....................182
Что значит путешествовать налегке?........................185
Какой документ является гибким?...........................187
Какую документацию нам следует создавать?.................190
Когда следует обновлять документацию?.....................190
Эффективная передача документации.........................1^5
Методы повышения гибкости документации....................195
Как это осуществить?......................................199
Глава 15 • По ту сторону UML.........................................200
UML — это еще не все.........~..................................200
UML — это слишком сложно........................................203
UML — это не методология или процесс............................203
Не рассчитывайте на появление исполняемого UML в ближайшем будущем . . 204
Как применять UML на практике...................................205
ЧАСТЬ Ш • Гибкое моделирование и экстремальное
программирование (ХР).............................................207
Глава 16 • Восстанавливаем справедливость............................208'
Моделирование является частью ХР................................209.
Документация существует, и с этим приходится считаться..........210
ХР и UML........................................................212
Итак, каково резюме почтенного собрания?........................214
Глава 17 • Гибкое моделирование и экстремальное
программирование ... /...............................................215
Совместимость AM и ХР...........................................215
10 Содержание
Рефакторинг и гибкое моделирование.............................216
Методика «Сначала-тест-потом-программа» и гибкое моделирование.219
Какие методики гибкого моделирования следует принять?..........220
Глава 18 • Гибкое моделирование в жизненном цикле ХР-проекта... 221
Этап исследования..............................................222
Этап планирования..............................................223
Этап итераций реализации.......................................225
Производство...................................................227
Сопровождение................................................ 228
Как это осуществить?...........................................229
Глава 19 • Моделирование на этапеисследования в ХР-проекте..........231
Прежде всего — базовые требования (IRUF)...................... 231
Метафоры, архитектура и пробы архитектуры............... -.....234
Закладываем основы проекта.....................................237
Глава 20 • Моделирование во время ХР-итерации: поиск товара ... .238
Задача............;.......................................... 239
Моделирование физической схемы базы данных.....................240
Наблюдения.....................................................242
Глава 21 • Моделирование во время ХР-итерации:
подсчет общей суммы заказа......................................245
Задача.........................................................245
Моделирование требований ведет к спасению ,....................246
Помощь специалиста со стороны..................................248
Сеанс быстрого проектирования..................................248
Формализуйте модели соглашения.................................251
А как насчет изменений в будущем?............................. 251
Наблюдения.....................................................253
Как это осуществить?...........................................253
Часть IV • Гибкое моделирование
и унифицированный процесс..................................... 255
Глава 22 • Гибкое моделирование и унифицированный процесс..........256
Моделирование в унифицированном процессе.......................256
Насколько совместимы AM и UP?................................ 258
Как добиться гибкости..........................................262
Глава 23 • Гибкое моделирование в жизненном цикле .
унифицированного процесса.......................................263
Содержание 11
Рабочие потоки, связанные с моделированием.......................263
Бизнес-моделирование.......................................264
Требования. . .............................................265
Анализ и проектирование....................................266
Управление инфраструктурой. ...............................269
Потоки, не относящиеся к моделированию...........................272
Реализация.................................................272
। Тестирование.................................................. 272
Управление проектом....................................... 273
Управление конфигурацией и изменениями.....................273
Среда .................................................... 274
Размещение.................................................275
Эксплуатация и сопровождение.............................. 275
Как это осуществить?.................., ... :...................275
Глава 24 • Гибкое бизнес-моделирование................................277
Бизнес-модель (основная модель) Use Case..................... 278
Простая бизнес-объектная модель................................. 279
Гибкая бизнес-спецификация.......................................281
Видение бизнес-среды.............................................284
Как это осуществить..............................................284
Глава 25 • Гибкое определение требований.............................. 285
Контекстная модель............................................... 286
Модель Use Case..................................................288
Последовательность кадров для элементов Use Case.................293
Спецификация.....................................................296
Как это осуществить? ............................................ 298
Глава 26 • Гибкий анализ и проектирование.............................зоо
Пересмотр модели анализа и модели проектирования в UP.............301
Моделирование архитектуры......................................... 303
Создание реализаций элементов Use Case......................... 308
Не пора ли совершенствовать элементы Use Case?...................312
Не пора ли использовать CASE-средства?...........................316
Моделирование классов на уровне проектирования...................317
Моделирование данных..............................................320
Ожидайте изменений............................................... 323
Как это осуществить?..............................................324
Глава 27 • Гибкое управление инфраструктурой . ?.................... .326
Модели инфраструктуры............................................327
Моделирование Инфраструктуры............................'........329
Нисходящее моделирование..................................330
12 Содержание
Восходящее моделирование..................................330
Сравним два подхода.......................................331
Применение стандартов и руководств..............:.............332
Группы по созданию базовой инфраструктуры......................333
Применение AM группами по созданию базовой архитектуры.........335
Как это осуществить?...........................................336
Глава 28 • Применение AM в UP-проекте................................338
Как это осуществить?...........................................342
Часть V • Глядя в будущее............................................343
Глава 29 • Внедряем гибкое моделирование: преодоление
трудностей........................................................344
Оцените степень совместимости....................-............ 345
Когда AM принесет вам пользу..............................345
Когда AM вам не поможет.................................. 347
Добивайтесь простоты...........................................348
Преодолевайте трудности, связанные с организацией и ее культурой.349
Скептично настроенные разработчики........................349
Слишком бдительные «надзиратели»..........................350
Власть имущие — бумажные крысы............................351
Принцип «поваренной книги».............................. 352
Неспособность признать свою вину..........................352
Создание излишней документации как страховка «от кирпича».353
Преодолевайте трудности, связанные с реализацией проекта.......354
Группа рассредоточена в разных местах.....................354
Передача работы другим группам............................356
Контракт с фиксированной ценой............................356
Подумайте о частичном применении AM............................357
Как это осуществить?...........................................358
Глава 30 • Заключение: стремитесь к успеху...........................359
Заблуждения, связанные с AM................................... 359
Правда и ложь о гибком моделировании...........................360
Ресурсы для гибкого моделирования............................. 362
Несколько слов на прощание.....................................362
Приложение А • Методики моделирования................................364
Глоссарий терминов и сокращений......................................384
Список литературы................................................... 401
Алфавитный указатель.................................................407
Вступление
Когда Скотт попросил меня написать вступление к этой книге, я был удивлен
и обрадован. Обрадовался я по нескольким причинам: каждому было бы приятно,
я Думаю, связать свое имя с такой великолепно написанной книгой. Кроме того,
гибкие методологии (особенно экстремальное программирование) в настоящее
время являются областью моих интересов. Удивился же оттого, что среди тех «со-
ветчиков», которые отговаривали Скотта от увлечения этой темой, я был одним из
первых и наиболее громким. «Я растолкую. Нет, это слишком объемный вопрос.
Я его обобщу».
По моему мнению, разработка программного обеспечения происходит наилуч-
шим образом, когда специализация минимальна. Я верю (и учу этому других), что
самые лучшие результаты можно получить от команды индивидуальных личностей,
которые помогают друг, другу там и тогда, где и когда это возможно, не выясняя,
кто из них архитектор, кто — проектировщик, кто занимается моделированием, кто
программирует, а кто выполняет тестирование. Не то чтобы все мы были божествен-
ными специалистами, людьми Ренессанса от программирования, но мы в состоянии
работать вместе и по мере возможности объединять свои усилия в одном деле.
Кроме того, разрабатывая программное обеспечение (это снова мое мнение),
лучше всего моделировать как можно меньше. Основная задача разработки про-
граммного обеспечения — это разрабатывать программное обеспечение. Слишком
много времени уходит на подготовку, слишком мало времени остается на самое
важное — создание надежного, хорошо спроектированного, высококачественного
программного обеспечения. Качество программного обеспечения не всегда корре-
лирует с качеством моделей, созданных при помощи новейших средств проекти-
рования до начала построения системы.
Итак, когда Скотт предложил рассмотреть эту тему и организовал форум
и веб-сайт по гибкому моделированию, я был против. Я опасался, что слишком
сильный упор на моделирование способен увести нас в сторону от таких вопро-
сов, как организация команды и необходимые для создания хороших программ
14 Вступление
навыки. Я высказывал это, хотя и не в таких определенных выражениях, в форуме
Скотта и в частных письмах.
Однако оказалось, что Скотт увидел то, чего не заметил я. Если люди соби-
раются работать вместе, чтобы использовать гибкие методы для разработки про-
граммного обеспечения, им недостаточно для этого одного понимания и энтузи-
азма. Они должны обладать навыками. Команда должна иметь навыки анализа,
моделирования, проектирования, программирования и тестирования — всего того,
что лежит в основе хороших программ. Кроме того, они должны применять эти
навыки в соответствии с принципами гибкой разработки, один из которых состо-
ит в упоре на «людей и контакты вместо процессов и средств», как мы писали
в «Манифесте гибких методов».
Об этом и начал говорить Скотт — в своем форуме, на своем веб-сайте и в этой
книге. Он показал, как эффективно применять облегченные методы моделирова-
ния в контексте гибких проектов. Он показал, как производить моделирование
в обычных проектах, и дал советы, которые позволяют сделать их более гибкими.
Что еще более важно; он сделал это на базе набора идей, принципов и методик, ко-
торые позволяют отдельным людям и командам эффективно моделировать. Он
постоянно следил за игрой в создание программного обеспечения, концентриру-
ясь на отдельных навыках и методиках моделирования, которые действительно
необходимы.
Скотт рассматривает использование простейших средств, рабочее простран-
ство, способ подбора группы и совместной работы. Мне особенно понравилась,
фраза сержанта Расчека из «Звездной пехоты» Хайнлайна: «У меня есть только
одно правило: все сражаются, никто не отступает. Кто струсит, того я пристрелю
сам». Скотт рассмотрел все варианты моделирования, от экстремального програм-
мирования до унифицированного процесса, и добился в этом весьма впечатляю-
щих успехов.
Одна из обязанностей всех, кто пишет вступления, — дать указания, кому сле-
дует читать эту книгу. Вот мои указания: прочтите эту книгу, если вы разработ-
чик программного обеспечения, которому для работы нужны знания по модели-
рованию, — то есть если вы разрабатываете программное обеспечение. Прочтите
эту книгу, если вы занимаетесь моделированием и должны обеспечить примени-
мость результатов своей работы в разработке программного обеспечения в наши
дни, когда изменения непрерывны, — то есть если вы занимаетесь моделировани-
ем. И наконец, прочтите эту книгу, если вы — менеджер по разработке програм-
много обеспечения, которому хочется понять, что сулит гибкая разработка про-
граммного обеспечения для ваших проектов, — то есть если вы — менеджер по
разработке программного обеспечения. Если вы каким-то образом связаны с раз-
работкой программного обеспечения, эта книга вам поможет.
Книга Скотта «Гибкое моделирование» описывает навыки, необходимые для
эффективного проектирования в ходе работ по созданию программного обеспе-
чения, которое, в свою очередь, необходимо для быстрой поставки качественных
программ заказчику.
Молодец, Скотт!
Рон Джеффриз
Предисловие
Если вы читаете это предисловие, значит вы, вероятно, пытаетесь определить, сто-
ит ли покупать эту книгу. Мне нравится ваша позиция! Чтобы помочь вам сде-
лать выбор, я попытаюсь кратко ответить на некоторые главные вопросы, которые
у вас, скорее всего, возникли.
Что такое гибкое моделирование?
Гибкое моделирование (Agile Modeling, AM) — это базирующийся на практи-
ческой деятельности процесс, описывающий, как строить полезные модели.
Современный подход к моделированию часто оказывается нефункциональным.
В крайнем варианте, когда моделирование не производится вообще, програм-
мы оказываются недостаточно продуманными и часто требуют значительной до-
работки. Другая крайность — неумеренное создание моделей и документов, кото-
рые замедляют собственно разработку до черепашьей скорости. AM поможет вам
определить разумный объем моделирования, когда его достаточно для того, чтобы
изучить и документировать систему, но не настолько много, чтобы тяжесть моде-
лей замедлила развитие проекта.
Методики AM могут применяться командой, которая использует гибкий под-
ход к разработке программного обеспечения, и, в частности, применяет гибкие
процессы разработки, такие, как экстремальное программирование (ХР), DSDM,
SCRUM или FDD. Однако AM может использоваться также для повышения эф-
фективности, а нередко и упрощения процесса моделирования в проектах, не ори-
ентированных в полной мере на гибкий подход.
Что вы найдете в этой книге?
Эта книга начинается с рассмотрения идей, принципов и методологии AM и опи-
сания методик, которые повысят вашу производительность при создании моде-
лей. Вы можете с радостью обнаружить, что давно уже применяете некоторые из
этих методик, хотя и побаивались раньше говорить об этом окружающим, и с не
меньшей радостью обнаружить новые способы повышения эффективности моде-
лирования.
16 Предисловие
Кроме того, в этой книге переосмысливаются некоторые важные вопросы раз-
работки программного обеспечения — как, в частности, писать документацию, как
хорганизовать сеансы моделирования и команду, занимающуюся моделированием,
и где использовать UML. Как сказано в названии книги, в ней детально рассмат-
риваются вопросы эффективного моделирования в ХР-проектах. В противопо-
ложность тому, что вы, может быть, слышали, моделирование — это важная часть
ХР. В этой книге рассказывается, как упростить процесс моделирования по срав-
нению с технологиями унифицированного процесса Rational (Rational Unified
Process, RUP) или корпоративного унифицированного процесса (Enterprise
Unified Process, EUP).
Чего вы не найдете в этой книге?
В этой книге вы не найдете инструкций по созданию моделей. Так, здесь не опи-
саны методики по написанию историй пользователя, элементов Use Case или
бизнес-правил. Эта книга не может рассматриваться в качестве введения в UML,
моделирование данных или проектирование, ориентированное на удобство ис-
пользования. Эту книгу следует рассматривать в качестве широкой картины про-
цесса моделирования, не содержащей тонких деталей. Это очень похоже на ХР,
в котором описывается процесс разработки программного обеспечения, а не то,
как именно следует программировать.
Более того, эта книга отличается от всех книг по моделированию в разработке
программного обеспечения, которые вы -когда-либо читали. Старые книги по ме-
тодологии моделирования описывали несколько артефактов моделирования, на-
пример, элементы Use Case, диаграммы последовательности и диаграммы клас-
сов — и определяли методологию использования этих артефактов в моделировании
программного обеспечения. AM использует иной подход — оно определяет мето-
дики моделирования, совершенно не настаивая на использовании определенных
типов моделей. Вместо этого вам предлагается изучать методы работы с различ-
ными артефактами моделирования, добавляя их в копилку опыта по мере работы.
Я верю, что когда (например, при изменении базовой технологии) другие методы
моделирования окажутся бесполезными, вы обнаружите, что принципы и методы
AM пройдут испытание временем, поскольку они поистине фундаментальны.
Кто я такой?
Несмотря на то что я живу к северу от Торонто, я являюсь старшим консультан-
том и президентом компании Ronin International, Inc, которая располагается в Ден-
вере. Я разрабатываю программное ббеспечение с середины 1980-х и занимаюсь
объектно-ориентированным программным обеспечением с начала 1990-х. Я актив-
но занимался созданием программ, имевших важнейшее значение для работы за-
казавших их клиентов, а в свободное время описывал свой опыт в книгах, жур-
налах и онлайновых изданиях. В течение последних нескольких лет я всерьез
занимался процессами разработки программного обеспечения, в том числе фор-
Предисловие 17
мализованными процессами, такими как унифицированный процесс (UP), и гиб-
кими процессами типа экстремального программирования (ХР), которые помогли
бы организациям повысить эффективность разработки программного обеспече-
ния. Кроме того, я больше люблю играть активную роль в проектах по разработке
программного обеспечения и лично прикладывать руки к клавиатуре, насколько
это возможно в моей роли главного разработчика или руководителя группы.
Кто вы?
Вы, вероятно, — разработчик или специалист по моделированию, который хочет
повысить свою эффективность как профессионала в создании программного обес-
печения. Вам любопытно, как производить моделирование в ХР-проектах или как
сократить объем моделирования в проектах по RUP. Вы можете также быть ме-
неджером проекта или экспертом по процессам, пытающимся понять, что же это
за «болтовня про гибкую разработку».
Кто мне помогал?
Я рад поблагодарить за идеи, вошедшие в эту книгу, специалистов, имена которых
перечислены ниже:
Глен Б. Аллеман (Glen В. Alleman)
-Джеймс Эймс (James Ames)
Дейв Астельс (Dave Astels)
Брюс Бэчеллер (Bruce Bacheller)
Кент Бек (Kent Beck)
Джон Беннет (John Bennett)
Лари Бернстайн (Larry Bernstein)
Говард Боллинг (Howard Bolling)
Терри Боллинджер (Terry Bollinger)
Гради Буч (Grady Booch)
Ларри Брюнель (Larry Brunelle)
Скотт Клеммонс (Scott Clemmons)
Алистер Кокбурн (Alistair Cockburn)
Энтони ДаСильва (Anthony DaSilva)
Рэчел Дэвис (Rachel Davies)
Крейг Деволт (Craig Dewait)
Брайан Доллери (Bryan Dollery)
Сара Эдвардс (Sara Edwards)
Дейл Эмери (Dale Emery)
Майкл С. Фитерс (Michael С. Feathers)
Рик Фишер (Rick Fisher)
Питер Фореман (Peter Foreman)
Мартин Фаулер (Martin Fowler)
Мартин Гайнти (Martin Gainty) .
Адам Гераш (Adam Geras)
Джон Гудсен (John Goodsen)
Леонард Грецки (Leonard Greski)
Лайонел Гриффит (Lionell Griffith)
Дэйвид Хексель (David Hecksei)
Матс Хеландер (Mats Helander)
Джим Хайсмит (Jim Highsmith)
Люк Хохманн (Luke Hohmann)
Джерри Хюммель (Gerry Hummell)
Рон Джеффриз (Ron Jeffries)
Питер Лаппо (Peter Lappo)
Марк Левисон (Mark Levison)
Дейв Любински (Dave Lubinsky)
Роберт С. Мартин (Robert С. Martin)
Линн X. Максон (Lynn Н. Maxson)
Билл Микин (Bill Meakin)
Дрю Миллс (Drew Mills)
Джон Налбоун (John Nalbone) '
Мирослав Новак (Miroslav Novak)
Ларри О’Брайан (Larry O’Brien)
Том Парди (Tom Pardee)
Эрих Паулик (Erich Pawlik)
Нейл Питман (Neil Pitman)
Чарли Пул (Charlie Poole)
18 Предисловие
Мэри Поппендик (Mary Poppendieck)
Гарет Ривз (Gareth Reeves)
Дэвид М. Рубин (David М. Rubin)
Марчело Лопес Руиз (Marcelo Lopez
Ruiz)
Джефф Рулей (Jeff Ruley)
Алан Шеллоуэй (Alan Shalloway)
Дуг Смит (Doug Smith)
Майк Смит (Mike Smith)
Роджер Смит (Roger Smith)
Джим Стендли (Jim Standley)
Др. Гернот Стейрк (Dr. Gernot Starke)
Дэн Стерлинг (Dan Sterling)
Брайан Тарбокс (Brian Tarbox)
Дейв Томас (Dave Thomas)
Нейл Торне (Neil Thorne)
Джон Уэлш (John Welch)
Гэри Уинтерс (Geri Winters)
Клаус Вюстфелд (Klaus Wuestefeld)
Эд Йордон (Ed Yourdon)
От издательства
Ваши замечания, предложения и вопросы отправляйте по адресу электронной
почты comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
Подробную информацию о наших книгах вы найдете на веб-сайте издательства:
http://www.piter.com.
Часть
Введение в гибкое
моделирование
Эта часть закладывает осйовы для понимания вопросов, рассматривающихся в кни-
ге. Здесь детально обсуждаются ценности, принципы и методики гибкого модели-
рования (Agile Modeling, AM). Этот раздел включает в себя следующие главы:
► Глава 1: Введение. В этой главе рассматриваются проблемы, возникающие се-
годня перед разработчиками программного обеспечения, и описывается, как
гибкая разработка программного обеспечения и гибкое моделирование могут
способствовать разрешению этих проблем.
► Глава 2: Ценности гибкого моделирования. В этой главе обсуждаются пять
ценностей AM.
► Глава 3: Базовые принципы. В этой главе детально разбираются базовые прин-
ципы AM, которые имеют первостепенное значение для тех, кто занимается
гибким моделированием.
► Глава 4: Дополнительные принципы. В этой главе мы обсуждаем дополни-
тельные принципы AM, которые подкрепляют действие базовых принципов.
► Глава 5: Базовые методики. В этой главе представляются важнейшие мето-
дики AM. Если вы не применяете какие-то из них, вы не можете говорить, что
занимаетесь гибким моделированием. Эти методикй описывают, как приме-
нять в моделировании итеративный и инкрементный подход, как поддержи-
вать и улучшить работу группы, как добиться простоты и как гибко проверять
результаты работы.
► Глава 6: Дополнительные методики. Эти методики касаются мотивации для
создания гибких моделей, создания гибкой документации и повышения вашей
эффективности как специалиста по гибким методам моделирования.
► Глава 7: От хаоса к порядку: как объединены методики AM. В этой главе
представлен обзор методов объединения отдельных методик для повышения
общей производительности.
Введение
Чтобы изменить судьбу,
измени свое оиюшеиие к ней.
Современная ситуация в разработке программного обеспечения весьма далека от
идеала. Системы регулярно поставляются позже намеченного срока и с превы-
шением бюджета, если поставляются вообще. Системы часто не удовлетворяют
заказчиков, и мы вынуждены разрабатывать их снова и снова. Наши заказчики
недовольны возникающими проблемами и никак не хотят ни поверить нам, ни
сотрудничать с нами, потому что они и так уже потратили массу времени пона-
прасну. Чтобы стало понятно, как все плохо, заметим, что при этом наши заказчи-
ки не слишком хорошо понимают, что мы вообще делаем, как мы это делаем и за-
чем мы это делаем, — и в результате они возлагают на нас неоправданные надежды
и не оказывают поддержки, которая нужна нам для удовлетворения их запросов.
Все это, понятно, не слишком радует разработчиков программного обеспече-
ния. Мы проводим на работе много времени, нередко 50, 60 или 70 часов в не-
делю и быстро сгораем. Когда в ходе проекта возникают проблемы, а часто это
происходит еще до его начала, мы показываем пальцами на других. Подходящими
мишенями для нашего пальца оказываются наши «умники-боссы», которые, как
мы полагаем, недостаточно квалифицированны даже для того, чтобы почистить
собственные ботинки, «бумажные крысы» из отдела дальше по коридору, которые
требуют совершенно невообразимого количества документации, и наши «глупые
пользователи», которые вечно не знают, что им нужно, — когда ни спросишь их,
чего же они хотят, они ничего не могут сказать. Естественно, мы никогда не счи-
таем себя виноватыми — мы великолепны, несмотря ни на что. Ну что же мы мо-
жем сделать, если работаем над проектом, в котором возникли проблемы? Иногда
мы посвящаем все наше рабочее время и еще сверх того бесполезным попыткам
выполнить те нереальные требования, которые перед нами поставлены, призна-
вая в итоге, что проект — провальный (Йордон, 1997). Порой мы полностью устра-
няемся от проекта. Зная, что этот проект обречен, мы приходим к выводу, что
можно, по крайней мере, научиться чему-то такому, что не стыдно будет добавить
Введение 21
в резюме. После этого мы скачиваем из Интернета новые средства разработки
и начинаем играть с ними.
Почему же мы пришли к такому печальному положению дел? Во-первых, я по-
лагаю, что многие люди перестали понимать тот факт, что основная задача разра-
ботчиков программного обеспечения — как можно более эффективно и произво-
дительно создавать системы, назначение которых — удовлетворять требованиям
пользователей. В контексте данного обсуждения я полагаю, что понятие «систе-
ма» включает в себя программное обеспечение, документацию, аппаратуру, меж-
платформенные программные средства, методику инсталляции и методы работы.
Проще говоря, организации утратили видение всего процесса поставки программ-
ного обеспечения заказчику и, к сожалению, организовали отделы ИТ в виде ко-
манд узких специалистов, которые часто были не в состоянии увидеть картину
в целом. Я полагаю, что это произошло из-за того, что одно, а то и два поколения
ИТ-специалистов поверили в то, что для разработки программного обеспечения
им достаточно будет следовать некоторому набору инструкций. Мы можем опи-
сать эти инструкции, известные под названием предопределенных процедур, или
всеобъемлющих процессов создания ПО. Предопределенные процессы создания
программного обеспечения, такие как унифицированный процесс (Кратчен, 2000;
Амблер, 2001b), процесс OPEN (Грэм, Хендерсон-Селлерс и Йонесси, 1997)
или Процесс создания объектно-ориентированного программного обеспечения
(Амблер, 1998; Амблер, 1999), имеют свою область применения. Но в определен-
ных ситуациях они могут быть не такими уж подходящими, как утверждают их
приверженцы. Проблема с этими процессами в том, что они обычно слишком упи-
рают на предопределенные процедуры и создаваемые артефакты. Эти процессы
часто вводятся в тех организациях, в которых людей считают «взаимозаменяемы-
ми». Другими словами, в подобных организациях полагают, что, внедрив правиль-
ный процесс и построив достаточное количество артефактов, можно относитель-
но легко перебрасывать людей из проекта в проект. Мой опыт говорит, что замена
людей из-за их невысокой продуктивности довольно характерна как раз для орга-
низаций, использующих всеобъемлющие процессы разработки. Реальность состо-
ит в том, что замена работающего человека — дело достаточно трудное, независимо
от того, какой процесс вы используете, так что возможность «взаимозаменяемо-
сти» в лучшем случае сомнительна.
Интересно, что предопределенные процессы нравятся менеджерам, в то время
как для большинства разработчиков они малопривлекательны. Предопределенные
процессы обычно базируются на парадигме управления-и-контроля, которая дает
возможность менеджерам контролировать события или, как минимум, позволяет
им полагать, что они контролируют события. Они обосновывают мнение менед-
жеров насчет уменьшения роли заказчиков (заинтересованных в разработке лиц),
с которыми теперь можно будет встречаться лишь в ходе нескольких коротких
сеансов определения требований. После этого заказчиков можно будет игнори-
ровать вплоть до того момента, когда возникнет необходимость в одобрении по-
строенной системы. Другая проблема состоит в том, что если дело начинает идти
плохо, разработчики быстро прекращают текущую работу, выбрасывая все то хо-
рошее и плохое, что уже сделано, после чего нередко обнаруживают, что оказались
22 Глава 1 • Введение
в еще большем бардаке, чем раньше. Мой опыт показывает, что упрощения часто
ведут не к спасению, а еще глубже в болото, делая наш «похоронный марш» еще
более безнадежным.
Я полагаю также, что способ обучения разработчиков их профессии содержит
несколько потрясающих недостатков. По большей части наши колледжи и универ-
ситеты делают отличную работу по подготовке разработчиков начального уровня.
Однако даже если школы проделали отличную работу и каждый студент получил
степень или диплом, я подозреваю, что у нас все равно возникнет проблема, свя-
занная с врожденным свойством разработчиков программного обеспечения. Пока
разработчики молоды, в свои восемнадцать-двадцать лет они в основном изучают
технологии и работают с ними. Они считают себя PERL-программистами, знато-
ками Linux, разработчиками Enterprise JavaBeans (EJB) или .NET. Технология для
них важнее всего. Поскольку технологии постоянно изменяются, молодые разра-
ботчики имеют тенденцию, лишь изучив технологию, применять ее в одном-двух
проектах, после чёго переходить к изучению новой технологии или последней
версии той, с которой они работали раньше. Проблема состоит в том, что они сно-
ва и снова продолжают изучать все те же оттенки того же нижнего уровня базо-
вых знаний. .
К счастью, многим разработчикам это не страшно даже после несколько витков
технологий — если вы писали код управления транзакциями на COBOL, Java и
С#, вы начинаете понимать, что базовые принципы не меняются. То же самое вер-
но и при доступе к базам данных в различных оболочках, разработке пользователь-
ских интерфейсов и во многих других областях. В скором времени разработчики
начали понимать, что многие базовые вещи, которые они могли изучать, а могли
и не изучать в школе, остаются неизменными вне зависимости от технологии. Это
понимание часто приходит к разработчикам ближе к тридцати годам, а иногда
и после тридцати, в то время, когда люди понемногу остепеняются, женятся и поку-
пают дома. Это не случайность, поскольку эти новые запросы означают, что разра-
ботчики не в состоянии больше тратить значительную часть времени на изучение
новых технологий, они хотят уделять время и семье. Внезапно для них становится
притягательным руководящее положение — лидер проекта, руководитель проекта
или специалист по (не гибкому) моделированию, поскольку на этих должностях
от них не требуется постоянно и в большом объеме изучать новые технологии.
Итак, к тому времени, когда эти разработчики действительно начинают понимать
свое дело, они уже понемногу перестают быть разработчиками. К счастью, прихо-
дит новая «молодая шпана», и цикл повторяется. В результате большинство тех лю-
дей, которые активно разрабатывают программное обеспечение, умеют это делать
не лучшим образом, а те, у кого «умение» на высоте, не занимаются разработкой.
С коммерческой точки зрения дело обстоит не лучше. ЕЕаши заказчики не по-
нимают, как разрабатывается программное обеспечение и почему для нас вполне
естественно остановиться и подумать. Мой опыт говорит, что немногие разработ-
чики расскажут вам, от начала до конца, как будет разрабатываться программное
обеспечение, демонстрируя хорошее понимание различных вопросов, которые мо-
гут возникнуть по ходу проекта — просто потому, что разработка программного
обеспечения весьма сложна. Кроме того, наши заказчики на самом деле обычно
Манифест гибкой разработки программного обеспечения 23
не заинтересованы принимать участие в сложном процессе, поскольку они плохо
понимают происходящее и в такой ситуации предпочитают оставить подробности
на наше усмотрение, чтобы иметь возможность вернуться к собственным делам.
Они полагают, что их участие будет ограничено одним или двумя совещаниями по
определению требований в начале работы над проектом, просмотром основных до-
кументов, утверждением блестящих (хотя порой и не соответствующих действи-
тельности) отчетов о состоянии проекта, тестированием приемки непосредствен-
но перед поставкой продукта и окончательным утверждением системы, нередко со
срывом сроков и превышением бюджета. Так было всегда, ИТ-профессионалы го-
ворили им, что так и должно быть, и часто они вообще не задавались вопросом, по-
чему же это именно так. Странно, что они терпят такое положение. Они просили
программы, которые должны полностью удовлетворять их потребностям, а разра-
ботчики показывают им пачки документов, отчеты о проделанной работе, какие-то
тесты, и, в конце концов, если все идет хорошо, — какое-то программное обеспече-
ние. Другими словами, современная практика состоит в том, чтобы поставлять то,
что мы хотим поставлять, а не то, о чем просил заказчик. Как мы покажем в этой
книге, заказчиков (заинтересованных в проекте лиц) можно (и необходимо) ак-
тивно вовлекать в работу над проектом, мы просто должны быть уверены, что они
одобряют процесс разработки.
Отлично! Я был рад выплеснуть весь этот негатив. Теперь перейдем к позитив-
ному подходу и рассмотрим, что мы можем сделать для решения этих проблем.
Введение в гибкую разработку
программного обеспечения
Чтобы разрешить проблемы, стоящие перед разработчиками программного обес-
печения, в феврале 2001 года инициативная группа из 17 методологов объедини-
лась в Альянс гибкой разработки программного обеспечения (www.agilealliance.
org), часто называемый просто Гцбким альянсом. Интересно, что все люди, вхо-
дившие в эту группу, имели различный опыт, в том числе они разбирались и в тех
вопросах, в которых методологи обычно не ориентируются (Фаулер, 2001а). Эта
группа людей приняла манифест, в котором поддерживала лучшие способы разра-
ботки программ, а затем, опираясь на этот манифест, сформулировала набор прин-
ципов, которые определяли критерии процесса гибкой разработки программного
обеспечения, такого как гибкий процесс.
Манифест гибкой разработки
программного обеспечения
Манифест (Agile Alliance 2001а) определял четыре базовых положения — для их
понимания следует заметить, что сначала, напечатанные жирным шрифтом, распо-
лагаются формулировки, а затем — разъяснение этих формулировок. Желательно
понимать, что в манифесте декларируются положения, не имеющие альтернативы.
I
24 Глава 1 • Введение
В то же время они касаются лишь отдельных вопросов разработки программ, и не
затронутые ими проблемы никуда не исчезают. Базовые ценности Гибкого альян-
са таковы:
Люди и контакты важнее процессов и средств. Программные системы строятся
не отдельными людьми, а командами, и в ходе работы члены этих команд — про-
граммисты, тестировщики, менеджеры проектов, специалисты по моделирова-
нию и заказчики — должны эффективно работать вместе. Кто, по-вашему, создаст
лучшую систему — пять разработчиков, которые используют свои излюбленные
средства и методы разработки и просто работают вместе в одной комнате, или пять
низкоквалифицированных программистов, весь опыт которых — приготовление
гамбургеров, которые работают в соответствии со строгим технологическим про-
цессом, применяют большое количество хитрых утилит и сидят в самом удобном
офисе, который только можно купить за деньги? Если проект действительно сло-
жен, я поставлю свои деньги на разработчиков, а вы? Смысл этого примера в том,
что самым важным фактором следует считать людей и то, как происходит их сов-
местная работа, поскольку если с этим плохо, то даже самые лучшие процессы
и средства не смогут ничем помочь. Средства и технологии имеют большое зна-
чение, не поймите меня превратно, но все же они важны не в такой степени, как
эффективная совместная работа. Вспомните старую поговорку о том, что дурак с
инструментом остается дураком. Менеджерам, может быть нелегко это усвоить,
поскольку им часто хочется'верить в то, что сотрудники и время, или люди и ме-
сяцы, взаимозаменяемы (Брукс, 1995).
Работающие программы важнее идеальной документации. Если вы спросите
пользователя, что он хочет получить — 50-страничное описание того, что вы соби-
раетесь сделать, или собственно программное обеспечение, как вы думаете, что он
выберет? Я полагаю, что в 99 случаях из 100 его выбором станет работающая про-
(грамма.’ Но если это так, то почему бы нам не уделить побольше усилий быстрому
созданию программ и частому выпуску новых версий, чтобы давать нашим поль-
зователям то, чего они хотят? Кроме того, я подозреваю, что пользователям будет
значительно проще понять программы, которые вы создаете, чем сложные техни-
ческие диаграммы, описывающие внутренний мир этих программ, или абстракт-
ные описания их работы, а как вам кажется? Документация играет свою роль, пра^
вильно написанная, она может иметь ценность для людей и помогает им понять,
как и зачем система была построена и как с этой системой работать. Однако ни-
когда не забывайте, что основная задача разработки программного обеспечения —
создавать программное обеспечение, а не документацию — иначе это занятие на-
зывалось бы разработкой документации, не так ли?
Сотрудничество с заказчиком важнее переговоров по условиям контракта.
Только ваш заказчик в состоянии сказать вам, чего он хочет. Да, часто ему не хва-
тает навыков для полного детального описания системы. Да, первое время он час-
тенько этого не понимает. Да, часто он может передумать. Совместная работа с
заказчиком нелегка, но такова действительность нашей работы. Подписание кон-
тракта с вашим заказчиком — это важно, понимание прав и обязанностей мо-
жет образовать основу этого контракта, но контракт не заменит вам контактов.
Успешно работающие разработчики работают рядом со своими заказчиками, они
Принципы гибкой разработки программного обеспечения 25
затрачивают усилия на то, чтобы разобраться в нуждах своих заказчиков, — и все
это время обучают своих заказчиков.
Готовность к изменениям важнее соблюдения планов. По многим причинам
люди могут изменить свои приоритеты. По мере работ над вашей системой заказ-
чики (заинтересованные в вашем проекте лица) лучше понимают предметную об-
ласть и вас самих, что порождает изменения. Меняется среда бизнеса. Меняются
технологии, хотя и не всегда к лучшему. Меняется практика разработки программ,
а процессы вашего программного обеспечения вынуждены следовать за ней. Нет
ничего плохого в наличии планов и графиков. На самом деле я всегда сомневался в
проектах, которые не имели плана. Однако план проекта должен быть эластичным,
если ситуация изменилась, должна быть возможность изменить и план, в против-
ном случае он очень быстро перестанет соответствовать действительности.
Интересно то, что все более или менее согласны с этими базовыми утвержде-
ниями, однако редко применяют их на практике. Старшие менеджеры частенько
утверждают, что их сотрудники — самый важный элемент их бизнеса, и в то же
время настойчиво добиваются от этих сотрудников соответствия рабочих про-
цессов стандарту ISO-9000 и рассматривают их как заменяемые элементы. Что
еще хуже, руководство часто отказывается предоставлять ресурсы в том объеме,
в котором они необходимы по процессу, следовать которому обязывают проект-
ную группу.
Каждый готов согласиться с тем, что создание программ — это основная цель
разработки программного обеспечения, однако настаивает на том, утобы месяцы
тратились на разработку документации, описывающей, что представляет собой
это программное обеспечение и как его следует создавать, вместо того чтобы уже
свернуть разговоры и построить его. Вы высказываете идею — люди говорят одно,
а делают другое. Это необходимо остановить. Специалисты по гибкому моделиро-
ванию говорят то, что делают, и делают то, что говорят.
Принципы гибкой разработки
программного обеспечения
Чтобы помочь людям лучше понять, что же такое гибкая разработка программного
обеспечения, члены Гибкого альянса решили уточнить и дополнить философские
положения, провозглашенные в манифесте, набором из двенадцати принципов
(Agile Alliance 2001b), которым должны удовлетворять методологии разработки
программного обеспечения, претендующие на гибкость, например такие, как гиб-
кое моделирование (AM).
Вот эти принципы:
1. Мы придаем первоочередное значение удовлетворению заказчика, быстро
и постоянно предоставляя нужное ему программное обеспечение.
2. Мы приветствуем изменения требований, даже на поздних этапах разработ-
ки. Гибкие процессы позволяют поддерживать изменения, обеспечивая за-
казчику конкурентное преимущество.
26
Глава 1 • Введение
3. Новые версии работающего программного обеспечения поставляются час-
то, с регулярностью от нескольких недель до нескольких месяцев, причем
более предпочтительны короткие временные периоды.
4'. В ходе проекта бизнесмены и разработчики должны постоянно работать
вместе.
5. Проекты строятся мотивированными индивидуалами. Создайте им усло-
вия, удовлетворяйте их требованиям и доверяйте им в том, что касается вы-
полнения работы.
6. Наиболее производительный и эффективный способ передачи информа-
ции рабочей группе и внутри нее — это разговор лицом к лицу.
7. Работающее программное обеспечение — это основной показатель про-
гресса.
8. Гибкие процессы стимулируют устойчивую разработку. Спонсоры, разра-
। ботчики и пользователи должны быть в состоянии реограниченно долго
поддерживать постоянный ритм работы.
9. Непрерывное внимание к техническому качеству и хорошему проектирова-
нию улучшает гибкость.
10. Простота — искусство минимизировать количество ненужной работы — ис-
ключительно важна.
И. Наилучшим образом архитектура, требования и проектирование формиру-
ются и выполняются самоорганизующимися командами.
12. Команда должна регулярно обсуждать, как повысить эффективность своей
работы, после чего изменять и согласовывать рабочий процесс с результата-
ми этих обсуждений.
Остановимся на минутку и обдумаем эти принципы. По этому ли пути сле-
дует ваш проект разработки? Думаете ли вы, что он должен следовать по этому
пути? Перечитайте принципы еще раз. Являются ли они чересчур радикальными
и недостижимыми, как полагают некоторые, наивны ли они, как детство и яблоч-
ный пирог, или олицетворяют собой здравый смысл? Я считаю, что эти принци-
пы образуют основание здравого смысла, на базе которого мы можем приклады-
вать усилия к созданию хорошего программного обеспечения..Более того, я верю,
что они определяют общие требования к эффективной методологии создания
программного обеспечения, требования, используемые для формулировки цен-
ностей (глава 2), принципов (главы 3 и 4) и методик (главы 5 и 6) гибкого моде-
лирования.
Гибкое моделирование
Гибкое моделирование (Adile Modeling — AM) — это упорядочивающая, основан-
ная на практическом опыте методология эффективного моделирования и доку-
ментирования программных систем. Методология AM представляет собой набор
Гибкое моделирование 27
методик, соответствующих принципам и ценностям профессионалов в разработ-
ке программ, и предназначена для постоянного применения. AM — это не пре-
допределенный процесс. Другими словами, оно не определяет детализированных
процедур создания определенных типов моделей, вместо этого оно предлагает
рекомендации по эффективному моделированию. AM упорядочивает (Хок, 199,9),
в том смысле, что оно сочетает в себе «хаос» простейших методов моделирования
со стабильностью, присущей артефактам моделирования. AM — это не ограниче-
ние моделирования. На самом деле многие разработчики обнаруживают, что, ис-
пользуя AM, они занимаются моделированием даже больше, чем раньше. AM —
это «плата за риск», это не тяжелый и мощный процесс, AM — это скорее не наука,
а искусство.
Как научиться эффективно моделировать? Поскольку моделирование явля-
ется важнейшей частью всякого процесса разработки программ, процессы гиб-
кой разработки (экстремальное программирование (ХР) (Бек, 2000), SCRUM
(Бидл и Швабер, 2001) и динамический метод разработки систем (DSDM,
Стэплтон, 1997)) используют такие средства моделирования, как истории поль-
зователей, CRC-модели и наброски. В противоположность тому, что говорят про-
тивники ХР, ХР не предлагает обходиться без моделирования. Скорее оно сво-
дит работу по моделированию до минимума благодаря использованию подхода
«Сначала тест — потом программа», при котором тесты разрабатываются рань-
ше, чем код. Это заставляет вас сначала подумать о том, как вы будете создавать
систему, и лишь затем приступать к ее созданию, как это происходит при тради-
ционном моделировании. В ХР иначе решаются некоторые задачи моделирования
(в основе лежит понимание того, что вы делаете), поэтому моделировать прихо-
дится меньше. Здесь нет ничего странного. Предопределенные процессы создания
программного обеспечения также включают в себя моделирование. Например,
в унифицированном процессе (UP) три из шести основных процессов (также на-
зываемых рабочими потоками) посвящены моделированию, да и мой собствен-
ный объектно-ориентированный процесс (OOSP) содержит этап проектирования,
названный просто: «Модель».
Существует две основные причины для моделирования: помочь понять, что' же
мы создаем, и способствовать общению как внутри команды разработчиков, так
и разработчиков с заказчиками. Вы можете выбрать моделирование требований
к системе, например, с использованием диаграммы Use Case (основные артефакты
моделирования описаны в приложении А) или набора бизнес-правил. Точно так
же вы можете предпочесть разработку модели для анализа этих требований, или
формулирования общей архитектуры, или детализированного проекта системы.
В любом из этих вариантов вашей целью будет лучшее понимание одного или не-
скольких аспектов вашей системы. Другими словами, вы используете модели для
того, чтобы помочь себе исследовать то, над чем вы работаете. Более того, вы мо-
жете использовать модели для общения членов команды между собой или. отдель-
ными людьми и другими группами. Модель данных помогает объяснить структу-
ру вашей базы данных программистам, которые пишут код на Java, работающий
с вашей базой данных. Диаграмма потоков пользовательского интерфейса позво-
ляет передать общую структуру пользовательского интерфейса вашей системы
28 Глава 1 • Введение
людям, которые создают отдельные окна, веб-страницы и отчеты. Диаграмма де-
ятельности объясняет бизнес-процессы, которые поддерживает ваша система, за-
казчикам, которые финансируют работу команды. Короче говоря, моделирование
крайне важно для успешной работы вашей команды. Как же эффективно и гибко
производить моделирование? Это главный вопрос, для ответа на который и была
создана методика AM.
AM преследует три цели:
1. Определение и демонстрация практического использования набора цен-
ностей, принципов и методик, имеющих отношение к эффективному облег-
ченному моделированию. Катализатором повышения эффективности дела-
ют AM не сйми по себе методологии моделирования — такие как модели
Use Case, модели классов, модели данных или пользовательских интерфей-
сов, — а то, как они применяются.
2. Рассмотрение вопроса о том, как применять методологии моделирования
в проектах по созданию программного обеспечения с использованием гиб-
кого подхода. Иногда разработчику бывает куда полезнее нарисовать не-
сколько кружков, соединив их линиями, чтобы уловить идею, или сравнить
несколько различных подходов к решению проблемы, чем просто начать
писать код. Опасно слишком зацикливаться на коде — иногда простой эс-
киз может предотвратить серьезную путаницу при кодировании.
3. Рассмотрение вопроса о том, как можно повысить эффективность модели-
рования путем использования «полугибкого» подхода к разработке про-
граммного обеспечения, в частности, в командах, которые используют та-
кую реализацию унифицированного процесса, как Унифицированный
процесс фирмы Rational (RUP) (Кратчен, 2000) или Корпоративный уни-
фицированный процесс (EUP) (Амблер, 2001b). Оба эти процесса облада-
ют достаточной гибкостью, чтобы сделать адаптацию возможной, то есть,
с одной стороны, они являются сильно предопределенными, но с другой
стороны, достаточно гибки для того, чтобы в них можно было использовать
AM. Хотя для того, чтобы считаться гибким разработчиком, вы должны сле-
довать принципам гибкого процесса разработки во всем (особенно сейчас),
вы можете также применять многие методики AM в негибких проектах, по-
лучая от этого существенный выигрыш. Таким же образом команды, не ра-
ботающие по технологии ХР, получают выигрыш от адаптации некоторых
экстремальных методик, таких как парное программирование или рефак-
торинг — они не используют ХР в полной мере, но значительно повышают
свою производительность, применяя соответствующие технологии.
Для понимания AM важно помнить, что оно не является законченным процес-
сом разработки программного обеспечения. В AM внимание сосредоточено на эф-
фективном моделировании и документировании. Это именно так. В него не входит
собственно программирование, хотя модели и предполагается проверять с помо,-
щью кодирования. В него не входит тестирование, хотя мы и предлагаем рассмат-
ривать тестируемость как задачу моделирования. Оно не охватывает вопросов
управления проектом, размещения системы, работы- с системой, ее поддержки
Гибкое моделирование 29
и множества других проблем. Поскольку в задачи AM входит лишь часть задач об-
щего процесса создания программного обеспечения, необходимо использовать его
совместно с другими процессами, которые содержат методы и средства для дру-
гих видов деятельности, такими как ХР, DSDM, SCRUM или UP. Эту идею ил-
люстрирует рис. 1.1. Мы начинаем работу с базового процесса, такого как ХР или
UP, или вашего собственного процесса, а затем присоединяем к нему AM (надеясь
при этом, что нам удастся использовать AM целиком), точно так же, как и другие
методологии, и в соответствии с обстоятельствами формируем свой процесс, от-
ражающий наши конкретные задачи. С другой стороны, мы можем сформировать
собственный процесс разработки, выбирая наилучшие средства из набора суще-
ствующих процессов создания программного обеспечения. Чтобы упростить из-
ложение материала в данной книге, я предполагаю, что мы используем первый
из этйх подходов и применяем один из процессов разработки в качестве базового.
Хотя AM -не зависит от других процессов, будь то ХР или UP, оно использует-
ся для повышения эффективности этих процессов. В третьей части этой книги я
покажу, каким образом AM сочетается с ХР, а в четвертой части — рассмотрю, как
использовать его совместно с UP. ,
Оперативное моделирование (AM)
---------------------------------- Ваш процесс
Базовые процессы разработки
разработки программного обеспечения программ
(ХР, UP, DSDM, ...)
Рис. 1.1. AM повышает эффективность других процессов
разработки программного обеспечения
Специалисты по гибкому моделированию — кто они?
Специалистом по гибкому моделированию является каждый, кто следует методо-
логии AM, применяет методики AM в соответствии с их принципами и ценностью.
Специалист по гибкому моделированию — это человек, использующий гибкий
подход к разработке программного обеспечения. Специалист по гибкому модели-
рованию — это специалист по гибкой разработке. Однако не все специалисты по
гибкой разработке являются специалистами по гибкому моделированию.
Сейчас я собираюсь внести некоторую неопределенность в свои рассуждения,
за что заранее прошу прощения. Во всем тексте книги я буду использовать термин
«специалист по гибкому моделированию» там, где мне потребуется указать на де-
ятельность, имеющую отношение к гибкому подходу к моделированию. Я буду ис-
пользовать более общее понятие «специалист по гибкой разработке» там, где раз-
говор пойдет о деятельности, имеющей отношение не только к AM, но и вообще к
гибкой разработке программного обеспечения. Другими словами, когда я говорю:
«Специалист по гибкой разработке делает то-то и то-то», вы должны понимать,
что это в полной мере относится и к специалисту по гибкому моделированию.
30 Глава 1 • Введение
Краткий обзор гибкого моделирования
В главе 2 я приведу данные, которые покажут вам, что AM использует ценности
ХР (Бек, 2000) — общение, простоту, обратную связь и смелость, и добавляет к
ним пятую ценность — смирение. Это крайне важно для организации эффектив-
ного общения как внутри команды разработчиков, так и вне ее, со всеми заказ-
чиками, да и между этими лицами. Вы должны стараться разрабатывать самые
простые (Возможные решения, которые удовлетворяли бы все ваши нужды, и по-
лучать отклик, свидетельствующий об успехе или неуспехе ваших усилий, как
можно раньше и чаще. Более того, вы должны иметь смелость принимать реше-
ния и следовать им, и смирение, которое позволит вам признать, что ваши знания
неполны, и другие люди также могут привнести нечто ценное в вашу работу над
проектом.
AM основано на. наборе принципов (главы 3 и 4), которые ведут свое проис-
хождение от принципов Гибкого альянса, таких как важность простоты в процес-
се моделирования и принятия изменений в ходе работы, поскольку требования
время от времени изменяются. Вы должны понимать, что периодические изме-
нения вашей системы требуют оперативного отклика, и прилагать усилия к тому,
дабы обеспечить быстрый отклик от людей, использующих ваши разработки, что-
бы гарантировать правильное понимание пожеланий заказчиков. Специалисты по
гибкому моделированию должны сознавать, что их основная задача — создание
программ, но им не следует забывать и того, что их вторая задача — понять, на
что должны быть направлены дальнейшие усилит. Моделируя, вы должны ста-
вить перед собой цель. Если вы не понимаете, зачем вы делаете то, что делаете, вам
не следует этим заниматься. Вы также должны понимать, что ваш набор инстру-
ментов должен содержать несколько моделей. Только тогда ваша работа будет эф-
фективной. Очень важно понимать, что модели не обязательно' документировать.
Реализация поможет вам осветить дорогу и уничтожит большинство моделей,
поскольку их роль будет уже выполнена. Специалисты по гибкому моделирова-
нию знают, что содержание важнее формы, и существует множество правильных
способов моделирования одних и те же сущностей.
Чтобы эффективно моделировать, вам необходимо знать свои модели. Чтобы
быть эффективным членом группы, вы должны добиться того, чтобы каждый мог
передать свои знания каждому. Для)этого вы должны действовать через инстинк-
ты, при этом наилучшей политикой для организации эффективной групповой ра-
боты является открытое и доброжелательное общение. И, наконец, очень важен
упор на качественную работу, поскольку никому не интересно делать ненужную
работу, а значит, необходима локальная адаптация AM под задачи вашей группы
и вашего окружения.
Для гибкого моделирования вам необходимо по возможности использовать
методики AM (главы 5 и 6). Основные методики включают в себя одновременное
создание нескольких моделей, использование подходящих к ситуации артефак-
тов и переход к другому артефакту для продолжения постоянного движения впе-
ред. Моделируйте небольшими кусками и не пытайтесь создать волшебную «все-
объемлющую модель» — это правило также необходимо соблюдать, если вы хотите
Гибкое моделирование 31
добиться успеха на ниве гибкого моделирования. Поскольку модели — это лишь
абстрактное представление программ, они могут быть и неточными.
Мы должны стараться подтвердить их при помощи программного кода, что-
бы доказать истинность наших идей и их практическую работоспособность. Для
успешности нашей работы по моделированию очень важным является активное
содействие заказчиков, поскольку только они знают, что должно получиться в
результате, и могут предоставить именно ту обратную связь, которая нам необ-
ходима. Для создания моделей имеются две основные причины: во-первых, мы
моделируем, чтобы прояснить для себя различные вопросы (например, как проек-
тировать различные части системы), во-вторых, мы создаем модели для того, что-
бы иметь возможность обсуждать, что необходимо сделать команде разработчи-
ков (или что уже сделано). Принцип стремления к простоте поддерживается на
практике созданием простого продукта, с упором только на те аспекты, которые
необходимо моделировать, с исключением сильно детализированных моделей,
упрощения описания моделей путем использования простейшей нотации и ис-
пользования для создания моделей простейших средств моделирования. Мы пе-
реносим внимание с одной части моделей на другую, отбрасывая временные моде-
ли и улучшая их только тогда, когда они перестают отвечать нашим требованиям.
Мы поддерживаем общение, размещая модели на информационных излучателях
(Кокберн, 2002), демонстрируя их публике на стенах офиса или на внутреннем
веб-сайте, используем коллективное владение артефактами проекта, применяем
стандарты моделирования и моделируем совместно с другими. Мы значительно
увеличиваем вкладываемую в разработку энергию, рассматривая тестируемость,
аккуратно применяя паттерны проектирования и повторно используя сущест-
вующие артефакты. Поскольку мы часто вынуждены интегрироваться с други-
ми системами, в том числе с существующими базами данных и веб-службами, мы
должны определить свои запросы путем формализации контрактных моделей с
владельцами этих систем.
В своей основе AM представляет собой просто набор методик, отражающих
принципы и ценности, разделяемые многими опытными разработчиками про-
граммного обеспечения. Но если существует такая вещь, как гибкое моделирова-
ние, то должны существовать и гибкие модели? Ну да, разумеется.
Что такое гибкие модели?
Чтобы разобраться в AM, вам необходимо понимать разницу между простой моде-
лью и моделью гибкой. Модель представляет собой абстракцию, которая описывает
один или более аспектов проблемы или ее потенциальное решение. Традиционно
под моделью понимаются несколько диаграмм и прилагаемая к ним документа-
ция. Однако и невизуальные артефакты, такие как набор CRC-карточек, текстовое
описание одного или нескольких бизнес-правил или описание бизнес-процесса на
структурированном английском языке, также могут считаться моделями. Гибкая
модель — это модель, которая всего лишь достаточно хороша. Но как понять, что
модель всего лишь достаточно хороша? Гибкая модель достаточно хороша в том
случае, если она демонстрирует следующие качества:
32 Глава 1 • Введение
Гибкая модель удовлетворяет тем задачам, для выполнения которых она созда-
валась. Иногда вы моделируете, чтобы облегчить общение, может быть, вам не-
обходимо обсудить направления вашей деятельности с высшим руководством, а
иногда строите модели для понимания, например, при необходимости определить
стратегию проектирования для последующей реализации набора классов Java.
Гибкая модель должна решать задачу, для решения которой она создавалась.
Гибкая модель должна быть понятна. Гибкие модели должны быть доступны
для понимания той аудитории, для которой они создаются. Модель этапа опре-
деления требований должна быть написана на языке того бизнеса, который в со-
стоянии понять пользователи, а в модели технической архитектуры должны ис-
пользоваться технические термины, которые поймут разработчики. Нотация
моделирования, которую вы используете, должна быть понятной — диаграммы
Use Case UML не будут иметь никакой ценности для ваших пользователей, если
те не смогут понять, что они означают: В подобном случае вы должны или ис-
пользовать другие методы моделирования, или обучить пользователей техноло-
гии моделирования. Вопросы оформления, такие как отказ от пересекающихся
линий, также способны оказать влияние на понимаемость — неопрятные диаграм-
мы сложнее читать, чем выполненные аккуратно. Уровень детализации ваших мо-
делей, как мы покажем ниже, также может повлиять на понимаемость, поскольку
чрезмерно детализированная модель воспринимается с большим трудом, чем бо-
лее грубая. Простота (см. ниже в этой главе) — это тоже фактор повышения пони-
маемости.
Гибкие модели достаточно точны. Моделям не всегда обязательно иметь сто-
процентную точность, им достаточно быть вполне точными для конкретной цели.
Так, например, если на карте для автомобилистов пропущена улица или дорога,
обозначенная на ней как открытая, закрыта на ремонт, стоит ли выбрасывать та-
кую карту и ехать по городу наугад? Вероятно, нет. Вы можете исправить свою
карту. Вы можете взять авторучку и сделать это самостоятельно или пойти в ма-
газин и купить более новое издание (которое тоже может оказаться не соответ-
ствующим действительности). Вы можете также признать, что ваша карта не иде-
альна, и продолжать использовать ее по-прежнему, поскольку она все же вполне
вас устраивает — по ней вы можете добраться до нужного вам места, поскольку эта
карта все же верно моделирует большинство улиц города. Причина, по которой
вы не выбрасываете свою карту в тот же миг, когда обнаружите в ней неточности,
состоит в том, что вы не ожидаете от нее совершенства. Да вам оно и не требует-
ся. Точно так же, обнаружив неточности в модели требований или в модели дан-
ных, вы можете поправить модель или смириться с тем фактом, что она хоть и не
идеальна, но все же вполне хороша. Некоторые команды разработчиков могут ра-
ботать с неточными моделями, некоторые — нет. Это определяется природой про-
екта, стилем отдельных членов команды и сложившимися в фирме традициями.
Достаточный уровень точности зависит как от коллектива, который будет рабо-
тать с моделью, так и от задачи, для решения которой она создавалась.
Мне довелось принимать участие в работе над проектом с использованием
технологии Enterprise JavaBeans (EJB) (Роман и др., 2002), где возникла необ-
ходимость объяснять, как происходит инициализация сущности из EJB. Во вре-
4
Гибкое моделирование 33
мя этого процесса я нарисовал эскиз, поясняющий принципы работы домашнего
и удаленного интерфейсов EJB, и несколько фигурок идущих людей для иллюст-
рации жизненного цикла сущности. Делая это, я пропустил существенные детали
по активизации и деактивизации ядра, кроме того, я неправильно указал имя од-
ной из операций, однако мне удалось донести до моей аудитории основную идею.
Аудитория состояла из людей, а не компьютеров, более того, этим людям не нуж-
ны были точные спецификации, им требовалось лишь описание, которое было бы
вполне хорошим для первого объяснения и после которого они могли бы самосто-
ятельно заполнить пробелы и исправить ошибки.
Гибкие модели достаточно непротиворечивы. Гибкая модель не должна быть
идеально непротиворечивой или идеально сочетаться с другими используемыми
артефактами. Если элемент Use Case на одном из своих шагов явно запускает дру-
гой элемент Use Case, соответствующая диаграмма Use Case должна указывать
на существование зависимости между ними, помеченной стереотипом «include»
UML. Однако вы смотрите на диаграмму и не видите там этой зависимости! Какой
кошмар, элемент Use Case и диаграмма не согласованы!
Берегись, Билли Робинсон, берегись! Тревога! Спасай свою шкуру! Эй, подо-
жди минутку, твоя модель Use Case действительно содержит противоречия, но
мир от этого рухнуть пока не собирается. '
Да, в идеальном мире все ваши артефакты должны быть абсолютно непроти-
воречивы, но, скорее всего, работать в таком виде они не будут. Когда вы строите
пример бизнес-приложения, вы должны быть готовы к определенным противоре-
чиям. Так, например, в модели Use Case может присутствовать актер, названный
«Заказчик», в то время как в модели классов соответствующий класс носит имя
«Клиент». Кто он — заказчик, клиент или и то'и другое? Если это важно, вы раз-
бираетесь в этом и решаете проблему, но если это неважно, вы просто продолжа-
ете работать дальше, не обращая внимания на несоответствие. Да, действительно,
иногда вы не можете допускать противоречивости — и NASA никогда не забудет,
в чем разница между метрами и ярдами, после того, как в 1999 году спутник, пред-
назначенный для изучения Марса, из-за неправильно выбранной системы мер
разбился о его поверхность. Однако не следует забывать, что хотя гибкая модель
всего лишь достаточно непротиворечива, очень часто нам и не требуется иметь
идеальную модель.
Вслед за точностью и непротиворечивостью следует обсудить вопросы энтро-
пии. Если существует артефакт, который вы собираетесь поддерживать и далее,
который я называю «хранителем», вам необходимо выделять ресурсы на то, что-
бы, когда придет время, вносить в него изменения. В противном случае он быстро
устареет и станет непригодным для работы. Так, например, я могу примириться
с картой, на которой пропущены одна или две улицы, но карта, на которой будут
отсутствовать три четверти улиц города, мне не нужна. Модель данных, в которой
пропущены несколько добавленных столбцов, способна дать вполне приемлемое
понятие о схеме базы данных, а диаграмма размещения, в которой указана преды-
дущая версия сервера приложений EJB, пригодна и теперь. Вы должны попасть
в узкую щель между слишком большими и чересчур малыми затратами на сохра-
нение такой точности артефактов, которая необходима для работы.
2 Зак. 926
34 Глава 1 • Введение
Гибкие модели достаточно детализированы. На дорожной карте не показан
каждый дом на каждой улице. Это было бы чрезмерной детализацией и затруд-
нило бы работу с картой. Однако при строительных работах на какой-либо улице,
я полагаю, строители имеют подробную карту, на которой изображены все дома,
люки, электрические щиты и все, что еще необходимо для того, чтобы эта карта
была пригодной для строителей. На этой карте не изображены отдельные камни,
из которых сложены дорожки у каждого из домов, поскольку это опять-таки было
бы неуместной детализацией. Достаточность детализации определяется аудито-
рией и целями, для которых создается модель, — водители машин хотят иметь
карту, на которой изображены улицы, а строителям нужна карта с деталями, важ-
ными для проведения строительных работ.
Рассмотрим модель архитектуры. Вам может оказаться достаточно набора диа-
грамм, нарисованных на доске и поправляемых по мере, развития проекта. Или
же несколько диаграмм при необходимости могут быть выполнены при помо-
щи CASE-средств. А может быть, эти диаграммы нужно будет сопроводить ис--
черпывающей документацией. К различным проектам предъявляются различные
требования. В каждом из этих трех проектов мы разрабатываем и поддерживаем
достаточно детализированную модель архитектуры, поскольку «достаточная де-
тализированность» сильно зависит от конкретной ситуации.
Гибкая модель выгодна. Основное свойство любого артефакта проекта состо-
ит в том, что он приносит прибыль. Хорошо ли будет, если модель архитектуры
приведет к перерасходу средств по разработке и, возможно, поддержке продукта?
Модель архитектуры помогает обосновать концепцию, в соответствии с которой
должна работать ваша команда, что, несомненно, полезно. Однако если затраты
на эту модель превышают выгоду от ее создания, значит, она убыточна. Наверное,
неразумно будет вкладывать $100 000 в разработку подробнейшей и великолепие
документированной модели архитектуры, если за $5000 мы можем получить до-
ску с нарисованными на ней диаграммами, сфотографировать ее на цифровую ка-
меру и, используя эту модель, сделать свою работу.
Гибкие модели просты настолько, насколько это возможно. Вы должны ста-
раться, чтобы ваши модели до самого окончания работ оставались как можно про-
ще. Простота сильно зависит от уровня детализации модели, однако свое влияние
на нее оказывает и сложность используемой нотации. Так, например, диаграммы
классов унифицированного языка моделирования (UML) могут содержать не-
сметное число имен и идентификаторов, включая и понятия объектного языка
ограничений (OCL), хотя большинство диаграмм могут использовать лишь часть
этой нотации. Обычно у нас нет необходимости использовать всю доступную но-
тацию, и мы можем ограничиться той частью, которая необходима нам для выпол-
нения нашей работы.
Таким образом, определение гибкой модели состоит в том, что эта модель удов-
летворяет тем целям, для которых она была создана, и ничего более; она понят-
на той аудитории, для которой она создавалась, она проста, достаточно точна, не-
противоречива и детальна; и затраты на ее разработку и поддержку выгодны для
проекта.
Гибкое моделирование 35
Традиционный вопрос философии программирования состоит в том, насколь-
ко можно считать моделью код программы и, что еще важнее, насколько его можно
считать гибкой моделью. Если вы, безотносительно к этой книге, зададите подоб-
ный вопрос мне, я отвечу. «Да». Да, исходный код является моделью, хотя и черес-
чур детализированной, поскольку он является абстрактным представлением ва-
шей программы. Я готов также утверждать, что хорошо написанный код является
гибкой моделью. Тем не менее, в этой книге я не буду отождествлять исходный
код с гибкой моделью — просто потому, что мне нужно использовать оба эти поня-
тия для демонстрации того, как гибкие модели способствуют разработке кода.
Чем является и чем не является гибкое моделирование?
Я твердо уверен в том, что когда вы познаете новую для себя область, будь то про-
граммная система или, в случае AM, методология, вы должны понять, чем являет-
ся эта новая система или методология и чем она не является. Для понимания AM
будут важны следующие положения:
AM — это позиция, выражающая отношение к моделированию, а не предопреде-
ленный процесс. AM состоит из набора ценностей, принимаемых человеком, кото-
рый производит гибкое моделирование, принципов, в правильность которых этот
человек верит, и методик, которые он применяет. AM описывает стиль моделиро-
вания, который, будучи правильно примененным в гибком окружении, приводит
к повышению качества программ ,и ускорению процесса разработки без чрезмер-
ного упрощения и нереалистичных оценок. AM не содержит «поваренной книги»
для разработки программ — если вам нужны детализированные инструкции по
созданию диаграмм последовательности UML или вычерчиванию диаграмм пото-
ков пользовательского интерфейса, подыщите себе одну из множества книг, пере-
численных в разделе ссылок в конце этой книги.
AM — это дополнение к существующим методикам, оно не является отдельной
методологией. Основная задача AM — это моделирование, дополнительная — со-
здание документации. Это все. Методики AM могут использоваться для коорди-
нации моделирования в группах, которые следуют гибким методологиям разра-
ботки, таким как ХР, SCRUM и Crystal Clear (Кокберн, 2001b). AM также может
использоваться в ходе предопределенных процессов, таких как унифицирован-
ный процесс, хотя ее успешность будет определяться гибкостью процесса.
AM дополняет другие процессы моделирования. Методологии моделирования,
такие как ICONIX (Розенберг и Скотт, 1999) и Catalysis (Д’Суза и Виллс, 1999),
концентрируются на создании определенных видов артефактов, детально рассмат-
ривая вопросы применения таких артефактов, как элементы Use Case, диаграм-
мы устойчивости или модели компонентов. В них не рассматриваются методоло-
гии высокого уровня, необходимые для эффективности моделирования, и именно
этими вопросами занимается AM. Мой опыт говорит мне, что AM и другие мето-
дологии моделирования прекрасно сочетаются, и я не сомневаюсь, что в один пре-
красный день мы найдем в книжном магазине книги «Гибкое моделирование с по-
мощью ICQNIX» и «Гибкое моделирование с помощью Catalysis».
36 Глава 1 • Введение
AM — это способ эффективной организации совместной работы для удовлетво-
рения требований заказчиков. Сотрудники, использующие методы гибкой разра-
ботки, составляют одну команду с заказчиками, которые, в свою очередь, прини-
мают непосредственное и активное участие в разработке системы. Как известно,
в слове «гибкость» нет буквы «я». AM эффективно и придает эффективность ра-
боте команды. Когда вы прочтете об AM больше, вам станет кристально ясно, что
AM жестко подчинено одной цели — эффективности. AM побуждает вас макси-
мально повышать вклад заказчиков в разработку, создавать модели или докумен-
ты только тогда, когда вам будут ясны задачи и понятны нужды аудитории, для
которой оно предназначено, использовать для.разрешения возникающих проблем
соответствующие им артефакты и создавать настолько простые модели, насколь-
ко это возможно. И ничего, кроме абсолютно необходимого.
AM — это работающая вещь, а не академические теории. Задача AM — опи-
сание методик для эффективного моделирования систем, которые эффективны
и способны решить стоящую перед проектировщиком задачу. Я и мои коллеги по
работе из Ronin International, Inc. (www.ronin-intl.com) за прошедшие несколъко лет
использовали множество методик AM, которые были отшлифованы на множест-
ве проектов и заказчиков из различных отраслей промышленности. Кроме того,
с февраля 2001 года в рассылке по гибкому моделированию (www.agilemodeling.
com/feedback.htm) эти методики рассматривали и обсуждали несколько сотен
практиков моделирования, в результате признавшие их эффективность.
AM — это не серебряная пуля. Гибкое моделирование — это методология для
повышения эффективности работы множества профессионалов при создании
программного обеспечения. Вот и все, ничего более. Это не волшебное.змеиное
масло, которое решит все ваши проблемы. Если вы будете усердно работать, если
вы сосредоточитесь на задаче, если вы всем сердцем воспримете ценности AM, ее
принципы и методики, вы повысите эффективность своей деятельности как раз-
работчика.
AM предназначена для средних по уровню разработчиков, но она не заменя-
ет человеческую компетентность. Ценности, принципы и методики AM просты,
многим из них вы следовали или хотели следовать многие годы. Для того чтобы
применять методики AM, вам не нужно уметь ходить по воде, но вам необходи-
мо иметь хотя бы базовые навыки разработки программного обеспечения. Самое
сложное в AM состоит в том, что эта методология требует изучения всевозможных
методик моделирования, длительной и непрерывной работы. Изучение моделиро-
вания может сначала показаться трудным делом, да так оно и есть, однако вы смо-
жете справиться с ним, если будете осваивать по одной методике за раз.
AM не предполагает отказа от документации. Человек, занимающийся гиб-
ким моделированием, создает такую документацию, которая повышает его вло-
жение в создание и поддержку системы. Гибкая документация проста настолько,
насколько это возможно, ее настолько мало, насколько это допустимо, она име-
ет ясное предназначение, непосредственно связана с разрабатываемой системой
и имеет четко очерченную аудиторию, требования которой понятны состави-
телю документации. О гибкой документации мы поговорим подробнее в главе 14.
AM не предполагает отказа от CASE-средств. Люди, занимающиеся гибким мо-
Учебный пример SWA Online 37
делированием, используют любые средства, позволяющие им получить выгоду
и делающие их работу более эффективной. Однако для выполнения работы они
всегда стараются использовать самые простые возможные средства.
Учебный пример SWA Online
На протяжении всей книги я буду рассматривать модели приложения под назва-
нием SWA Online. В этом разделе приводится краткое представление- системы
с точки зрения менеджмента, вариант того представления высокого уровня, с ко-
торого вам обычно приходится начинать проект.
SWA Enterprises — это организация, занимающаяся торговлей товарами (с вы-
сокой нормой прибыли) на территорий США. Она поставляет специализиро-
ванным магазинам уникальные товары, -которые нелегко найти в других местах.
SWA Enterprises считает себя компанией, торгующей разнородным и постоян-
но изменяющимся набором продуктов. Хотя до настоящего времени бизнес шел
вполне успешно, компания желает распространить свою сферу деятельности и на
Интернет. Ниже следует исходное представление высшего руководства о новой
системе SWA Online, которую они хотят получить.
SWA Online должна предоставлять набор физически существующих продук-
тов, которыми SWA Enterprises торгует в настоящее время, кроме того, в любой
момент компания может пожелать торговать и виртуальными продуктами, таки-
ми как онлайновая музыка или видео. Целевым рынком остаются Соединенные
Штаты. Мы, разумеется, нацеливаемся на всю Северную Америку, но полагаем,
что для первой версии это чересчур агрессивные планы, и лучше будет сосредо-
точиться на существующем рынке и, прежде чем вторгаться на новые территории,
обеспечить как следует то, что у нас уже есть. Однако наша конечная цель — меж-
дународная торговля.
Мы намерены использовать существующего перевозчика, Fly-By-Night
Shipping, однако мы сознаем, что в будущем эта компания, возможно, не будет
удовлетворять нашим задачам. Она обеспечивает весьма эффективную достав-
ку товара в магазины на территории США; ночная доставка значительно лучше
более дешевых вариантов, таких как медленная доставка наземным транспортом.
Однако мы не уверены, будет ли настолько же эффективна доставка в другие стра-
ны, и, в конце концов, мы не хотим зависеть от единственного поставщика такой
основной для нашего бизнеса услуги, как доставка.
Мы полагаем, что та система, коробочный вариант (COTS) который мы купи-
ли несколько лет назад для обработки информации о складских запасах и расчета
налогов, должна удовлетворить наши запросы к первой версии SWA Online, хотя
мы и хотели бы внести в пакет некоторые дополнительные возможности.
На SWA Enterprises в настоящее время работают 87 человек. Основные зада-
чи организации — это продажи магазинам, причем закупщики определяют но-
вые продукты, которые они хотят заказать, по каталогу, а также доставка и воз-
врат непроданного товара. Мы только что наняли вице-президента по онлайновой
торговле, Салли Джонс, которая будет отвечать за создание структуры, обеспечи-
38 Глава 1 • Введение
вающей поддержку и работу с SWA Online. Салли будет активно участвовать в ра-
боте нашей команды и поможет вам получить доступ к другим сотрудникам SWA
Enterprises, когда у вас возникнет такая необходимость. Основная задача наших
сотрудников — ,это их обычная работа, в течение восьмичасового рабочего дня, но
они проинструктированы, что при необходимости должны помогать команде раз-
работки.
Процесс разработки программного обеспечения, согласованный с SWA Enter-
prise, — это упрощенная версия EUP, к которой добавлены некоторые методики
ХР и полный набор методик AM.
Краткое содержание этой книги
Эта книга состоит из пяти частей.
Часть 1: Введение в гибкое моделирование. В этой части в ходе подробного
обсуждения ценностей, принципов и методик AM закладывается базис для пони-
мания излагаемого в книге материала.
Часть 2: Гибкое моделирование на практике. В этой части рассматриваются
такие серьезные вещи, как методики эффективного общения и документирования,
использование простейших средств моделирования, а также организационные и
культурные аспекты поддержки AM. Кроме того, здесь рассматриваются вопросы,
связанные с организацией рабочих зон моделирования и групп моделирования,
проведения сеансов моделирования, и приводится анализ методик UML в свете
гибкого моделирования.
Часть 3: Гибкое моделирование и экстремальное программирование (ХР).
Эта часть посвящена подробному обсуждению повышения эффективности ХР
при помощи принципов и методик AM. Она начинается с внесения ясности в то,
какое положение занимают в ХР процессы моделирования и документирования.
После такого вступления мы переносим внимание на моделирование частей учеб-
ного проекта SWA Online с помощью методов ХР/АМ.
Часть 4: Гибкое моделирование и унифицированный процесс (UP). Эта часть
посвящена подробному обсуждению того, как сделать моделирование по UP про-
ще, используя принципы и методики AM. И вновь мы производим моделирование
на примере частей проекта SWA.
Часть 5: Глядя в будущее. В этой части рассматриваются проблемы организа-
ции и управления, возникающие при проведении гибкого моделирования.
Ценности гибкого
моделирования
Моделирование схоже с планированием — наиболь-
шую ценность представляет процесс моделирования,
а не сама модель.
Когда я впервые читал книгу «Экстремальное программирование» (Кент Бек,
2000), наиболее пикантной особенностью ХР я посчитал тот способ, которым
Кент определил основание этой методологии. Он описал четыре ценности — об-
щение, простоту, обратную связь и смелость. Меня привело в восхищение то,
что ему удалось найти способ описать некоторые из фундаментальных факторов,
которые приводят к победе в состязаниях по разработке программ, и что он ухит-
рился сделать это так, что отдельные разработчики тоже почувствовали, что это
такое. Браво! Таким образом, когда я начал собирать материал по гибкому моде-
лированию (AM), я решил, что буду подходить к этому примерно так же, как Кент
к ХР. Я начну описание с высших ценностей, определю набор конкретных .при-
нципов (глава 3), которые базируются на этих ценностях, после чего, отталкива-
ясь от этих ценностей и принципов, сформулирую положения (глава 4), которые
могут быть использованы людьми, занимающимися гибким моделированием, в их
работе.
. Поскольку я полностью разделяю ценности ХР, я просто подогнал все четы-
ре его ценности под свой материал — зачем заново изобретать колесо, если его
уже можно использовать? Однако я почувствовал, что что-то упускаю, что-то та-
кое, что я не мог ясно сформулировать. Как-то раз я работал над сайтом клиен-
та и вместе с другим разработчиком участвовал в обсуждении требований. Наши
пользователи описывали, как они представляют себе свою работу, а разработчик
считал, что они описывают ее неправильно. Он считал, что они не могут работать
таким образом, а пользователи раз за разом повторяли ему, что да, именно так они
могут работать и работают. Он знал другой метод работы, который считал более
правильным, и знал, что технически такое возможно, но пользователям это было
неинтересно, они хотели выполнять свою работу так, как делали ее всегда (иногда
попадаются такие странные пользователи). Это хорошо, я думаю, но не для того
разработчика. Он был прав, пользователи были неправы, несмотря на то, что они
утверждают требования. Бе-е;е. В конце концов я настоял на том, что мы работаем
40 Глава 2 • Ценности гибкого моделирования
так, как говорят нам пользователи, и позже, через какое-то время, объяснил ему,
что именно заказчики — а не разработчики — являются создателями требований.
Хотя это было головной болью для нашей команды, это происшествие открыло
для меня еще одну ценность, необходимую для гибкого моделирования: смирение.
Таким образом, ценностями AM я считаю:
• общение,
• простоту,
• обратную связь,
• смелость,
• смирение.
Общение
Что такое общение? Университетский словарь Вебстера (Merriam Webster’s
Collegiate Dictionary, 10th Edition) определяет общение как «процесс, в ходе ко-
торого информация передается от одного лица другому посредством общей сис-
темы символов, знаков или поведения». Общение — это улица с двусторонним
движением: в результате общения вы и передаете информацию, и получаете ее.
Мой опыт подсказывает, что эффективное общение (между любыми лицами, при-
нимающими участие в проекте, включая как разработчиков, так и заинтересован-
ных в проекте людей) является необходимой составной частью успеха разработки.
Проблемы проекта возникают, когда общение прерывается. Так, например, если
разработчик не может сказать своим коллегам, что его код работает неправильно,
результатом станет сверхурочная работа другого разработчика по отслеживанию
возникающих проблем. Пользователь не в состоянии указать относительную важ-
ность своих требований, и разработчики сосредотачиваются на вторичных свой-
ствах, игнорируя действительно важные для организации. Ваш менеджер проек-
та преуменьшает важность получения разработчиками новой рабочей станции и
в результате не получает средств на необходимый апгрейд. Разработчики демон-
стрируют заинтересованным лицам проект пользовательского интерфейса, кото-
рый эмулирует существующую систему, а те ошибочно полагают, что видят перед
собой реальную систему, и требуют поставки на полгода раньше, чем вы договари-
вались. Множество проблем, с которыми приходится сталкиваться команде раз-
работчиков, вызываются недопониманием.
Если мы остановимся и подумаем, то одной из основных причин моделиро-
вания окажется то, что моделирование помогает при общении. Когда ваши поль-
зователи описывают сложный бизнес-процесс, вы можете способствовать улуч-
шению понимания процесса, набросав диаграмму потоков данных, которая будет
отражать его логику. Часто вы можете больше узнать за пять минут совместного
рисования, чем за пять часов обсуждения или чтения корпоративных руководств.
Если вы хотите прояснить проект части вашей системы, вы можете совместно про-
моделировать эту часть, например, начертив диаграмму классов UML, чтобы ра-
зобраться в структуре ваших классов. Совместно вы можете работать и в ходе про-
Простота 41
ектирования, обсуждая результаты применения различных подходов и прикиды-
вая, как вы собираетесь их реализовать. Моделирование поможет вам обсуждать
' ваши идеи, объяснять эти идеи другим, совместно проверять их, чтобы в конеч-
ном счете добиться общего понимания. В главе 8 я рассмотрю важность общения
в процессе разработки программного обеспечения и способы активизации обще-
ния в методиках AM.
Простота
Я полагаю, что вам нелегко было бы найти такую книгу по разработке программ-
ного обеспечения, в которой хотя бы раз не упоминалось правило KISS (Keep It
Simple Stupid! — «Сделай это проще, дурачок!»). Индустрия производства про-
граммного обеспечения многие годы проповедует необходимость простоты, но по
некоторым причинам этот хор до сих пор не услышан. После того как в книге о
программном обеспечении утверждается необходимость простоты, в ней обяза-
тельно рекомендуется производить такие действия, которые непременно услож-
няют ваши программы, затрудняют их разработку, тестирование и обслуживание.
Наиболее часто предлагаются следующие усложнения:
Слишком частое использование сложных паттернов. Если вам нужно реа-
лизовать телефонные номера ваших заказчиков, использование паттерна анали-
за Место встречи (Contact Point) (Амблер, 2001а) часто подобно катастрофе. Да,
реализация этого паттерна — очень интересное дело, но иерархия классов силь-
но затрудняет его разработку, тестирование и поддержку, по.сравнению с прос-
тым классом Номер телефона. Чтобы применение паттерна Место встречи в вашей
программе было оправданным, лучше дождаться того момента, когда вам дей-
ствительно понадобятся адреса электронной почты и почтовые адреса. Не пойми-
те меня неправильно, я всецело за паттерны, и я первый соглашусь с тем, что не-
редко применение паттернов — это самый простой из возможных путей. Штука
в том, что «нередко» не означает «всегда».
Усложнение архитектуры системы для поддержки возможных будущих рас-
ширений. Может быть, банковская информационная система, над которой вы
сейчас работаете, в один прекрасный день будет использоваться для поддержки
продаж'страховых полисов, так не будет ли правильнее спроектировать универ-
сальное средство для работы с финансовыми инструментами? Да, моделирова-
ние подобной вещицы должно быть весьма интересным занятием, но вам придет-
ся сделать программу более сложной, чем она должна быть на сегодняшний день.
Разработчики, которые сомневаются в своей способности внести изменения в сис-
тему позднее, или подстегиваемые своим «эго» к созданию «абсолютной» системы,
частенько проектируют программное обеспечение именно таким образом. Гибкие
разработчики не создают избыточного программного обеспечения. Они готовы
/ держать пари, что в состоянии создать настолько простой продукт, насколько это
возможно в настоящее время, а затем добавлять к нему при необходимости новую
функциональность, опять-таки настолько простую, насколько это возможно. Как
это происходит? Мартин Фаулер (2001b) прекрасно показал это в ходе обсуж-
42 Глава 2 • Ценности гибкого моделирования
дения принципа YAGNI (You Ain’t Gonna Need It — «Это вам не понадобится»).
Он указывал на то, что мы не в состоянии предсказать, что именно понадобит-
ся нам в будущем, и с одинаковым успехом можем как угадать, так и ошибиться.
А если это так, то зачем разрабатывать, тестировать и создавать избыточную функ-
циональность, функциональность, которая не является необходимой прямо сей-
час, а может, и вовсе не понадобится? Не лучше ли сосредоточиться на удовлет-
ворении текущих требований, которые предъявляют к проекту заинтересованные
в нем лица, чтобы сохранить их расположение (а вот это хорошо всегда!), и иметь
смелость считать, что мы сможем справиться с завтрашними проблемами завтра?
Если мы сконцентрируемся на построении самого простого решения сегодняшних
проблем, с тем чтобы впоследствии добавить ставшую нужной функциональность,
мы будем знать, что завтра нам придется изменять простую систему. Будет ли эта
система настолько же проста, если мы изменим ее сейчас, когда даже не.знаем тол-
ком, что нам может понадобиться?
Разработка сложной инфраструктуры. Широко распространенная ошибка,
совершаемая командой, — когда начальные усилия прикладываются к разработ-
ке инфраструктуры проекта (например, компонентов, сред и библиотек классов),
вместо того, чтобы употребить их на построение блоков системы. Идея здесь со-
стоит в том, что подобные первоначальные вложения в конечном счете обычно
оправдываются. Однако такой подход содержит несколько серьезных недостат-
ков. Во-первых, вы вкладываете ресурсы заказчиков, не показывая им такого ре-
зультата, которым они могли бы немедленно воспользоваться. Заказчики, веро-
ятно, хотят получить от вас конкретную вещь, которая помогла бы им выполнять
их работу, а первое, что вы им показываете, — это подсистема обработки ошибок.
В результате из-за невозможности быстро разработать требуемую функциональ-
ность вы подвергаете свой проект риску. Во-вторых, вы часто игнорируете прин-
цип YAGNI и начинаете включать в состав инфраструктуры такие вещи, которые
вам, собственно, не очень-то и нужны. Наилучший подход — сократить разработ-
ку инфраструктуры по ходу проекта до действительно необходимого уровня. Так,
например, разработку подсистемы для обработки ошибок можно отложить до того
момента, когда она вам действительно понадобится.
СОВЕТ: ПОДСТИЛАЯ СОЛОМУ, НЕ ПЕРЕСТАРАЙТЕСЬ -----------------------------
Я часто видел разработчиков, которые отвлекались от своей настоящей задачи, создания
программ, и которые эффективно удовлетворяли запросы пользователей, выдумывая
всевозможные сумасшедшие сценарии типа «А что, если?». Они начинали заниматься излишним
моделированием, пытаясь подстелить соломку во всех возможных местах падения, решить все
возможные проблемы — такие проблемы, которые заинтересованные в проекте лица не брали
в расчет, или такие проблемы, на риск возникновения которых они были готовы пойти. Затем,
поскольку они излишне моделировали, им приходилось излишне работать. Да, вы не должны
быть слишком оптимистичны. Следует понимать, что некоторые проблемы, такие как сбой базы
данных или отказ сети, действительно могут происходить, но при моделировании не следует
отрываться от реальности.
Итак, что со всем этим делать при гибком моделировании? Основное положе-
ние состоит в том, чтобы сохранять модели настолько простыми, насколько это
возможно, моделировать сегодня то, что вам необходимо сегодня, и откладывать
Обратная связь 43
завтрашнее моделирование на завтра. Другими словами, не моделируйте чрезмер-
но — следуйте правилу KISS, а не правилу KICK (Keep It Complex Kamikaze —
«Сделай это посложнее, самоубийца»).
Модели играют основную роль в упрощении программ и процессов их созда-
ния — гораздо проще разработать идею и улучшить понимание задачи, нарисовав
одну-две диаграммы, чем писать десятки или сотни строк кода.
Обратная связь
Единственный способ определить, правильно ли вы сделали свою работу, — это
получить отклик, то же самое относится и к отклику на ваши модели. Модели —
это абстракции. Например, набор элементов Use Case — это абстракция способов
работы с вашей системой, а модель компонентов — это абстракция внутренней
структуры программного обеспечения. Как узнать, что ваша абстракция правиль-
на? Существует множество способов обеспечить модели обратную связь:
Разрабатывайте модели в команде. Разработка программного обеспечения
сродни плаванию, заниматься этим в одиночку опасно. Когда вы работаете с дру-
гими людьми, вы быстро получаете отклик на свои идеи.
Обсуждайте модель со своей целевой аудиторией. В идеале ваша целевая ау-
дитория должна быть вовлечена в процесс создания модели. Моделирование тре-
бований должно производиться совместно с пользователями, подробные модели
проектирования должны разрабатываться совместно с теми людьми, которые бу-
дут выполнять программирование. Если это невозможно, будет полезно сесть и
вместе с ними пройтись по моделям, а может быть, и проработать сценарии ис-
пользования. Неформальные обсуждения могут быть .организованы и на нефор-
мальной основе, например, вы легко можете устроить краткое обсуждение с каким-то
человеком, чтобы получить его отклик на свою работу, тогда как организация фор-
мальных совещаний (Гилб и Грэм, 1993) потребует больших усилий.
Реализуйте модель. Самый надежный способ получить отклик — реализо-
вать модель в виде программы и дать заказчикам поработать с этой программой.
Лучше один раз увидеть.
Проводите приемо-сдаточные испытания. Убедитесь в том, что ваша модель
отражает требования заказчиков к системе. В ходе приемо-сдаточных испытаний
заказчики проверяют правильность своих требований, да и вам не помешает лиш-
ний раз проверить свои модели.
Интересно будет рассмотреть затраты времени на каждый из вариантов полу-
чения отклика. Когда вы работаете вместе, командой, отклик приходит практи-
чески немедленно,'в пределах секунд или минут. В ходе неформальных обсужде-
ний получение отклика может потребовать от нескольких минут до нескольких
часов, хотя если вам удалось заполучить человека на неформальное обсуждение,
почему же вы с самого начала не создавали модель вместе с ним? С другой сто-
роны, формальные совещания могут откладываться на несколько дней, недель
или даже месяцев, в зависимости от доступности участников. При реализации
модели в виде программы отклик в идеальном случае будет получен уже через
44 Глава 2 • Ценности гибкого моделирования
несколько дней или даже часов (помните, вы используете гибкий подход к разра-
ботке). Приемо-сдаточные испытания обычно приносят результат через несколь-
ко недель или месяцев.
Почему затраты времени так важны? Потому, что чем быстрее мы получаем от-
клик, тем легче нам изменить наши модели, приводя их в соответствие с действие
тельными нуждами заказчика. Хотя свое место есть у всех методов организации
обратной связи, предпочтение следует отдавать обратной связи, возникающей
внутри рабочей группы, потому что она является мгновенной. Кроме того, следует
отдать должное проверке моделей путем создания программ, поскольку на бумаге
все может выглядеть отлично, но при попытке реализации такая идиллия может
прекратиться. \
Смелость
Смелые люди проходят в дверь; они не топчут-
ся за ней, раздумывая о том, что ждет их на той
стороне.
Семпай Рик Микуччи
Гибкое моделирование и вообще гибкая разработка программного обеспечения
пока в новинку большинству людей, а также организациям, в> которых они работа-
ют. Как мы показали в главе 1, принципы гибкой разработки программного обес-
печения бросают вызов сложившемуся положению, что угрожает благополучию
многих людей. Гораздо проще сесть на место и принять существующее положение,
не пытаясь улучшить ситуацию, или ждать, когда кто-нибудь придет и все испра-
вит. Такой вызванный страхом паралич — основная причина теперешнего ужас-
ного положения в индустрии ИТ.
В одной организации, в которой мне довелось работать, группа администриро-
вания баз данных держала группу разработки программ мертвой хваткой.
Разработчики не могли работать с корпоративными данными, не пройдя через
группу баз данных, они не могли создать свою собственную базу данных, не пройдя
через группу баз данных, и, само собой разумеется, они не могли передавать про-
граммы в производство без благословения группы баз данных. В этом нет ничего
особенно плохого, если работа группы баз данных эффективна, но, к сожалению,
это был не тот случай. Моя группа работала над проектом на основе Enterprise
JavaBeans (EJB), первым для этой компании, используя в качестве источника дан-
ных базу данных Oracle. Когда мы услышали, что группе баз данных'для установки
базы потребуется несколько недель, мы решили сделать это своими силами, для
чего нам потребовалось сначала потратить пару часов на установку, а затем в тече-
ние нескольких следующих дней подправлять по мелочам то там, то здесь, чтобы
получить нужный вариант. Причина, по которой группе баз данных требовалось
несколько недель, заключалась в том, что они настаивали на использовании своей
Смелость 45
особой процедуры определения размеров базы данных (работа, которую мы уже
выполнили), чтобы быть уверенными в том, что их машины имеют необходимую
емкость дисков (мы просто взяли емкость по максимуму), и, разумеется, необходи-
мо было, заполнить множество форм, которые потом никому не понадобятся. Они
пришли в ярость, и начальник группы закатил скандал нашему начальнику, кото-
рый устроил нам головомойку. Мы стояли на своем, утверждая, что у нас нет вре-
мени на удовлетворение бюрократических прихотей группы баз данных. Никто не
мог нормально работать с этой группой. Люди в моей команде были обеспокоены,
но первоочередным делом для нас была своевременная разработка системы, так
что мы решили драться. Это требует смелости. Чтобы снять напряжение, мы сказа-
ли, что были бы более чем счастливы сотрудничать с ними в вопросах администри-
рования нашей базы данных и улучшения нашей схемы данных, что действительно
было правдой. Цосле этого у нас возникла следующая проблема. Вместо того чтобы
поручить работу с нами одному администратору баз данных (DBA), они хотели
включить в наш проект несколько человек: одного — для администрирования базы
данных, одного — для разработки логической модели данных (которая при разра-
ботке объектно-ориентированного программного обеспечения не имеет никакого
значения) и одного — для создания физической модели данных (это нам было
действительно необходимо). Более того, они хотели делать все это независимо, па-
раллельно с нашей разработкой, вместо того чтобы включить этих людей в нашу
команду. Другими словами, большая часть их предложений была направлена на
создание ненужной работы. Нам было гораздо проще самим создать эту физиче-
скую модель данных, чем организовывать работу с подобной отдельной группой.
У нас было несколько человек, квалификации которых на это вполне хватало. Они
умели также создавать и использовать схемы баз данных (некоторые из нас зани-
мались такими вещами по нескольку лет). И снова нам пришлось с ними сражать-
ся — еще один смелый поступок, учитывая, что никто из нас раньше этого не делал.
А ведь мы однажды уже заставили их пойти на уступки! В конце концов все реши-
лось на большом совещании с участием их менеджеров и наших менеджеров. На
самом деле мы были в хороших отношениях с некоторыми администраторами в
группе баз данных, которые в частных беседах соглашались с нами, и мы надеялись,
что нам удастся найти выход из организационного тупика. На совещании началь-
ник группы баз данных утверждал, что наши инсинуации о том, что наша произво-
дительность упадет, беспочвенны, что его сотрудники быстро, за несколько недель,
помогут нам продвинуть работу, и будут помогать нам следующие несколько меся-
цев. И в этот момент я сказал, что наша база данных уже работает и мы можем''про-
демонстрировать ее каждому в этой комнате. У нас хватало смелости делать пра-
вильные вещи: отказаться работать с нефункционирующей группой и показать всем,
что существует другой метод работы. Это нелегко, однако в долгосрочной перспек-
тиве это принесло выигрыш не только нашему проекту, но и всей организации. Мы
заразили другие группы смелостью, необходимой для того, чтобы отказаться от
услуг группы баз данных, и в конечном счете вынудили эту группу к совершенство-
ванию (хотя, по моему мнению, и недостаточному) рабочих процессов.
46 Глава 2 • Ценности гибкого моделирования
Гибкие методологии ориентируют нас на работу в тесном контакте с другими
людьми, требуют ,веры в них и в себя. Это обуславливает нашу смелость. Такие
методики, как ХР и AM, предлагают создавать вещи настолько простыми, насколь-
ко это возможно. Они требуют уверенности в том, что завтра мы сможем решить
завтрашние проблемы. Для этого нужна смелость. AM требует, чтобы мы созда-
вали документацию только тогда, когда без. нее не обойтись, а не тогда, когда это
кажется нам удобным. И на это нужна смелость. ХР и AM требует, чтобы мы
оставили принятие бизнес-решений, таких как приоритетность требований,
бизнесменам, а принятие технических решений о том, какая программа будет
удовлетворять этим требованиям, — техническим специалистам. Это обеспечи-
вается дополнительной порцией смелости. AM требует от нас использования
самых простых возможных средств, таких как грифельная доска и бумага, слож-
ные средства должны использоваться для моделирования только тогда, когда они
приносят максимальную прибыль. «Это немыслимо без смелости», — справедли-
во отметите вы. AM требует, чтобы мы не отвлекались на рисование диаграмм
в ущерб действительно сложным вещам, таким как преобразование моделей в код.
«Да, такое по плечу только смелым!» — воскликнете вы. AM требует, чтобы мы
доверяли своим коллегам, верили в то, что программисты могут создавать про-
ектные решения, и поэтому вам не нужно забивать им головы чрезмерной дета-
лизацией. Разве такое возможно без смелости? AM требует от вас выбрать победу,
разорвать круг почти катастроф и простых ошибок, характерный для промыш-
ленности информационных технологий. Это опять значит, что без смелости не
обойтись.
Я полагаю, что смелость — необходимая составляющая гибкой разработки про-
грамм. Во-первых, смелость необходима, поскольку вам нужно решать, использо-
вать ли гибкий подход. Затем — продолжать использовать этот подход, когда дела
пойдут туго (а так бывает всегда). В вашей организации найдутся люди с другими
взглядами на жизнь, от вас могут потребовать освоить пакет XYZ, освоить полно-
масштабный процесс разработки, руководство пожелает поставить вас под более
жесткий контроль, от вас потребуют отдать все производство ИТ на сторону, вам
велят следовать указаниям других отделов, — и на каждом шагу все будут сопро-
тивляться вашим усилиям. Это все политика. Во-вторых, в ходе разработки вам
потребуется смелость для принятия важных решений — предпочесть одно архи-
тектурное решение другому или выбрать язык программирования, на котором вы
будете работать. В ходе разработки вам также потребуется смелость, чтобы сме-
нить направление, отказаться от сделанного или произвести рефакторинг, если
некоторые из ваших решений окажутся неверными.
В-третьих, вам потребуется смелость для того, чтобы понять, что вы не иде-
альны и способны делать ошибки. В-четвертых, смелость потребуется, чтобы по-
верить, что завтра вам удастся решить завтрашние проблемы. Смелость нужна не
только для завтрака1.
' Это перефраз лозунга рекламной кампании, проводившейся в Северной Америке в середине 90-х:
«Яйца нужны не только для завтрака».
Вдали от мамы и яблочного пирога 47
Смирение
Хорошие разработчики обладают достаточным смирением, чтобы осознавать, что
они ничего не знают. Откровенно говоря, это возможно. Вы можете быть велико-
лепным Java-кодировщиком, не зная при этом каждой отдельной детали в каждом
отдельном Java API. Более того, даже если вы прекрасный Java-кодировщик, это
не означает, что вы прекрасно проектируете интерфейсы, или прекрасно разра-
батываете базы данных, или прекрасно поете, — это означает только, что вы пре-
красный Java-кодировщик. Но даже если вы прекрасный Java-кодировщик, это не
означает, что вы не можете научиться ничему новому у других Java-кодировщиков
вашей команды, включая новичков. На самом деле я часто узнаю от новичков
больше, чем от опытных людей, поскольку новичок, расспрашивая, как работает
та или иная вещь, нередко может подвергнуть мои представления испытанию на
прочность.
Люди, занимающиеся гибким моделированием, понимают, что их коллеги и за-
казчики являются экспертами в своих областях и обладают ценностями, которые
следует привнести в проект. Некоторые разработчики кодируют лучше вас, или
лучше тестируют код, или лучше умеют моделировать требования или разрабаты-
вать архитектуру. Ваши пользователи, вероятно, разбираются в различных вопро-
сах бизнеса лучше вас. Руководители верхнего уровня лучше понимают, как раз-
вивается та область, в которой они работают, а сотрудники знают, что можно и
чего нельзя сделать с их продукцией.'Тот, кто занимается гибким моделировани-
ем, должен обладать достаточным смирением, чтобы понимать — для того, что-
бы успешно выполнить свою работу, ему необходима помощь, он должен работать
совместно с этими людьми.
Смирение также используется в методах общения с людьми. Тот, кто занимает-
ся гибким моделированием, проявляет смирение по отношению к людям, с кото-
рыми он работает, полагая, что другие, возможно, обладают иными приоритетами
и опытом, и поэтому имеют иную точку зрения. Они не называют своих началь-
ников «умниками», людей из других отделов — «бумажными крысами», а пользо-
вателей или заказчиков — «тупицами» или «полными психами»?Придумывание
обидных прозвищ — это не смирение, это гордыня. Гордыня приводит к пробле-
мам в общении, поскольку является той причиной, по которой люди перестают с
вами сотрудничать. Это, в свою очередь, вызывает затруднения в реализации про-
екта. Люди, которые занимаются гибким моделированием, смиренны и в резуль-
тате более производительны.
Вдали от мамы и яблочного пирога
Люди, которые занимаются гибким моделированием, мужественны. Они стре-
мятся к простоте, они ищут отклика, они коммуникабельны, и, наконец, смирен-
ны. Кажется, что когда вы начинаете заниматься гибким моделированием, вас мож-
но сразу причислять к лику святых. На самом деле люди, занимающиеся гибким
48 Глава 2 • Ценности гибкого моделирования
моделированием, — всего лишь люди. Они допускают ошибки, в их жизни суще-
ствуют и другие проблемы, не имеющие отношения к эффективным методикам
моделирования, и они думают и действуют в соответствии со своими собственны-
ми мотивами. Я описал здесь эти ценности не потому, что эти ценности следует
воспринимать дословно, моя задача — не столько добиться абсолютного следова-
ния этим ценностям, сколько использовать их в качестве фундамента, на основе
которого люди могли бы построить свое гибкое мировоззрение, а команды и орга-
низаций — культуру, в которой поощрялась бы гибкость и эффективная разработ-
ка. Эти ценности также используются вместе с ценностями и принципами Гибкого
альянса (2001а, 2001b), о которых мы говорили в главе 1, в качестве фундамента,
на основе которого мы в главах 3 и 4 определим принципы AM.
Базовые принципы
Принципы что-то значат, если вы придерживае-
тесь их, даже когда это непросто.
Принципы гибкого моделирования вытекают из ценностей гибкого моделирова-
ния (глава 2) — общения, простоты, обратной связи, смелости и смирения, а также
из ценностей и принципов Гибкого альянса (2001а, 2001b). Используя эти принци-
пы в проектах по разработке программ, мы создадим на их основе набор методик
моделирования (главы 5 и 6). Ценности AM, несмотря на всю их важность, доста-
точно абстрактны и являются слишком общими, чтобы задавать разработчикам
верное направление движения. Отсюда следует необходимость определить прин-
ципы AM — значительно более конкретные понятия. Некоторые из принципов
были перенесены в гибкое моделирование из экстремального программирования
(ХР) (Бек, 2000), которое, в свою очередь, заимствовало их из общепринятых ме-
тодик создания программного обеспечения. А что вы хотите — повторное исполь-
зование! В этой книге принципы в основном рассматриваются с точки зрения их
применения в моделировании, и, таким образом, материал, известный из ХР, мо-
жет предстать перед нами в новом свете. В этой главе рассматриваются базовые
принципы AM, те принципы, которые вы должны полностью соблюдать; если хо-
тите иметь право называть свою работу гибким моделированием (подробнее об
этом чуть позже). В главе 4 мы рассмотрим дополнительные принципы AM, опи-
сывающие важные понятия, которые помогут нам усовершенствовать работу над
моделями. Основные принципы AM таковы:
• Главная цель — программное обеспечение.
• Еще одна цель — продолжать проект.
• Путешествуйте налегке.
• Добивайтесь простоты.
• Ожидайте изменений.
• Изменения должны быть небольшими.
50 Глава 3 • Базовые принципы
• Модель должна решать конкретную задачу.
• Множество моделей.
• Вам нужен набор методик.
• Качественная работа.
• Быстрая обратная связь.
• Повышайте отдачу от ресурсов, полученных от заинтересованных лиц.
Главная цель — программное обеспечение
Главная цель разработчиков программного обеспечения — создание высокока-
чественных программ, которые вполне удовлетворяют запросам заинтересован-
ных лиц. Этот принцип перекликается с принципом Гибкого альянса (2001b):
«Работающая программа — это единственный критерий прогресса». Нравится нам
это или нет, но главная наша цель — не создание документации, не создание до-
полнительных артефактов управления и даже не создание моделей. Создание до-
кументации очень удобно тем, что вы можете успешно обманывать самого себя
и верить, что продвигаетесь вперед, хотя на самом деле это не так. С другой сто-
роны, когда вы занимаетесь сложными задачами, такими как написание и тести-
рование кода, может случиться так, что выбранный вами подход не оправдывает
ваших ожиданий. Однако написание отчетов, в которых вы рассказываете об успе-
хах или, хуже того, скрываете свои ошибки, может доставить вам удовольствие, но
ни на шаг не приблизит вас к конечной цели.
Имейте смелость сконцентрироваться на том, что действительно важно, на со-
здании необходимой пользователям системы. Вы — не разработчики документа-
ции и даже не разработчики моделей, вы — разработчики программ. Подумайте об
этом. Следует ставить под вопрос целесообразность любой работы, не связанной
непосредственно с выполнением главной задачи. Если этой работе не находится
достаточного обоснования, ее следует немедленно прекратить.
Еще одна цель — продолжать проект
Ваш проект может быть признан неудачным даже тогда, когда ваша команда пре-
доставит пользователям работающую систему, — отчасти удовлетворение запро-
сов заинтересованных в проекте лиц состоит в том, чтобы уверить их, что ваша
система достаточно надежна и со временем ее можно будет усовершенствовать.
Как любил говорить Алистер Кокберн (2001b), когда вы играете в игру под назва-
нием «разработка программ», ваша вторая цель — организовать следующую игру.
Ваши усилия во вторую очередь должны быть сосредоточены на выпуске новой
основной версии системы или просто на поддержке работы и обслуживании су-
ществующей версии. Чтобы этого добиться, вы должны не только разработать
качественный программный продукт, но и полностью документировать его, что-
бы люди, которые будут играть в следующей игре, могли делать это успешно; вы
Путешествуйте налегке 51
должны стимулировать разработчиков передавать накопленный опыт, создавать
у имеющихся сотрудников мотивацию остаться и разработать следующую версию
системы, или, проще говоря, мотивировать сохранение команды разработчиков.
В число факторов, которые вам следует принимать во внимание, входят челове-
ческие качества разработчиков, тип дальнейших действий по разработке програм-
мы и важность дальнейшей разработки для вашей организации. Говоря коротко,
когда вы работаете над системой, вы должны смотреть в будущее.
Этот принцип вытекает из такой ценности AM, как «Общение» (контакты).
г‘
Путешествуйте налегке
Под путешествиями налегке мы подразумеваем, что вы не должны создавать йз-
лишних моделей и документов. Каждый созданный вами артефакт, с которым вы
работаете продолжительное время, подлежит периодическому пересмотру. Это
относится к моделям, документам и артефактам управления проектом, таким как
графики, наборы тестов и код программ. Так, например, вы решили создать семь
моделей. Когда что-нибудь изменится, например появятся новые или поменяют-
ся старые требования, ваша команда начнет использовать новый подход или при-
менит новую технологию, — вам потребуется рассмотреть, как эти изменения пов-
лияют на все семь моделей и что в связи с этим необходимо предпринять. Если
в результате вы решите, что нужно сохранить только три модели, понятно, что
вы затратите на поддержку изменений значительно меньше усилий. Это повысит
вашу гибкость, поскольку вы будете путешествовать налегке.
Чем сложнее или детальнее будут ваши модели, тем опять-таки выше веро-
ятность того, что изменять их тоже будет сложно (поскольку отдельная модель
сложнее, затраты на ее поддержку также возрастают). Каждый раз, когда вы при-
нимаете решение сохранить модель, вы расплачиваетесь гибкостью за те удобства,
которые приносит вашей команде представленная в абстрактном виде информа-
ция. Однако при этом вы потенциально повышаете способность к общению внут-
ри команды и возможность диалога, с заинтересованными лицами. Никогда не
следует недооценивать значение подобного компромисса.
z Джим Хайсмит (2000) указывал, что человеку, который пересекает пустыню,
будут очень полезны карта, шляпа, хорошие ботинки и фляга с водой. Ему, скорее
всего, не удастся достичь цели, если он обременит себя сотнями литров воды, кон-
тейнером, полным всевозможного спасательного снаряжения и подборкой книг
о пустыне. Однако можно представить себе и обратную картину — понятно, что
было бы глупо отправляться в поход через пустыню вообще без снаряжения.
Точно так же и команда разработчиков, которая собирается разработать и под-
держивать в дальнейшем детальные требования, детализированный набор моде-
лей анализа, детализированный набор моделей архитектуры и детализированный
набор моделей проектирования, быстро обнаружит, что большую часть времени
она тратит не на написание кода программы, а на внесение изменений во все эти
документы. Хорошая практическая рекомендация — не вводите модель, пока вам
не станет совершенно ясно, что она необходима.
52 Глава 3 • Базовые принципы
Внутри команды необходимо взаимопонимание, это позволит вам путешест-
вовать налегке. Если разработчики не понимают ваших требований или архитек-
туры и, тем более, если никто не готов быстро ответить на их вопросы, значит, вы
в серьезной беде. Понятно, что для путешествий налегке налаженное взаимопо-
нимание совершенно необходимо. Путешествия налегке требуют смелости. Вы
должны обладать уверенностью в том, что у вас нет необходимости в некоем арте-
факте, и в том, что вы сможете создать его, если это представление окажется оши-
бочным.
Принцип «Путешествуйте налегке» вносит простоту в ваш подход к разработ-
ке. Он предписывает максимальное понижение затрат на поддержку различных
артефактов в ходе разработки.
Добивайтесь простоты
Когда вы занимаетесь разработкой, вам следует предполагать, что самое простое
решение является наилучшим, и поступать в соответствии с заголовком этого раз-
дела. Этот принцип вытекает из ценности AM «Простота» и принципа простоты
Гибкого альянса (2001b). Как указывал Кент Бек (2000), простые решения пре-
красно работают большую часть времени, а поскольку они просты, их легко реали-
зовать. Их преимущество состоит в том, что вам не нужно тратить лишнее время
на реализацию сложных решений, таких вариантов, реализация которых требует
дополнительных затрат времени и сил. Их преимущество также и в том, что в тех
редких случаях, когда простых решений недостаточно, у вас остается время для
реализации более сложных решений. Необходимые для этого ресурсы вы сэконо-
мили заранее. К тому же простое решение легче поддерживать и дополнять.
Реализация этого принципа сводится к тому, чтобы не создавать слишком объ-
емный продукт или, в случае моделирования, не добавлять в свои модели'допол-
нительные возможности, которые не нужны вам сегодня. Не занимайтесь чрез-
мерным моделированием системы, создавайте модель на основе тех требований,
которыми вы располагаете, и производите рефакторинг системы, когда эти требо-
вания будут уточнены или изменятся. Для реализации этого принципа сохраняйте
свои модели настолько простыми, настолько это возможно. Это принцип Оккама
в. моделировании — когда имеются сомнения, выбирай самый простой подход.
! Всегда ли срабатывает принцип выбора самого простого подхода? Возможно,
нет, но в подавляющем большинстве случаев он все-таки срабатывает. Если он не
сработал, то, скорее всего, вы поймете это достаточно быстро, и у вас хватит вре-
мени еще раз изучить имеющиеся данные. Если применять более сложные методы
(а сложные методы тоже, бывает, заводят нас в тупик), то чтобы понять, что наши
идеи не работают, нам придется вложить в их проработку значительные ресурсы.
Ожидайте изменений
Изменения происходят — примите это как факт. Получайте от этого удоволь-
ствие. Изменения — это одна из тех вещей, которые делают разработку программ-
Изменения должны быть небольшими 53
ного обеспечения увлекательной. Требования со временем пересматриваются.
Заинтересованные в вашем проекте лица со временем лучше понимают, чего они
хотят. По мере того как ваш проект продвигается, может изменяться и состав заин-
тересованных лиц — в их число могут добавиться новые люди, а старые могут уйти.
Заинтересованные в проекте лица могут также сменить свою точку зрения, а воз-
можно, изменят и цели, а также критерии успеха проекта. Кроме того, по мере раз-
вития проекта могут измениться деловая обстановка и технологическая среда. Они
вообще частенько выходят из-под контроля. Общий смысл всех этих предложений
состоит в том, что среда, в которой существует ваш проект, со временем меняется.
Люди, занимающиеся гибким моделированием, ожидают изменений. Они по-
нимают,, что изменения в ходе разработки программного обеспечения — обычное
дело. Гибкий альянс (2001b) объявил, что мы приветствуем изменения требова-
ний, даже на поздних этапах жизненного цикла проекта. Люди, занимающиеся
гибким моделированием, знают, что их работа будет подвергаться изменениям,
они стараются активно общаться с заинтересованными в проекте лицами и полу-
чать от них комментарии и отклик, чтобы иметь возможность своевременно опре-
делить необходимость изменений и вовремя внести их в проект.
Они не осуждают заинтересованных в проекте лиц за необходимость измене-
ний, напротив, они активно сотрудничают с ними, чтобы определить, что в проект
необходимо внести изменения, и побуждают их принимать наилучшие решения
о том, как, где и когда внести изменения в проект. Кроме того, люди, производя-
щие гибкое моделирование, понимают, что их модели — это всего лишь модели,
и разработчики при необходимости могут порубить их на куски и собрать зано-
во в улучшенном виде. Они допускают, что другие люди могут внести улучшения
в то, что они делают.
Люди, занимающиеся гибким моделированием, осознают опасность, таящую-
ся в ожидании изменений. Эта опасность состоит в тенденции создавать на пред-
варительных этапах, например, при моделировании требований, невнятные реше-
ния. Зачем тратить много времени на разработку понятных требований, если их
все равно придется менять? Не лучше ли быстренько написать некий код и по-
дождать, пока заинтересованные в проекте лица не скажут, что нужно изменить?
Верно? Нет, неверно! Значительно полезнее не полениться и потратить время на
то, чтобы разобраться в требованиях так хорошо, как это возможно в настоящий
момент, чтобы создать программное обеспечение, которое будет соответствовать
имеющимся требованиям. Некоторые требования могут измениться, и вы долж-
ны'это предвидеть, но большая часть требований изменяться не будет (во всяком
случае, часто). Заметим, что такие принципы AM, как «Качественная работа» и
«Повышайте отдачу от ресурсов, полученных от заинтересованных лиц», проти-
водействуют тенденции появления невнятных решений.
Изменения должны быть небольшими
Ожидая изменений, вы должны построить разработку на базе инкрементного под-
хода, чтобы изменять систему небольшими порциями, вместо того, чтобы пытаться
54 Глава 3 • Базовые принципы
включить все изменения в одну большую версию. Даже весьма значительное изме-
нение следует реализовывать в виде серии небольших последовательных измене-
ний. Так, третий принцип Гибкого альянса (2001b) гласит, что вы должны постав-
лять работающие версии программ часто, лучше всего каждые несколько недель
или в худшем случае каждые нескольких месяцев. Это важная концепция, кото-
рая позволяет понять, почему в гибком моделировании не требуется сделать все
правильно с первого раза. На самом деле это весьма маловероятно, даже если вы
сделаете такую попытку. Таким образом, в своей модели вам не следует старать-
ся сразу же охватить все детали, вполне достаточно, если вы сделаете это тогда,
когда возникнет такая необходимость. Бесполезно пытаться в начале проекта раз-
работать всеобъемлющую модель. Расставьте вехи и создайте маленькую деталь-
ную модель или, может быть, модель верхнего уровня, а впоследствии раз за разом
уточняйте ее (или просто избавьтесь от нее, когда необходимость в ней исчезнет).
Чтобы признать, что вы не можете все сделать правильно сразу или даже с Уг-го
раза, требуется смирение. Чтобы признаться в этом другим, требуется смелость.
Кент Бек (2000) хорошо сказал об этом: «Сделайте, чтобы оно работало, сделайте,
чтобы оно работало правильно, а уж потом сделайте, чтобы оно работало быстро».
Модель должна решать конкретную задачу
Если вы не в состоянии понять, зачем и для кого вы создаете модель, для чего вы
вообще будете заниматься этой работой? Многие разработчики волнуются о том,
будут ли их артефакты — будь то модели, тексты программ или документация —
достаточно подробны, или не будут ли они чересчур подробны, или достаточно
ли они точны. Им даже не приходит в голову отступить на шаг назад и спросить
себя, зачем они создают артефакт и для кого они его создают. Для этого необходи-
мо смирение. Вы не должны заниматься моделированием для удовлетворения соб-
ственного желания моделировать, вы должны моделировать для удовлетворения
нужд заинтересованных в проекте лиц.
Каковы же разумные причины создания модели? Обычно вы хотите лучше
продумать определенные Аспекты своей программы, часто вам нужно донести свое
видение проблемы до высшего руководства, чтобы оно утвердило ваши решения,
или создать документацию, которая содержала бы описание вашей системы для
людей, которые будут работать с этой системой, поддерживать ее или развивать.
Вы моделируете для того, чтобы понимать, или для того, чтобы общаться.
Следующие причины не являются разумными:
• Это нужно делать согласно полномасштабному процессу разработки, и вы
делаете это по долгу службы, не понимая, зачем вам это нужно.
• Кто-то требует у вас модель, не объясняя, зачем она нужна, если не считать
объяснением слово «Надо!».
• Не поговорив с человеком, хотя возможность для этого имеется, вы, тем не
менее, хотите создать для него модель.
Множество'моделей 55
Ваш первый шаг при моделировании — определить разумную цель созда-
ния модели и аудиторию, для которой будет предназначена эта модель. После
определения цели и аудитории разрабатывайте модель, пока она не станет до-
статочно детальной и достаточно точной. После того как модель будет соответ-
ствовать своей задаче, вы должны прекратить работу — потому что вы ее закон-
чили!
Переходите к следующему этапу, например, к написанию кода, который необ-
ходим для того, чтобы продемонстрировать работоспособность модели. В резуль-
тате ваши модели будут оставаться простыми, поскольку вы не перегружали их
бесполезными деталями. Этот же принцип применяется и к существующим моде-
лям: если вы вносите изменения, например применяете паттерн, для внесения из-
менений вам необходима разумная причина, такая как необходимость поддержки
новых требований или рефакторинг, который должен внести в модель большую
ясность. Одно из важных следствий (этого принципа) состоит в том, что вам необ-
ходимо знать аудиторию, для которой предназначена модель, даже если эта ауди-
тория — вы сами. Например, вы создаете модель для разработчиков. Что им на
самом деле нужно? Какой документ будет считаться достаточным — пятисотстра-
ничный том со всеобъемлющими инструкциями или десятистраничное описание
того, как все работает? Не знаете? Сходите, поговорите с разработчиками — они
вам скажут. :
Посмотрим на это с другой стороны. Требование, согласно которому модель
.должна не более чем соответствовать своей задаче, эквивалентно требованию огра-
ничения затрат на разработку этой модели. Когда вы в первый раз работаете над
моделью, вы, вполне вероятно, испытываете чувство удовлетворения, поскольку
вам удалось обдумать некоторый предмет, добиться лучшего понимания своих за-
дач или яснее понять, как создать то, что вы создаете. По мере продолжения ра-
боты вы все ближе и ближе подходите к своей цели —. разработать нужную вам
модель, пока, наконец, не настает тот миг, когда вы достигаете финиша. Начиная
с этого момента дальнейшая работа над моделью приносит все меньше и меньше
пользы. Да, вы можете углубиться в детали. Да, вы можете повышать точность и
непротиворечивость модели, но при этом вы не будете продвигаться вперед. Вы
должны найти себе другое занятие, лучше всего начать писать код, который при-
несет вашему проекту наибольшую пользу.
Множество моделей
У вас имеется широкий выбор артефактов моделирования, многие из которых
описаны в приложении А этой книги. В число этих артефактов входят диаграм-
мы Унифицированного языка моделирования (UML) (Object Management
Group 2001), структурные артефакты разработки, такие как модели данных, и ар-
тефакты нижнего уровня, например модели пользовательских интерфейсов.
Каждый из артефактов имеет свои сильные и слабые стороны, каждый из них ре-
комендуется применять в одних ситуациях и не рекомендуется — в других. По-
скольку современное программное обеспечение отличается сложностью, ни один
56 Глава 3 • Базовое принципы
из артефактов, и даже все семейство артефактов UML, не может применяться во
всех возможных ситуациях. Из этого следует, что для эффективной работы вам
необходимо использовать для описания программной системы различные мо-
дели, поскольку каждая-из моделей будет описывать лишь один аспект вашего
программного обеспечения. Так, например, на рис. 3.1 приведена логика разме-
щения заказа в режиме он-лайн, в то время как диаграмма потоков пользова-
тельского интерфейса (UI) на рис. 3.2 описывает навигацию потоков пользова-
тельского интерфейса в системе SWA Online. Полезно будет заметить, что
диаграмма последовательности определена в UML, в то время как диаграмма по-
токов пользовательского интерфейса — (еще) нет, при этом обе диаграммы опи-
сывают различные, но одинаково важные аспекты системы SWA Online.
Рис. 3.1. Диаграмма последовательности UML Для размещения заказа
Используя любую из моделей там, где это полезно, и отказываясь от ее исполь-
зования там, где это не имеет смысла, вы можете ограничить сложность проекта.
Создавайте его на основе нескольких простых моделей. Если вы будете оттал-
киваться от одной или двух очень сложных моделей, ваша задача значительно
усложнится. Вам как разработчику проще при работе над базой данных вашей
системы использовать модель данных, а при работе над пользовательским ин-
терфейсом — модели, ориентированные на пользовательский интерфейс, напри-
Множество моделей 57
мер, диаграммы потоков пользовательского интерфейса: Точно так же будет
проще и тем, кто будет с вами общаться, поскольку в каждый момент времени
им нужно будет сосредоточиться на одной модели, не пытаясь охватить взгля-
дом все в целом. Этот принцип вытекает из таких ценностей AM, как «Простота»
и «Общение».
Рис, 3.2. Диаграмма потоков пользовательского интерфейса для SWA Online
Отметим, что хотя вам доступен широкий выбор моделей, нет такой системы,
для которой нужно было бы создавать все эти модели. В зависимости от при-
роды программного обеспечения, которое вы разрабатываете, и процессов раз-
работки программного обеспечения, которые вы используете наряду с AM, вам
придется разработать самое большее несколько моделей. Так, например, коман-
да, работающая по ХР, может использовать в качестве основного артефакта
моделирования истории пользователя, а групца, использующая унифициро-
ванный процесс, воспользуется для этой цели комбинацией из элементов Use
Case, бизнес-правил, ограничений и технических требований. Приложение на
базе EJB будет требовать объектно-ориентированных артефактов проектирова-
ния, например, входящих в UML, а для проекта по созданию хранилища данных
нужны модели данных. Различные типы проектов требуют создания различных
наборов артефактов. Для успешного гибкого моделирования вам необходимо
уметь разрабатывать множество моделей, чтобы при необходимости воспользо-
58 Глава 3 • Базовые принципы
\
ваться теми моделями, которые\улсны в данном случае. Чтобы долго и успеш-
но заниматься гибким моделированиёмгвам необходимо «Смирение» (еще одна
ценность AM), для того чтобы понимать необходимость постоянного изучения
новых методик, нередко обучаясь у молодых разработчиков, еще сохранивших
школьные знания, или у заинтересованных в проекте лиц, которые понимают,
как ведется бизнес.
Вам нужен набор методик
Во многих местах этой книги я буду использовать следующую аналогию. Я счи-
таю, что разработчик должен иметь набор (McConnell, 1993) методик, которые
он мог бы при необходимости применять, точно так, же, как плотник имеет на-
бор инструментов. Чем больше у вас инструментов и знаний о том, как их при-
менять, тем более вы эффективны как разработчик, поскольку выше вероятность
того, что в вашем наборе найдется нужный для работы инструмент. Никакой мел-
кий ремонт не требует применения всех инструментов, лежащих в вашем наборе.
Точно так же никакая разработка не требует использования всех известных вам
методик. Однако разнообразие мелких ремонтов таково, что вам потребуется каж-
дый из этих инструментов. Так же и проекты, в которых вам приходится прини-
мать участие, столь разнообразны, что требуют от вас применения всех известных
вам методик моделирования. Наконец, некоторые из инструментов вы использу-
ете особенно часто. Точно так же и среди различных типов моделей у вас будут
свои любимцы.
Качественная работа
Никто не любит небрежную работу. Люди, выполняющие подобную работу, не лю-
бят ее потому, что это. такая вещь, которой нельзя гордиться. Люди, которые зани-
маются рефакторингом, — возможно, это будете вы сами несколько недель спус-
тя, когда поменяются требования, или разработчик группы поддержки, которому
придется совершенствовать вашу систему, — не любят ее потому, что в небреж-
но сделанной работе труднее разобраться, а значит, в нее труднее внести измене-
ния. Другими словами, качественная работа повышает эффективность общения в
рамках проекта. Конечные пользователи, которые будут пользоваться результата-
ми вашей небрежной работы, будут не в восторге от того, что получившиеся про-
граммы, скорее всего, будут подвержены сбоям и/или не будут соответствовать
их ожиданиям. Высшее руководство не любит небрежной работы, потому что они
чувствуют, что такая работа не принесет им ожидаемой прибыли на вложенный
капитал.
Люди, занимающиеся гибкой разработкой, понимают, что они должны вкла-
дывать свои усилия в создание стабильных артефактов, таких как код программ,
пользовательская и техническая документация по системе (документация деталь-
но рассматривается в главе 14) надлежащего качества. Впрочем, для того, что-
бы встать и сказать, что на хорошую работу нужно время, необходима сила воли.
Быстрая обратная связь 59
Гибкие разработчики не прикладывают чрезмерных усилий к разработке артефак-
тов, которые со временем потеряют свою необходимость и будут забыты, напри-
мер к наброскам или эскизам как прототипам основных пользовательских интер-
фейсов. Другими словами, они обладают смирением, чтобы разумно расходовать
свое время, поскольку понимают, что в противном случае будут просто разбаза-
ривать ресурсы заинтересованных в проекте лиц. Вы хотите сказать, что эти ре-
комендации противоречат друг другу? Я так не думаю. Если что-то строится на-
долго, оно должно быть построено как следует, в противном случае обойдитесь
минимально возможным.
Быстрая обратная связь
Обратная связь — это одна из пяти ценностей AM, и поскольку время между дей-
ствием и реакцией на это действие очень важно для нас, люди, которые занимаются
гибким моделированием, предпочитают быструю обратную связь медленной. При
совместной работе над моделью, особенно при совместном моделировании, на-
пример на белой доске, с CRC-карточками или со стикерами (бумагой на клейкой
основе), вы получаете реакцию па евой идеи почти мгновенно. Это позволяет опре-
делить, подходят ли ваши методы для разрешения возникающих проблем, а так-
же дает возможность проработать и улучшить создаваемые модели. Проводимая
совместно с заказчиком работа по уточнению требований, анализу этих требова-
ний или разработке пользовательского интерфейса, который удовлетворял бы за-
казчика, дает вам возможность быстро получить отклик. Написание кода на осно-
ве созданных моделей — еще один способ получения быстрого отклика, поскольку
код демонстрирует, насколько реальна ваша модель. При этом в вашей работе не-
редко обнаруживаются изъяны, вызванные тем, что вы не продумали все до конца.
Отклик на то, что вы сделали, — это разочаровывающий, но очень полезный опыт,
и лучше получить его раньше, чем позже, пока вопросы не переросли в проблемы’
и вы еще способны справиться с ситуацией.
Быстрая обратная связь важна для нас по двум причинам. Мы делаем большую
часть ошибок на ранних стадиях разработки, а стоимость их исправления с тече-
нием времени возрастает по экспоненте. Технические специалисты прекрасно
разбираются в технических вопросах, таких как проектирование и кодирование, —
потому что они технические специалисты. К сожалению, технические специали-
сты часто слабы в задачах, не относящихся к технике, таких как сбор требований
и анализ производительности, — вероятно, потому, что они все-таки технические
специалисты. В результате, как показано на рис. 3.3, разработчики обычно делают
больше ошибок на этапах определения требований и анализа, чем при проектиро-
вании и написании кода. Кроме того, при негибкой разработке стоимость исправ-
ления этих ошибок тем выше, чем позже они будут обнаружены (рис. 3.4). Это
связано с природой разработки программного обеспечения — выполняемая работа
базируется на ранее выполненной. Так, например, моделирование на этапе про-
ектирования выполняется на основе требований. Программирование ведется на
основе модели проектирования, а тестирование производится на основе написан-
ного текста программ.
60 Глава 3 • Базовые принципы
Вероятность
появления
ошибок
Определение Моделирование Кодирование Полномасштабное Реализация
требований тестирование
системы
• Рис. 3.3. Снижение вероятности появления ошибок
Если требования остались непонятыми, все модели, которые будут построены
на основе этих требований, потенциально ошибочны, весь код, написанный на
основе этих моделей, тоже сомнителен, а тестирование выявляет соответствие
приложения некорректным условиям. Если вы получаете отклик только на позд-
них стадиях разработки, при тестировании системы, или после выхода версии, ис-
правлять ошибки будет очень накладно. При быстрой обратной связи, когда об
ошибках в толковании передаваемой информации вам сообщают немедленно, раз-
решить возникшее непонимание будет гораздо дешевле.
Стоимость
исправления
ошибок
Определение Моделирование Кодирование Полномасштабное Реализация
требований тестирование
системы
Рис. 3.4. Рост стоимости поиска и исправления ошибок
Почему это базовые принципы? 61
Повышайте отдачу от ресурсов,
полученных от заинтересованных лиц
Заинтересованные в вашем проекте лица вкладывают в него ресурсы — время,
деньги, оборудование и т. д., — чтобы получить программное обеспечение, удов-
летворяющее их запросам. Они заинтересованы в том, чтобы использовать свои
ресурсы наилучшим возможным образом, и не хотят, чтобы ваша команда растра-
тила их на ерунду. Более того, заинтересованные лица заслуживают того, чтобы
им в результате сказали, как были использованы или не использованы эти ресур-
сы. А если бы это были ваши деньги, вы распорядились бы ими иначе?
СОВЕТ: ДОКУМЕНТАЦИЯ ПО СИСТЕМЕ — ЭТО НЕ ТЕХНИЧЕСКОЕ РЕШЕНИЕ,
ЭТО БИЗНЕС-РЕШЕНИЕ -----------------:------------------------
Важно понимать, что каждый раз, когда вы собираетесь создать модель или документ, вы
принимаете серьезное решение — вы отказываетесь от новой функциональности в обмен на
написание документации. Если вы хорошенько подумаете, то поймете, что это решение является
не техническим, а бизнес-решением. Вы обмениваете бизнес-функциональность на возможные
выгоды от понижения риска, которое обеспечивается наличием стабильных артефактов,
описывающих систему. Таким образом, вы должны пойти к заинтересованным в проекте лицам
и спросить, хотят ли они, чтобы их ресурсы были потрачены таким образом, представив им при
этом все преимущества и недостатки подобного решения. Они могут выбрать предложенные
артефакты, а могут пойти на риск и предпочесть путешествие налегке. Но это должно быть их
решением, а не вашим.
Почему это базовые принципы?
Почему я заостряю ваше внимание на том, что гибкое моделирование гарантиру-
ется только тогда, когда используются все базовые принципы AM? Я хочу предуп-
редить проблему, которая возникла в ХР, — люди, утверждавшие, что они занима-
ются ХР, на самом деле ХР не занимались, при этом обвиняя методологию в своих
ошибках. Как и для ХР, принципы, и методики AM работают только в комплексе,
и если вы не будете использовать некоторые из них, совокупный эффект исчезнет.
Потерпев неудачу в освоении одного из базовых принципов или методик AM, вы
понизите эффективность методологии. Да, вы получите выгоду даже от части AM,
но вам, вероятно, не удастся добиться потрясающего повышения производитель-
ности, потому что у вас не будет совокупного эффекта. Короче говоря, применяй-
те столько AM, сколько сочтете нужным, но, пожалуйста, не говорите, что занима-
етесь гибким моделированием, если вы освоили его лишь частично.
Дополнительные
принципы
Бороться за принципы проще, чем жить по ним.
Альфред Адлер
Дополнительные принципы гибкого моделирования представляют собой концеп-
ции, способные повысить вашу эффективность в гибком моделировании. Хотя
эти принципы подкрепляют базовые принципы AM, описанные в главе 3, для
того чтобы заниматься гибким моделированием, использовать их не обязатель-
но. Все эти принципы представляют собой очень полезные рекомендации, и вам
стоило бы адаптировать их, если они подходят к вашей корпоративной культуре.
Дополнительные принципы AM таковы:
• Содержание важнее формы.
• Учитесь друг у друга.
• Знай свои модели.
• Приспосабливаем по месту.
• Открытые и доброжелательные контакты.
• Доверяйте человеческим инстинктам.
Содержание важнее формы
Любую модель можно представить различным образом. Так, например, описание
пользовательского интерфейса (UI) можно создать, наклеивая стикеры на большом
листе бумаги (основные или высокоуровневые прототипы); в виде наброска на бу-
маге или белой доске, или в виде «традиционного» прототипа, который построен
при помощи средств прототипирования или языка программирования, или в виде
официального документа, в котором имеются как визуальное представление, так и
текстовое описание UL В зависимости от причины, побудившей вас создать модель,
различные варианты представления могут быть одинаково хороши. Если вашей за-
дачей является вывод информации в виде HTML-страницы, вам подойдет любой
Содержание важнее формы 63
из трех вариантов. На самом деле, если вы, применив средства рисования, сделаете
описание аккуратнее и выполните полное документирование, это ничего не приба-
вит к решению данной задачи. Содержание в данном случае будет важнее формы.
Важное следствие из этого принципа состоит в том, что нет никакой необходимости
срочно переходить к использованию сложных CASE-средств. Да, CASE-средства
могут быть очень полезны, если они генерируют для вас код или могут произвести
обратную разработку и построить на основе имеющегося кода понятную модель, но
начинать лучше с использования простых и гибких инструментов. Эти вопросы де-
тально рассматриваются в главе 10. Рассмотрим другой пример. UML-диаграмму
классов можно создать в виде наброска, как показано на рис. 4.1, с использовани-
ем программы построения диаграмм Microsoft Visio, как показано на рис. 4.2, или
построить с помощью сложного CASE-средства. Это будет одна и та же диаграм-
ма классов, меняться будет лишь ее изображение. Для выполнения требуемой за-
дачи может быть достаточно наброска — он поможет людям, которые его рисуют,
выработать основу подхода к проектированию программы, над которой они работа-
ют. Можно ли использовать набросок с рис. 4.1 в официальной документации (если
считать, что в нем содержится важная информация, которую вы хотите сохранить)?
Почему бы и нет?
Рис. 4.1. Набросок диаграммы классов UML
Он выглядит не так аккуратно, как нарисованная с помощью CASE-средства
диаграмма с рис. 4.2, но чтобы создать его, требуется втрое меньше времени.
Запомните, что люди, занимающиеся гибкой разработкой, повышают отдачу от
ресурсов, полученных от заинтересованных лиц, а значит, потратить время на то,
чтобы просто сделать что-то аккуратнее, — это серьезное решение. Я полагаю, что
мир не перевернется, если вы вставите в официальную документацию сделанный
от руки рисунок. Я нередко использую отсканированные или сфотографирован-
ные цифровым фотоаппаратом наброски в официальных документах или на пре-
зентациях. Набросок отражает идею, которую я хочу донести до своей аудитории,
и я не хочу попусту тратить время на перевод этого наброска в более аккуратный
вид только для того, чтобы он лучше смотрелся. Очень полезно демонстрировать
64 Глава 4 • Дополнительные принципы
людям неидеальную работу, отстаивать свои решения, затрачивая на это минимум
труда, и продолжать двигаться дальше. Подобные модели действительно неполны,
и, откровенно говоря, мой почерк ужасен, но запомните: тот, кто занимается гиб-
ким моделированием, строит модели с определенной целью и прекращает работу
сразу после достижения этой цели.
Рис. 4.2. Диаграмма классов UML, выполненная при помощи Microsoft Visio
СОВЕТ: ДАЙТЕ СВОЕЙ АУДИТОРИИ ТО, ЧЕГО ОНА ЖДЕТ ------------------------
Осуществимость методики с включением в документацию диаграмм, нарисованных от
руки, зависит от вашей аудитории. Если вы готовите документ для настоящих бюрократов,
вам, вероятно, следует потратить некоторое время на то, чтобы перерисовать модели с
использованием соответствующих инструментов. В этом нет ничего странного, в конце концов,
вы тратите их деньги, но следует понимать, что в этом случае у вас есть резерв для увеличения
гибкости и вам следует уведомить об этом своих заказчиков.
Точно так же, одна ита же структура классов, приводимая на рис. 4.1 и 4.2, может
быть описана при помощи различных артефактов, например модели Класс-Обя-
занность-Сотрудничество (модели CRC), или, в случае использования другой но-
тации, при помощи нотации ОМТ (Рамбо и др., 1991). Говоря об этом, мы не пы-
таемся противопоставить нотацию ОМТ нотации UML по той простой причине,
что UML — это промышленный стандарт, в то время как ОМТ — нет. Да, по неко-
торым техническим характеристикам ОМТ может считаться лучше, чем UML,
однако имеются хорошие шансы сорвать общение из-за неиспользования извест-
ного стандарта, а это более важно. Интересное следствие из всего этого состоит в
том, что модель не обязательно должна представляться в виде документа. Я могу
набросать рисунок, показанный на рис. 4.1, просто чтобы разобраться в структуре
классов, с которыми работаю, затем написать код, протестировать классы и выбро-
сить эту модель после окончания работы. Точно так же сложный набор диаграмм,
созданных с использованием CASE-средства, может не являться составной частью
документа. Они могут использоваться для создания других артефактов, обычно
кода программ, но никогда не формализуются в виде официальной документации.
I
fe'’
Приспосабливаем по месту 65
Это делается для того, чтобы получить все преимущества моделирования, не тратя
средств на создание и поддержку документации. Этот принцип вытекает из таких
ценностей AM, как «Простота» и «Общение» и из предпочтения, которое выказы-
вает Гибкий альянс (2001а): «Работающие программы важнее идеальной докумен-
тации».
Учитесь друг у друга
Люди, занимающиеся гибким моделированием, знают, что они никогда не смогут
добиться полного совершенства, им всегда будет необходимо познавать все боль-
ше, расширяя свои знания. У них будет возможность работать вместе с другими
людьми и учиться у-них, находить новые способы выполнения работы, лучше по-
нимать, что следует делать, а чего не следует. Технологии быстро изменяются,
существующие технологии, такие как Java, развиваются гигантскими шагами, ре-
гулярно появляются новые технологии, такие как C# и .NET. Существующие мето-
дики разработки развиваются медленнее, но тоже не остаются неизменными. Так,
в промышленности мы осознали научные основы тестирования, но продолжаем
повышать наши знания в этой области при помощи исследований и практической
работы. Дело в том, что мы работаем в промышленности, для которой изменения
являются нормой, и вынуждены использовать любую возможность научиться но-
вым методам работы — при помощи практических занятий, на курсах, под руко-
водством инструктора, по книгам и в ходе работы.
Следствие такого положения дел состоит в том, что каждый должен быть го-
тов к работе с другими людьми, в ходе которой он будет помогать им изучать но-
вые приемы работы. На самом деле я верю, что вы в состоянии помочь другим
пополнить их набор методик. Этот принцип вытекает из таких ценностей, как
«Общение» и «Смирение».
Знай свои модели
Поскольку у- вас имеется множество моделей, которые вы можете гибко при-
менять, для эффективного использования вам необходимо знать их сильные и
слабые стороны. Кроме того, методики моделирования все время изменяются,
приспосабливаясь к-изменениям технологии. Когда аспектно-ориентированное
программирование (Xerox, 2001) станет более широко распространенным, если
это вообще произойдет, мне непременно придется изучить одну или несколько
аспектно-ориентированных моделей и/или аспектно-ориентированных версий
существующих типов моделей. Это поможет мне делать эти модели настолько
простыми, насколько это возможно, а также повышать эффективность общения
в ходе проекта, в котором я буду использовать эти методики.
Приспосабливаем по месту
Я сомневаюсь, что вам удастся когда-нибудь применить «типовое АМ». Скорее
всего, вам придется модифицировать его, приводя в соответствие со средой, к ко-
3 Зак. 926
66 Глава 4 • Дополнительные принципы
торой относятся стиль работы, принятый в вашей организации, ваши коллеги, за-
интересованные в проекте лица и сам проект. Когда вы будете адаптировать про-
ект так, чтобы он удовлетворял вашим требованиям, вы, разумеется, должны бу-
дете принимать во внимание те методики моделирования, которые собираетесь
применять. Так, например, ваши пользователи могут не ограничиться наброска-
ми наиболее важных прототипов UI и пожелать увидеть общий вид готового ин-
терфейса пользователя. Средства, которые вы применяете, окажут воздёйствие на
ваш подход. Хотя это и дороже, чем цифровой фотоаппарат, но у вас уже долж-
ны быть лицензии на существующие CASE-средства. AM может быть изменено,
чтобы отражать особенности используемого процесса разработки программного
обеспечения. В третьей части книги рассматривается использование AM в проек-
тах, разрабатываемых по ХР, а в четвертой части — использование AM в проектах,
разрабатываемых в соответствии с унифицированным процессом.
Вы можете изменить свой подход как на уровне отдельного человека, так
и на уровне всего проекта. Например, некоторые разработчики предпочита-
ют один набор средств другому. Так, когда я занимался кодированием на Java,
я предпочитал умный редактор кода и JDK, а мои коллеги пользовались интегри-
рованными средами разработки (Java IDE). Некоторые люди концентрируются
на написании кода и очень мало моделируют, а другие больше ориентированы
на визуальное восприятие и предпочитают перед тем, как писать код, потратить
время на рисунок. Разные люди, разное применение AM. Важно понимать, что
ценности, принципы и методики остаются теми же самыми, а их применение раз-
лично.
Кроме того, запомните: AM работает не всегда. Я уже говорил об этом в главе 1.
Полная адаптация AM может быть нереальной или как минимум не мгновенной.
В этом случае может оказаться, что в принятом у вас программном процессе мож-
но использовать хотя бы часть принципов и методик AM. Если в результате вам
удастся повысить свою эффективность как разработчика, это будет прекрасно.
Открытые и доброжелательные контакты
Для того чтобы делать выбор, люди хотят быть свободными и знать, что они сво-
бодны. Это относится и к мыслям по поводу того, что предпочесть, одну модель
или несколько. Допустим, придуман новый подход к проектированию, появился
новый взгляд на требования или просто новый способ для показа текущего состо-
яния проекта. Открытые и доброжелательные контакты помогают людям прини-
мать наилучшие решения, поскольку эти решения основаны на более точной ин-
формации.
Открытые и доброжелательные контакты требуют общей ответственности и по-
нимания того факта, что эффективное общение является важнейшим фактором в
успешности проектов по созданию программ. Люди, которые в состоянии это по-
нять, должны быть готовы услышать не слишком приятные вещи. Все должны
быть в состоянии отбросить свои выстраданные предложения, услышав, что они
не так хороши, как казалось вначале.
Выгода от применения этих принципов 67
Доверяйте человеческим инстинктам
Когда кому-то кажется, что «эта штука» не заработает, что две вещи несовмести-
мы между собой или что «эта штука неправильно пахнет», очень может быть, что
так оно и есть. По мере того как вы приобретаете опыт в разработке программного
обеспечения, ваши инстинкты становятся точнее, и то, что ваши инстинкты под-
сознательно вам сообщают, может быть полезным вкладом в моделирование. Если
ваши инстинкты говорят о том, что требования бессмысленны или неполны, об-
судите это с пользователями. Если ваши инстинкты говорят вам, что часть архи-
тектуры не соответствует вашим задачам, постройте небольшой технологический
прототип, чтобы проверить эту гипотезу. Если ваши инстинкты говорят вам при
проектировании, что альтернатива А лучше альтернативы В, и никаких серьезных
критериев для выбора одной из этих альтернатив нет; смело предпочтите альтер-
нативу А. Важно понимать, что такая ценность AM, как «Смелость», указывает,
что вы сможете исправить ситуацию в будущем, если в какой-то момент окажется,
что инстинкты вас подвели.
Выгода от применения этих принципов
Принципы, описанные в этой главе и главе 3, пока они не усвоены, лишь немногим
лучше добрых пожеланий. Люди, которые занимаются гибким моделированием,
адаптируют эти принципы и действуют в соответствии с ними. Сказать это проще,
чем сделать. Я не знаю, как гарантировать усвоение этих принципов, все, что я мо-
гу сделать, — это порекомендовать вам думать о них и стараться по возможности
им следовать. Я составил документ, в котором кратко изложено описание гибко-
го моделирования — в него входит список ценностей, принципов и методик AM —
и который вы можете загрузить с сайта, посвященного AM: www.agilemodeling.com.
Пожалуй, если вы распечатаете этот документ — три листа при односторонней пе-
чати и прикрепите его к стене в пределах вашей рабочей зоны, это может вам по-
мочь. По крайней мере, попытаться стоит. , . ‘
Базовые методики
Совершенная методика дает совершенный
результат.
Сенсей Рик Виллемсен
Основа гибкого моделирования — это набор его методик. В своих проектах вы бу-
дете применять именно методики AM, основанные на ценностях и принципах AM.
Как и принципы, методики AM делятся на базовые и дополнительные. Как уже
говорилось в главе 3, вам придется принять базовые методики AM, чтобы иметь
основание утверждать, что вы занимаетесь гибким моделированием. Конечно, вы
можете успешно работать, используя лишь некоторые из этих методик, но лучше
принять их все, если они соответствуют культуре производства вашей организа-
ции. Применение методик AM в вашей организации подробно рассмотрено в гла-
ве 28.
Базовые методики AM делятся на четыре категории, подробно описанные
в главе 7: как объединены методики AM. Вот эти категории и соответствующие
им базовые методики:
1. Итеративное и инкрементное моделирование:
• применяйте нужный артефакт (артефакты);
• создавайте несколько моделей параллельно;
• переходите от одного артефакта к другому;
• моделируйте постепенно.
2. Работа в группе:
• моделируйте в группе;
• активное участие заинтересованных лиц;
• совместное владение;
• демонстрируйте модели открыто.
3. Простота:
создавайте простое содержание;
Применяйте нужный артефакт (артефакты) 69
• изображайте модели просто;
• используйте простейшие инструментальные средства.
4. Подтверждение правильности:
• учитывайте тестируемость;
• подтверждение модели кодом.
СОВЕТ: НИ ОДНА ИЗ ЭТИХ МЕТОДИК НЕ ЯВЛЯЕТСЯ НОВШЕСТВОМ -----------------
Когда вы прочитаете данную главу и главу 6, многие (если не все) методики AM навер-
няка покажутся вам знакомыми. Дело в том, что отдельно взятые методики AM не новы —
они давно и успешно используются разработчиками. Новшеством является то, что я впер-
вые объединил их и дал их совместное описание. Более того, они являются квинтэссен-
цией сотен лучших методик, которым следуют разработчики, и как вы увидите в главе 7,
они объединены в синергетическое целое, которое я называю гибким моделированием.
Методики итеративного
и инкрементного моделирования
AM определяет четыре методики, которые основаны на итеративном и инкремен-
тном подходе к моделированию:
1. Применяйте нужный артефакт (артефакты).
2. Создавайте несколько моделей параллельно.
3. Переходите от одного артефакта к другому.
4. Моделируйте постепенно.
Применяйте нужный артефакт (артефакты)
Данная методика полностью соответствует выражению «Всему свое время».
В данном случае вы хотите создать верную модель (модели), чтобы выполнить ра-
боту. Каждый артефакт, будь то схема состояний UML, базовый элемент Use Case,
исходный код или диаграмма потока данных (DFD), имеет свои сильные и сла-
бые стороны и поэтому применяется в зависимости от ситуации. Например, диа-
грамма деятельности UML (Рамбо, Джекобсон и Буч, 1999) на рис. 5.1 подходит
для описания обработки деловой информации, тогда как статическую структуру
вашей базы данных лучше изобразить в виде модели физического представления
данных (Рейнгрубер и Грегори, 1994), как показано на рис. 5.2. Точно так же и
диаграмма лучше, чем исходный код. Если рисунок сбережет вам тысячу слов, то
модель, использованная при определенных обстоятельствах, может сэкономить
вам 1024 кодовые строки (Карл Вигерс, 1999). Порой для эффективного анали-
за вариантов проекта лучше нарисовать со своими коллегами пару диаграмм, чем
просиживать часами над разработкой примеров кода.
Для разработчика гибких моделей важно понять, когда следует и когда не сле-
дует применять тот или иной тип артефакта. Данная информация представлена
70 Глава 5 • Базовые методики
в приложении А и применяется в различных методах моделирования. Изучить
каждый тип артефактов весьма трудно; проблема осложняется тем, что в вашем
распоряжении может быть значительное количество артефактов.
Рис. 5.1. Диаграмма деятельности UML для обработки заказа
СОВЕТ: НАЧНИТЕ С ИЗУЧЕНИЯ ПОДМНОЖЕСТВА АРТЕФАКТОВ -----------------—
Поражены количеством артефактов, описанных в приложении А? Не беспокойтесь, это
нормально. AM имеет обратную сторону. Оно требует от вас научиться применять множество
артефактов, а на это уходит много времени и сил. Для начала следует остановиться на
изучении основного подмножества, а затем изучать новые приемы по мере необходимости.
Такие методологии, как ICONIX (Розенберг и Скотт, 1999) и Catalysis (Д'Суза и Виле, 1999),
рекомендуют несколько артефактов и описывают их применение на практике. В случае, если
вы обнаруживаете недостающие аспекты методологии, вы можете пополнить их подходящими
артефактами.
Создавайте несколько моделей параллельно
Любая модель имеет свои плюсы и минусы, поэтому ни одна модель не может
удовлетворить ваши требования полностью. Например, вы рассматриваете требо-
вания и решаете разработать элемент Use Case (Джекобсон, 1992; Кокбёрн, 2001а),
Методики итеративного и инкрементного моделирования 71
как показано на рис. 5.3; сущностный прототип UI, как показано на рис. 5.4
(Константайн и Локвуд, 1999); CRC-модель (Каннингем и Бэк, 1989), как на
рис. 5.5. Элемент Use Case описывает, как размещается заказ; прототип UI опре-
деляет требования к экрану или странице для поддержки ввода заказа; карточки
CRC содержат концептуальную информацию о сфере деятельности.
Рис. 5.2. Запуск модели физического представления данных для SWA Online
Выясняя требования заинтересованных лиц, вы вносите необходимые усовер-
шенствования в каждую модель, заключая информацию в тот артефакт, где эта ин-
формация будет наиболее эффективна. То же происходит, например, когда вы раз-
рабатываете ПО на Java и обнаруживаете, что вам нужно разработать диаграмму
классов UML для определения структуры ПО, диаграмму схем состояний UML
для изучения внутренней деятельности сложного класса, диаграмму последова-
тельности UML для определения способа обеспечения логики потока в пределах
элемента Use Case (см. рис. 5.1) или бизнес-правила, и модель физического пред-
ставления данных для понимания .структуры вашей реляционной базы данных
(см. рис. 5.2). Используя данную методику в сочетании с методикой «Переходите
72 Глава 5 • Базовые методики
от одного артефакта к другому» (см. следующий раздел), разработчики гибких мо-
делей быстро осознают, что они работают более продуктивно, разрабатывая не-
сколько моделей одновременно, в отличие от случаев, когда они сосредоточива-
ются на одной модели.
1. Элемент Use Case начинается с тоге момента, когда покупатель решает
разместить заказ.
2. . Покупатель ищет товар посредством элемента Use Case «Поиск товара
3. Покупатель добавляет товар к своему заказу
4. Покупатель указывает количество заказываемого товара.
5. Система считает промежуточную сумму , умножая цену товара на его количество.
6/ Покупатель повторяет шаги с 2 по 5 по мере формирования заказа,
7. Покупатель заканчивает добавлять товары к заказу
8. Покупатель дает информацию по доставке и оплате, включая имя, телефон
и физический адрес. • ,
. 9. Система считает промежуточную сумму всего заказа, путем сложения промежу-
точных сумм отдельных групп товара,
10. Система считает налоги, которыми облагается заказ, в соответствии с деловым
регламентом Расчет налога на заказ.
11. - Система считает действующие скидки, в соответствии с деловым
регламентом Расчет скидок на заказ.
12. Система отображает действующие налоги и скидки,
13. Система считает общую сумму заказа путем добавления действующих налогов
к промежуточной сумме заказа и вычитания скидкою
14. Система отображает итог заказа,
15, Покупатель подтверждает правильность заказа,
16. Система планирует выполнение заказа (см. элемент Use Case «Выполнение заказа»).
17. Система выдает покупателю подтверждение получения заказа с его описанием.
Рис. 5.3. Основные действия при размещении заказа
Интересное свойство данной методики заключается в том, что она дискре-
дитирует два распространенных антипаттерна в информационных технологиях.
К сторонникам первого, который я называю «разработчик одного артефакта», от-
носятся те, кто специализируется в разработке одного вида комплектующих уз-
лов. Пример — те, кто желает только писать коды, кодировщики низкого уровня,
которые считают, что важнее исходного кода нет ничего на свете, и разработчики
моделей данных, которые думают, что по степени важности ничто не сравнится
с данными.
На самом деле такой узкий подход не эффективен при современном уровне
развития ПО. Я советую вам не только накопить как можно больше опыта в облас-
ти создания различных типов артефактов (исходный код и модели данных — от-
личные варианты), но и обзавестись хотя бы поверхностными знаниями о различ-
ных методах. Другими словами, заполните свой багаж знаний до предела. Другой
Методики итеративного и инкрементного моделирования 73
антипаттерн — «сеансы моделирования одного артефакта». Наиболее распростра-
ненным примером работы над одним типом модели являются сеансы моделирова-
ния элементов Use Case. Для меня важен сеанс моделирования требований, а вот
сеанс моделирования элементов Use Case просто не имеет смысла в условиях гиб-
кого моделирования.
Рис. 5.4. Сущностный прототип UI, демонстрирующий требования к экрану/странице
. Кому-то первое время будет сложно создавать несколько моделей одновремен-
но, особенно тем людям, которые предпочитают выполнять одну задачу в единицу
времени, и тем, кто является сторонником использования антипаттерна «разра-
ботчик одного артефакта». Если ваша организация не знакома с гибким модели-
рованием, то будьте готовы оказать помощь таким сотрудникам. Я обнаружил, что
первым шагом к преодолению этих проблем является работа с несколькими моде-
лями одновременно, следуя методике «Моделируйте в группе», также описанной
74 Глава 5 « Базовые методики
в данной главе. Для этого необходимо сотрудничество между людьми, успешно
освоившими данную методику, и теми, кто испытывает проблемы с ее примене-
нием. Я обычно предлагаю своему партнеру известный ему артефакт в сочетании
с другим, также известным ему артефактом, который он считает незначительным.
Я бы выбрал такие сочетания: элемент Use Case и диаграмма последовательно-
сти UML, диаграммачслассов UML и модель физического представления данных.
Цель такого упражнения — на практике убедить партнера, что этот подход дей-
ствительно эффективно работает.
И оърнакыь
Р а^яыцаьк ^.ала^ы Мяя а^ьвяно /7оголят Роке,? яою^яаяЧ'Ля а^чяа.н Маяороя ^аьа^а Зала^
Заьаа.
Дака ра^кащщая «ьй я к а Дака ^оаяа1юа ааоааяна Ойщая а^яяа а^ое-акяа Де-лая^ующие, налога а^мяны Р0/K.t.p ^.аюа^а а^мя^н Зом^акныа Kotap Заласами* Koiaft
Рис. 5.5. Две карточки CRC для SWA Online
Переходите от одного артефакта к другому
Возможно, вы работаете над элементом Use Case, карточкой CRC, диаграммой
последовательности или даже исходным кодом, и вдруг заходите в тупик. Это по-
казатель того, что вам на некоторое время следует заняться другим артефактом.
У каждого артефакта есть слабые и сильные стороны; каждый артефакт хорош для
определенного типа работы. Если вы начинаете испытывать трудности при рабо-
те с артефактом (например, вы работаете с элементом Use Case и обнаруживаете,
что не в состоянии описать бизнес-логику), это значит, что пора переключиться
на другой артефакт. При этом вы немедленно «сниметесь с мели», потому что над
Методики итеративного и инкрементного моделирования 75
другим артефактом работа пойдет быстрее. Более того, за счет изменения точки
зрения вы вдруг можете обнаружить, что успешно работаете над тем, что еще не-
давно вызывало у вас затруднения. То есть кроме того, что вы вновь обретете спо-
собность двигаться дальше, вы еще сделаете важную часть работы, а это и есть ос-
новная концепция гибкого моделирования.
Наибольшая сложность данной методики — выбрать подходящий объект, на
который вы переключаетесь, когда зашли в тупик. Тут вам поможет опыт, но если
его не хватает, то на этот случай в приложении А имеется список подходящих ва-
риантов. Например, если вы работаете над основным элементом Use Case, то вы
можете переключиться на сущностный прототип UI, модель CRC, бизнес-правило,
системный элемент Use Case или вариант изменений.
Моделируйте постепенно
Принцип «Изменения должны быть небольшими» показывает, что инкрементный
подход к разработке является основой AM. Как вы читали в главе 1, это действи-
тельно основной аспект гибкой разработки ПО вообще (Альянс гибких методоло-
гий, 2001b). Главная идея в том, что вы делите весь объем работы на небольшие
части, которые выполняются постепенно, в идеале с интервалом в несколько не-
дель или месяцев. Тем самым вы добиваетесь большей гибкости за счет ускорения
передачи ПО в распоряжение пользователя, а также имеете конкретную и быст-
рую обратную связь с пользователем во время всей работы над проектом. Если вы
применяете инкрементный подход к разработке, то будете применять его и к мо-
делированию.
При инкрементном подходе к разработке вы понемногу моделируете, понемно^
гу пишете код, понемногу проводите испытания, затем предоставляете заказчику
небольшую часть работы. Больше не нужно следовать схеме «Сначала все спро-
ектируем» и тратить недели, а то и месяцы на создание моделей и документации.
Теперь большинство сеансов моделирования (обычно импровизированные сове-
щания для обсуждения одного-двух вопросов) длится 10-20 минут. Разработчики
гибких моделей выполняют моделирование небольшими порциями, позволяющи-
ми оперативно вернуться к работающему ПО, как того требует принцип «Главная
цель — программное обеспечение». Более продолжительные сеансы моделиро-
вания, иногда длящиеся несколько дней (обычно в начале проекта), могут иметь
место, но они являются скорее исключением, чем правилом. Чем дальше вы про-
двигаетесь, не получая конкретной обратной связи, тем больше шансов обнару-
жить, что вы моделируете не то, что от вас требуется, то есть напрасно тратите
силы. Далее, если вы подолгу сосредоточиваетесь на вашей модели (моделях), вы
рискуете нарушить, мето дики «Изображайте модели просто» и «Создавайте про-
стое содержание», также описанные в данной главе.
Самое сложное в этой методике — прекратить моделирование, как только вы
достигли определенной цели. Возможно, вам захочется моделировать то, с чем
придется работать завтра, на следующей неделе или через месяц. Вы подсознатель-
но хотите предусмотреть все наилучшим образом, но остановитесь! Наберитесь
76 Глава 5 • Базовые методики
смелости и решайте сегодняшние проблемы сегодня; скажите себе, что вы в состо-
янии разобраться с завтрашними проблемами завтра (Бек, 2000).
Методики эффективной работы в группе
Гибкое моделирование определяет четыре методики, способствующие эффектив-
ной работе в группе и налаживанию общения как внутри группы, так и с заинте-
ресованными лицами:
1. Моделируйте в группе.
2. Активное участие заинтересованных лиц.
3. Совместное владение.
4. Демонстрируйте модели открыто.
Моделируйте в группе
Разработка ПО во многом подобна плаванию — и то и другое опасно делать в оди-
ночку. Моделируя с определенной целью, вы часто ловите себя на том, что дела-
ете это для того, чтобы в чем-то разобраться или донести свои идеи до окружаю-
щих или чтобы создать общее представление о проекте. Этим лучше заниматься
в группе, поскольку вам понадобится вклад нескольких эффективно сотруднича-
ющих людей. Вы не раз убедитесь, что над созданием базового набора моделей,
имеющих критическое значение для проекта, должна работать вся группа разра-
ботчиков. Например, при разработке метафоры или архитектуры системы тре-
буется, чтобы моделирование выполняла вся группа. Так находится согласован-
ное простейшее решение, удовлетворяющее всю группу. В большинстве случаев
для этого следует обсудить проблему с несколькими людьми. Никто не запреща-
ет вам нарисовать простую схему, которую вы можете обдумать самостоятельно,
но после этого вам следует с кем-нибудь поделиться своими идеями, чтобы по-
нять, в верном ли направлении вы двигаетесь. Одна голова — хорошо, а две лучше.
Применение данной методики наладит общение между людьми, занятыми в про-
екте, поможет выработать общую терминологию, увеличит шансы успешного вы-
полнения работы и предоставит членам группы возможность обмениваться опы-
том между собой.
Применение данной методики может оказаться сложным на первых порах
в организациях, которые придерживаются политики «разделяй и властвуй», ког-
да объем работ делится на отдельные части, выполняемые разными людьми, или
если в организации процветает жесткая конкуренция, что не способствует сотруд-
ничеству. Чтобы устранить эту проблему, вам придется донести до окружающих
выгоды совместной работы; возможен следующий подход: «Новая методика под-
разумевает новые методы работы, так что давайте попробуем и посмотрим, что из
этого выйдет». Вам также понадобится рабочая зона (см. главу И), которая помо-
жет совместной работе в группе. Иногда достаточно белой доски, расположенной
Методики'эффективной работы в группе 77
на стене чьей-нибудь загородки или в специально отведенном месте для работы
группы.
Активное участие заинтересованных лиц
Заинтересованным лицом может быть любое лицо, являющееся прямым пользо-
вателем, косвенным пользователем, руководителем пользователей, старшим руко-
водителем, оператором, сотрудником группы поддержки пользователей, испыта-
телем, разработчиком, работающим над другой системой, которая является частью
разрабатываемой системы или взаимодействует с ней, или работником техниче-
ского обслуживания, которого так или иначе коснулась разработка и/или развер-
тывание проекта. Поскольку речь идет о гибком моделировании, я намеренно ис-
ключил разработчиков, работающих над проектом, из списка заинтересованных
лиц. Хотя разработчики тоже заинтересованы в проекте, термин «заинтересован-
ное лицо» будет обозначать всех таковых лиц, кроме разработчиков, работающих
над проектом. То есть говоря о разработчиках и заинтересованных лицах, я имею^
в виду разные группы людей. В качестве альтернативы могу предложить такой ва- ’
риант: «разработчики, заинтересованные в проекте» и «не-разработчики, заинте-
ресованные в проекте». Нравится? Вот и я так считаю.
Методика гибкого моделирования «Активное участие заинтересованных лиц»
близко соприкасается с методикой «Моделируйте в группе». Более того, это рас-
ширенная методика экстремального программирования (ХР), которая называется
«Локальный заказчик» (Бек, 2000). Данная методика заключается в присутствии
при разработке лиц (обычно это пользователи или их представители), которые
имеют полномочия и способности для предоставления информации по разраба-
тываемой системе, а также могут принимать уместные и своевременные решения
относительно требований и их приоритета. Такой минимальный уровень сотруд-
ничества необходим для успешной разработки ПО, хотя этого явно недостаточно,
если речь идет об организации, где сотрудники занимаются не созданием работа-
ющей системы, а интригами. Для успеха проекта часто требуется более активное
вовлечение заинтересованных лиц. Старшее руководство должно поддерживать
проект как открыто, так и в частном порядке; операторы и обслуживающий пер-
сонал должны активно сотрудничать с вашей группой, чтобы подготовить про-
изводственную среду к принятию вашей системы; другие группы разработчиков
должны сотрудничать с вами для интеграции усилий; сотрудники сопровож-
дения должны разобраться в технологиях и методах, используемых в вашей сис-
теме. Данная методика основывается на принципах «Быстрая обратная связь» и
«Открытые и доброжелательные контакты».
Само собой, чтобы добиться успеха, все заинтересованные в проекте лица
должны активно сотрудничать с вашей группой. Вот несколько выводов, сделан-
ных с помощью данной методики:
• Пользователи должны быть готовы поделиться с группой своими знания-
ми бизнеса и принимать уместные и своевременные решения относительно
цели проекта и приоритетов требований.
78 Глава 5 • Базовые методики
• Чтобы старшее руководство всячески содействовало осуществлению ваше-
го проекта, оно сначала должно понять преимущества и дополнительную
ценность технологии и методов, используемых вашей группой, понять при-
чину, по которой ваша группа их использует, и понять результаты их ис-
пользования. При наличии этих знаний действия старшего руководства на
внутренней политической арене вашей организации наверняка станут бо-
лее эффективными и своевременными. Старшее руководство не получит
этих так необходимых знаний, читая еженедельный отчет по проекту или
посещая ежемесячное совещание по управлению проектом. Для этого ру-
ководитель должен потратить время на изучений того, чем он руководит,
и принимать активное участие в разработке вашей системы.
• Операторы и обслуживающий персонал должны приложить все возможные
усилия для того, чтобы понять вашу систему и используемые в ней техноло-
гии. Обслуживающему персоналу придется изучить все тонкости системы;
он должен работать с вашей системой в процессе разработки, а ваша группа
должна будет обучать персонал. Далее, операторы должны в совершенстве
овладеть установкой и управлением вашей системой. Можно включить од-
ного или более инженеров по эксплуатации в состав группы разработчиков
или использовать проектные ресурсы на необходимую подготовку операто-
ров. В любом случае группа эксплуатации и группа обслуживания должны
активно сотрудничать с группой разработчиков.
• Другие группы, занятые в проекте, должны сотрудничать с вами в том слу-
чае, если ваша система должна интегрироваться с другими системами. На-
пример, ваша система должна обращаться к действующей базе данных, вза-
имодействовать с оперативной системой, работать с файлами данных, со-
зданными внешней системой, или обеспечивать извлечение данных XML
для других систем. Без активного участия других разработчиков интегра-
ция часто оказывается сложной, если возможной вообще. Представьте, на-
сколько сложным будет обращение к действующей базе данных, если вла-
, дельцы БД отказываются предоставить соответствующую информацию.
Помните, что общение — это улица с двусторонним движением; вы также
должны делиться информацией о вашей системе с другими группами.
• Сотрудники сопровождения должны работать с вашей группой, чтобы озна-
комиться с вашей системой. Если вы намереваетесь частично или полно-
стью поручить сопровождение вашей системы другим сотрудникам, то сто-
ит пригласить программистов, имеющих опыт по сопровождению и модер-
низации существующих систем, чтобы разгрузить вашу группу. В этом слу-
чае ваша группа должна сотрудничать с этими программистами, чтобы они
могли принять у вас систему. Даже если кто-то из числа ваших постоянных
сотрудников продолжает работать над этой задачей, вы должны постарать-
ся, передать знания новым членам группы. Хорошо, если при освоении сис-
темы ваши опытные сотрудники будут руководить новичками или просто
будут работать с ними в паре. '
Методики эффективной работы в группе 79
Совместное владение
Каждый может работать над любой моделью, а в идеальной ситуации и над лю-
бым артефактом в проекте, если возникнет такая необходимость. Например, если
я нарисую на белой доске диаграмму потока данных (DFD), то такой подход имеет
несколько преимуществ. Во-первых, чем больше людей участвует в разработке ар-
тефакта, тем больше шансов определить его потенциальное несоответствие требо-
ваниям, согласно принципу «Быстрая обратная связь». Во-вторых, это предостав-
ляет людям большие возможности накопления опыта при разработке различных
типов моделей, пополняя их багаж знаний и тем самым повышая их эффектив-
ность как разработчиков гибких моделей. Это согласуется с принципом «Учитесь
друг у друга», потому что члены группы могут наблюдать за работой других и за
счет этого повышать свой уровень. В-третьих, это подавляет искушение сказать
что-нибудь типа «Твоя модель никуда не годится», потому что если кто-нибудь
замечает проблему, то должен решить ее, а не жаловаться. В-четвертых, это сни-
жает риск присвоения определенных артефактов. Никто не может сказать: «Эта
модель классов — мое детище, а значит, с ней все в порядке», потому что никакой
отдельный артефакт не принадлежит кому бы то ни было в отдельности. В-пятых,
это способствует тому, что члены группы лучше понимают систему и налаживают
общение в группе. Также это снижает необходимость написания пространной до-
кументации и необходимость полагаться на отдельного сотрудника или подгруп-
пу. В руководстве проектом есть следующее понятие — «число кирпичей». С его
помощью оценивается минимальное количество сотрудников, при отсутствии ко-
торых (например, им упадет кирпич на голову) проект придет в упадок. Число
кирпичей, равное единице, является серьезной проблемой; если число кирпичей
превышает или равняется количеству людей в вашей группе, то это идеальная си-
туация. Совместное владение увеличивает число кирпичей для вашей группы.
Данная методика может с трудом приниматься в организациях, где личность
ставят выше группы и/или назначают членам группы узкие задачи. Сотрудники
должны признать-, что артефакты, над которыми они работают, являются груп-
повой собственностью. Они также должны научиться работать над различными
типами задач, то есть не должно получаться так, что один работает только над
пользовательским интерфейсом, а другой создает отдельную подсистему или сис-
темный интегрирующий код.
Демонстрируйте модели открыто
Вам следует открыто демонстрировать свои модели, например с помощью того,
что часто называют «стеной моделирования» или «стеной чудес» (Готтсдинер,
2001). Тем самым в вашей группе поддерживается принцип «Открытые и добро-
желательные контакты», потому что все текущие модели доступны членам груп-
пы, а также заинтересованным лицам, от которых вы ничего не скрываете. Ваша
стена моделирования находится там, где вы выставляете свои модели на всеобщее
обозрение; стена моделирования должна быть доступна вашей группе разработ-
чиков и остальным заинтересованным лицам. Ваше моделирование может быть
физическим (например, специально для этого предназначенная белая доска, на
80 Глава 5 • Базовые методики
которой вы рисуете диаграмму архитектуры, или просто место, где вы приклеива-
ете скотчем распечатку модели физического представления данных) или вирту-
альным (например, страничка во внутренней сети, которая обновляется с помо-
щью сканированного изображения).
Следующим преимуществом данной методики является то, что с ее помощью
вы показываете заинтересованным лицам выполненную вами работу — вот она,
у них перед глазами. Это особенно удобно, когда вы разрабатываете простые мо-
дели впервые и боитесь, что вы не так продуктивны (в отношении количества),
как ранее; демонстрация нескольких простых моделей в доступном для всех месте
имеет огромное значение для оценки вашей работы.
Данную методику сложно применять в организациях, где невозможно найти
свободное место на стене; или если группа работает в сравнительно людной зоне,
где ходят клиенты или даже конкуренты, а вы не хотите раскрывать рабочий про-
цесс; или там, где на отделку стен были потрачены значительные средства (напри-
мер, юридическая фирма со стенами, обшитыми дубовыми панелями, которые вы
не хотите испортить). Если препятствием является одна из этих причин, возмож-
но, вы захотите перевести свою группу в другое помещение. Далее, препятствием
может явиться нежелание делиться информацией с посторонними людьми. В этом
случае я советую вам набраться смелости и все-таки принять эту методику.
Упрощающие методики
AM выделяет три методики, которые позволяют упростить процесс модели-
рования:
1. Создавайте простое содержание.
2. Изображайте модели просто.
3. Используйте простейшие инструментальные средства.
Создавайте простое содержание
Содержание ваших моделей (моделей требований, анализа, архитектуры или про-
ектных моделей) должно быть максимально простым, но при этом все-таки соот-
ветствовать требованиям заказчика. Смысл в том, что не стоит вносить дополни-
тельные аспекты в вашу модель без особой надобности. Например, изображенная
на рис. 5.6 диаграмма классов UML (Рамбо, Джекобсон и Буч, 1999) не отражает
свойств и операций классов, которые предположительно должны определить те,
кто будет заниматься программированием этих классов (надеюсь, ими окажутся
люди, нарисовавшие эту диаграмму), когда до этого дойдет дело. Это соответству-
ет методике экстремального программирования «Простой дизайн» (Бек, 2000).
Эта методика также применима к таким не-моделируемым артефактам, как ис-
ходный код, план проекта или пользовательская документация.
Упрощающие методики 81
Рис. 5.6. Диаграмма классов UML
Как узнать, проста ли ваша модель по содержанию? Для определения просто-
ты модели я применяю следующие показатели, основанные на советах Кента Бека
(2000) по простейшему проектированию:
• Модель показывает все, что вы хотите показать. Другими словами, она отве-
чает своей цели.
• Модель не должна содержать дублирующей информации.
• Модель должна состоять из минимального количества элементов.
При освоении данной методики камнем преткновения может стать ваша склон-
ность чрезмерно усложнять модели, но ее возможно преодолеть, если вы признаете
за собой этот недостаток и будете сдерживать себя и других сотрудников вашей
организации, старающихся добиться успеха с помощью сложных моделей и до-
кументации. Часто вы будете испытывать на себе давление организаций (обычно
тех, которые используют предопределенные процессы и не знакомы с гибким под-
ходом), требующих от вас соответствия существующим стандартам оформления
документации и моделирования. (В этом случае вам придется рассказать коллегам
о своем подходе и объяснить причины, которые вами движут. Можно дать им по-
/читать эту книгу, а еще лучше, если вы предложите им приобрести собственный
экземпляр!
Изображайте модели просто
Когда вы рассматриваете возможные типы диаграмм, которые вы можете приме-
нить (диаграммы UML, диаграммы пользовательского интерфейса, модели дан-
ных и т. д.), вы быстро поймете, что чаще всего требуется всего лишь подмноже-
ство из доступных типов диаграмм. Например, простая модель (модель классов,
отображающая основные обязанности классов и отношения между ними), пока-
зывающая основные характеристики, которые вы пытаетесь понять, оказывается
зачастую достаточной. Вы, конечно, можете написать вспомогательный код, все
82 Глава 5 • Базовые методики
операции «получатели» и «установщики», в соответствии с кодовыми стандарта-
ми, но будет ли от этого польза? Для гибкого разработчика — очень маленькая.
Хотя эта методика дополняет методику «Создавайте простое содержание»,
идеи обеих методик являются ортогональными. Методика «Создавайте про-
стое содержание» фокусируется на содержании модели,, в то время как методи-
ка «Изображайте модель просто» рассматривает способы представления моделей.
Ниже перечислены советы по созданию простых диаграмм (Амблер, 2002):
• Избегайте пересекающихся линий.
• Избегайте кривых линий.
• Избегайте диагональных линий.
• Избегайте рамок разного размера.
• Избегайте большого количества рамок (не больше 7±2).
• Избегайте ненужных деталей.
Используйте простейшие инструментальные средства
Большинство моделей может быть нарисовано на белой доске, бумаге или даже
салфетке. Чтобы сохранить эти диаграммы, можно сфотографировать их циф-
ровой камерой или просто перенести на бумагу. Вы ознакомились с нескольки-
ми диаграммами, созданными при помощи простейших средств. Рисунок 5.4 был
создан при помощи планшета, стикеров (бумаги для записей на липкой осно-
ве) и маркеров; рис. 5.1 был нарисован на белой доске, а карточки CRC (Класс-
Обязанность-Сотрудничество) на рис. 5.5 — при помощи обычных карточек и
ручки. Использование простейших средств допустимо, потому что большинство
диаграмм нужны лишь для временного использования. Истинное значение диа-
граммы в том, что вы можете обдумать проблему в процессе ее создания, но как
только проблема решена, диаграмма утрачивает ценность. Поэтому белая доска
и маркер — лучшие средства моделирования. Используйте графические утили-
ты для создания диаграмм, предназначенных для показа важным представителям
заинтересованных лиц, а средства (утилиты) моделирования используйте тогда
и только тогда, когда они стоят затраченных на них усилий (например, при ге-
нерации кода). Создавая простые модели, вы моделируете лишь для того, чтобы
разобраться с той или иной проблемой; поэтому модели часто имеют временное
значение и, скорее всего, не будут нужны после ее решения, следовательно, нет не-
обходимости применять сложные средства.
В главе 10 эта методика рассматривается подробно. Хотя я ясно указал на это
в главе 1, я сделаю это еще раз: AM не имеет ничего против CASE-средств. Если
наиболее эффективным использованием ваших ресурсов является приобрете-
ние CASE-средства, то не теряйте времени и извлеките из этого средства все
возможности'. На рынке представлено множество различных CASE-средств, но
внимания заслуживают лишь немногие. Если простых средств достаточно — ис-
пользуйте их.
Методики подтверждения правильности работы 83
Эту методику будет сложно применять в организациях, где привыкли созда-
вать модели при помощи сложных средств. Многие разработчики не считают мо-
делированием то, что создается без использования дорогостоящих CASE-средств,
и им трудно согласиться с тем, что стопка учетных карточек может быть не менее
-эффективной. Лучший выход из ситуации — вовлечь их в использование простей-
ших средств, обучая их таким методам, как моделирование CRC и основных про-
тотипов пользовательских интерфейсов (UI).
Методики подтверждения правильности работы
AM выделяет две методики, относящиеся к тестированию и подтверждению пра-
вильности вашей работы:
1. Учитывайте тестируемость.
2. Подтверждение модели кодом.
Учитывайте тестируемость
Когда вы моделируете, постоянно задавайте себе вопрос: «Как мы будем это тес-
тировать?» Если вы не можете тестировать программу, которую создаете, не сто-
ит ее и создавать. Современные процессы разработки ПО включают тестирова-
ние и подтверждение качества на всех-этапах выполнения проекта, а кое-где даже
практикуют создание тестов до написания программы, например в методике ХР
«Сначала тест, потом программа» (Бек, 2000). Гибкие разработчики проводят тес-
тирование на раннем этапе и делают это часто, чтобы убедиться в качестве выпол-
няемой работы. Самое сложное в применении данной методики — научиться по-
стоянно думать о том, как вы собираетесь тестировать свою работу.
Подтверждайте модель кодом
Модель — это абстрактное понятие, которое должно точно отражать аспекты того,
что вы создаете. Вам следует написать соответствующий код, чтобы определить,
будет ли она работать. Вы разработали схему странички HTML для приема ин-
формации об адресации счета? Закодируйте ее и покажите пользовательский ин-
терфейс вашим пользователям для получения обратной связи. Вы разработали
диаграмму последовательности UML, на которой представлена логика примене-
ния сложного бизнес-правила? Напишите код тестирования, программный код,
а затем проведите тесты, чтобы убедиться в том, что все сделано правильно. Не
забывайте о том, что при использовании итеративного и инкрементного подходов,
ставших нормой в большинстве проектов по разработке ПО, моделирование —
одна из многих задач, которые вы будете выполнять. Занимайтесь моделирова-
нием, выполняйте кодирование и проводите тестирование (наряду с остальны-
ми операциями). Хотя целью AM является моделирование, не забывайте о других
аспектах разработки.
84 Глава 5 • Базовые методики
Есть ряд помех на пути к применению этого метода..
• Лучше всего он работает, когда люди, занимающиеся моделированием, так-
же пишут программный код. Это предполагает, что гибкие разработчики
должны обладать рядом умений и навыков. В главе 12 я пишу о том, что гиб-
кие разработчики должны быть специалистами широкого профиля. Помни-
те, что разработка ПО больше, чем моделирование.
• Многие разработчики придерживаются принципа «Сначала все смоделиру-
ем», поэтому на моделирование уходит больше времени, чем нужно, а коди-
рование отходит на второй план.
• Многие разработчики привыкли работать следующим образом: создание
модели, рецензирование и доработка, а затем — кодирование. В гибком мо-
делировании вы моделируете и кодируете небольшими порциями. В таком
случае необходимость рецензирования отходит на второй план, потому что
вы подтверждаете свои модели кодированием, являясь их потребителем, на
которого непосредственно повлияют любые проблемы моделей, и это сти-
мулирует выполнение качественной работы с самого начала.
Дополнительные
методики
Методика — это не знание, а путь к знанию.
Рон Джеффрис
Гибкое моделирование включает в себя дополнительные методики, которые ос-
новываются на базовых методиках, описанных в главе 5, Возможно, ваша группа
решила принять эти методики. Так же как и базовые, дополнительные методики
делятся на категории, описанные в главе 7. Вот эти категории и составляющие их
методики.
L Продуктивность:
• применяйте стандарты моделирования;
• не увлекайтесь паттернами;
• используйте имеющиеся ресурсы.
2. Документация:
• избавляйтесь от временных моделей;
• формализуйте модели соглашения;
• совершенствуйте только в случае необходимости.
3. Мотивация:
• моделируйте, чтобы общаться;
• моделируйте, чтобы понять.
Методики, повышающие продуктивность
Гибкое моделирование определяет три дополнительные методики, повышающие
продуктивность моделирования.
1. Применяйте стандарты моделирования.
86 Глава 6 • Дополнительные методики
/
2. Не увлекайтесь паттернами.
3. Используйте имеющиеся ресурсы.
Применяйте стандарты моделирования
Данная методика является версией методики ХР «Стандарты кодирования»
(Бек, 2001), применяемой к моделированию. Основная ее идея состоит в том, что
в ходе работы над проектом по созданию ПО разработчики должны придержи-
ваться общеупотребительных стандартов моделирования. Если вы придержи-
ваетесь общих соглашений по программированию, то чистый код, соответствую-
щий выбранной вами норме кодирования, легче понять и развить, чем код, не
соответствующий норме. То же самое можно сказать и об общих соглашениях
по моделированию. Наиболее употребительным стандартом является язык UML
(Object Management Group, 2001), определяющий нотацию и семантику обычных
объектно-ориентированных моделей.
СОВЕТ: UML — ЭТО ЕЩЕ НЕ ВСЕ ------------------------------------------
Унифицированный язык моделирования UML (Object Management Group, 2001а) является
хорошей основой для стандартной нотации моделирования, но этого явно недостаточно.
Как вы могли убедиться, приложение А содержит множество артефактов, созданных не
в UML. На момент написания этой книги в UML не имеется никаких моделей для дизайна
пользовательского интерфейса и моделей данных/устойчивости. Вы когда-нибудь создавали
систему без пользовательского интерфейса или хранения данных? Не обращайте внимания
на маркетинговые ухищрения продавцов, пытающихся всучить вам инструментальные CASE-
средства, или доморощенных гуру (похоже, я и сам попадаю под эту категорию), навязывающих
вам свои книги, обучающие курсы и консультационные услуги. Не верьте тому, кто заявляет,
что для реальной разработки достаточно UML. Я сомневаюсь, что те, кто делают подобные
заявления, когда-либо действительно обдумывали этот вопрос, который детально рассмотрен
в главе 15.
Рис. 6.1. Описание нотации диаграммы устойчивости
Ваши стандарты должны включать описание нотации для любых моделей, со-
зданных не на основе UML; часто бывает достаточно простой схемы, нарисован-
ной от руки. Например, описание нотации для диаграмм устойчивости (Якобсон
и др., 1992; Розенберг и Скотт, 1999) на рис. 6.1 дает разработчику модели ин-
формацию по общепринятой нотации для создания диаграммы устойчивости,
Методики, повышающие продуктивность 87
показанной на рис. ^6.2. Рисунок 6.1 также дает основную информацию для
быстрого освоения применяемой нотации. Возможно, вы захотите использовать
такой стиль моделирования, который поможет вам создавать логичные и акку-
ратные диаграммы. В чем разница между стилем и стандартом? Для исходно-
го кода стандартом является наименование атрибутов в формате attributeName,
тогда как стилем является отступ в три пробела для кода внутри управляющей
структуры (условного оператора, цикла и т. д.). Для моделей стандартом являет-
ся использование прямоугольника для моделирования класса в диаграмме клас-
сов, а стилем на диаграмме будет расположение подклассов под их суперклассом
(суперклассами).
Рис. 6.2. Пример практического использования диаграммы устойчивости
Главное препятствие на пути к использованию этой методики — отсутствие
стандартов и руководящих принципов в вашей организации. Я предпочитаю начи-’
нать с описания нотации (см. рис. 6.1), потому что без него не обойтись. Затем по
88 Глава 6 • Дополнительные методики
мере надобности я ввожу руководящие принципы моделирования с последующим
их развитием. Я также советую вам поискать существующие стандарты и нормы
стиля в сети, например на www.uml-style.org, и взять на вооружение то, что можно.
СОВЕТ: ПОНЯТНОСТЬ ВАЖНЕЕ, ЧЕМ СОБЛЮДЕНИЕ СТАНДАРТОВ —--------------------------
Желание соответствовать стандарту или стилю не должно мешать практическим задачам
моделирования — изучению проблемы или общению с другими людьми. Я помню конфликты,
возникавшие из-за того, что для обозначения ассоциаций между элементами Use Case я рисовал
стрелки не так, как принято для официальной нотации в UML. Согласен, было бы неплохо
выучить пятьсот с лишним страниц спецификаций для UML (Object Management Group, 2001а),
но, к сожалению, у меня нет на это времени. Успокойтесь, вы и без этого можете успешно
работать.
Не увлекайтесь паттернами
Хороший разработчик моделей изучает и применяет общие архитектурные, проект-
ные и аналитические паттерны в своих моделях. Однако Мартин Фаулер (2001b)
и Джошуа Кериевски (2001) утверждают, что разработчики должны применять
паттерны умеренно и с осторожностью. Это находит отражение в ценности AM
«Простота». Другими словами, если вы сомневаетесь в пригодности паттерна, то
моделируйте на уровне минимальной функциональности, необходимой на дан-
ный момент, но с условием, что при необходимости вы можете легко все реор-
ганизовать/переделать. Когда становится ясно, что наиболее простым подходом
является применение готового паттерна, реорганизуйте работу. В общем, не надо
усложнять модель.
Например, у вас есть хорошая возможность применить в своем проекте паттерн
«Стратегия» GoF (Гамма, Хельм, Джонсон и Влиссидес, 1995), но на данный мо-
мент у вас имеются только два алгоритма, которые вы можете реализовать. Проще
всего будет заключить каждую стратегию в собственный класс и создать опера-
цию, которая будет выбирать между ними и посылать входные данные. Эта час-
тичная реализация паттерна «Стратегия» GoF оставляет вам возможность произ-
вести рефакторинг, если понадобится ввести новые алгоритмы, и в то же время не
требует написания всего вспомогательного кода, необходимого для «Стратегии»,
что значительно облегчает применение паттерна.
Чтобы использовать эту методику, вам придется усвоить две вещи. Во-первых,
многие разработчики моделей, долгие годы имевшие дело с паттернами, применя-
ют их не задумываясь, так что им придется научиться сдерживать себя. Во-вторых,
в вашем распоряжении имеются сотни стоящих паттернов, так что тут есть чему
поучиться.
Используйте имеющиеся ресурсы
Существует множество информации, которая может быть использована повторно
для разработки гибких моделей. Допустим, некие паттерны анализа или дизайна
подходят для частичного применения в вашей системе. Или, возможно, вы може-
те воспользоваться существующей моделью' требований, моделью рабочего про-
Методики, повышающие продуктивность 89
цесса, моделью физического представления данных или даже моделью размеще-
ния ваших систем среди пользователей. Понятно, что эти модели устарели или не
применяются во многих организациях, но если поискать, то можно найти вполне
достойные экземпляры. Помните принцип «Повышайте отдачу от ресурсов, полу-
ченных от заинтересованных лиц» и не изобретайте велосипед — просто садитесь
и поезжайте.
Самое сложное — избавиться от мысли, что высококачественных объектов, ко-
торые можно повторно использовать в вашем проекте, очень мало. На самом деле
существует множество ресурсов, которые могут быть повторно использованы,
включая коды, модели, компоненты, оболочки, паттерны, шаблоны документации,
и крупномасштабные компоненты проблемной области (Амблер, 1999). Ими час-
то пренебрегают по причине синдрома «изобретено не здесь» (ИНЗ), но я знаю,
что при работе над проектом разработчики гибких моделей с радостью использу-
ют все пригодные ресурсы, имеющиеся в наличии.
Методики гибкого подхода к документации
Гибкое моделирование определяет три дополнительные методики, относящиеся
к созданию постоянных моделей и/или документации.
1. Избавляйтесь от временных моделей.
2. Формализуйте модели соглашения.
3. Совершенствуйте только в случае необходимости.
Избавляйтесь от временных моделей
Большинство создаваемых вами моделей являются временными/рабочими моде-
лями — схемами, низкоуровневыми прототипами, карточками, вариантами архи-
тектуры/дизайна, которые уже сыграли свою роль, но больше не нужны. Такие
модели быстро утрачивают синхронизацию с кодом и другими моделями, что ес-
тественно. В этом случае вам надо решить, будете ли вы синхронизировать моде-
ли, если это принесет пользу проекту, или просто избавитесь от них, потому что
затраты на усовершенствование моделей не окупятся.
Эта методика перекликается с методикой «Совершенствуйте только в случае
необходимости» (см. соответствующий раздел этой главы). Если вы обнаружили,
что давно не совершенствовали некую модель, это наверняка значит, что она со-
здавалась как временная, просто тогда вы этого не осознавали.
ВНИМАНИЕ: ХРАНЕНИЕ ВРЕМЕННЫХ МОДЕЛЕЙ ДО ДОБРА НЕ ДОВЕДЕТ ---------
Если модель является временной, избавьтесь от нее сразу после того, как закончили с ней
работать. Это принесет вам определенную пользу. Во-первых, ваша рабочая зона освободится
от лишнего хлама. Во-вторых, меньше риска, что кто-либо примет решение, основанное на
устаревшей (скорее всего) информации, содержащейся в этой модели. В-третьих, вы избавитесь
от искушения тратить время на ее модернизацию.
Применению данной методики часто мешает нерешительность. Многие разра-
1 ботчики боятся уничтожать модель, думая, что им может понадобиться вернуться
90 Глава 6 • Дополнительные методики
в некую исходную точку, чтобы определить ход своих мыслей в тот момент. Они
собирают модели в папку, хранят стопкой на столе, делают цифровые снимки
и помещают в директорию. Самое интересное, что к ним почти не возвращают-
ся, потому что либо их невозможно отыскать, либо просто не возникает ситуации,
где старые модели были бы полезны. Если сохранение ваших временных моде-
лей не требует усилий и дает вам чувство защищенности, тогда, конечно, храните
их; однако я настоятельно рекомендую вам подумать, приносит ли это реальную
пользу. Я уверен, что вы придете к выводу, что хранение временных моделей себя
не оправдывает, и вы могли бы с тем же успехом избавиться от них при .первой
возможности.
Формализуйте модели соглашения
Модели соглашения требуются в том случае, когда внешняя группа контролирует
информационные ресурсы, необходимые вашей системе, например базу данных,,
наследуемые приложения или информационную службу. Модель соглашения
формализуется по обоюдному согласию сторон и готовности внести необходи-
мые изменения в дальнейшем, если потребуется. Примеры модели соглашения
включают подробную документацию интерфейса прикладного программирова-
ния (API), описание структуры файла, шаблон DTD в XML, или модель физи-
ческого представления данных, описывающую общую базу данных. Как и юри-
дический контракт, модель соглашения часто требует значительных ресурсов
для разработки и поддержки соглашения, чтобы обеспечить его точность и де-
тальность. Вашей задачей является сокращение количества моделей соглашения
для системы, чтобы следовать принципу ХР «Путешествуйте налегке». Имейте
в виду, что для создания модели соглашения вам обычно нужны электронные
инструментальные средства, так как вам надо поддерживать модель в течение
какого-то времени.
Интернет является лучшим примером формализованных моделей согла-
шения. Интернет состоит из четко определенных протоколов, например FTP
и HTTP, а также таких файловых форматов, как XML и HTML. Данные про-
токолы являются файловыми форматами, которые определены соответствую-
щими организациями. Каждое определение является действующей моделью
соглашения между продавцами инструментальных средств. НТТР-протокол
определяет, как ПО веб-браузера взаимодействует с ПО веб-сервера — про-
цесс, стоящий миллиарды долларов и основанный на формализованных моде-
лях соглашения.
Самое сложное в этой методике -- человеческий фактор. Людей из различ-
ных групп трудно заставить работать совместно над созданием модели (моделей).
Лишняя документация также может стать проблемой, хотя с ней вы можете спра-
виться, следуя совету, данному в главе 14.
Совершенствуйте только в случае необходимости
Такие артефакты, как модель или документ, следует совершенствовать только то-
гда, когда вы абсолютно уверены, что это необходимо, то есть если совершенство-
Методики, повышающие продуктивность 91
вать модель менее проблематично, чем оставить все как есть. Следуя этому со-
вету, вы обнаружите, что вам нужно совершенствовать гораздо меньше моделей,
чем раньше, потому что на самом деле модель может быть несовершенной и в то
: же время эффективной. Слишком много времени и денег расходуется на попыт-
ки синхронизировать артефакты — например, модели между собой или модель с
исходным кодом, а ведь эти деньги и время могли быть потрачены на разработку
нового программного обеспечения. Программное обеспечение развивается слиш-
. ком быстро, что делает синхронизацию артефактов почти невозможной, если уж
' на то пошло. Помните принцип «Повышайте отдачу от ресурсов, полученных от
заинтересованных лиц» и то, что работающее ПО лучше, чем всеобъемлющая до-
кументация (Альянс гибких методологий, 2,001а). 4
Рис. 6.3. UML-диаграмма классов
Например, сравните UML-диаграмму классов (Рамбо, Якобсон и Буч, 1999) на
рис. 6.3 с моделью данных на рис. 6.4 (Райнгрубер и Грегори, 1994). Нельзя ска-
зать, что они идеально совместимы; диаграмма классов показывает, что покупатель
имеет адрес, в то время как модель данных показывает, что покупатель имеет один
или два адреса. Модель данных также показывает, что между заказами и адресами
имеются два типа отношений; заказы имеют адрес доставки товара и потенциаль-
но иной адрес доставки счета, однако на диаграмме классов нет никакого упоми-
нания о подобном типе отношений. Стоит ли совершенствовать диаграммы таким
образом, чтобы они были совместимы друг с другом? Диаграмма классов довольно
проста и, скорее всего, уже превратилась в другой артефакт (исходный код); к тому
же она нарисована от руки, и это значит, что ее уже выбросили за ненадобностью.
Если модель превратилась в исходный код, то, скорее всего, программисты уже по-
няли, что диаграмма классов не была совершенной по той простой причине, что
она несовместима ни с требованиями пользовательского интерфейса, отраженны-
ми в сущностном прототипе UI на рис. 6.5 (Константайн и Локвуд, 1999), ни с мо-
делью данных, которые синхронизированы между собой. Вероятно, разработчики
нарисовали диаграмму классов на скорую руку, изучая потенциальное применение
стратегии бизнес-классов для поддержания размещения заказа. Вряд ли они соби-
92 Глава 6 • Дополнительные методики
рались совершенствовать диаграмму или хранить ее после написания кода, так что
они просто сделали ее достаточно точной для своих насущных нуждлг не сочли
нужным совершенствовать ее после создания исходного кода и схемы базы данных.
Таким образом, в совершенствовании данной диаграммы классов нет крайней не-
обходимости, так что я не рекомендую тратить на это время.
Рис. 6.4. Начальная физическая модель данных для SWA Online
Рисунок 6.5 показывает сущностный прототип UI, который определяет требо-
вания к содержанию экрана (страницы). Однако если разработчики не ознакоми-
лись с исходным кодом и схемой базы данных, то, наверное, они будут работать над
функциональными возможностями выполнения заказа; затем они, скорее всего, бу-
дут совершенствовать диаграмму классов. Получается, что совместимость моделей
и документации являются залогом того, что две группы разработчиков будут иметь
.^одинаковую точку зрения. Так? Нет! Если вы хотите, чтобы разные группы лю-
дей имели одинаковую точку зрения, они должны общаться между собой и прийти
к такой точке зрения совместно. Согласен, документация — один из способов об-
щения, но, как вы увидите в главе 8, это один из наименее эффективных способов.
Совершенствуйте только в случае необходимости 93
Вместо того чтобы синхронизировать артефакты, лучше дать двум группам разра-
ботчиков возможность встретиться и поговорить; тем самым вы не только быстрее
придете к пониманию, но и наверняка потратите меньше ресурсов. Как сказано в
главе 1, один из принципов гибкого моделирования состоит в том, что при разра-
ботке ПО наиболее эффективным способом передачи информации является лич-
ное общение (Альянс гибких методологий, 2001а).
t Рис. 6.5. Сущностный прототип пользовательского интерфейса,
изображающего требования к содержанию экрана/страницы
Если вы впервые применяете эту методику, самое сложное — смириться с тем,
что артефакты могут терять синхронизацию. Подождите, пока это не начнет при-
чинять существенные неудобства. Многим организациям, особенно тем, где мно-.
94 Глава 6 • Дополнительные методики
го внимания уделяется пересмотру материала, или тем, кто следует сложным схе-
мам предопределенных процессов, будет сложно принять эту методику, так как
она идет вразрез с их политикой подгонки артефактов до одного уровня. Данная
методика согласуется с принципом «Путешествуйте налегке» — чем меньше пос-
тоянных моделей и документации вы имеете, тем меньше придется совершенство-
вать, если в том возникнет необходимость.
Методики, ориентированные на мотивацию
Гибкое моделирование определяет две методики, изучающие мотивацию модели-
рования:
1. Моделируйте, чтобы понять.
2. Моделируйте, чтобы общаться.
Моделируйте, чтобы понять
Основная цель моделирования — изучить проблему, определить и проанализиро-
вать требования к системе или сравнить и сопоставить потенциальные варианты
схемы, чтобы прийти к простейшему решению, которое удовлетворит требовани-
ям. Согласно этой методике, в большинстве сл:учаев вы будете создавать неболь-
шие и простые диаграммы, фокусирующиеся на каком-нибудь одном аспекте
вашего программного обеспечения (например, жизненном цикле класса или пос-
ледовательности экранов) и которые вы будете выбрасывать сразу после того, как
закончили с ними работать. Это следует моделировать в группе, обычно на корот-
ких импровизированных сеансах моделирования.
Моделируйте, чтобы общаться
Одна из целей моделирования — общение с людьми, не входящими в вашу груп-
пу, или создание моделей соглашения (см. методику «Формализуйте модели со-
глашения»). Например, вам нужно объяснить вышестоящему руководству замы-
сел вашего проекта. Это можно сделать с помощью UML-диаграммы Use Case или
диаграммы последовательности действий. Другой вариант — описать архитектуру
системы в рамках системной документации, которую вы должны передать сотруд-
никам сопровождения (эта тема подробно обсуждается в главе 14). Или можно
разработать блок-схему (например, как на рис. 6.6), чтобы объяснить коллеге ло-
гику элемента Use Case.
Поскольку некоторые модели предназначены для показа лицам, не входящим
в вашу группу, иногда вам придется поработать над тем, чтобы модель выгляде-
ла «пристойно», для чего вам понадобятся электронные средства — текстовой ре-
дактор, графическая утилита или даже сложные CASE-средства. Тем не менее,
помните принцип «Модель должна решать конкретную задачу» и в первую оче-
Просто хорошие идеи 95
редь решите, зачем и для кого вы моделируете. Если вы знаете, кому будете демон-
стрировать модель и тесно общаетесь с этими людьми, то вам не составит тру-
да выбрать наиболее подходящий способ представления вашей модели (помните
принцип «Содержание важнее формы»).
Данная методика имеет положительный побочный эффект: с ее помощью раз-
работчики и заинтересованные лица вырабатывают общую терминологию. Также
она облегчает представление ожидаемого результата и дает возможность подгото-
вить поддержку вашего проекта.
Рис. 6.6. Блок-схема, поясняющая элемент Use Case «Размещение заказа»
Просто хорошие идеи
Существуют некоторые методики, официально не являющиеся частью гибко-
го моделирования, но значительно облегчающие работу над проектом. В треть-
ей части книги рассмотрены важные аспекты экстремального программирова-
ния, например «Рефакторинг» (Фаулер, 1999) и «Сначала тест, потом программа»
96 Глава 6 • Дополнительные методики
(Бек, 2000), которые могут быть использованы наряду с методиками гибкого мо-,
делирования. Вот эти дополнительные методики:
• Умейте пользоваться инструментальными средствами.
• Рефакторинг.
• Сначала тест, потом программа.
Умейте пользоваться инструментальными средствами
Средства для разработки программного обеспечения (например, для создания
диаграмм или для моделирования) весьма разнообразны. Перед тем как исполь-
зовать то или иное средство, изучите его возможности и решите, в каких случаях
вы будете его применять. Разработчик должен уметь пользоваться тем или иным
средством и знать, как его эффективно применять.
Рефакторинг
«Рефакторинг» (Фаулер, 1999) — это методика кодирования, при которой вы вно-
сите в код небольшие изменения, необходимые для удовлетворения новых требо-
ваний или сохранения простоты вашего проекта1. Главное в «Рефакторинге» то,
что он сохраняет семантику кода. Другими словами, вы вносите изменения, а код
все равно работает. Например, если вы замените имя операции или класса, то весь
код вашей системы, выполняющий данную операцию, должен будет обращаться
к новому имени. Лучше всего рассматривать рефакторинг как корректный спо-
соб улучшения качества кода и детального проекта. «Рефакторинг» делает воз-
можным применение таких методик AM, как «Создавайте простое содержание»
и «Моделируйте постепенно», и подробно обсуждается в главе 18.
Сначала тест, потом программа
«Сначала тест, потом программа» — это методика экстремального программиро-
вания. Ее суть заключается в том, что сначала вы пишете код теста, а уже по-
том код программы. Всегда. С точки зрения гибкого моделирования, первооче-
редное. преимущество какого подхода в том, что разработчики должны обдумать
код и учесть все детали заранее. Следуя этой методике, разработчики могут суще-
ственно сократить время,работы над детальным проектом кода. При этом разра-
ботчики гибких моделей быстро выясняют, будут ли их идеи работать (тестиро-
вание подтвердит или опровергнет правильность модели), тем самым обеспечив
быструю обратную связь относительно содержащихся в модели идей. Методика
«Сначала тест, потом программа» и ее применение в гибком моделировании под-
робно обсуждается в главе 18.
1 Более распространено следующее определение: рефакторинг^ — это изменение с целью улучше-
ния качества и упрощения кода. Иначе говоря, при рефакторинге функциональность кода не изменя-
ется. — Примеч. науч. ред.
Как планировать применение методик AM 97
Как планировать применение методик AM
Ага, попались! Разработчики применяют методики AM постоянно; в плане про-
екта вы не увидите таких зада}!, как «Создавайте простое содержание» или
«Моделируйте, чтобы понять». Конечно, время от времени вы можете включать
в расписание сеансы моделирования, описанные в главе 13, но это деятельность,
а не методика.
СОВЕТ: ЧИТАЙТЕ ОБ АДАПТИВНОЙ РАЗРАБОТКЕ \
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (ASD) -------------------:-----------
В книге «Адаптивная разработка ПО» (Dorset House Publishing, 2000) Джим Хайсмит
переосмысливает процесс разработки программного обеспечения. Если вы намеревались
включить методики AM в ваше расписание, то я настоятельно рекомендую вам прочесть
эту книгу. Там вы найдете массу интересных и полезных сведений о различных методиках
планирования проекта, большинство которых настолько нефункциональны, что просто диву
даешься.
От хаоса к порядку:
как объединены
методики АН
Многое из того, что мы называем управлением,
состоит в создании трудностей в работе.
Питер Друкер
Методики AM синергичны: они согласуются между собой и подтверждают друг
друга. Хок (1999) определяет их как упорядочивающие: в них гармонично соче-
таются порядок и хаос (подробнее об этом в конце главы). Для того чтобы гиб-
кое моделирование работало эффективно, необходимо понимать, как объеди-
нены его методики. На рис. 7.1 изображена схема взаимодействия методик AM,
на которой они подразделяются на семь категорий. Первые четыре категории —
«Подтверждение правильности», «Итеративное и инкрементное моделирование»,
«Работа в группе» и «Простота» — являются базовыми методиками, описанными в
главе 5, и для того чтобы утверждать, что вы занимаетесь гибким моделированием,
вы должны полностью принять их. Дополнительные методики, описанные в главе
6, в свою очередь, включают в себя документацию, мотивацию и продуктивность.
Сначала давайте рассмотрим, как основные методики соотносятся внутри каждой
категории, а затем изучим дополнительные методики внутри каждой категории
и обсудим, как эти категории подтверждают друг друга.
Базовые методики
Базовые методики AM делятся на четыре категории:
1. Работа в группе.
2. Итеративное и инкрементное моделирование.
3. Простота.
4. Подтверждение правильности.
Базовые методики 99
Рис. 7.1. Как методики AM сочетаются между собой
Методики эффективной работы в группе
Категория «Работа в группе» включает в себя четыре методики — «Активное учас-
тие заинтересованных сторон», «Моделируйте в группе», «Демонстрируйте моде-
ли открыто» и «Совместное владение». Методика «Активное участие заинтересо-
ванных лиц» подразумевает критичное отношение к вашему успеху, потому что
именно для заинтересованных лиц вы и разрабатываете программу. Вы должны
понять и выполнить требования этих людей. Другими словами, вы должны тес-
но сотрудничать с заинтересованными лицами, и это подтверждается методикой
«Моделируйте в группе». Заинтересованные лица попадают под эту категорию
«в группе». Когда в процесс моделирования вовлечено несколько людей (по край-
100 Глава 7 • От хаоса к порядку: как объединены методики AM
ней мере, один из них должен быть заинтересованным в проекте лицом, а другой —
разработчиком), вы находитесь в положении, когда можете работать синергич-
но, извлекая пользу из сильных сторон и нейтрализуя слабые стороны друг дру-
га. Гибкий разработчик, специализирующийся в моделировании бизнес-процесса
и определении бизнес-правила, может пропустить информацию, которую обяза-
тельно заметит другой разработчик, занимающийся структурным моделирова-
нием (созданием диаграмм классов в UML или моделей баз данных). Подобным
образом непосредственный пользователь вашей программы предоставит вашей
группе информацию, отличную от той, что будет исходить от вашего вышестояще-
го начальства. Суть в том, что вы хотите активно сотрудничать не только с заинте-
ресованными лицами, но и со своими коллегами в группе, таким образом, увели-
чивая разнообразие точек зрения и принимая во внимание умения других.
Методика «Совместное владение» улучшает работу в группе, потому что когда
один человек «владеет» моделью, он может стать преградой для моделирования,
в то время как при совместном владении разработчики легко могут работать над
моделью в группе. Методика «Демонстрируйте модели открыто» позволяет легко
просматривать модели, учитывая информацию, которую они содержат, тем самым
усиливая сотрудничество. Это, конечно, подразумевает, что модели находятся
в поле зрения, по крайней мере те, над которыми вы сейчас работаете. Я подробно
остановлюсь на этом в главе И.
Методики итеративного
и инкрементного моделирования
Категория итеративности и инкрементности включает в себя следующие методи-
ки: «Применяйте нужный артефакт (артефакты)», «Создавайте несколько моде-
лей параллельно», «Переходите от одного артефакта к другому» и «Моделируйте
постепенно». Каждый артефакт имеет свои сильные и слабые стороны, поэтому
одной модели недостаточно для описания таких основных аспектов вашего проек-
та, как требования или архитектура. Например, для того чтобы определить требо-
вания к системе, вам часто нужна комбинация, состоящая из элементов Use Case
и определения бизнес-правила. Маловероятно, что заинтересованные в проекте
лица сразу же предъявят все свои требования к элементам Use Case, затем пол-
ностью изложат свою стратегию бизнеса, которую вы должны рассматривать как
бизнес-правило, а затем выдадут вам исчерпывающую информацию о своих не-
функциональных потребностях, которые вы должны принять как технические тре-
бования. Вместо этого они будут высказывать свои требования по мере обдумыва-
ния и часто будут возвращаться к сказанному ранее, чтобы уточнить детали или
вообще отказаться от какого-либо требования. Ваша работа по выяснению требо-
ваний может зачастую быть очень динамичной, как и работа по анализу, архитек-
туре и проектированию. Я полагаю, что динамизм является результатом образа
мышления; похоже, что наш мозг объединяет информацию совершенно хаотич-
но. В результате кажется, что идеи возникают из ничего по принципу «О! Идея!».
Гибкие разработчики признают, что люди думают динамично, особенно сотрудни-
чая в группе, и действуют соответственно. Они создают несколько моделей парал-
Базовые методики 101
лелъно, чтобы собрать разнообразную информацию об интересующем их предмете.
Эта методика подтверждается другими методиками «Применяйте нужный арте-
факт (артефакты)» и «Переходите от одного артефакта к другому». Вы можете за-
ниматься включением информации о требованиях в элемент Use Case, когда заин-
тересованные лица начнут говорить об их потребности в редактировании данных
на экране, а для этого лучше подходит сущностный прототип пользовательского
интерфейса (UI) или традиционный прототип UI. Переход от одного артефакта к
другому (одним из которых может запросто являться исходный код программы)
возможен благодаря методике «Моделируйте постепенно». Обычно вы немного
работаете с одним артефактом, затем с другим и т. д.
Методики, которые позволяют упрощать
Категория «Простота» включает в себя такие базовые методики, как «Создавайте
простое содержание», «Изображайте модели просто» и «Используйте простей-
шие инструментальные средства». Две первые методики фокусируются на про-
стоте модели и часто идут рука об руку в процессе моделирования. Фокусируясь
на простоте изображения, разработчики часто открывают для себя, как можно со-
здавать простые модели независимо от того, что они моделируют.
Однажды я разрабатывал несколько уровней устойчивости (Амблер, 200Id) —
программного обеспечения, схожего с контейнерами устойчивости Enterprise
JavaBeans (EJB), которые принимают на постоянное хранение объекты предмет-
ной области, что подразумевает сложную работу по проектированию и созданию
архитектуры. Мы пытались придумать способ создания простой диаграммы, ко-
торая помогла бы разработчикам приложений понять, как работать с уровнем ус-
тойчивости. В процессе работы мы произвели рефакторинг, который упростил
проектирование. Простота разработки подчеркивается методикой «Используйте
простейшие инструментальные средства». Чем проще средство, тем легче с ним
работать. Это увеличивает доступ к вашим моделям, тем самым увеличивая шан-
сы других людей (в том числе заинтересованных в проекте лиц) работать над
ними. Используя простые средства, вы изображаете модели проще. Более того, ис-
пользуя самые простые средства (карточки, стикеры и белую доску), вы ощущае-
те их эффективность, подсознательно убеждаясь в том, что простейшее решение
дает очень хороший результат. Такой подход значительно облегчит проектирова-
ние системы.
Методики подтверждения правильности работы
Категория подтверждения правильности состоит из двух базовые методик:
; «Учитывайте тестируемость» и «Подтверждение модели кодом». Моя философия,
которая не раз приносила мне пользу, заключается в следующем: «Не знаешь, как
протестировать — не разрабатывай» и «Я могу протестировать все, что разрабаты-
ваю». Эта философия заставляет меня не только учитывать тестируемость, когда
: я моделирую системы, но и добиваться обратной связи. Обычно я обобщаю тести-
‘ руемость всех артефактов, когда создаю и подтверждаю правильность всех типов
артефактов, но это выходит за рамки гибкого моделирования. Учитывая тестиру-
кжд
Как категории соотносятся друг с другом 103
ность». Методика «Используйте имеющиеся ресурсы» является своего рода
позицией: «Я хочу применить хороший опыт других с наибольшей пользой для
себя». Такое отношение способствует применению паттернов, которые являют-
ся одной из самых продуктивных форм многократного использования, доступных
разработчикам, так как вы используете проверенные решения других програм-
мистов (Амблер, 1999). Это отношение также порождает готовность следовать
стандартам и нормам моделирования, а они, в свою очередь, способствуют сла-
женности в работе. Вы создаете свои нормы (иногда это действительно необхо-
димо из-за какого-то необычного фактора в вашей рабочей среде), но если вы по-
ищете в Интернете, то найдете нормы моделирования на таких сайтах, как www.
modelingstyle.info и www.codingstyle.info.
Как категории соотносятся друг с другом
Рассмотрим методики категории «Работа в группе». Методика «Активное участие
заинтересованных лиц» опирается на категорию «Простота», потому что именно
простота открывает дорогу к сотрудничеству. Методики итеративного и инкре-
ментного моделирования также способствуют сотрудничеству, особенно методи-
ка «Создавайте несколько моделей параллельно», так как она открывает большие
возможности для участия заинтересованных лиц. Методики «Совместное владе-
ние» и «Моделируйте в группе» опираются на методики мотивации (потребность
разобраться в проблеме или поделиться ею часто мотивирует людей к совместной
работе) и простоты (она открывает дорогу к сотрудничеству).
Методика «Демонстрируйте модели открыто» усиливается методиками про-
дуктивности: следование стандартам и разумное применение паттернов увели-
чивают последовательность и понятность, а использование имеющихся ресурсов,
таких как обычные архитектурные модели, обеспечивает знакомую основу, с кото-
рой можно начинать моделирование. Методика «Совместное владение» опирает-
ся на итеративные и инкрементные методики. Методики «Создавайте несколько
моделей параллельно» и «Переходите от одного артефакта к другому» позволяют
нескольким людям работать вместе над любыми моделями, которые требуются
в данный момент.
Методики категории «Простота» основываются на методиках некоторых дру-
гих категорий. Методика «Изображайте модели просто» подтверждается мето-
диками «Применяйте стандарты моделирования» и «Не увлекайтесь паттерна?
ми», потому что обе эти методики берут за основу моделирование на простом
языке (выбранные вами стандарты и понятные паттерны). Методики категории
«Простота» подтверждаются методиками категории «Документация»: когда вы
совершенствуете только в случае необходимости, вы, вероятнее всего, изображае-
те модели просто и используете простое содержание, так как вы не перегружаете
свои модели ненужной информацией.
Теперь рассмотрим методики итеративного и инкрементного моделирования.
Ясно, что эти методики поддерживаются методиками категории «Работа в группе».
Когда несколько человек работают в группе, растет вероятность того, что кто-то
104 Глава 7 • От хаоса к порядку: как объединены методики AM
подскажет, какой именно артефакт стоит применить в вашей ситуации, что помо-
жет вам перейти к нужной итерации. Методики подтверждения правильности
модели также побуждают к применению инкрементного подхода, особенно когда
вы подтверждаете модель кодом, а помня о тестируемости, вы начнете работать
над несколькими моделями одновременно и переходить от одной к другой, потому
что для тестирования требуется разнообразие. Методики категории «Документа-
ция» также предполагают инкрементный подход, особенно «Совершенствуйте
только в случае необходимости», хотя методика «Формализуйте модели согла-
шения» часто ему противоречит, потому что вы хотите создать основу интерфейса
как можно скорее. Методики «Переходите от одного артефакта к другому» и
«Избавляйтесь от временных моделей» дополняют друг друга: вы создаете модель,
преследуя определенную цель, а затем избавляетесь от нее и переходите к другой.
Методики категории «Простота» тоже важны. Использование простейших инстру-
ментальных средств позволяет легко переходить от одного артефакта к другому.
Вам требуется меньше времени для работы с простейшими средствами, а фокуси-
руясь на простом содержании и простом изображении, вы быстрее поймете, что
к чему, при этом не забывая о назначении модели. Наконец, методики «Мотивации»
приведут вас к работе над несколькими моделями одновременно, потому что обыч-
но вам требуется сообщить несколько точек зрения или понять сложности систе-
мы, и вам придется переходить от одного подходящего артефакта к другому, чтобы
достичь цели.
Методики подтверждения правильности модели основываются на методиках
категории «Простота»: когда вы создаете простое содержание и изображаете мо-
дели просто, вам легче учитывать тестируемость модели. Итеративный и инкре-
ментный подходы также поддерживают методики подтверждения правильности
модели. Когда вы переходите от одного артефакта к другому (выполняете итера-
' цию), вероятнее всего, вы перейдете к исходному коду и тем самым докажете, что
ваша модель работает.
Методики категории продуктивности подтверждаются методиками категории
простоты. Гораздо легче не увлечься паттернами, работая с простыми моделями;
применять стандарты моделирования, изображая модели просто, и использовать
имеющиеся ресурсы (такие как модели корпоративных требований или модели об-
щей архитектуры), если модели просты и понятны.
Методики документации основываются на методиках категорий простоты и
' итеративного и инкрементного подхода. Чем проще ваша документация, тем
легче с ней работать. Если ваша документация проста, вы можете совершен-
ствовать только в случае необходимости именно потому, что сделать это будет
нетрудно. Сложная документация представляет угрозу для вашего проекта, по-
тому что, возможно, вы не сможете ее усовершенствовать при необходимости.
Методики «Совершенствуйте только в случае необходимости» и «Избавляйтесь
от временных моделей» работают только в том случае, когда вы придерживае-
тесь методик «Переходите от одного артефакта к другому» и «Моделируйте по-
степенно».
Хаос и порядок: упорядочивание 105
Хаос и порядок: упорядочивание
Вот мы и добрались до конца главы 7. Процесс гибкого моделирования (AM) пол-
ностью описан, но никаких конкретных указаний, которым вы должны следовать,
так и не поступило. Вы не встретили советов типа: «Создайте диаграмму А, затем
напишите документацию и заполните форму Б. Вашим следующим шагом будет
создание моделей В, Г и Д. Убедитесь в том, что они последовательны и доступ-
ны для анализа. Затем используйте эти модели для создания диаграммы Е, кото-
рая нужна программистам для выполнения их работы». Это предопределенный
процесс, который больше похож на рецепт из поваренной книги, а не на гибкое
моделирование. Я подчеркнул в главе 1, что гибкое моделирование не является
предопределенным процессом. Вместо этого я определил AM следующим обра-
зом: упорядочивающая, основанная на практике методология для эффективного
моделирования и документирования программных систем. Методология AM —
это набор методик, основанных на принципах и ценностях, которые применяют-
ся программистами в обычной каждодневной работе. Непонятно, что такое «упо-
рядочивающая» и «основанная на практике»? Давайте подробно рассмотрим эти
две идеи, потому что они явно отличаются от большинства других привычных ме-
тодологий.
Ди Хок (1999), разработчик кредитной системы VISA, дает следующее опреде-
ление термина «упорядочивающий»:
1) свойство саморегулирующихся организмов или систем, в которых гармо-
нично сцчетаются хаос и порядок;
I '
2) сочетающий в себе равную долю хаоса и порядка;
3) свойство основного организационного принципа эволюции и природы.
В книге «Упорядочивание. Рождение эпохи» Хок дает советы по созданию
упорядочивающих организаций. По его мнению, создание упорядочивающих ор-
ганизаций начинается с постановки цели, затем принципов, поиска людей и идей,
а потом определения структуры и методов. Я видоизменил подход Хока, ведь я
занимаюсь методологией, а не организацией, и начал с определения задач, опи-
санных в главе 1, и ценностей (глава 2). Они послужили основой для принципов,
описанных в главах 3 и 4, из которых сложились методики (главы 5 и 6). Хотя
гибкое моделирование не рассматривает понятия организационных принципов и
структуры, мы выясним, кто может стать разработчиками гибких моделей и даже
гибкими разработчиками, когда будем рассматривать группы гибкого моделиро-
вания (глава 12).
Почему идея упорядочивания важна? Потому что она дает концептуальную
основу для такой практической инфраструктуры, как AM. На первый взгляд, AM
кажется хаотичным и не способным произвести что-либо, имеющее практическую
ценность. По правде говоря, если бы вам пришлось применять AM наобум, скорее
всего, так бы и получилось. Но вы ведь не станете этого делать, правда? Принципы
AM дают представление о том, когда и как эффективно применять методики, а ин-
106 Глава 7 • От хаоса к порядку: как объединены методики AM
формация, которую вы получили в этой главе, дает представление о том, как ме-
тодики объединены в синергетическое целое. Да, вы должны применять каждую
из методик к месту и должным образом (в двух предыдущих главах я предоста-
вил вам для этого достаточно информации). Со временем, когда вы накопите опыт
по гибкому моделированию, вы получите большее представление о его методиках,
открывая для себя тонкости, которые поначалу не видны..
1 Такая практическая методология, как AM, может показаться временами ха-
отичной,. особенно людям, с нею незнакомым или не очень занятым в проек-
те. Но «хаотичный» — не совсем верное слово. Гибкое моделирование дает зна-
чительные результаты, когда вы следуете ему точно. AM основывается на хаосе
в хорошем смысле этого слова. Этот хаос не создается, а управляется людьми, ко-
торые работают вместе, руководствуясь общими принципами и ценностями, и спо-
собствует повышению эффективности их работы. Так AM поддерживает порядок
внутри проекта. Хаос + порядок = упорядочивание.
Забегая вперед
Во второй части я остановлюсь на проблемах, связанных с успешным примене-
нием AM в вашей организации. Я начну с общения, обуславливающего успех
в разработке ПО, и расскажу о создании эффективной среды для AM. Я также
рассмотрю проблемы использования простейших средств, и эффективного доку-
ментирования. Мною также будут рассмотрены другие важные для AM факторы:
создание рабочей зоны AM, формирование группы AM и проведение сеансов мо-
делйрования. Я также рассмотрю язык UML, чтобы развеять некоторые пагубные
заблуждения, существующие в индустрии информационных технологий, и, на-
конец, моделирование с точки зрения процесса гибкой разработки программного
обеспечения.
Часть
Гибкое
моделирование
на практике
Вторая часть посвящена практическому применению гибкого моделирования
в вашей организации и состоит из следующих глав:
► Глава 8: Общение. Поскольку моделирование зависит от общения и в то же
время его поддерживает, в данной главе рассмотрена природа общения и усло-
вия, необходимые для эффективного общения.
► Глава 9: Учимся культуре гибкого моделирования. В данной главе рассмат-
риваются культурные и организационные вопросы, связанные с эффективным
применением гибкого моделирования.
► Глава 10: Используем простейшие средства. Гибкое моделирование предла-
гает вам использовать простейший инструментальные средства. Однако в не-
которых случаях «простейшее средство» не значит «простое средство». В дан-
ной главе обсуждаются средства моделирования, находящиеся в вашем распо-
ряжении.
► Глава 11>: Рабочее место гибкого разработчика. Обстановка на рабочем месте
в большой степени влияет на эффективность работы, и в этой главе рассказы-
вается, как оборудовать рабочую зону гибкого моделирования.
► Глава 12: Группы гибкого моделирования. Данная глава рассматривает во-
просы, связанные с коллективом, занимающимся гибким моделированием.
, ► Глава 13: Сеансы гибкого моделирования. Когда вы создаете гибкие модели,
вам нужно проводить сеансы моделирования, и в данной главе рассказывается,
как это делать наиболее' эффективно.
Глава 14: Гибкая документация. Документация является важной частью раз-
работки программного обеспечения, и в этой главе изложен гибкий подход
к созданию документации.
Глава 15: По ту сторону UML. Данная глава изучает некоторые заблужде-
ния и разногласия по поводу UML и предлагает реалистичный и в то же время
практичный взгляд на этот важный рабочий стандарт.
Общение
Это не то, о чем вы подумали.
Общение — одна из основных ценностей гибкого моделирования. Хотя, если быть
точным', залогом успеха гибкого моделирования является именно эффективное
общение. Что такое общение? С точки зрения AM, общение является актом обме-
на информацией между людьми. Почему эта тема стоит отдельного обсуждения?
Потому что разработка, использование и поддержка ПО нуждаются в эффектив-
ном общении между разработчиком и пользователем, разработчиком и операто-
ром, разработчиком и руководством, разработчиком и... короче, вы поняли.
В данной главе подробно рассмотрены проблемы общения; особенное внима-
ние уделено гибкому подходу к оформлению документации. Для многих людей
моделирование и документация неотделимы друг от друга — весьма сомнительное
убеждение, которое я намерен опровергнуть, что и будет сделано в этой главе, ко-
торая состоит из следующих разделов:
• Как мы общаемся?
• Факторы, влияющие на общение.
• Общение и гибкое моделирование.
• Эффективное общение.
Как мы общаемся?
В книге «Гибкая разработка программного обеспечения» (Алистер Кокберн, 2002)
описаны различные способы общения, которые могут быть использованы при сов-
местной работе. На рис. 8.1 с небольшими изменениями приведена схема из этой
книги, где эффективность способов общения сравнивается с мощностью средства
коммуникации. Обратите внимание на эти две кривые: левая показывает комму-
никативные возможности документации (здесь бумажными документами также
считаются электронные средства информации, например страница HTML, кото-
110 Глава 8 • Общение
рую можно перенести на бумагу), а правая относится к моделированию. Конечно,
относительная ценность этих способов зависит от ситуации — например, сеанс ви-
деосвязи (видеоконференция) с Сергеем Александровичем может оказаться эф-
фективнее личного разговора, а вот с Лидией Николаевной — совсем наоборот.
Кокберн утверждает, что наиболее эффективным является личное общение,
особенно если оно происходит с использованием средства моделирования — бе-
лая доска, планшет, бумага или карточки. Если изменить ситуацию, например
убрать средство моделирования или заменить личное общение на другой способ
общения, то его эффективность значительно снижается. При понижении мощ-
ности средства коммуникации теряется эффект близости, а также сознательный
и подсознательный ход мысли, которые обеспечивает такая близость. Вы также
теряете преимущества многоуровневой модальности — способность общаться не-
вербальными средствами, такими как жесты и выражение лица. Вместе с этим те-
ряется ритмическая и интонационная выразительность речи, а ведь общение — это
не только слова, но и то, как они произносятся. Кокберн отмечает, что говорящий
может усиливать значение слов, замедляя или ускоряя темп речи, выдерживая па-
узы или меняя интонацию. И наконец, важной является возможность задать во-
прос в режиме реального времени (как раз то, что отличает обмен документаци-
ей от моделирования), поскольку заданный вопрос показывает, насколько хорошо
информация понята слушателем.
Бумажные / Возможности
документу ' документации
--------------------------------------------------------►
Холодно Мощность коммуникативного средства Горячо
Рис. 8.1. Способы общения
Факторы, влияющие на общение
Существует несколько факторов, влияющих на общение:
Близость по месту. Чем ближе контакт, тем больше возможностей для обще-
ния. С одной стороны, двое людей могут работать бок о бок, программируя в паре
Факторы, влияющие на общение 111
за одной рабочей станцией. С другой стороны, двор людей могут находиться в раз-
ных зданиях.
Близость во времени. Общение зависит от того, работаете ли вы в одно и то
же время. Ваши коллеги могут находиться на территории с другим часовым по-
ясом (североамериканские фирмы часто поручают разработку компаниям, нахо-
дящимся в Азии или Европе) или у них просто могут быть другие рабочие часы.
Однажды я работал в Сан-Франциско по контракту, связанному с разработкой.
Я проводил там четыре дня в неделю, но жил по своим биологическим часам, то
есть по времени Торонто. Будучи «жаворонком», я вставал в 3 часа утра по вре-
мени Сан-Франциско; однако многие из моих тамошних коллег были «совами»
и обычно засиживались на работе до трех или четырех часов утра. Это было весь-
ма удобно, так как к концу моего рабочего дня они начинали приходить в офис,
и мы могли при необходимости посовещаться. Затем я шел в гостиницу и ложился
спать, а проснувшись, первым делом проверял электронную почту. Таким образом
я узнавал, чего они достигли за ночь, и'при необходимости немедленно отвечал на
письма. Конечно, это был не идеальный вариант, но мы справились.
Дружеские отношения. Кокберн (2002) утверждает, что дружелюбная атмо-
сфера, желание выслушать чужое мнение и способность высказываться без не-
доброжелательства является важным фактором на пути к успеху. Чем дружелюб-
нее отношения, тем легче люди обмениваются информацией и ничего не скрывают.
Дружеские отношения тесно связаны с взаимным доверием и «чувством локтя».
В то же время Кокберн отмечает, что иногда дружелюбие заходит так далеко, что
люди боятся обидеть коллегу, выражая несогласие, или не проявляют инициати-
вы, чтобы не прослыть выскочками.
Инструментальные средства. Простые средства, такие как белая доска, бума-
га для заметок на клейкой основе (стикеры), планшет и карточки удобны в ра-
боте и не требуют специальных навыков. Именно они используются при работе
в группе; никто не окажется в неловком положении из-за того, что он не умеет
пользоваться этим средством. Более сложные средства обычно мешают общению,
например CASE-средства, рассчитанные на одного пользователя и полностью по-
глощающие внимание, вследствие чего вы не можете участвовать в обсуждении
до время работы с ними. (Хотя существуют и CASE-средства, допускающие со-
трудничество, см. табл. 8.1.) Далее, при использовании средств, требующих серь-
езной подготовки, возможности сотрудничества понижаются, так как не все могут
знать, как пользоваться этими средствами.
Дискомфорт. Люди могут испытывать неудобства по поводу некоторых спо-
собов общения. Например, кто-то любит говорить по телефону, а кто-то этого тер-
петь не может. Одни предпочитают пользоваться электронной почтой, а другие
избегают этого, потому что у них неважные навыки письменной речи. Если люди
работают вместе, им надо найти удобный для всех способ общения или, по край-
ней мере, научиться терпимости.
При тесном сотрудничестве, обусловленном близостью по месту и времени,
возникает возможность того, что Кокберн называет осмотическим общением, —
косвенная передача информации, когда люди слышат чей-нибудь разговор или
просто обращают внимание на то, что происходит вокруг. Осмотическое общение
112 Глава 8 • Общение
часто приносит реальную пользу. Я уже не помню, сколько раз бывало, что я под-
сознательно улавливал полезную для себя информацию в то время, когда работал
над чем-то другим. Например, кто-нибудь закончил текущее задание, или что-то
не работает так, как нужно, или даже слух о том, что руководство подумывает о за-
крытии проекта. Осмотическое общение часто может быть и вредным, особенно
если кто-нибудь шумит возле вашего рабочего места, или если вы подхватываете
ложные слухи типа мыслей начальства о закрытии проекта.
СОВЕТ: НЕ ХВАТАЕТ МЕСТА? АРЕНДУЙТЕ ДОМ ----------------------------------
Многим организациям не хватает рабочих зон. Например, фирма быстро растет или находится
в престижном районе, где помещения дорого стоят. Я как-то работал в молодой интернет-
компании, персонал которой удваивался каждые пару месяцев. Места катастрофически не
хватало, и мой стол два месяца простоял в кухне, где мне и пришлось работать вместе с
несколькими коллегами. Еще помню компанию, находившуюся в деловом районе Лондона; там
тоже было так тесно, что иногда нужно было колесить по городу несколько часов, чтобы найти
подходящее место для проведения часового совещания, к тому же часто ненужного. Хотя обе
эти организации кое-как справлялись, но согласитесь, что это никуда не годится. А вот другой
фирме, принадлежащей моему другу, понадобилось помещение для разработки программного
обеспечения. Зная, что в офисе места не хватит, он начал поиски временного помещения и
обнаружил, что может снять дом на год, причем за цену, гораздо меньшую той, что пришлось
бы заплатить за арендованный на девять месяцев офис. В неотделанном подвале он поставил
белые доски и предусмотрел хорошее освещение, а в доме разместились столы с оргтехникой
и объединенными сетью рабочими станциями. Так что если вы будете мыслить нестандартно,
то найдете место для рабочей зоны. Успех сопутствует тем, кто его добивается.
Общение и гибкое моделирование
Для гибкого моделирования в первую очередь необходимо успешное общение.
Существуют различные способы общения, перечисленные в табл. 8.1. Выберите
тот способ, который наиболее отвечает ситуации. Иногда это будет электронная
почта, иногда личное общение, а иногда создание документа. Далее, если вы хоти-
те эффективно использовать технические средства, то придерживайтесь методики
«Используйте простейшие инструментальные средства». В табл. 8.1 описаны не-
которые средства связи, которыми вы можете воспользоваться. Если вы ищете но-
вые технологии и средства совместной работы, то вот прекрасный ресурс для этой
цели: www.collaboration-tools.com.
Таблица 8.1. Техника связи
Техника Описание Примеры
Средства для совместного моделирования CASE-средства, позволяющие нескольким разработчикам одновременно работать над одной или более моделями с корректировкой в режиме реального времени • Cittera, Canyon Blue (www.canyonblue.com) • Describe, Embarcadero ' Technologies (www.embarcadero.com)
Средства для совместного создания документа Текстовые редакторы, позволяющие нескольким людям одновременно создавать документ с корректировкой в режиме реального времени • NetPerfect, Corel Corporation (www.corel.com)
Эффективное общение 113
Техника Описание Примеры
Средства обсуждения Электронная почта, группы новостей, список рассылки, мгновенные сообщения, дискуссионные форумы, позволяющие пересылку текстовых сообщений и прочих вложений • Список рассылки Agile Modeling (www.agilemodeling.com/ feedback.htm) • IRCPIus (www.ircplus.com)
Видеосвязь Видеокамера и соответствующее ПО, установленные на вашей рабочей станции для обеспечения связи между вами и лицом, имеющим подобное оборудование • Оборудование LogiTech QuickCam (www.logitech.com)
Средства управления версиями Программное обеспечение для контроля, определения и управления версиями артефактов проекта • Microsoft SourceSafe (www.microsoft.com) • Concurrent Versions System (CVS) (www.cvshome.org)
Виртуальные средства общения Средства для общения между несколькими людьми, физически удаленными друг от друга • ERoom (www.microsoft.com) • Click to Meet (www.cuseeme.com)
Эффективное общение
Общение приносит наибольшую пользу тогда, когда люди хотят сотрудничать
и делать то, что требуется для выполнения задачи. Здесь работает принцип AM
«Открытые и доброжелательные контакты». Если вы не доверяете получаемой ин-
формации или людям, от которых она исходит, то ни о каком эффективном об-
щении не может идти речи. Залогом успеха является принцип «Каждый должен
у кого-то учиться», поскольку он является своего рода позицией, обеспечиваю-
щей успешное общение. Те, кто верят, что могут чему-нибудь научиться у собесед-
ника, более восприимчивы, чем те, кто в это не верит. Этот принцип берет начало
в ценности AM «Смирение», которая является одним из важных факторов, веду-
щих разработчиков к успеху.
Цель общения — обмен информацией, и те, кто это понимает, знает и то, что
такой обмен должен быть двусторонним. Например, недавно я был на совещании,
где наша группа разработчиков встречалась с другой группой, разрабатывающей
систему, с которой мы должны были интегрировать нашу систему. Нашей целью
было определить модель соглашения, описывающую интерфейс этой системы,
для чего в конце концов потребовалась лишь передача файлов. Большей частью
мы разговаривали и рисовали диаграммы на белой доске. Наша группа принесла
диаграмму размещения, которая показывала, как, по нашему мнению, две системы
будут работать вместе, и выдвинула предложения по совместному подходу. Обе
группы пришли на совещание с мыслью о сотрудничестве. Мы знали, что нужно
другой I ' дет поддержать такую
группу, имали необходимость
эффект! [ения к ней.
114 Глава 8 • Общение
Успех также зависит от вашего умения выбрать правильный способ общения.
В предыдущем примере мы решили собрать нужных людей в одном месте, что-
бы обсудить проблему и прийти к общему решению. Мы рисовали схемы на бе-
лых досках и даже принесли свою диаграмму размещения. Но самое главное — мы
говорили и слушали. Конечно, мы могли сделать и по-другому, например, обме-
ниваться электронными письмами или бумажными документами, но мы этого не
сделали. У нас была возможность высшей формы общения — личный разговор
у белой доски — и мы ею воспользовались. Это было быстро, эффективно и де-
монстрировало гибкий подход к работе.
И последнее. Вам необходимо иметь реальный взгляд на документацию.
Документация может быть хорошей или плохой. Пишите хорошую документацию
и не тратьте время на плохую. Документация может принимать различные фор-
мы, включая бумажные документы и видеозаписи, как вы могли видеть в табл. 8.1.
Суть в том, что документация может быть разнообразной и при этом не отнимать
у вас много времени и сил. Как вы увидите в главе 14, гибкий подход к документа-
ции заключается в том, что ее следует писать только тогда, когда это действитель-
но необходимо и принесет проекту ощутимую пользу.
Учимся
культуре гибкого
моделирования
Вы можете быть либо гибким, либо хрупким.
Для эффективной работы вашей группы культура вашей организации и особенно
вашего отдела должна способствовать применению гибкого моделирования. Если
в вашей организации не приветствуются методы AM или, более того, их не при-
емлют, тогда возможность применения AM в вашем проекте значительно умень-
шается. Что вы можете сделать для того, чтобы привить хорошее отношение к AM
в вашей организации? Советую вам:
• преодолеть неверные представления о моделировании;
• отдавать предпочтение малому;
• > успокоиться;
• четко соблюдать права и обязанности заинтересованных лиц;
• продумывать представление модели заинтересованным лицам.
Преодолевайте заблуждения о моделировании
У многих программистов, разработчиков и менеджеров сложились неправильные
представления о моделировании, которые существенно снижают эффективность
их работы. Давайте обсудим эти проблемы и проанализируем их с точки зрения
ценностей, принципов и методик AM.
Заблуждение № 1: модель = документация
Вероятнее всего, это самое ужасное заблуждение, касающееся моделирования.
Оно дает разработчикам повод не заниматься моделированием под тем предлогом,
что они не хотят тратить время на написание бесполезной документации.
Последствия этого весьма печальны — многие прекрасные разработчики ПО стано-
вятся простыми программистами-поденщиками, пишущими низкокачественные
116 Глава 9 • Учимся культуре гибкого моделирования
•неустойчивые системы. Более того, моделирование стало восприниматься как за-
нятие неинтересное. В результате многие разработчики уклоняются от изучения
навыков моделирования, которые необходимы для успешной работы. На самом
деле, понятия «модель» и «документ» ортогональны: у вас могут быть модели, ко-
торые не являются документами, и документы, которые не являются моделями.
Набросок на салфетке также является моделью, как и рисунок на белой доске, на-
бор карточек «Класс-Обязанность-Сотрудничество» (CRC) или грубый прототип
пользовательского интерфейса, созданный при помощи планшета и бумаги для
записей на липкой основе. Эти модели представляют ценность, хотя не являются
официальными документами. По опыту знаю, что моделирование во многом схо-
же с планированием: в планировании ценен не сам план, а процесс планирования,
а в моделировании — не модель, а процесс ее создания. Вы можете создать модель,
не являющуюся частью официальной документации, вашей программы, и вы изба-
витесь от нее, как только она выполнит свою задачу. Вы обнаружите, что на самом
деле не так много моделей стоит хранить. Вы можете без ущерба для себя следо-
вать методике «Избавляйтесь от временных моделей». Методики, касающиеся
гибкого подхода к документации, подробно рассмотрены в главе 14.
Заблуждение № 2: вы можете все
продумать с самого начала
Это заблуждение — пережиток прошлого. Оно развилось из подхода, широко рас-
пространенного в 70-е и середине 80-х годов. Как раз в это время сегодняшние
менеджеры учились разрабатывать ПО. Суть этого подхода заключается в том,
что часто при разработке проекта огромное количество времени с самого нача-
ла посвящается моделированию. Целью этого подхода, часто также называемого
«Сначала все спроектируем», является попытка предусмотреть все заранее. Часто
возникает желание «заморозить» требования до начала кодирования (см. заблуж-
дение № 4) и начинается «столбняк анализа» — боязнь продвигаться вперед до
тех пор, пока модели не доведены до совершенства. Проектные группы, которые
страдают от этого мифа, часто предоставляют пользователям огромное количе-
ство документации вместо того, что от них на самом деле требуется работаю-
щего ПО, соответствующего требованиям пользователей (принцип AM «Главная
цель — ПО»). Как преодолеть эту проблему? Во-первых, примите как данность
то, что вы не можете продумать все детали. Во-вторых, поймите, что в данной сре-
/ де ваши кодировщики, вероятнее всего, не станут принимать во внимание работу
по моделированию. Вполне обоснованная позиция, сторонники которой считают,
что работа по моделированию чаще всего не представляет ценности. Вероятнее
всего, ваши кодировщики подойдут к проблеме по-своему, утверждая, что модели
не отражают реальных условиий среды. В-третьих, поймите, что как бы ни была
хороша первоначальная спецификация, очень скоро она перестанет быть синхро-
низованной с вашим кодом и с собой, даже если вы будете изменять свои моде-
ли со временем. На самом же деле только ваш код по-настоящему синхронизиро-
ван с вашим/кодом. В-четвертых, признайте, что итеративный подход (немного
моделирования, немного кодирования, тестирование и, может быть, размещение
Преодолевайте заблуждения о моделировании 117
небольшой рабочей версии вашей системы) — норма разработки ПО. Это осново-
полагающий принцип современных крупномасштабных процессов, таких как кор-
поративный унифицированный процесс (EUP) (Амблер, 2001b) и гибких процес-
сов, например, экстремальное программирование (ХР) (Бек, 2000).
Заблуждение № 3: моделирование предполагает
крупномасштабный программный процесс
Это заблуждение тесно связано с заблуждением № 1 о том, что под моделью под-
разумевается документация. Из-за этого разработчики перестают моделировать
вообще, так как крупномасштабный процесс становится слишком сложным и обре-
менительным для них. Подобных выводов возникать не должно, и, я надеюсь,
данная книга показывает это. На самом же деле вы можете моделировать гибко,
создавая простые модели и используя простые средства. Ваша работа по модели-
рованию может быть легкой или тяжелой, в зависимости от того, что вы предпо-
чтете. Вы приспосабливаете процесс моделирования в соответствии с потребнос-
тями вашего окружения по принципу «Приспосабливаем по месту».
Заблуждение № 4: вы должны
«заморозить» требования
Это распоряжение часто исходит от вышестоящего начальства, которое хочет убе-
диться в том, что оно знает, что получит от группы разработчиков. Положительным
моментом является то, что, заморозив требования ,на начальном этапе жизненного
цикла, они, скорее всего, получат в точности то, что хотят. Отрицательная сторо-
на — вероятнее всего, они не получат то, что нужно на самом деле. Все может изме-
ниться. В процессе разработки понимание проблемы, видение методов ее решения,
приоритеты ваших заинтересованных лиц могут измениться по мере развития сис-
темы. Изменяющиеся требования являются главным аспектом большинства про-
граммных разработок и особенно их коммерческого применения. Примите этот
факт, руководствуясь принципом «Ожидайте изменений». Применяйте итератив-
ный и инкрементный подходы к разработке ПО, которые позволяют вам действо-
вать в соответствии с изменяющимися требованиями. Лучше следуйте методике
AM «Моделируйте постепенно», а не замораживайте требования.
Заблуждение № 5: ваш дизайн высечен в камне
Это заблуждение сродни желанию заморозить требования. В данном случае ру-
ководство хочет убедиться в том, что все разработчики шагают в ногу, следуя
«единственно верному дизайну». Сохраняя дизайн неизменным, вы не сможете
применить знания, полученные по мере продвижения проекта. В результате чего
разработчики либо разрабатывают не то, что нужно, либо — то, что нужно, но не
так, как надо, добиваясь соответствия этому «дизайну». И, наоборот, они могут
просто игнорировать «единственно верный дизайн», отрицая всякую пользу от ра-
боты по проектированию. Более того, разработчики вынуждены писать огромное
118 Глава 9 • Учимся культуре гибкого моделирования
количество документации вместо того, чтобы создавать реальное программное
обеспечение и использовать ориентированные на документацию CASE-средства
вместо средств, ориентированных на реализацию, которые принесут проекту го-
раздо больше пользы. Разработчики гибких моделей предполагают изменения
дизайна, часто основанные на обратной связи, следуя методике «Подтвердите
модель кодом», когда работа по программированию или созданию базы данных
показывает, что ваш дизайн не идеален. На самом деле никто не являет собой
совершенства, даже самые лучшие проектировщики и их работа. Неужели вы хо-
тите зафиксировать эти недостатки, не предоставляя себе возможности исправить
ошибки? К тому же, если вы не «заморозите» требования, соответств;енно вы не
сможете заморозить и ваш дизайн: изменения требований повлекут за собой из-
менения дизайна. Помните, что дизайн данной версии не закончен, пока не напи-
сан код.
Заблуждение № 6: вы должны
использовать CASE-средства
Моделирование часто рассматривается как сложная работа. Во многих отношени-
ях это так, но вы можете создавать эффективные и в то же время простые модели,
которые отражают только важную информацию, опуская несущественные детали.
На протяжении всей книги я привожу примеры моделей, созданных при помощи
простых средств, таких как карточки, бумага на липкой основе, планшеты и белые
доски. На рис. 9.1 и 9.2 показаны примеры таких моделей. Эти модели отвечают
своей цели и имеют огромную ценность для работы группы, показывая, что сле-
дуя методике «Используйте простейшие средства», можно добиться успеха. В гла-
ве 10 мы подробно рассмотрим, как эффективно использовать средства моделиро-
вания, включая низкотехнологичные средства и сложные CASE-средства.
Заблуждение № 7: моделирование —
пустая трата времени
Многие начинающие разработчики не считают это заблуждением. Часто это про-
исходит потому, что их учили только писать коды, а не процессу разработки ПО
в целом. Их опыт как молодых программистов состоит лишь в реализации кода.
Эти разработчики лишают себя возможности значительно увеличить собствен-
ную продуктивность и приобрести навыки, которые можно будет применять в
других проектах и организациях. На самом деле вы работаете продуктивнее, ри-
суя диаграмму, разрабатывая грубый прототип или используя несколько карто-
чек для того, чтобы что-то обдумать прежде, чем кодировать, следуя методике
«Моделируйте, чтобы понять». Продуктивно работающие разработчики часто мо-
делируют прежде, чем кодируют. Они сначала думают, а потом делают. Кроме
того, моделирование — прекрасный способ наладить общение между группой и за-
интересованными лицами. Вы обговариваете проблемы, достигаете взаимопони-
мания по вопросу, что нужно разработать, и налаживаете связи между всеми людь-
Преодолевайте заблуждения о моделировании 119
ми, участвующими в разработке проекта. Другими словами, вы следуете методике
«Моделируйте, чтобы общаться».
Рис. 9.1. Грубый прототип экрана для ввода данных
Заблуждение № 8: все вращается
вокруг моделирования данных
Во многих организациях применение разработки нового типа затрудняется из-за
того, что работу начинают с модели данных. Это происходит по нескольким при-
чинам. В вашей организации так работали в течение долгих лет, и всем трудно
представить, что существуют другие способы работы. Деятельность вашего отде-
ла IT целиком и полностью зависит от отдела данных. Таким образом, последний
делает все возможное, чтобы контролировать ваши проекты разработки ПО, или
ваша существующая база данных находится в таком беспорядке, что у вас нет дру-
120 Глава 9 • Учимся культуре гибкого моделирования
гого выбора. Я знаю по опыту, что при разработке большинства коммерческих
программных продуктов моделирование данных является важной, но второсте-
пенной задачей, которую лучше решать, чтобы разработать схему физической
базы данных, основанной на дизайне ПО (Амблер, 2001а). То же самое касается
работы, ориентированной на данные. Например, проекты по организации храни-
лищ данных, проводимые без должного понимания того, как эти хранилища дан-
ных будут использованы (модели данных не показывают этого), часто обречены
на провал. Принцип «Множество моделей» гласит, что на самом деле в вашем рас-
поряжении огромный выбор моделей: элементы Use Case, бизнес-правила, диа-
граммы деятельности, Диаграммы классов, компонентные диаграммы, потоковые
диаграммы пользовательского интерфейса и модели «Класс-Обязанность-Сотру
дничество» (CRC) и многие другие. Модель данных — всего лишь одна из них.
Каждая из моделей имеет свои преимущества и недостатки. Вместо того чтобы
слепо следовать предопределенному процессу моделирования, лучше придержи-
ваться методики «Применяйте нужный артефакт (артефакты)» как наиболее под-
ходящей. Если вы окажетесь в ситуации, когда кто-нибудь будет советовать вам
взять за основу вашей системы модель данных, я бы посоветовал вам проверить,
насколько хорошо эти люди понимают процесс разработки ПО. Спросите их о
том, когда следует применять модели, перечисленные выше, и когда этого делать
не стоит. Если они не смогут этого объяснить или будут просто отмахиваться от
вопросов, говоря, что «об этом должны думать программисты», значит, они имеют
недостаточные представления об основах, чтобы давать вам советы по проекту.
Рис. 9.2. Высокоуровневая архитектура бизнес-компонента,
представленная в виде рисунка на белой доске
Отдавайте предпочтение малому 121
Заблуждение № 9: все разработчики
знают, как моделировать
Серьезной проблемой, с которой мы постоянно сталкиваемся в нашей сфере рабо-
ты, является то, что большинство заинтересованных лиц, не являющихся разра-
ботчиками, включая высшее руководство и пользователей, не понимают, как раз-
рабатывается ПО. В результате они не делают различий между опытными
разработчиками и программистами-поденщиками и, конечно же, между про-
граммистами, на самом деле занимающимися экстремальным программировани-
ем, и теми, кто утверждает, что им занимается. Обычно они склонны полагать, что
все разработчики имеют необходимые навыки, чтобы разработать систему от на-
чала и до конца. Это не так. Навыки моделирования приобретаются с годами и
только в случае, если разработчик желает их приобрести. Программисты, являясь
людьми очень умными, часто считают, что могут сделать все (ведь они же про-
граммисты, в конце концов). В результате они возносятся до небес. Они самоуве-
ренно берутся за выполнение задач, не имея для этого достаточного опыта. На са-
мом же деле разработка ПО — слишком сложный и напряженный процесс, и один
отдельно взятый человек не может обладать достаточным количеством умений и
навыков, необходимых для успешной разработки и размещения даже не очень
сложной системы. Наоборот, люди должны работать вместе, чтобы дополнять
друг друга. Людям, обладающим навыками моделирования,' следует работать
вместе с людьми, у которых имеется хороший опыт по реализации. Всем разработ-
чикам следует обладать смирением, чтобы понимать, что они не могут знать всего
и им всегда есть чему поучиться у других. Специалисты по моделированию могут
узнать детали определенной технологии от программистов, а программисты могут
научиться ценным методам дизайна и архитектуры у специалистов по моделиро-
ванию. Мое личное убеждение состоит в том, что все мы (в том числе и я сам) —
новички. Таким образом, я еще раз подчеркиваю важность принципа AM «Учитесь,
друг у друга».
Отдавайте предпочтение малому
Для того чтобы избавиться от большинства заблуждений, перечисленных на пре-
дыдущих страницах, ваша организация должна понять, что необходимо поме-
нять философию разработки ПО в целом. В начале 90-х достаточно часто мож-
но было услышать высказывание «маленькая — значит гармоничная», когда речь
шла о размере организации. Сейчас в сфере программной разработки мы слышим
«маленький — значит гибкий». Например, вы должны предпочитать:
Короткие (маленькие) сеансы моделирования. Короткие сеансы моделиро-
вания позволяют вам сосредоточить свое внимание на одной части системы, по-
работать с ней и быстро получить обратную связь по результатам работы. Более
длинные сеансы моделирования обычно приводят к тому, что вы рассматриваете
больше функциональных возможностей. Более длинные сеансы моделирования
увеличивают объем функциональных возможностей, который вы намереваетесь
122 Глава 9 • Учимся культуре гибкого моделирования
рассмотреть за это время, но тем самым уменьшают вероятность получения ран-
ней обратной связи и увеличивают риск того, что вы случайно собьетесь с пути.
Мы подробно обсудим сеансы моделирования далее в этой главе.
Маленькие группы. Маленькие группы моделирования требуют меньшего
участия руководства (отчетов по состоянию дел и собраний), нежели большие.
Маленькую группу легче разместить, тем самым устраняя барьеры общения среди
участников проекта.
Маленькие модели. Маленькие модели легче создать и понять, нежели боль-
шие. Архитектуру, требования и подробный дизайн вашей системы очень часто
лучше передать при помощи нескольких маленьких диаграмм, чем при помощи
одной всеобъемлющей.
Маленький объем документации. Документация небольшого объема позволя-
ет вам путешествовать налегке. Гораздо легче хранить документ на пяти страни-
цах, нежели на пятистах. Простота — одна из пяти ценностей AM. Отдавая пред-
почтение малому, вы также отдаете предпочтение простоте.
Умерьте пыл!
Одним из важнейших моментов в принятии гибкого моделирования является по-
нимание того, что гибкие модели просто должны быть достаточно хорошими, а не
безупречными. Например, я часто замечал, что слишком много внимания уделяет-
ся вопросам типа: правильно ли используется «официальная нотация» или допус-
тимо ли создание модели определенного типа на данном этапе. Однажды я работал
над проектом, участники которого часами обсуждали, правильно ли они исполь-
зуют стереотипы «uses» и «extends» (теперь «include» и «extend») Проблема со-
стояла в том, что разные люди использовали стереотипы по-разному. Безусловно,
вы хотите следовать общепризнанным стереотипам моделирования (если это воз-
можно), как рекомендует методика AM «Применяйте стандарты моделирования»,
но иногда вам необходимо отклониться от правил. В некоторых случаях люди не-
правильно применяли стереотипы. Я решил эту проблему, проведя несколько ко-
ротких совещаний. Но в других случаях стереотипы действительно применялись
в соответствии с ситуацией. Мы пришли к заключению, что стандарты модели-
рования должны быть более гибкими, но прежде разработчики потратили нема-
ло времени на бесплодные споры, ошибочно полагая, что стандарты имеют лишь
одно толкование.
Я не раз был свидетелем горячих споров по поводу того, когда лучше всего
применять определенную модель. Классическим примером этого является твер-
дая убежденность некоторых людей в том, что модель данных должна создаваться
в течение всего жизненного цикла проекта как часть требований, анализа и рабо-
ты по проектированию. В момент определения требований модели данных могут
быть разработаны, чтобы отразить модель предметной области. Во время анализа
они могут быть созданы для концептуального моделирования, а при проектиро-
вании — для моделирования схемы физической устойчивости. Конечно, понима-
ние основных объектов предметной области как части ваших требований может
Четко соблюдайте права и обязанности 123
оказаться полезным, но нужна ли для этого модель данных? Сомневаюсь. Вы ведь
работаете над требованиями. Ваши заинтересованные лица должны принимать
активное участие, но они, вероятнее всего, не являются специалистами по созда-
нию моделей данных, поэтому модель данных — не самый лучший выбор. Гораздо
лучше в некоторых случаях для создания модели данных использовать карточки
CRC. Речь об этом идет в книге «The Object Primer 2/е» (Амблер, 2001а). Как на-
счет концептуальной модели на уровне анализа? Когда-то модели данных впол-
не подходили для выполнения этой задачи, но являются ли они сейчас наилуч-
шцм решением? Я знаю по опыту, что по крайней мере при разработке программ,
требующих объектно-ориентированного или компонентного подхода, использо-
вание диаграмм классов UML является лучшим решением. Диаграммы классов
позволяют вам отразить и данные, и аспекты поведения вашей системы, то есть
супермножество того, что вообще может быть отражено с помощью модели дан-
ных. Они лучше совмещаются с другими диаграммами UML, которые вы, вероят-
нее всего, используете. Нет никакой необходимости рабски следовать указаниям
типа: для достижения цели X следует произвести артефакт Y. Во-первых, возни-
кает вопрос: нужно ли достигать цели X? Если да, то выясните, какой артефакт яв-
ляется лучшим для достижения этой цели. Другими словами, следуйте методике
«Применяйте нужный артефакт».
В заключение скажем, что вас не станет преследовать полиция, если вы слег-
ка отойдете от правил. Итак, умерьте пыл и экспериментируйте со своими моде-
лями.
Четко соблюдайте права и обязанности
Одной из сильных сторон ХР является четкое и подробное определение ролей за-
казчиков и разработчиков в проекте. Заказчики отвечают за описание того, чего
они хотят от системы, и назначают приоритеты для возникающих в результате
требований. В свою очередь, разработчики отвечают за объективную оценку
этих требований и разработку системы, основанной на приоритетах требований.
Другими словами, заказчики отвечают за деловые проблемы, а разработчики — за
технические, и каждая группа действует в соответствии с этим распределением
обязанностей.
Я считаю, что идея о том, что заинтересованные лица и разработчики имеют
определенные роли и сферу влияния, имеет решающее значение для успеха ваше-
го проекта. Лучше всего распределить эти роли с точки зрения заинтересованных
лиц, так как именно они платят вам за разработку их программ. В требованиях по
созданию ПО (1999) Карл Уигерс обобщает права и обязанности пользователей.
Я изменил их здесь, добавив права и обязанности заинтересованных лиц в. рамках
AM. По моему мнению, эти права и обязанности помогают эффективно опреде-
лить пункты соглашения между группой разработчиков и заинтересованными ли-
цами. Вы успешно следуете методике «Формализуйте модели соглашения», ког-
да решаете обсудить следующие моменты со своими заинтересованными лицами,
124 Глава 9 • Учимся культуре гибкого моделирования
достигая соглашения, пункты которого должны соблюдаться для успешной рабо-
ты группы.
Заинтересованные лица имеют право:
• Потребовать от разработчиков изучить сферу деятельности и цели заинте-
ресованных лиц.
• Потребовать от разработчиков, чтобы те научились разговаривать с заинте-
ресованными лицами на понятном языке.
• Ожидать, что разработчики смогут определить и понять их требования.
• Получать объяснения артефактов, которые разработчики используют при
работе с заинтересованными лицами. Например, модели, которые разработ-
чики создают совместно с заинтересованными лицами (истории заказчика
или основные прототипы UI), или артефакты, которые они им предоставля-
ют (UML-диаграммы размещения).
• Ожидать от разработчиков уважительного отношения к себе.
• Быть в курсе новых идей и вариантов требований.
'• Описывать характеристики, которые облегчают использование продукта.
• Получить возможность корректировки требований для обеспечения по-
вторного использования, сокращения времени разработки и расходов на
разработку.
• Получить добросовестно составленную смету.
• Получить систему, отвечающую их требованиям по функциональности
и качеству.
• Определить, как группа разработчиков потратит их ресурсы, включая раз-
мер вложения средств на создание документации для постоянного йсполь-
зования (см. главу 14).
Обязанности заинтересованных сторон:
• Обеспечить группу разработчиков ресурсами (денежными, временными
ит. д.).
• Предоставить разработчикам информацию о сфере своей деятельности.
• Найти время для определения и разъяснения требований.
• Четкр определять требования.
• Принимать своевременные решения.
• Принять во внимание выполненную разработчиками оценку затрат и при-
годности.
• Установить приоритеты требований.
• Оценивать результаты и обеспечивать своевременную обратную связь, ка-
сающуюся важных рабочих артефактов.
• Незамедлительно сообщать об изменении требований.
Продумайте презентацию заинтересованным лицам 125
» Иметь представление о программных процессах в своей организации; следо-
вать им и активно помогать их налаживать, когда это необходимо.
СОВЕТ: ПОМЕСТИТЕ СПИСОК ПРАВ И ОБЯЗАННОСТЕЙ
Й ОБЩЕДОСТУПНОМ МЕСТЕ .--------------------------------------------
В данной ситуации уместно применить методику «Демонстрируйте модели открыто». Поместите
перечень прав и обязанностей, установленных путем переговоров, в доступном всем месте,
чтобы быть уверенными в том, что ваша группа знает свои права и обязанности.
Продумайте презентацию
заинтересованным лицам
Однажды я работал над проектом, в котором менеджер требовал предостав-
ления формальной презентации заинтересованным лицам один раз в месяц.
Заинтересованные лица просто обожали презентации. Мы не только сообщали
о положении дел в группе, но также описывали технические детали всего, над чем
работали с момента последней презентации. В один прекрасный день я работал с
несколькими представителями пользователя. Они объясняли мне детали некоего
сложного бизнес-правила и предложили встретиться на следующий день, чтобы
продолжить работу. Я отказался, сказав, что должен поработать над слайдами пре-
зентации, чтобы подготовить их к следующему понедельнику. Тогда они предло-
жили поработать вместе через день, но я снова отказался, пояснив, что до конца
недели буду работать над слайдами. Они были поражены тем, что один из веду-
щих разработчиков, занятых в проекте, будет вынужден потратить так много вре-
мени на работу со слайдами. Они еще сильнее удивились, когда узнали, что еще
несколько разработчиков были частично привлечены к этой работе для выяснения
технических деталей того, над чем они работали. Заинтересованные лица были
очень огорчены тем, что нам придется потратить столько сил на презентацию, но,
к сожалению, менеджер проекта на этом настаивал. Нет необходимости говорить,
что следующее собрание прошло не слишком хорошо для него — повестка дня соб-
рания была изменена, чтобы менеджер проекта и заинтересованные лица могли
пересмотреть приоритеты проекта и направить больше усилий на разработку ПО
и меньше — на создание документации. С тех пор в презентациях меньше времени
уделялось созданию красивых слайдов, а у разработчиков появилось больше вре-
мени для создания работающей системы.
Презентации заинтересованным лицам являются неотъемлемой частью боль-
шинства проектов по созданию ПО: вышестоящее начальство хочет знать поло-
жение дел в проекте; заинтересованным лицам, непосредственно не участвующим
в повседневной работе над проектом, необходима демонстрация данной версии
системы; другим группам разработчиков, которые работают над созданием сис-
тем, которые будут интегрированы с вашей, необходимо понять, как она работает.
Вы можете предоставить им документацию, но зачастую это не очень эффективно
(если вы путешествуете налегке, документации, которая им нужна, может не ока-
заться под рукой). В главе б мы уже говорили о том, что документация — вовсе не
126 Глава 9 • Учимся культуре гибкого моделирования
лучший подход к общению. Подводя итог, скажем, что вы должны быть готовы
устраивать презентации для заинтересованных лиц. Вы должны не только прове-
сти презентацию; вы должны к ней подготовиться и подвести итоги впоследствии.
В результате, презентации часто становятся главной причиной пустой траты вре-
мени. Вот несколько советов, как решить эту проблему при помощи гибкого под-
хода:
Сократите число презентаций. Лучшая презентация — та, которую вы не стали
проводить. Презентация должна иметь четкую цель, четко определенную аудито-
рию (должно быть ясно, зачем присутствует каждый из участников) и обоснова-
ние необходимости ее проведения. Велики шансы того, что не только вы не хотите
проводить презентацию, но и у заинтересованных лиц могут быть дела поважнее,
чем посещение еще одного собрания. Тесно сотрудничайте с ними, чтобы сокра-
тить количество презентаций.
Пытайтесь найти альтернативу. Возможно, будет вполне достаточно списать-
ся по электронной почте, обсудить все по телефону или при встрече в коридо-
ре. Это проще и зачастую эффективнее, если вам нужно пообщаться с неболь-
шой группой заинтересованных лиц. Презентации больше подходят для больших
групп, а не для маленьких.
Превратите презентацию в рабочий сеанс. Когда заинтересованные лица при-
сутствуют на презентации, привлекайте их к работе. Работайте с ними совмест-
но, чтобы определить новые требования, пересмотреть существующие требования
или назначить приоритеты работы в будущем.
Сообщайте заинтересованным сторонам о затратах. Всем нравятся красивые
слайды, но не все отдают себе отчет в том, сколько необходимо усилий на то, что-
бы создать их. Понимают ли они, что время, которое было потрачено на создание
красивых слайдов, можно было посвятить разработке ПО?
Пусть заинтересованные лица решают, проводить ли презентацию. Как
и предоставление документации, решение о проведении презентации заинтере-
сованным лицам — дело первостепенной важности, и именно заинтересованные
лица должны его принимать.
Стремитесь к простоте. В чем больше заинтересованы ваши заказчики:
в программе, которую вы для них разрабатываете, или в вашем умении работать
в Microsoft PowerPoint? Многие совершают ошибку, посвящая массу времени на
создание «красивых слайдов» для презентации. Бывало, я проводил часы, преоб-
разовывая диаграммы, нарисованные от руки, при помощи графических утилит,
чтобы использовать их для презентации. Затем однажды я выбился из графика
и был вынужден просто включить сканированный рисунок в презентацию. Всем
было все равно, как это выглядело. Конец света не настал. С тех пор я стал вклю-
чать больше рисунков, выполненных от руки, в мои презентации и тратил мень-
ше сил на преобразование диаграмм. Конец света до сих пор не настал. Когда я не-
сколько раз получал замечания по этому поводу, моим главным козырем перед
заинтересованными лицами было то, что я предпочел не тратить время на рисова-
ние красивых рисунков, а посвятил его созданию ПО. Никто никогда не жаловал-
ся. Короче говоря, применяйте принцип «Повышайте отдачу от ресурсов, полу-
ченных от заинтересованных лиц» и будьте находчивее.
Продумайте презентацию заинтересованным лицам 127
Сократите число людей, участвующих в подготовке презентации. Не от-
влекайте всю группу на создание презентации. Эта работа не требует созда-
ния особой комиссии. Пусть этим занимаются один-два человека, анализирую-
щие работу других, как это и должно происходить. Имейте в виду, что методика
«Совместное владение» позволяет паре людей создать всеобъемлющую презен-
тацию. Наверняка они знают о различных системах больше, чем могли бы узнать,
работая в любом другом не-гибком проекте, и имеют доступ к текущим версиям
артефактов проекта.
Сократите число людей, присутствующих на презентации. Совершенно не
v обязательно присутствие врех членов вашей группы на каждой презентации.
Лучше.всего определить минимальное количество человек, которым нужно ее по-
сетить. В идеале — это один человек, который проводит презентацию и сообщает о
результатах остальным членам группы.
Применение AM — это не просто принятие его ценностей, принципов и ме-
тодик. Вам нужно создать среду, в которой можно будет применять AM, среду, в
которой уже пересмотрели свою точку зрения на моделирование. Эти изменения
касаются преодоления распространенных заблуждений о моделировании, необхо-
димости научиться отдавать предпдчтение малому, а самое главное — умерить пыл.
Также важно определить и соблюдать права и обязанности заинтересованных лиц.
И наконец, в силу того что презентации могут тормозить работу группы, я умоляю
вас рационализировать этот вид деятельности. Помните, что время, потраченное
на подготовку, проведение или подведение итогов презентации, украдено у непо-
средственной разработки ПО. Добиться успеха в применении AM в вашей органи-
зации вполне возможно, но для этого вы должны к нему стремиться.
Используем
простейшие
средства
Пользуйтесь простыми средствами—карандашом,
бумагой и белой доской. Общение важнее, чем
технология.
Кент Бек и Мартин Фаулер. «Планирование
в экстремальном программировании»
Из главы 5 вы узнали, что одной из основных методик гибкого моделирования яв-
ляется методика «Используйте простейшие инструментальные средства». Гибкое
моделирование различает два типа средств моделирования: простые средства и
компьютерные средства разработки программного обеспечения (CASE-средства).
Простые средства — это обычные инструменты, используемые для моделирова-
ния систем, включая планшеты, стикеры (бумагу для заметок на липкой основе),
бумажные салфетки, просто листы бумаги, канцелярские кнопки, белые доски и
карточки. С помощью простых средств можно создавать самые разнообразные мо-
дели. CASE-средства— это пакеты программного обеспечения, с помощью кото-
рых моделируются системы. Наиболее распространенные CASE-средства вклю-
чают TogetherSoft Together Control Center (www.togethersoft.com), Canyon Blue
Cittera (www.canyonblue.com), Embarcadero ER/Studio (www.embarcadero.com),
Gentleware Poseidon (www.gentleware.com) и Rational Corporation Rational Rose
(www.rational.com). Перечисленные CASE-средства имеют свои сильные и слабые
стороны, и при соблюдении методик гибкого моделирования любое из них может
быть использовано в проекте.
Погодите минутку. Разве вы не должны использовать только простые средства
для гибкого моделирования и забыть о CASE-средствах? Не совсем так. Методика
предписывает использовать простейшие, а не простые средства — большая разница.
Конечно, следует использовать простые средства, где это возможно. Данное разли-
чие имеет смысл, если вы следуете методикам «Создавайте простое содержание» и
«Изображайте модели просто». Остаточная стоимость создаваемых вами моделей
невелика после того, как они выполнили свою задачу, которая обычно заключается
в том, чтобы изучить/понять проблему или донести свою идею до остальных.
Гибкое моделирование с помощью простых средств 129
Далее,'если вы следуете методике AM «Избавляйтесь от временных моделей»,
то нет смысла тратить время на моделирование с помощью CASE-средств. Если
простое средство (например, карточки или белая доска) позволяет вам достичь'
цели (следуя принципу «Модель должна решать конкретную задачу», вы должны
знать, с какой целью вы моделируете, а иначе незачем тратить время), то вы выбе-
рете простое средство. Хотя иногда простых средств недостаточно. Допустим, вам
нужно придать диаграмме «пристойный» вид, чтобы продемонстрировать ее заин-
тересованным лицам, или вы генерируете исходный код на основе ваших моделей.
В таком случае вам действительно нужны сложные CASE-средства. Короче гово-
ря, используйте простейшее средство, которое отвечает вашей цели. Иногда это
белая доска и маркер, а иногда — новейшие CASE-средства.
В данной главе будут рассмотрены следующие вопросы, касающиеся средств
моделирования:
• Гибкое моделирование с помощью простых средств.
• Эволюция модели.
• Гибкое моделирование с помощью CASE-средств.
• Используйте возможности представления информаций.
• Какое средство, такая и модель.
• Практическое применение простейших средств.
Гибкое моделирование с помощью
простых средств
Какие простые средства могут быть использованы для моделирования?
Приверженцы ХР (Бек, 2000) клянутся, что с помощью обычных карточек они
создают множество различных моделей, в частности, CRC-моделей, историй за-
казчика и задач. Бумага для заметок па липкой основе (стикеры) является рас-
пространенным средством для создания грубых/сущностных прототипов пользо-
вательского интерфейса на больших листах бумаги (Константайн и Локвуд, 1999).
Стикеры можно использовать и на белой доске — они заменяют схематическое
изображение логических элементов, а отношения между элементами рисуются
на доске. Я сам много раз рисовал UML-диаграммы Use Case и UML-диаграммы
классов подобным образом. Листы бумаги или карточки можно прикрепить кноп-
ками к пробковой доске и обозначить связи между ними с помощью струн — тоже
неплохой вариант для создания различных моделей. Например, отдельные листы
бумаги могут представлять таблицы базы данных, а струны могут обозначать от-
ношения между таблицами в физической модели данных. Другой пример — листы
бумаги могут представлять экраны, а струны — навигационные потоки между эк-
ранами на диаграмме потоков пользовательского интерфейса. Листы бумаги так-
же могут представлять элементы Use Case и актеров, а струны — ассоциации меж-
ду элементами Use Case и актерами на UML-диаграмме Use Case. Прочие простые
средства включают бумажные салфетки, на которых можно рисовать, белую доску
5 Зак. 926
130 Глава 10 • Используем простейшие средства
для эскизов и цифровую камеру для создания копий рисунков, которые вы хоти-
те сохранить. 1
Преимущества простых средств
Зачем использовать простые средства для моделирования? Я советую вам снача-
ла спросить себя, с какой целью вы. моделируете. Моя философия заключается
в том, что разработка должна производиться с определенной целью, иначе неза-
чем и моделировать. Если вы моделируете, чтобы понять что-нибудь, то ценность
представляет не модель, а сам процесс моделирования. Тогда вам ни к чему тра-
тить время и силы, применяя CASE-средства, чтобы модель выглядела «пристой-
но», или сопровождать модель полной документацией. Вы лучше справитесь с за-
дачей, используя простые средства, например карточки или белую доску, и быстро
закончив моделирование, вернетесь к разработке ПО.
Простые средства доступны всем. Простые средства могут использовать все,
даже заинтересованные в проекте лица, которые должны принимать активное
участие, потому что именно они отвечают за формулировку требований.
Простые средства обеспечивают ощутимую обратную связь. С простыми
средствами легко работать. Карточки можно перемещать по столу, причем вы
это делаете просто руками, и все присутствующие могут участвовать в процессе.
Работая непосредственно с простыми средствами, люди лучше понимают то, что
они моделируют.
Простые средства недороги.
Простые средства гибки в применении. На карточках, стикерах, салфетках
или листах бумаги можно писать. Их можно перемещать с одного места на дру-
гое, а когда они больше не нужны, их можно просто порвать и выбросить. Далее,
с помощью простых средств можно создавать множество различных моделей.
Приложение А предлагает по крайней мере одно простое средство для создания
любых типов артефактов, описанных там, включая все артефакты, определенные
UML.
Простые средства не пугают пользователей. Никто не боится потерять работу
из-за того, что он не сможет справиться со стопкой карточек, несколькими лист-
ками бумаги для заметок или схемой, нарисованной на белой доске. Однако мно-
гие люди боятся компьютеров. Когда люди боятся потерять работу, они не очень
охотно пользуются компьютерными средствами. Применяя простую технологию
анализа, вы способствуете сотрудничеству с пользователями.
Работая с простыми средствами, вы работаете быстро. Вам когда-нибудь
приходилось ждать, пока стопка карточек загрузится в память?
Простые средства мобильны. Вы просто суете в портфель стопку карточек
и ручку и отправляетесь по своим делам.
Простые средства можно комбинировать со сложными. Разработчики гиб-
ких моделей часто начинают с применения простых средств и создают множест-
во моделей. Если выясняется, что какую-нибудь модель стоит сохранить, или ис-
пользование CASE-средства будет более эффективным, то они переходят к работе,
с другим средством. Это подробно рассмотрено в разделе «Эволюция модели».
Гибкое моделирование с помощью простых средств 131
Простые средства способствуют итеративной и инкрементной разработке.
Разработчики, применяющие итеративный и инкрементный подходы к разра-
ботке, будут решать проблему постепенно, небольшими порциями. Простые сред-
ства как раз удобны для изучения небольших проблем или небольших частей
какой-нибудь большой проблемы. Например, с помощью карточек вы легко мо-
жете разобраться с внутренней структурой компонента, состоящего из двадца-
ти или более классов. Можно ли с помощью карточек создать всеобъемлющую
модель, представляющую сотни классов? Вполне возможно, но создание такой
модели наверняка будет весьма трудоемким, да и модель получится неуклюжая.
Рассмотреть требования к отчету очень просто при помощи планшета и стикеров.
Но можно ли при помощи тех же средств рассмотреть содержимое каждого отде-
льного экрана и каждый отчет в вашей системе? Вряд ли.
Простые средства способствуют путешествию налегке. Можно легко рас-
статься с тем, во что вы не вкладываете больших усилий.
Недостатки простых средств
У простых средств есть и слабые стороны:
Простые средства неприемлемы для многих людей. Разработчики при-
выкли создавать модели при помощи сложных САЗЕ-средст§. Им трудно при-
знать, что для моделирования может быть достаточно белой доски или карточек.
Пользователи привыкли к тому, что требования к системе представляются в фор-
ме сложных и подробных документов. Им также трудно принять описание требо-
ваний к своей системе, представленное на кусочках картона.
Простые средства имеют ограниченные возможности.
Простые средства йе подходят для создания основной документации. Хотя
набор карточек может должным образом отражать требования с точки зрения лю-
дей, которые сделали эти карточки, скорее всего, этих карточек будет недостаточ-
но для людей, не входящих в группу, или для тех, кто попытается разобраться
в системе через несколько лет. Для создания постоянной документации вам дей-
ствительно понадобятся более сложные средства, например текстовые процессо-
ры или CASE-средства. Гибкий подход к документации описан в главе 14.
Простые средства не годятся для сотрудничества «на расстоянии». Простые
средства представляют собой физические предметы. В результате, чтобы совмест-
но работать с помощью простых средств, вам нужно находиться в одно и то же вре-
мя в одном и том же месте. Согласен, электронные белые доски позволяют людям,
находящимся в разных местах, совместно работать над диаграммой, а телеконфе-
ренция обеспечивает надежную связь во время рабочей сессии. Но удаленное об-
щение все же отличается от личного. Трудности, связанные с удаленным общени-
ем, рассматриваются в главе 8.
Когда следует использовать простые средства?
Когда следует использовать простые средства? При любой возможности, то есть
почти всегда. Я придерживаюсь правила, что чем больше неясных моментов
в проблеме, которую вы моделируете, тем большая гибкость требуется от исполь-
132 Глава 10 • Используем простейшие средства
зуемых вами средств. Таким образом, следует пользоваться простыми средствами.
На белой доске можно рисовать быстрее, чем с помощью графических утилит, на-
пример Microsoft Visio или более сложных CASE-средств. Требования к содержи-
мому экрана или отчету можно рассмотреть быстрее с помощью стикеров и план-
шета, чем с помощью компьютерной макетной системы. Следует ли ограничиться
простыми средствами? Нет. Когда вы начнете лучше понимать проблему, вы смо-
жете при необходимости обратиться к более сложному средству, если его исполь-
зование себя оправдает. Данная тема обсуждается в разделе «Эволюция модели».
Короче говоря, разработчики гибких моделей начинают с обсуждения проблемы
и используют простые средства, если те помогают в обсуждении. Затем они либо
пишут исходный код вручную, либо используют CASE-средство, которое, воз-
можно, сделает это за них.
Технология в помощь простым средствам
Чтобы справиться с недостатками простых средств, вы можете призвать на по-
мощь технические средства. Обычно такие средства используются, когда вы хоти-
те сохранить результаты работы или поделиться информацией с физически уда-
ленными от вас людьми. Наиболее распространенными техническими средствами
для поддержки простых средств являются:
Цифровые камеры и сканеры. Самый простой способ сохранить информацию,
выраженную с помощью простых средств, — снять ее на цифровую камеру, или
сканировать. В данной книге есть схемы, нарисованные на белой доске или сущ-
ностные прототипы пользовательских интерфейсов, перенесенные на бумагу с по-
мощью цифровой камеры, или рисунки на листах бумаги и карточках, которые
были сканированы. Эти технические средства (особенно цифровые камеры) быс-
тро выполняют задачу и легки в применении.
Программы обработки изображения. Существует несколько средств для
работы с цифровым изображением. Я лично использую для этой цели Adobe
Illustrator (www.adobeicom) и Corel Photo Paint (www.corel.com). Я обрезаю картин-
ку так, чтобы сохранить только необходимую мне информацию, и сокращаю раз-
мер файла, чтобы упростить его хранение и передачу. Еще я использую программу
Pixid Whiteboardphoto (www.pixid.com), чтобы подчистить изображение и преоб-
разовать в формат, подходящий для программы оптического распознавания сим-
волов (OCR). Например, с помощью Whiteboardphoto я преобразовал рис. 10.1
в рис. 10.2 меньше, чем за минуту. Как вы можете убедиться, чистая версия диа-
граммы гораздо легче для восприятия.
Среды типа Wiki. Wiki (Леф и Каннингэм, 2001) — это интегрированная сре-
да, позволяющая совместную работу с данными в формате HTML. Можно сказать,
что Wiki — это веб-сайт, снабженный собственными инструментами для редак-
тирования, добавления и удаления страниц. Среды типа Wiki часто применяют
вместо дискуссионной группы с обменом электронными письмами, особенно ког-
да в дискуссии участвует вся группа. Группы разработчиков используют Wiki для
накопления общего архива (Амблер, 1998), сохраняя артефакты, относящиеся
Технология в помощь простым средствам 133
к требованиям, ключевые решения по архитектуре и дизайну и совместные доку-
менты. Применение Wiki поддерживает принцип «Открытые и доброжелатель-
ные контакты» и методику «Демонстрируйте модели открыто». Чтобы больше
узнать об этих программах, зайдите на www.wiki.org.
Текстовые процессоры, текстовые редакторы и HTML-редакторы. Эти
средства хороши для сохранения текстовой информации и имеют широкие воз-
можности редактирования. Отредактированный документ легко можно переслать
или передать, или преобразовать в HTML-страницу и выложить в сеть.
Электронные белые доски. Электронные доски отличаются друг от друга воз-
можностями. Некоторые доски просто сканируют изображение и выдают копию до-
кумента на бумаге, например серия Panaboard фирмы Panasonic (www.panasonic.com).
Более продвинутое оборудование — TeamBoard (www.teamboard.com) и Poly Vision
Webster (www.websterboards.com). Такие средства интегрируются с компьютером
или ПО" для совместной работы (например, Microsoft NetMeeting), и вы можете
обмениваться информацией с удаленными членами группы. Некоторые органи-
зации вместо того, чтобы покупать новую электронную доску, оснащают обычные
«ручные» доски оборудованием типа Mimio (www.mimio.com).
Рис. 10.1. Нарисованная на белой доске UML-диаграмма размещения для SWA Online
134 Глава 10 • Используем простейшие средства
Рис. 10.2. Та же диаграмма, «чистая» версия
Эволюция модели
Как разработчики гибких моделей комбинируют простые средства и CASE-
средства? Схема, изображенная на рис. 10.3, показывает, в какой последователь-
ности разработчики используют средства моделирования. Начинают обычно с об-
суждения текущей задачи. Если все решается на обсуждении,. тс> можно сразу писать
код. В других случаях требуется моделировать, чтобы понять. Тогда разработчи-
ки выбирают простейшее (для решения данной задачи) средство и приступают
к моделированию. В большинстве случаев будут использованы простые ёредства.
ХР-разработчики обычно пользуются карточками, хотя белые доски тоже весь-
ма популярны, и работают над задачей вместе, следуя методике «Моделируйте в
группе». Разработчики гибких моделей меняют средства в зависимости от ситу-
ации, например, начинают с карточек, а затем переходят к CASE-средству, если
проблема становится ясной. Они могут приступить к написанию кода в любой
момент, независимо от средства моделирования. Код можно писать вручную,
а можно генерировать с помощью CASE-средства, в соответствии с принципом
«Главная цель — программное обеспечение» и методиками «Моделируйте посте-
пенно» и «Подтверждайте модель кодом».
Когда разработчики гибких моделей находятся в начальной стадии изучения
проблемы, им требуются гибкие инструменты, чтобы быстро вносить изменения
в модель, над которой они работают. Глупо тратить много времени на начальную
Эволюция модели 135
стадию, так как наверняка большинство работы, проделанной в этот период, бу-
дет отбрасываться по мере понимания проблемы. Например, когда я начинаю раз-
бираться с содержимым экрана, я обычно пользуюсь стикерами. Я наклеиваю их
на все ровные поверхности, до которых могу дотянуться — на стол, белую доску,
планшет и т. д. (см. рис. 10.4). Со стикерами очень легко работать. На них можно
рисовать небольшие схемы или описания, их можно перемещать туда-сюда, и они
останутся там, где я их приклеил. В общем, отличное средство, чтобы быстро разо-
браться с компоновкой, — стикеры могут представлять экранные элементы, и их
можно легко убирать и добавлять.
Согласно схеме на рис. 10.3, вам следует либо сразу перейти к кодированию со-
держимого. экрана, либо продолжать моделирование, используя другие средства,
например белую доску или CASE-средство. Действуйте согласно исходной цели
моделирования компоновкй экрана. Если вашей целью было просто выработать
стратегию организации основных элементов управления экрана, то, скорее всего,
вы уже достигли этой цели, значит, можно писать код. Если же вы хотели выяс-
нить, как организовать содержимое экрана и идентифицировать элементы управ-
ления, которые вы намереваетесь использовать, то переходите к белой доске. На
белой доске вы можете изображать элементы управления экрана более точно, вы-
брав подходящий масштаб относительно их реальных размеров (переключатель,
однострочное поле ввода, многострочное поле ввода и т. д.), см. рис. 10.5. Обратите
внимание на то, что эта схема содержимого экрана сделана на основе рис. 10.6 —
некоторые компоненты переставлены. Мы поняли, что лучше показывать номер
и наименование заказа вместо наименования и описания; также нам нужно было
добавить возможность удаления отдельных пунктов с помощью переключателей
и показывать оплату доставки как часть общей суммы. Хотя на самом деле белая
доска -т не такой гибкий инструмент, как стикеры. Если выясняется, что нужно до-
бавить пару элементов, то на доске вам придется что-то стирать, а потом рисовать
заново. А если вы работаете со стикерами, то их можно просто поменять местами.
При работе с белой доской вы выигрываете в точности, но теряете в гибкости.
Рис. 10.3. Использование простых средств и CASE-средств
136 Глава 10 • Используем простейшие средства
ITроме-папоь
по ^оама^к,е>
Дос/па^амь по а^ре-бр
пою^памепя
ПО ^МОППапаю)
: ,Л о сказать па ом я [:
(ttмя пою^памспя '?
по ^моппапою) |>
Рис. 10.4. Сущностный прототип пользовательского интерфейса,
отражающий требования к содержанию экрана/страницы
Следует ли воспользоваться' программой обработки изображения для коррек-
тировки рис. 10.5, как мы сделали, чтобы преобразовать рис. 10.1 в рис. 10.2, или
оставить все как есть? Это зависит от ситуации. Если нужно показать рисунок
кому-нибудь, например, отправить его по электронной почте нескольким людям,
чтобы получить обратную связь, то стоит потратить пару минут и обработать изоб-
ражение с помощью соответствующего'ПО. А если эта схема только для внутрен-
него пользования, то это ни к чему. Рисунок достаточно разборчив и в таком виде,
а раз мы придерживаемся принципа AM «Содержание важнее формы», то незачем
понапрасну тратить время. То, что рисунок легко можно подчистить, еще не зна-
чит, что это следует делать.
Эволюция модели 137
Итак, наш следующий шаг: нужно решить, будем ли мы уже писать код или пе-
рейдем к новому средству. В данном случае это средство для создания прототипа
пользовательского интерфейса. На рис. 10.6 изображен готовый прототип поль-
зовательского интерфейса для размещения заказа, созданный на основе рис. 10.5.
Обратите внимание, как изменилась модель. Когда заинтересованные лица озна-
комились с прототипом в действии, они поняли, что обработка самого заказа важ-
нее, чем информация об адресе, и попросили нас передвинуть эту секцию повыше.
Наша модель стала еще точнее, и теперь наши пользователи точно знают, что они
получат от нас. Мы применили корпоративные стандарты разработки пользова-
тельского интерфейса (вспомните методику «Применяйте стандарты моделиро-
вания»), использовав корпоративные цвета и выровняв поля. В случае с HTML
мы частично написали код для страницы, по крайней мере, для ее видимой части,
хотя могли пойти и дальше, написав код JavaScript вручную или «вычистив» стра-
ницу с помощью текстового редактора, который может то, чего не может средство
для создания прототипа HTML.
Иомер коюдмамеля: 4234567
мя: ОгдрцДа /FлирдЛем'а
ДоокаЗимь:-------------------------—
'’ДгурчНа ИляраЗема
Аррие: I'p"риЗдц керенок,р.1 }
Горор ——.
Ohac-Mt/paioK: \Аекакграрс-КАя о5л. ~|у|
Смарала: \Роса-оя
flромечалоя:
окаройомь »|
Номер ракАра: 3675309
Дама: 14ре$раля,2004
С чем кроаламь;----------
Ге же самые цояя,
чмо и. 3 рарррле
«ДосмоЛамь»
|7~t-H( ЯРИМО
7~е-кррщнй. ро*Ар‘-----------------------------------------
.2SS3 ЗакАраше ffpo^r
0ломкое (fwa кАла.чеом/)о w^aa одмма
Барак
Змеебак,
Иолоёак- 2,999.99 I 7 1
flромеопумочкая сумма rv_
Налога
Довма/ка ''
Сказка 77
• О5щая сумма г
Номер могара
23 456
34 5 6 7
Заклрамое ССромему-
* I iff П <4 МП О
19.99 Г7~] ™,93
29.97
2,999.9
Ирцлимь
Рис. 10.5. Нарисованная на белой доске схема страницы HTML для размещения заказа
138 Глава 10 • Используем простейшие средства
*^ost/D:/temp/index. him
Имя покупателя: Огурцова Елизавета
Номер покупателя: 1234567
Заказа: 8675309
Дата: 14 февраля; 2002. •;
Текуирси заказ:
^товара Описание Цена Количество Промежуточен, сумма Удалить
123453 Бвдон й 19,997 J ~ j 139,93 Й;. : Йй X.feй<й:f
27.156 Змеевик 9,99 j * Й9,97 • й 'йййзй • йЦП Й;Й
1.2697 Половик 2999,99 ] ~~ ; 2999,99 . .'П ;
Промежуточная сумма 3169,89
.: z;-Налоги.; i. 206,04 •
: .. л' &спт-'; 17,50 •
Скидка 150,00 '
Сумма 3243,43
Доставить:
Счет прислать:
П' Те же поля, что ив таблице “Доставить1
^Имя:
Адрес;
Город:
^Область:
:Страиа:
:Прхмечамхя
Рис. 10.6. Прототип пользовательского интерфейса для
размещения заказа в виде страницы HTML
Гибкое моделирование с помощью CASE-средств 139
При работе над моделью данных вам понадобится средство для моделирова-
ния данных. Если вы работаете над UML-диаграммой классов, то нужно средство,
позволяющее работу с таким типом диаграмм, и т. д. Другими словами, всякому
средству свое время. Важным аспектом методики «Используйте простейшие инс-
трументальные средства» является применение того средства, от которого больше
толку при меньших затратах. В большинстве случаев оказывается, что вы уже ре-
шили задачу, моделируя при помощи карточек или белой доски, а вбивать модель
в CASE-средство стоит только в том случае, если вы это самое средство собирае-
тесь использовать.
Зачем вообще нужны инструментальные средства? В самом деле, почему бы не
начать писать код сразу? Во-первых, код сам по себе не так гибок. Элементы кода
не так-то легко менять местами — это вам не стикеры или рисунок на белой доске.
Короче говоря, несколько минут, потраченных на возню со стикерами или рисо-
вание схем на доске, сэкономят вам гораздо больше времени при написании кода.
Во-вторых, менять стикеры местами или рисовать на доске могут все, а вот писать
код — нет. Так что не только разработчики, но и наши прямые пользователи могут
принимать активное участие в разработке дизайна пользовательского интерфейса
или системы, которую мы для них делаем.
Гибкое моделирование с помощью CASE-средств
Вы могли прийти к преждевременному выводу, что разработчики гибких моделей
не пользуются CASE-средствами. Чепуха! Разработчик гибких моделей применя-
ет любое средство, которое больше всего подходит к ситуации. Как столяр иногда
пользуется ручной отверткой, а иногда — электрической, так.и разработчик гиб-
кой модели в одном случае работает, с карточками, а в другом — со сложным про-
граммным обеспечением. В данном разделе будут рассмотрены следующие про-
блемы, связанные с CASE-средствами:
• выбираем CASE-средство;
• избавляемся от заблуждений, связанных с CASE-средствами;
• генерируемый исходный код;
• генерируемая документация.
Выбираем CASE-средство
Любое средство, включая CASE-средство, следует применять только тогда, когда
отдача от его использования будет максимальной. Помните принцип «Повышайте
отдачу от ресурсов, полученных от заинтересованных лиц». Вот основная теория
использования ресурсов: вы можете вложить свои деньги в одно предприятие
с прибылью 10 % или в другое с прибылью 15 %. При прочих равных вы выберете
второй вариант, не так ли? Когда речь идет о средствах моделирования, вам нуж-
но сделать следующий выбор: использовать простые средства типа карточек или
белой доски, или средство для создания диаграмм типа Microsoft Visio, или более
к
140 Глава 10 • Используем простейшие средства
сложное средство для моделирования данных типа TogetherSoft Together Control
Center или Computer Associate ERWin.
Таблица 10.1. Потенциальные преимущества и недостатки CASE-средств
п 1РЕИМУЩЕСТВА НЕДОСТАТКИ
• Прямая разработка (генерация кода) • Предварительная подготовка и обучение
• Обратная разработка существующего кода • Расходы по оценке
• • • Поддержка меняющихся уровней абстракции (например, от требований к анализу — к разработке кода) Тестирование согласованности и правильности модели Синхронизация модели с кодом • Дальнейшее сопровождение модели (еще хуже, если модель пережила то время, когда от нее была польза, но вы сопровождаете ее для потомков) • Расходы на новые версии программного обеспечения
• • Поддержка различных точек зрения и/или возможных решений проблемы Генерация документации ' • Текущие эксплуатационные расходы • Время, потерянное в ожидании, пока средство выполнит свою задачу • Время, потерянное из-за злоупотребления возможностями средства (например, вы тщательно «вылизываете» диаграмму, вводите постороннюю информацию и т. д.) • Расходы по передаче модели на другое средство • Более сложная синхронизация модели с другими артефактами, например с исходным кодом • CASE-средства предполагают скорее «букву», нежели «дух» моделирования, то есть ухудшается общение между разработчиками. Другими словами, если модель хорошо выглядит, это еще не значит, что она работает • Генерируемый код обычно упрощен до предела или засорен посторонней информацией, которая требуется для работы средства • Пользовательские интерфейсы низкого качества затрудняют моделирование • Недостаточные возможности интеграции с другими средствами понижают продуктивность и/или требуют дополнительной работы по интеграции • Необходимость постоянно заниматься системным программированием для интеграции с другими средствами. Часто это не предусмотрено бюджетом, но делать-то все равно надо
Гибкое моделирование с помощью CASE-средств 141
Как вы будете высчитывать предполагаемую отдачу от использования того или
иного средства? На самом деле этого не нужно делать, по крайней мере, в строгом
смысле слова «высчитывать». Конечно, вы можете сделать сложные табличные вы-
гисления расходов, как количественных (в денежном выражении), так и качест-
венных, которые надо перевести в денежный эквивалент. Затем можно сравнить
расходы с предполагаемой прибылью, как количественной, так и качественной (по-
тенциальные расходы и прибыль см. в табл. 10.1). Далее вам придется высчитать
гистую текущую стоимость этих данных, чтобы иметь возможность их сопоста-
вить. Если вас это заинтересовало, я подробно описал этот процесс в книге «Process
Patterns» (Амблер, 1998), но все же настоятельно рекомендую вам воздержаться от
подобного анализа. Почему? Да потому, что на это уйдет куча времени, и вообще,
это приблизительно то же самое, что искать оправдание для принятия решений.
Возможен ли гибкий подход к выбору CASE-средства? Можно просто следо-
вать принципам и методикам гибкого моделирования. Принцип «Модель долж-
на решать конкретную задачу» гласит, что вы должны понимать, зачем создаете
гот или иной артефакт. Знание цели артефакта определяет объем работы, необ-
ходимый для завершения модели. Как только модель выполнила свое назначение,
вы прекращаете работу над ней. В свою очередь вы начнете понимать, какие тре-
бования вы предъявляете к используемым средствам. Зная свои требования, вы
можете определить, выполнит ли то или иное средство поставленную перед ним
задачу в каждой конкретной ситуации. По моему собственному опыту, лучший
подход к выбору средства — делать это, руководствуясь инстинктом (хотя ваше
начальство может и не одобрить этот метод). Методика «Умейте пользоваться
инструментальными средствами» означает, что вы должны знать возможности
средств, которыми пользуетесь. Методика «Используйте простейшие инструмен-
тальные средства» советует выбирать самое простое средство (даже если это будет
CASE-средство) для решения поставленной задачи.
Избавляемся от заблуждений,
связанных с CASE-средствами
Давайте рассмотрим наиболее распространенные заблуждения в отношении
CASE-средств:
Заблуждение № 1: Разработчики гибких моделей не пользуются CASE-
средствами. Разработчики гибких моделей следуют методике «Используйте про-
стейшие инструментальные средства», и если в данной ситуации простейшим яв-
ляется CASE-средство, то оно и будет использовано.
Заблуждение № 2: Для работы в UML нужны CASE-средства. Многие
разработчики связывают унифицированный язык моделирования (UML) ,
с CASE-средствами, хотя это выдумка чистой воды. В данной книге (да хотя бы
и в этой главе) множество UML-диаграмм, нарисованных от руки.
Заблуждение № 3: Моделирование следует начинать с применения
CASE-средств. Как вы уже читали в разделе «Эволюция.модели», обычно моде-
лирование начинают с помощью простых средств, а к CASE-средствам переходят
только при необходимости. Конечно, CASE-средства могут быть полезны, когда
142 Глава 10 • Используем простейшие средства
они генерируют за вас код или выполняют обратную разработку для создания мо-
дели из существующего кода, но на первых порах я советую применять простые,
гибкие средства.
Заблуждение № 4: CASE-средство является эталоном. Как бы ни было хоро-
шо ваше CASE-средство, на самом деле исходный код можно синхронизировать
только с исходным кодом (Бек, 2000). Разработчики гибких моделей знают, что
как только вы сгенерировали код из модели или написали код на основе модели,
код становится первичным артефактом и перестает быть моделью. Возможно, вы
решите произвести обратную разработку вашего кода, чтобы усовершенствовать
модель, следуя методике «Совершенствуйте только в случае необходимости».
Генерируемый исходный код
На рис. 10.3 учтена возможность генерации исходного кода из модели, созданной
с применением CASE-средства, и возможность обратной разработки существую-
щего кода с целью получения модели. Эти шаги могут, оказаться либо очень удач-
ными, либо привести к провалу, в зависимости от используемого CASE-средства.
Если мы говорим о коде, то вот требования, предъявляемые разработчиками гиб-
ких моделей к CASE-средствам:
Соответствие вашим стандартам кодирования. Следует учитывать возмож-
ность редактирования исходного кода, сгенерированного CASE-средством. Если
сгенерированный код существенно отличается от вашего собственного, то с ним
сложнее работать, и вообще это ставит под сомнение саму идею генерирования
кода. Таким образом, вам нужно или выбирать средства, которые можно конфигу-
рировать в соответствии с вашими стандартами кодирования, или изменить стан-
дарты кодирования в соответствии со средством (в этом случае вы целиком и пол-
ностью зависите от прихотей производителя).
Возможность настройки. CASE-средства должны предоставлять возмож-
ность решить, какой код вы хотите генерировать. Вам нужно генерировать вспо-
могательный код, типа операций «получатель-установщик»? Код, необходимый
для используемой оболочки, например удаленный интерфейс для Enterprise
JavaBeans (EJB)? Код для n-звенного окружения, где применяется пользователь-
ский интерфейс на основе браузера? Или код для архитектуры «толстого клиен-
та», использующий графический пользовательский интерфейс? г
Минимальная агрессивность. Некоторые средства ведут себя агрессивно:
вставляют идентификаторы в комментарий к исходному коду, например уни-
кальные имена или собственные метки, показывающие, какой именно код был
генерирован. Бывают и еще более агрессивные средства, которые ограничивают
возможности внесения изменений в определенные части сгенерированного исход-
ного кода; при этом они снабжают эти части комментарием. Такой агрессивностью
мы обязаны производителю, который закладывает эти функции в программу для
своего удобства, например, чтобы выполнить обратную разработку собственного
кода. Вам это ни к чему. По мере доработки CASE-средства производитель более
тщательно продумывает функцию обратной разработки кода, и средство стано-
вится менее агрессивным.
Гибкое моделирование с помощью CASE-средств 143
Возможность гибкого применения обратной разработки кода. Обычно разра-
ботчики работают над небольшой частью системы и, возможно, они будут концен-
трироваться только на одном аспекте этой части в определенный период времени.
Чтобы этот процесс был эффективным, нужна возможность подвергнуть обрат-
ной разработке только какую-то часть системы в период времени, например, де-
сять из трехсот классов C++, составляющих вашу систему, и генерировать толь-
ко тот тип диаграмм, который вам нужен в этот момент, скажем, для начала одну
UML-диаграмму классов.
Простота в использовании. Если средство сложно в обращении, значит, с ним
будет трудно научиться работать, то есть ваши вложения в средство возрастут,
а отдача уменьшится.
Поддержка разных языков. Многие системы разрабатываются с применени-
ем различных языков, например, www-система может состоять из кода HTML,
JavaScript, Perl, Java и кода собственной базы данных. В идеале CASE-средство
должно поддерживать те языки, с которыми вы собираетесь работать.
Вот несколько советов, которые помогут вам сохранить гибкость, применяя
CASE-средства с возможностями генерации кода:
Имейте в виду, что генерация кода не всегда подразумевает гибкий подход.
Вам не поможет средство, генерирующее низкокачественный или неверный код.
Не поддавайтесь на рекламные уловки. Используйте CASE-средства, выбирая те,
которые соответствуют вашим целям.
Генерируемый код должен быть понятным. Хант и Томас (2000) предупреж-
дают о «злых волшебниках» — генераторах кода, которые создают непонятный код.
На первый взгляд, генерация очень сложного кода — неплохая идея, ведь вам не
придется платить за это людям с соответствующей квалификацией, но что вы бу-
дете делать, когда понадобится модифицировать сгенерированный исходный код
в соответствии с условиями или новыми требованиями? Суть принципа «Ожи-
дайте изменений» состоит в том, чтобы не загнать себя в безвыходное положение.
Итерация, итерация и еще раз итерация. Чтобы снизить накладные расходы,
необходимо регулярно выполнять обратную разработку кода для преобразования
его в модель (модели). Легче выполнить обратную разработку в связи с неболь-
шими изменениями, сделанными парой разработчиков, чем потратить несколь-
ко недель, выполняя обратную разработку изменений, внесенных всей группой.
Выполняя обратную разработку кода, вы часто сталкиваетесь с необходимостью
переместить некоторые графические объекты, потому что у них изменились раз-
меры; также часто случается, что используемое вами CASE-средство не в состоя-
нии преобразовать новую версию кода в существующую модель.
Генерируемая документация
Если вы используете CASE-средство в первую очередь для того, чтобы сгенери-
ровать документацию, то вы явно не сторонник гибкого подхода к разработке.
Принцип «Главная цель — программное обеспечение» гласит, что нашей целью яв-
ляется создание ПО, а не документации. Выбирайте средства, с которыми легко ра-
ботать и которые генерируют высококачественный исходный код, а не те, которые
144 Глава 10 • Используем простейшие средства
обладают обширными возможностями для генерации документов. Большинство
CASE-средств генерируют всеобъемлющую документацию по принципу телефон-
ного справочника, а не гибкую документацию (см. главу 14). Согласен, принцип
«Еще одна цель — продолжать проект» гласит, что документация — очень важ-
ная часть работы, но все дело в том, что это не самая важная часть. Да, многие
группы должны создавать документацию для внешних групп, но, как вы читали
в главе 8, существуют более эффективные средства общения, чем документация.
Короче, чем меньше вы пользуетесь CASE-средствами для генерации документов,
тем лучше, потому что в этом случае вы сделаете гораздо меньше ошибок.
Используйте возможности
представления информации
Работая с различными средствами, разработчики гибких моделей используют все
возможности представления информации. Вот некоторые из них:
Цвет. Коуд, Лефевр и ДеЛука (1999) подробно описали, как использовать
цветовые возможности при создании диаграмм классов, например выделять фаз-
ными цветами различные типы классов. Вы можете рисовать на белой доске мар-
керами разного цвета. Например, при создании диаграммы размещения можно ис-
пользовать красный маркер для выделения тех пунктов, в которых вы не уверены;
синий маркер можно использовать в модели данных для таблицы поиска или в
диаграмме потока данных для выделения пунктов, которые выходят за рамки ва-
шего проекта.
Размер. Можно использовать стикеры разного размера для обозначения раз-
личных типов экранных элементов на основных прототипах пользовательского ин-
терфейса, как на рис. 10.6, где стикеры большого размера обозначают поля ввода.
Гибкие графические средства. Такие средства, как Microsoft Visio (www.
microsoft.com), весьма популярны, так как с их помощью вы можете создавать са-
мые разнообразные диаграммы, а также менять и подбирать обозначения. Microsoft
Visio — очень гибкое в использовании средство, с помощью которого можно созда-
вать сложные диаграммы свободной формы. Свободная форма особенно полезна
для создания диаграмм архитектуры и тех диаграмм, которые нужно представлять
заинтересованным в проекте лицам, кому нужно более наглядное изображение,
чем то, которое получается при. использовании таких нотаций, как UML.
Трехмерная модель (SD-модель). Бывает, что какой-нибудь вопрос может
быть рассмотрен только с помощью трехмерной модели. Например, когда речь
идет об интернет-магазинах типа SWA Online, возникает вопрос о доставке това-
ра. Если покупатель заказывает несколько единиц товара, способ упаковки влияет
на стоимость заказа (вы хотите использовать самую маленькую коробку), а стои-
мость доставки оплачивает покупатель (чем меньше коробка, тем меньше затраты
на доставку). Другой пример — разработка системы для авиадиспетчерской служ-
бы. Тут вам нужно позаботиться не только о дизайне ПО, но и об интерьере поме-
щения, включая размещение мебели, поскольку авиадиспетчер должен видеть са-
молеты не только на мониторе, но и в реальности.
Какое средство, такая и модель 145
СОВЕТ: НЕ ПРИДИРАЙТЕСЬ ------------------------------------------:-----
Людям свойственно ошибаться. Они хватают синий маркер вместо черного и рисуют им
как ни в чем не бывало. Вместо стикера размером 5x10см они используют стикер размером
5x5см. Они пользуются Microsoft Visio вместо Microsoft PowerPoint, который является вашим
корпоративным стандартом. Или вы сами взяли по пачке желтых и белых карточек, а про
синие забыли. Запомните, ваши модели не должны быть идеальными — они просто должны
выполнять свое назначение, потому что содержание важнее формы.
Какое средство, такая и модель
Когда у вас в руках молоток, все остальное пред-
ставляется в виде гвоздей.
Автор неизвестен
Зависит ли результат вашей работы от того, какими средствами моделирования
вы пользуетесь? По-моему, да. На самом деле это серьезная проблема, и вам сле-
дует это признать. Во-первых, если ваши инструменты и средства не полностью
поддерживают выбранную вами нотацию (нотации), то, возможно, вам не удастся
создать именно такую модель, какую бы вы создали, имея более функциональное
средство. Во-вторых, если ваше средство работает в одном направлении эффек-
тивнее, чем в другом, то и модель получится соответствующая. Если ваше сред-
ство позволяет без труда применять общие паттерны дизайна, то вы будете при-
менять их чаще, чем применяли бы, используя неподходящее для этого средство,
и тем самым отвергнете методику «Не увлекайтесь паттернами». В-третьих, уро-
вень поддержки модели повлияет на качество и типы создаваемых вами моделей.
Например, используя средство, поддерживающее UML, разработку пользователь-
ского интерфейса и моделирование базы данных, вы получите другой результат,
нежели используя средство, поддерживающее только UML. Ваш взгляд на про-
блему зависит от того, какие нотации поддерживает ваше средство. Они могут от-
ражать определенные методики моделирования, например ICONIX (Розенберг
и Скотт, 1999) или Catalysis (Д’Суза и Виллз, 1999), что, в свою очередь, влия-
ет на выбор структуры вашей модели. В-четвертых, используя простые средства,
вы получите не такую модель, какую получили бы при использовании сложных
средств — заинтересованные в проекте лица примут более активное участие в мо-
делировании, если вы будете использовать простые средства, и лучше смогут объ-
яснить вам свои требования. К тому же простые средства являются более гибкими
и на них не распространяются ограничения моделирования, присущие большин-
ству CASE-средств (например, поддержка только определенной нотации).
И самое главное — в моделировании люди важнее, чем инструменты.
Разработчик гибких моделей, обладающий хорошими собственными навыка-
ми, лучше поймет требования, чем тот, который такими навыками не облада-
ет. Разработчик гибких моделей, который понимает и может применять различ-
ные технологии и методы (например, такие, как описаны в приложении А), будет
гораздо более эффективен, чем разработчик, обладающий менее богатым Интел-
146 Глава 10 • Используем простейшие средства
лектуальным багажом, потому что он сможет следовать методике «Применяйте
нужный артефакт (артефакты)».
Практическое применение простейших средств
\
Методика «Используйте простейшие инструментальные средства» советует вам
применять то средство моделирования, которое лучше всего подходит для дан-
ной задачи и которое принесет максимальную отдачу средств и времени, потра-
ченных на освоение и работу с этим средством. Предпочтение следует отдавать
простым средствам, таким как карточки или белая доска, но более сложные сред-
ства, такие как текстовые процессоры, графические утилиты и даже совершенные
CASE-средства, также используются разработчиками гибких моделей. При выбо-
ре средства руководствуйтесь методикой «Умейте пользоваться инструменталь-
ными средствами» и принципом «Повышайте отдачу от ресурсов, полученных от
заинтересованных лиц». Разработчики гибких моделей предпочитают самые про-
стые средства, подходящие для выполнения определенной задачи, и делают свой
выбор с умом.
Рабочее место
гибкого
разработчика
Физическая среда, в которой вы работаете, имеет огромное значение для эф-
фективности работы гибкого разработчика. Все мы помним детский стишок про
гвоздь и подкову:
Не было гвоздя — подкова пропала.
Не было подковы — лошадь захромала.
Лошадь захромала — командир убит.
Конница разбита — армия бежит.
Враг вступает в город, пленных не щадя,
Оттого, что в кузнице не было гвоздя.1
Значит ли это, что в вашей организации произойдет то же самое из-за отсут-
ствия маркера? Надеюсь, что нет. Тем не менее, я работал в организациях, где лю-
дям приходилось держать свои маркеры при себе. Если они оставляли маркеры
в комнате, где проходили собрания, они вскоре исчезали. По какой-то причине
в этой организации постоянно не хватало маркеров для рисования на белой до-
ске, которые являются самым эффективным средством, способствующим обще-
нию (см. главу 8). Зарубите себе на носу: для эффективной работы гибких разра-
ботчиков необходимы доступ к нужным ресурсам и рабочая среда, позволяющая
применять методики AM.
Помещение для гибкой разработки
Каким должно быть рабочее место для эффективной гибкой разработки? На мой
взгляд, следующие факторы, представленные по степени значимости, являются
решающими для создания эффективной рабочей среды:
1 Перевод С. Я. Маршака. '
148 Глава 11 • Рабочее место гибкого разработчика
Вам нужно специально отведенное место. Самые результативные группы раз-
работчиков имеют свои собственные рабочие места. Да, во многих организаци-
ях не хватает места, но если вышестоящее начальство хочет, чтобы ваша группа
успешно работала, оно должно снабдить вас всеми необходимыми ресурсами. Вы
не должны ждать, пока найдется место для проведения собрания, на котором вы
сможете заняться моделированием. Вы должны быть уверены в том, что никто не
сотрет ваши записи с белой доски и не выбросит в мусорное ведро ваши карточки.
Я работал в компаниях, где очень не хватало места. Мы были вынуждены ждать по
нескольку дней, пока находилось помещение, где можно было провести собрание.
Больше места для белых досок. Я считаю, что места для размещения белых
досок никогда не бывает много. К счастью, белые доски очень недороги. Я предпо-
читаю белые доски от пола до потолка, в любом свободном месте на стене, даже на
колоннах, если они шире 30 см. У разработчиков должны быть свои личные белые
доски, на которых они могут рисовать диаграммы самостоятельно, в парах (рабо-
та многих групп разработчиков, особенно групп ХР, основана на работе в парах)
или совместно с несколькими коллегами. Нет места для белых досок? Поговорите
с обслуживающим персоналом, который отвечает за помещения в вашей органи-
зации. Скажите им, что белые доски — самое главное для вашей группы. Вам не
разрешают повесить белые доски? Попросите руководство помочь вам или прос-
то установите белые доски сами и извинитесь впоследствии. Знаете ли вы, что су-
ществуют обои, которые можно использовать в качестве белой доски? Я успешно
применял их в работе. Используя любую из перечисленных технологий, вы легко
сможете оборудовать большую комнату за пару часов.
Цифровая камера. Можно использовать цифровую камеру для того, чтобы
сфотографировать ваши моделируемые артефакты. Используйте цифровые ка-
меры, чтобы сфотографировать важные диаграммы для размещения на внутрен-
них веб-сайтах, заснять бумажные модели (сущностный прототип UI или моде-
ли CRC), сделать снимок модели, отражающей альтернативный подход, который
вы отвергли, но к которому, возможно, захотите вернуться в будущем или прос-
то сделать копию диаграммы для контроля версии. Цифровые камеры недороги
и просты в использовании. Я советую вам приобрести камеру с высоким разреше-
нием, которая сможет фиксировать малейшие детали, так как стоит она не намно-
го дороже. Цифровые камеры быстро оправдывают расходы на их приобретение.
Они заменяют высокооплачиваемых разработчиков, работа которых заключается
в переносе ваших моделей на бумагу. Цифровые камеры также являются хоро-
шей заменой печатающих белых досок, которые были популярны в начале 90-х.
Цифровые камеры более функциональны, портативны и недороги.
Оборудование для моделирования. Методика «Используйте простейшие
инструментальные средства» говорит нам о том, что, работая с простейшими сред-
ствами, вы сможете выполнить работу. Поэтому у вас должны быть эти простые
средства. Вам нужны маркеры, бумага на липкой основе (разных цветов и разме-
ров), карточки (разных цветов и размеров), писчая бумага, планшеты, липкая лента,
кнопки, струны и любое другое оборудование, которое необходимо вашей группе.
Книжная полка или шкаф. Вам нужно место для хранения оборудования для
моделирования и справочников. >
Помещение для гибкой разработки 149 '
Большой стол. Для применения некоторых методик, например моделирова-
ния с помощью карточек CRC, вам для работы нужен большой стол. Также стол
нужен вам для того, чтобы положить ваши записные книжки или (что важнее) еду,
когда вы соберетесь поесть.
Компьютер. Наличие компьютера на вашем рабочем месте может принести
пользу, особенно когда вам нужно получить информацию из Интернета во время
сеанса моделирования (хотя я предпочитаю, чтобы это было сделано после сеанса),
или просто чтобы получить доступ к моделям, размещенным для контроля вер-
сии. Возможно, вы захотите установить CASE-средства на этот компьютер, чтобы
можно было осуществлять работу при помощи выбранных вами средств. Все же
помните, что использование сложных средств устанавливает барьеры в общении
и может привести к обратным результатам. В главе 8 вы сможете найти подробное
обсуждение вопросов, связанных с общением. Если вы собираетесь установить
компьютер на своем рабочем месте, то позаботьтесь о том, чтобы он был хорошим,
если не хотите, чтобы ваша группа ждала, пока компьютер выполнит задачу.
Стулья. Хотя рабочие сеансы, во время которых люди стоят, очень продук-
тивны (люди нацелены на выполнение работы и готовы сотрудничать), все же им
нужно предоставить возможность присесть. Я считаю, что необходимо иметь не-
сколько стульев на рабочем месте. Ведь это рабочее место, а не зал заседаний, по-
этому если кому-то захочется присесть, они смогут это сделать. В начале рабо-
ты над проектом, когда сеансы моделирования достаточно длинны (см. главу 13),
важно предусмотреть места для сидения, так как, вероятнее всего, члены вашей
группы захотят работать сидя. Когда ваш проект перейдет к стадии создания, се-
ансы моделирования становятся короткими, часто от 10 до 20 минут. Во время та-
кого сеанса можно и постоять.
Место, где можно прикрепить бумагу. Кроме места для белых досок необхо-
димо также место, где можно прикрепить бумагу. Вам нужно где-то размещать ар-
тефакты, выполненные на бумаге. Если это возможно — повесьте пробковую до-
ску. На худой конец, пусть это просто будет свободное место на стене.
Проектор. Если вы собираетесь установить компьютер на своем рабочем ме-
сте, вам нужно предусмотреть и проектор, который вы подключите к компьютеру,
чтобы показывать изображения на стене. Просмотр изображений способствует
общению, так как все могут их увидеть. Тем не менее, группы разработчиков со-
вершают одну и ту же ошибку, пытаясь преобразовать информацию при помощи
CASE-средств во время сеанса моделирования. Обычно во время сеанса есть
«CASE-жокей», который работает с CASE-средствами в то время, как другие
моделируют. Обычно изображение проецируется на белую доску, где осталь-
ные могут вносить изменения. К сожалению, этот подход чрезвычайно непродук-
тивен, потому что членам группы приходится ждать, пока CASE-жокей отразит
информацию. Лучше будет использовать более гибкие средства для совместной
работы, например белые доски. А потом подойдет использование менее гибкого
средства (CASE-средства) для того, чтобы зафиксировать результаты. В качестве
поддержки моделирования при помощи белых досок вы можете использовать
CASE-жокея для проецирования созданных моделей. Разница будет в том, что
вы не будете пытаться усовершенствовать модели по мере продвижения работы.
150 Глава 11 • Рабочее место гибкого разработчика
Справочники. Во время моделирования может возникнуть необходимость по-
лучения информации из справочника. Например, вам может понадобиться узнать
нотацию UML для определенного понятия или- определение паттерна дизайна.
В табл. 11.1 представлен краткий перечень книг, которые, по моему мнению, мо-
гут оказаться полезными во время сеансов моделирования. На самом деле я обыч-
но прошу своих клиентов заказать хотя бы по одному экземпляру каждой книги
для всей группы и предлагаю каждому разработчику обзавестись своим экземпля-
ром, чтобы они могли при необходимости делать в них пометки.
Таблица 11.1. Рекомендуемые справочники по моделированию
Название справочника Использование
The Object Primer, Second Edition Edition: The Application Developer's Guide to Object Orientation. Амблер, 2001a Справочник по множеству методик, в том числе по диаграммам UML
UML Distilled, Second Editibn: Applying the Standard Object Modeling Language. Фаулер и Скотт, 1999 Хороший справочник по UML
Analysis Patterns: Reusable Object Models. Фаулер, 1997 Предлагает решения распространенных проблем, связанных с бизнес-приложением
Design Patterns: Elements of Reusable Object- Oriented Software. Гамма, Хельм, Джонсон и Влиссидес, 1995 Предлагает решения проблем, типичных для объектно-ориентированной разработки
A Systems of Patterns: Pattern-Oriented Software Architecture. Бушман, Мюнье, Рохнерт, Соммерлед и Стал, 1996 Предлагает решения проблем, типичных для объектно-ориентированной архитектуры и дизайна
Еда. Наличие еды на рабочем месте обычно нравится всем и способствует со-
зданию атмосферы товарищества. Лучше всего, если она будет разной. Вкусы
и пристрастия в еде у всех разные. Лично я люблю карамельки. Они маленькие
и хорошо хранятся. Фрукты — тоже неплохая идея.
Игрушки. Когда у вас есть с чем поиграть, вам легче сняться с мели, если вы
застряли на чем-то во время работы. Во многих группах, где ратуют за вежливость
во время работы, разрешается бросать мячик в того, кто ведет себя невежливо или
невнимательно по отношению к другим.
СОВЕТ: ДОСТУПНОСТЬ РЕСУРСОВ ОПРЕДЕЛЯЕТ
СТЕПЕНЬ ПОДДЕРЖКИ РУКОВОДСТВА ----------------------------------------
Я знаю из своего опыта, что готовность руководства предоставить вам необходимые средства
является главным индикатором их реальной поддержки вашей группы. Все, о чем говорилось в
разделе «Помещение для гибкой разработки», действительно необходимо и стоит недорого.
Да, действительно иногда катастрофически не хватает места, и вы не можете предоставить
своей группе отдельное помещение для разработки. Я считаю, что в вашей организации
должны подумать о проблемах, связанных с физическими неудобствами, прежде чем браться
за новый проект по разработке ПО. Невозможно получить маркеры, потому что выделенные на
год средства уже потрачены? Подумайте об увольнении бухгалтера за то, что он экономит на
малом, но не может обеспечить необходимого. Вы ведь не просите слишком много. Если выше-
стоящее начальство не может предоставить вам все необходимое, велика вероятность того, что
- они не верят в ваш проект, а это уже проблема, которую вамхнужно решить как можно скорее.
Как это осуществить? 151
СОВЕТ: ВОЗЬМИТЕ НА ВООРУЖЕНИЕ ИСПОЛЬЗОВАНИЕ ЦИФРОВЫХ КАМЕР —
С ростом популярности цифровых камер для фиксации изображений, выполненных на белой
доске, мы видим, что ПО способно «подчищать» изображение и даже фиксировать текстовую
информацию, содержащуюся на нем. Быстрый поиск по сети безусловно гарантируется.
Эффективные рабочие зоны
Рабочее место — это не просто пространство, которое используется для модели-
рования. Вам нужно такое место, которое способствует и остальной части жиз-
ненного цикла проекта. Кроме места для моделирования, вам необходимо место
для программирования и тестирования вашей системы. Само собой разумеется,
вашим разработчикам понадобятся рабочие станции. Процесс, лежащий в осно-
ве (например, ХР или Unified Process), и который вы используете в гибком мо-
делировании (см. главу 1), должен давать советы, касающиеся рабочих зон, под-
ходящих для этого процесса. Например, при работе над проектом ХР на вашем
рабочем месте должны быть рабочие станции для работы в парах, в то время как
в UP-проекте группа может решить, что каждый работает самостоятельно в сво-
ей отдельной кабинке или офисе. Важно понимать, что, вероятнее всего, вам при-
дется учитывать и рекомендации по работе с этими процессами, и советы, данные
мной в этой главе, чтобы организовать ваше рабочее место. Размер группы также
влияет на форму вашей рабочей зоны. Возможно, большие группы захотят иметь
несколько рабочих зон с местом для совместной работы.
Как это осуществить?
Далеко не во всех, организациях есть лишнее место. Очень легко объяснить, что
группе разработчиков необходимо отдельное рабочее место, но очень сложно по-
лучить и удержать это рабочее место. Очень легко объяснить, что людям необхо-
димо работать совместно, но на самом деле время от времени им необходимо уеди-
нение. Работая над проектами ХР, легко настаивать на том, чтобы люди работали
совместно за одним столом, но это очень трудно сделать в организациях, где ваша
важность отмечена размером вашего стола1 или офиса. Я многие годы применял
следующие методики в различных организациях для организации эффективных
рабочих мест:
Убедите высшее руководство в важности организации эффективной рабо-
чей зоны. На решение данной проблемы стоит потратить политический капитал,
потому что работа вашей группы не может быть успешной без среды, которая спо-
собствует выполняемой работе. Это может означать, что других людей перемес-
тят в другое место в вашей организации; это может означать, что вам нужно будет
1 Однажды я работал в компании, в которой очень легко было узнать, насколько велико положе-
ние того или иного человека в корпоративной иерархии по форме стола. Люди с первого по седьмой
уровень имели стол формы А, с восьмого по двенадцатый — формы Б и т. д. Вы понимали, что кто-то
занимает очень важное положение (вероятнее всего, вице-президент), если у него был свой собствен-
ный стол (обычно большого размера и сделанный из ценных пород дерева).
152 Глава И • Рабочее место гибкого разработчика
сделать некоторые перестановки (возможно, убрать существующие перегородки,
чтобы освободить помещение); или это может означать, что вам придется найти
новое место под офис. Сделайте это. Затраты на это минимальны по сравнению с
увеличением продуктивности, которая будет ими обусловлена.
Убедите группу в важности организации эффективной рабочей зоны. Каждый
человек, активно участвующий в проекте (включая и разработчиков, и заинтере-
сованных лиц), должен понимать, почему его рабочее место организовано таким
«новым» образом. Они могут не знать о совместных рабочих зонах или о необхо-
димом для такой среды этикете. Вероятнее всего, они не знают, почему новое ра-
бочее место имеет решающее значение для успеха вашей работы. Поговорите с ни-
ми об этом.
Избавьтесь от наушников. Для того чтобы рабочая зона была эффективной,
она должна способствовать общению внутри вашей группы. Но если у всех членов
группы наушники, в которых звучит их любимая музыка, это означает, что они не
могут общаться.
Позвольте людям сохранить за собой их прежние офисы. Если некоторые
члены группы считают, что потеряют свой «хороший стол/офис/...», став участ-
ником вашего проекта, позвольте им сохранить их. Настаивайте на том, чтобы они
в рабочее время трудились в рабочей зоне группы, но позвольте им сохранить за
собой свое личное рабочее место, чтобы они могли поддерживать корпоративный
имидж. Да, это немного нефункционально, но вы вынуждены пойти на подобные
уступки, внедряя такие новые методики, как AM.
Предусмотрите отдельные помещения. Многим группам необходимо наличие
маленьких отдельных комнат, где можно сделать звонок личного характера, по-
говорить наедине с другим членом группы или просто удалиться от всего на пару
минут. Я работал над несколькими проектами, где для группы выделялось такое
помещение, хотя обычно для этого используется комната для проведения собра-
ний, которая является общей для всей организации.
Я не могу слишком заострять внимание на важности получения достаточных
средств (заметьте, я говорю «достаточных», а не «непомерных»). Никогда не за-
бывайте применять принцип «Повышайте отдачу от ресурсов, полученных от за-
интересованных лиц» и просите лишь те ресурсы, которые вам нужны и которые
вы сможете оправдать.
Группы гибкого
моделирования
В гибком моделировании нет «Я»,
Гибкое моделирование — это всего лишь совокупность синергетических методик,
которые опираются на определенный набор принципов и ценностей. Если нет лю-
дей, следующих этим методикам, людей, которые хотят работать и развиваться
вместе, то гибкое моделирование — это пустой звук. Чтобы гибкое моделирование
приносило пользу вашей организации, в группу разработки должны входить как
разработчики, так и заинтересованные в проекте лица, которые в идеале будут ра-
ботать бок о бок с разработчиками. Чтобы создать эффективную группу разработ-
ки, вам нужно предпринять следующие шаги:
• нанять несколько хороших разработчиков;
• усвоить, что в гибкой разработке нет «Я»;
• потребовать от всех активного участия;
• моделировать в группе.
Берем несколько хороших разработчиков
Первый шаг к созданию эффективной группы — найти правильных людей, ко-
торые будут там работать. Кокберн (2001b) отмечает, что многие методологии
определяют роли, которые разработчики могут выполнять в процессе разработки,
и типы задач, соответствующие той или иной роли, но при этом часто забывают
определить людей, наиболее подходящих для выполнения этих задач в этих ролях.
- Чтобы быть эффективным в той или иной роли, разработчик должен в известной
степени для нее подходить. Не обязательно иметь все необходимые навыки и уме-
ния — главное, чтобы были желание и способности их развить. Я считаю (и убе-
дился в этом на опыте), что разработчик гибких моделей должен обладать следу-
ющими качествами:
154 Глава 12 • Группы гибкого моделирования
Способность быть членом группы. Первое и самое главное — разработчик
гибких моделей должен активно стремиться к сотрудничеству с другими члена-
ми группы, потому что он сознает, что не может знать всего на свете и, чтобы быть
эффективным, иногда отчаянно нуждается в помощи. Разработка программного
обеспечения во многом подобна плаванию — и тем и другим опасно заниматься
в одиночку. Еще раз напомню, что в гибком моделировании, как и в любой кол-
лективной работе, нет «Я».
Общительность. Разработчик гибких моделей должен иметь хорошие навыки
общения. Он умеет подавать свои идеи. Он прислушивается к другим. Он стре-
мится получить обратную связь. Он обладает хорошими навыками письменной
речи.
Практичность. Разработчик гибких моделей должен быть практичным. Он
должен уметь сосредоточиться на удовлетворении нужд пользователя и не пере-
гружать модели лишними деталями. Разработчик должен удовлетвориться про-
стейшим решением, которое приведет к выполнению задачи.
Любознательность. Разработчик гибких моделей с удовольствием изучает
возникающие проблемьГи'способы их решения.
Скептицизм. Разработчик гибких моделей не принимает ничего на веру. Вместо
этого он задает вопросы и изучает проблему до тех пор, пока она не станет доста-
точно ясна. Он не покупается на рекламные ухищрения, а все проверяет в работе.
Реалистичность. Разработчик гибких моделей должен быть достаточно скро-
мен, чтобы признать, что он не знает всего на свете, и достаточно предусмотрите-
лен, чтобы понять, что модель придется подтвердить кодом, причем чем раньше,
тем лучше.
Смелость. Разработчик гибких моделей всегда готов предложить идею, смо-
делировать ее, а затем попытаться подтвердить ее кодом. В случае неудачи он по-
пробует изменить подход, а если и это не поможет, то он найдет в себе смелость
оставить эту идею. Чтобы предлагать сотрудникам свои идеи и пытаться их обо-
сновать, нужна смелость. '
Готовность экспериментировать. Разработчик гибких моделей всегда готов
применить новый подход, например новый (или, наоборот, забытый) метод мо-
делирования. Он принимает методики гибкого моделирования в целом и всегда
готов пойти против общепринятых правил, чтобы обосновать такие идеи, как, на-
пример, сокращение количества проектной документации.
Дисциплина. Легко сказать себе «Дополнительная возможность еще никому
не помешала» или «Я лучше знаю, что нужно заказчику» и действовать соответ-
ственно. Чтобы быть гибким, нужно быть дисциплинированным.
Что, если вы не обладаете всеми этими качествами, но все же хотите стать раз-
работчиком гибких моделей? Не волнуйтесь. Вы вполне можете их приобрести,
нужно просто немного поработать над собой. Если честно, я вовсе не могу ска-
зать о себе, что я практичен и реалистичен на 100 %, а часто я еще и необщителен.
Никто не может демонстрировать все эти качества постоянно. Достаточно прояв-
лять их в некоторой степени. Люди отличаются друг от друга, и именно эти отли-
чия придают силу группе гибкой разработки. Некоторые люди, например, любо-
Берем несколько хороших разработчиков 155
знательны от природы, а другим приходится над собой работать. В конце концов,
мы всего лишь люди.
Специалисты или универсалы?
Специалистам нельзя доверять. Они хороши
лишь в своей области и ничего не видят за ее
пределами.
Император Лето II
Из: Франк Герберт. «Бог-Император Дюны»
Выбирая.членов группы, вам придется решить, каким в ней будет соотношение
специалистов и универсалов. Вам следует учитывать природу современной разра-
ботки программного обеспечения. На рис. 12.1 изображен жизненный цикл кор-
поративного унифицированного процесса (EUP, Амблер, 2001b). По рабочим по-
токам процесса, показанным слева, можно судить о потенциальной сложности
разработки программного обеспечения — возможно, вам придется заниматься
бизнес-моделированием, собирать требования, анализировать и проектировать
вашу систему и т. д. Это всего лишь верхушка айсберга. Этапы (с начала до произ-
водства) показывают, как меняется фокус в ходе проекта, что требует различных
умений и навыков в разных стадиях проекта. Понятно, что разработка ПО — слож-
нейший процесс, требующий различных умений и обширного опыта. Важно понять,
что разработка ПО является весьма сложным занятием вообще, а не только в кор-
поративном унифицированном процессе — группам разработчиков, применяю-
щим экстремальное программирование (ХР, Бек 2000), подход DSDM (Стэплтон,
1997)-или SCRUM (Бидл и Швабер, 2001), придется столкнуться с теми же слож-
ностями. Хотя жизненные циклы DSDM, SCRUM и ХР не определяют эти слож-
ности столь же четко, как EUP, жизненный цикл ХР подробно описан в третьей
части этой книги. Группам, которые следуют перечисленным методам, все равно
приходится заниматься управлением конфигурации и проектом вообще, и т. д.,
(хотя все делают это по-разному).
Чтобы справиться со всеми сложностями разработки, некоторые организации
решают создать группу, состоящую из специалистов, исходя из того, что специ-
алисты наиболее эффективны для решения определенных задач. То есть чтобы
добиться эффективной разработки ПО, вам нужно всего лишь собрать группу
специалистов, каждый из которых будет работать над своей частью проекта и пе-
редавать свою работу другому специалисту для дальнейшего развития. Такая
«конвейерная сборка» эффективна при производстве автомобилей, но при созда-
нии программного обеспечения она себя не оправдывает, в чем я убедился на опы-
те. Далее, такой подход приводит к раздуванию штатов: допустим, в процессе раз-
работки вам нужно решить X задач — тогда вам нужно набрать по крайней мере
X специалистов. Насколько велико значение X? 20? 50? 100? Это зависит от того,
насколько узких специалистов вы подобрали. Если каждый специалист будет раз-
рабатывать один артефакт, тогда лишь для моделирования вам понадобится более
двадцати специалистов. Именно это количество артефактов перечислено в при-
156 Глава 12 • Группы гибкого моделирования
ложении А. Если каждый специалист будет играть одну роль, то лишь для разра-
ботки рабочего процесса в проекте EUP вам понадобится одиннадцать человек.
К тому же специалисты часто не слишком расположены к сотрудничеству. Либо
им не хватает скромности признать, что другие специалисты тоже вносят свой
полезный вклад в работу, либо они настолько узкие специалисты, что просто не
осознают того, что кому-нибудь придется переделывать (или вообще отбросить)
многое из того, что они наработали. Другая проблема состоит в том, что на самом
деле специалист может быть недостаточно квалифицирован даже в своей специ-
альности. Стремительные изменения в сфере информационных технологий при-
вели к тому, что разработчик осваивает новую технологию в течение всего лишь
нескольких месяцев, после чего объявляет себя специалистом просто потому, что
немногие могут похвастаться даже таким уровнем знаний в этой сфере. В общем,
ясно, что из одних специалистов группу создать нельзя.
Виды деятельности
Бизнес-моделирование__
Требования ___________
Анализ и проектирование
Реализация _
Тестирование
Размещение_________________
Эксплуатация и сопровождение
Управление конфигурацией
и изменениями--------------
Управление проектом________
Среда______________________
Управление инфраструктурой _
Этапы
Итерации
Рис. 12.1. Жизненный цикл корпоративного унифицированного процесса (EUP)
А как начет того, чтобы набрать группу только из универсалов? Каждый бу-
дет иметь неплохие познания в разработке программного обеспечения в принци-
пе, но, к сожалению, они не будут обладать специальными навыками, без которых
работу невозможно выполнить. Вашему проекту понадобятся люди, доскональ-
но знающие технологию и методы, которые вы будете использовать. Если вы ис-
пользуете Enterprise JavaBeans (EJB), то вам понадобятся разработчики, умею-
щие программировать на Java и знакомые со средой EJB. Группе, использующей
Oracle в качестве внутреннего интерфейса, понадобится специалист с опытом ад-
министрирования базы данных Oracle, а группе, разрабатывающей программное
Берем несколько хороших разработчиков 157
обеспечение для биржи, понадобится кто-нибудь, хорошо знающий все тонкости
торговли акциями.
ВНИМАНИЕ: МНОГИЕ РАЗРАБОТЧИКИ СТАНОВЯТСЯ
СПЕЦИАЛИСТАМИ СЕБЕ ВО ВРЕД -----------------------------------------
Многие разработчики становятся специалистами себе же во вред, потому что не учитывают
сложностей, присущих разработке ПО. Типичный пример — антипаттерн «Разработчик одного
артефакта», когда разработчик работает только над одним типом артефактов (например, код,
модель Use Case или модель данных), или антипаттерн «Разработчик одной роли», когда
разработчик ограничивается выполнением только одного типа задач (например, моделирование,
тестирование или кодирование). Другими словами, происходит специализация в определенной
роли — тенденция, которая часто поощряется в больших организациях, следующих предопре-
деленному процессу (если они вообще следуют какому-либо процессу). Проблема в том, что
специалисты, которые попадаются на эту удочку, обычно являются слишком узкими специ-
алистами, чтобы быть эффективными в проекте, где используется гибкая разработка. Хотя если
они пожелают раздвинуть рамки своих возможностей, то этот недостаток можно преодолеть.
На опыте я убедился, что ни первая, ни вторая крайность себя не оправ-
дывают. Необходимо найти золотую середину. Первый вариант: вы набирае-
те группу, частично состоящую из специалистов, а частично — из универсалов.
Универсалы обеспечат связь внутри группы и сосредоточатся на общей картине
действий, а специалисты будут решать конкретные сложные задачи, входящие
в проект. При таком подходе сильные стороны универсалов уравновесят слабые
стороны специалистов, и наоборот; часто полезно бывает поставить специалис-
та работать в паре с универсалом, что создает своеобразный баланс сил. Второй
(лучший) вариант: наберите группу универсалов, каждый из которых имеет пару
специализаций. Например, я считаю себя универсалом, потому что прекрас-
но знаю, как создается ПО в принципе, однако я еще специализируюсь в облас-
ти моделирования коммерческого программного ПО, устойчивости объектов
и программировании на Java. Один из моих коллег в настоящее время также яв-
ляется универсалом, специализирующимся в области моделирования, разработки
EJB и тестирования, а другой — универсал, специализирующийся в телекоммуни-
кационных сетях и программировании на Java. Создание группы, состоящей из
универсалов с одной-двумя специальностями, имеет следующие преимущества:
члены группы легко находят общий язык между собой (они же универсалы!), и в
то же время у каждого есть необходимый опыт в той или иной специализации.
Есть, правда, один недостаток: люди обычно достигают такого уровня в среднем
возрасте, если не позднее. Чтобы стать универсалом, нужно 10-20 лет, поэтому
универсалы — довольно редкое явление, и если в вашей группе есть такие люди,
то вам крупно повезло.
СОВЕТ: НОВИЧКИ ПЫТАЮТСЯ СТАТЬ СПЕЦИАЛИСТАМИ ------------------------
Люди, начинающие заниматься разработкой, обычно поражаются разнообразию знаний,
которые им нужно приобрести. Это нормально. Большинство для начала пытаются сосре-
доточиться на одном или двух аспектах разработки, цапример программировании на Java или
сборе требований пользователя, и накопленный опыт становится для них отправной точкой.
Постепенно они накопят навыки и опыт; возможно, они освоят пару специализаций и начнут
лучше понимать, как различные аспекты разработки соотносятся между собой.
158 Глава 12 • Группы гибкого моделирования
Признайте, что в гибком моделировании нет «Я»
Эффективная группа — группа, каждый член которой сознает, что он должен со-
трудничать с остальными членами, группы. Вы. уже читали в главе 1, что первая
ценность Гибкого альянса (2001а) заключается в том, что отдельные лица и вза-
имодействие. между ними важнее, чем процессы и средства, а третья из четырех
ценностей говорит о том, что сотрудничество с заказчиком важнее, чем перегово-
ры по контракту. Гибкий альянс также определил набор принципов для гибкой
разработки ПО, включая принцип «Заказчик и разработчики должны ежедневно
сотрудничать на протяжении всей работы над проектом». Эти ценностипринци-
пы четко определяют предпочтение групповой работе в гибкой среде, то'есть лю-
дям, совместно работающим для достижения общей цели. Правильность данного
предпочтения подтверждается моим собственным опытом гибкого разработчи-
ка ПО. Качество моей работы значительно улучшается, когда я работаю не один.
Я считаю, что разработка ПО во многом подобна плаванию — и то и другое опасно
делать в одиночку. Это убеждение нашло отражение в методике «Моделируйте в
группе».
Несколько лет назад я работал над созданием биллинговой системы и прило-
жения для службы поддержки клиентов по заказу большой организации, предо-
ставляющей услуги в сфере телекоммуникаций. Частью задачи являлась разра-
ботка пользовательского интерфейса,’с которым заказчику предстояло работать.
Поскольку я уже работал с подобной системой и имел некоторый опыт в разра-
ботке дизайна пользовательского интерфейса, я сразу приступил к созданию про-
тотипа, который основывался на требованиях к новой биллинговой системе. Мы
потратили массу времени на разработку подробных элементов Use Case, которые
были рассмотрены и одобрены комиссией, состоящей из представителей пользо-
вателя (это был не гибкий проект). Я думал, что четко представляю себе то, что
следует разработать. Я начал создание прототипа без всякой помощи со стороны
представителей пользователя, большинство из которых в тот момент были на кур-
сах по изучению элементов Use Case (на самом деле к тому времени они уже уз-
нали о них все от разработчиков, но это уже совсем другая история о корпоратив-
ной дезорганизации). Размещение системы планировалось на платформе Win32,
так что я создал графический пользовательский интерфейс, соответствующий
нормам дизайна пользовательского интерфейса Microsoft (Microsoft Corporation,
1995), и удовлетворил требования пользователей к системе (по крайней мере, я
так думал). Я самостоятельно смоделировал почти 20 экранов, многие из кото-
рых допускали навигацию между собой, параллельно я создал диаграмму пото-
ков пользовательского интерфейса на белой доске в моем маленьком кабинете,
так что прототип пользовательского интерфейса был, как мне казалось, почти го-
тов. По-моему, прототип был просто очарователен, и при этом я сэкономил для
проекта массу времени, сделав самую важную часть дизайна. Но тут пришла пора
вернуться на землю. Когда явились представители пользователя, я был необычай-
но доволен собой, показывая им то, что я сделал, в уверенности, что можно празд-
Потребуйте от всех активного участия 159
новать победу (к тому времени я еще не принял ценность гибкого моделирования
«Смирение»). Я был поражен, когда выяснилось, что прототип совершенно не под-
ходит моим пользователям. Хотя система размещалась в среде Win32, мы также
должны были соблюдать корпоративные стандарты дизайна, которые требовали
использования монохромного текстового пользовательского интерфейса, а не гра-
фического пользовательского интерфейса — ограничение, не отраженное в тре-
бованиях, от которых я отталкивался, так как считалось, что это общеизвестный
факт (и все же разработчики не знали об этом до последнего момента).. Далее, оп-
ределенная информация должна была отображаться особым образом, чтобы наша
система не отличалась от приложений службы клиента, с которыми наши поль-
зователи тогда уже работали, — вот вам еще одно ограничение. В общем, боль-
шая часть проделанной работы (кроме диаграммы потоков пользовательского ин-
терфейса, да и то лишь частично) просто никуда не годилась. Пришлось начать
создание прототипа пользовательского интерфейса с нуля, на этот раз в тесном
сотрудничестве с представителями пользователя, которые хорошо знали суще-
ствующую систему и могли направлять меня в работе. Работая в одиночку, я по-
; ставил себя в невыгодное положение, где не получал никакой помощи со стороны.
Я не следовал принципу «Быстрая обратная связь» и двигался в неверном направ-
, лении, сам того не зная. Получив обратную связь, я осознал свою ошибку, которая
была очевидна для заинтересованных лиц, но не для моих коллег-разработчиков.
Положение было исправлено благодаря методикам «Активное участие заинтере-
сованных лиц» и «^Моделируйте в группе» — одна голова хорошо, а две лучше.
Эффективная работа в группе и эффективное общение (см; главу 8) являются
залогом гибкости. Работа в группе требует доверия, а оно возникает со временем.
Разработчики гибких моделей активно ищут помощи и вклада в работу со стороны;
в свою очередь, они всегда готовы помочь как коллегам-разработчикам, так и за-
интересованным в проекте лицам. Ценности гибкого моделирования «Смирение»
и «Обратная связь» крайне важны для эффективной работы и общения в группе.
В группе нет «Я», а по опыту я могу сказать, что в гибком моделировании также
нет «Я».
Потребуйте от всех активного участия
У меня есть только одно правило: все сражаются,
никто не отступает. Кто струсит, того я пристре-
лю сам.
Сержант Раечек из фильма «Звездный десант»
Лучше не скажешь. Разработка ПО лучше всего получается, когда все работают
вместе. Каждый готов помочь коллеге, и каждый может и хочет выполнять раз-
личные виды задач. Если кто-либо не принимает активного участия, если на сеан-
се моделирования он присутствует в качестве пассивного наблюдателя, или если
он не помогает коллеге, когда тот просит о помощи, то такой сотрудник не только
160 Глава 12 • Группы гибкого моделирования
снижает общую продуктивность вашей группы, но и является причиной того, что
кто-то выполняет лишнюю работу вместо него. Сотрудники, не участвующие в ра-
боте активно, являются балластом, тормозящим проект. Вам придется либо
заставить их работать, либо расстаться с ними — решайте сами. В мире полно ра-
боты, и лентяи никому не нужны. Как вы уже читали в главе 7, в гибком модели-
ровании есть несколько методик, направленных на активное сотрудничество.
Первая методика «Активное участие заинтересованных лиц» говорит о том, что
заинтересованные в проекте лица должны принимать активное участие в разра-
ботке ПО, помогая вам в работе. Далее, методика «Совместное владение» способ-
ствует устранению препятствий к сотрудничеству, то есть каждый работает над
тем, что нужно, артефакты принадлежат всей группе, а не человеку, их создавшему.
И третья методика «Моделируйте в группе» также способствует сотрудничеству,
так как любому может понадобиться помощь при моделировании.
Моделируйте в группе
Почему важно создать эффективную группу? Потому что моделированием лучше
всего заниматься в группе, а не по отдельности. Методика «Моделируйте в груп-
пе» как раз об этом и говорит. Однако данная методика не дает объяснений, как
добиться эффективной работы. Насколько велика должна быть группа? Кто дол-
жен в нее входить? Как обеспечить эффективность сеансов моделирования?
Существует несколько распространенных типов групп моделирования:
Разработка в паре. Многие группы гибкой разработки ПО практикуют рабо-
ту разработчиков в паре; на самом деле программирование в паре — это типичная
методика ХР (Бек, 2000), а это включает в себя и моделирование в паре. Обычно
вы с напарником по разработке (я предпочитаю говорить «разработка», потому
что вы занимаетесь не только программированием) обсуждаете идею или подход,
совместно работая над моделью, например рисуете на белой доске или создаете
карточки CRC. Подробное описание моделирования в группах ХР содержится
в третьей части этой книги.
Небольшие импровизированные группы. Импровизированная группа модели-
рования — это группа, образованная быстро (иногда за несколько секунд) для ре-
шения определенной задачи. Как только задача выполнена, группа так же быстро
распадается. Гибкие разработчики часто формируют небольшие импровизирован-
ные группы моделирования, обычно состоящие из 2-3 человек, когда понимают,
что им нужна помощь в решении текущей задачи — например, им нужно получить
у заинтересованных в проекте лиц дополнительную информацию о предметной
области или техническую помощь от другого разработчика. Импровизированную
группу легко собрать, когда вся группа сосредоточена в одном месте — если вы
знаете, кто именно вам нужен, вы просто подходите к нему и просите помочь, а ес-
ли не знаете, то просто кричите что-нибудь типа: «Эй, кто-нибудь что-нибудь зна-
ет об XYZ?» — может, вам повезет. Если же ваша группа рассредоточена, то им-
провизированную группу собрать сложнее — требуется больше времени, чтобы
Моделируйте в группе 161
выяснить, кто может вам помочь, да и работать с этими людьми будет сложнее, так
/как вам придется либо общаться с ними удаленно (по телефону или с помощью
e-mail, см. главу 8, чтобы выработать стратегию общения), либо придется ждать,
пока не появится возможность общаться с ними лично.
Сборная группа. Иногда вам приходится собирать группу людей, которые бу-
дут выполнять определенную задачу по моделированию. В начале проекта вы
(можете решить провести сеанс моделирования требований, на который вы при-
гласите группу пользователей. Их целью будет определение первоначальных
требований к системе и границ проекта. Для такой группы назначаются опреде-
ленные люди, которые выполняют задачу, затем группа распускается. Согласен,
некоторые пользователи могут принимать участие в' проекте на постоянной осно-
ве в роли «заказчика» или «представителя пользователя», но это отдельный слу-
чай. Типичный пример сборной группы — группа, занимающаяся архитектурой.
В малых проектах в эту группу входят все разработчики, в больших проектах —
часть разработчиков.
СОВЕТ: НЕ ПРЕНЕБРЕГАЙТЕ РАЗРАБОТКОЙ В ПАРЕ -----------------------------
Хотя сначала может показаться, что разработка в паре менее продуктивна, потому что двое
людей делают работу, которую мог бы выполнять один человек, на самом деле такой подход
вполне эффективен. Исследования показали, что результаты разработки в паре отличаются
большей устойчивостью, эффективностью и качеством; к тому же разработчики получают более
высокое удовлетворение от работы. По опыту могу утверждать, что разработка в паре вполне
себя оправдывает — я обнаружил, что если вы честно попробуете применять этот подход в
течение месяца (вначале многие отнесутся к этой затее скептически, что вполне естественно),
то большинство ваших сотрудников не захочет вернуться к обычному «одиночному» подходу.
ВНИМАНИЕ: ЧЛЕНЫ СБОРНОЙ ГРУППЫ МОДЕЛИРОВАНИЯ
ВЫПОЛНЯЮТ НЕ ТОЛЬКО МОДЕЛИРОВАНИЕ -------------------------------------
Я уже приводил доводы, почему наиболее продуктивно в группе разработчиков работают те,
кто может и хочет выполнять различные виды задач, одной из которых, скорее всего, является
моделирование. Вы можете являться членом сборной архитектурной группы, но это еще не
значит, что вы будете заниматься только моделированием архитектуры. В идеале вам придется
засучить рукава и заняться также написанием кода. Опасность состоит в том, что многие
разработчики предпочитают сосредоточиться на одной определенной специализации, приводя
в оправдание тот факт, что в сборной группе они выступают только в одной роли — например,
специалист по архитектуре или аналитик предметной области. Проблема в том, что такие люди
утрачивают связь с работой, которую выполняет остальная часть группы, тем самым давая
повод для разногласий внутри вашей группы ввиду отсутствия общего видения задачи.
Исходя из собственного опыта, я считаю, что небольшие группы (например,
пары разработчиков или маленькие импровизированные группы) выполняют
' большую часть моделирования в гибких проектах по разработке ПО. Если вы все
: взвесите, то придете к выводу, что это весьма практично — при итеративном и ин-
крементном подходах, обычно используемых группами гибкой разработки ПО,
моделирование в импровизированных группах оправдывает себя как нельзя луч-
ше. Далее, многие гибкие разработчики предпочитают моделировать в паре для
лучшей эффективности. Сборные группы моделирования также выполняют важ-
6 Зак. 926
г..
162 Глава 12 • Группы гибкого моделирования
ную работу, часто в начале проекта — например, сбор первоначальных требований,
создание первоначальной архитектуры или моделирование дизайна.
Как это осуществить?
Каждый раз, когда я предлагаю своим клиентам идеи, описанные в этой главе,
я слышу приблизительно такой ответ: «Звучит неплохо, но нам это не подходит,
потому что...» Ну что тут скажешь? Каждый считает, что его ситуация уникаль-
на (это действительно так — до известной степени), но на самом деле основные
моменты одинаковы для всех. В конце концов, все люди одинаковы в том смыс-
ле, что ничто человеческое им не чуждо. Конечно, отдельные люди имеют свои
сильные и слабые стороны, свои уникальные способности и навыки, свой опыт
и приоритеты. Всегда будут возникать какие-нибудь межличностные конфликты,
завязываться новые дружеские отношения и новые отношения будут строиться
на основе существующих — все это необходимо учитывать. Словом, если вы дей-
ствительно хотите создать эффективную группу, то вы ее создадите. Исходя из
собственного опыта, я могу дать несколько советов для организаций, желающих
создать эффективную группу:
Учитывайте важность активного участия заинтересованных лиц. Значение
этого условия невозможно переоценить — заинтересованные в проекте лица
должны сознавать, что от их активного участия во многом зависит успех проекта,
а разработчики должны понять, что им следует тесно сотрудничать с заинтересо-
ванными лицами.
Учитывайте важность работы в группе. Вы все вместе взялись выполнить эту
работу, вот и работайте вместе — так будет гораздо эффективнее.
Предлагайте людям попробовать новый подход. Всегда найдутся такие, кто
скажет, что новый подход (например, сотрудничество разработчиков и заинте-
ресованных лиц) не сработает. Часто они не примут ваши аргументы в защиту
нового подхода по той простой причине, что они вбили себе в голову, что он не
сработает. Если причина именно в этом, я обычно предлагаю им такой вариант:
они честно пытаются применить новый подход в течение определенного времени
(скажем, месяц или два), а я обещаю, что по истечении срока мы вернемся к этому
вопросу еще раз.
Пересмотрите состав вашей группы. Если кто-нибудь отказывается работать
так, как описано в этой главе, то один из вариантов — заменить этих людей. У не-
которых просто нет навыков или желания быть частью группы — они предпочи-
тают работать в одиночку и испытывать на себе все последствия такого решения,
которые непременно отразятся на их карьере.
Подчеркните необходимость освоения новых навыков. Стать универсалом,
да еще с несколькими специализациями, нелегко — на это нужны годы упорно-
го труда. Если вы еще не достигли такого уровня, значит ли это, что вы не можете
заниматься моделированием в гибком проекте? Конечно, можете. Вы не обязаны
Как это осуществить? 163
знать о разработке ПО абсолютно все, но вы должны стремиться к приобретению
новых навыков при любой возможности.
Создание эффективной группы — сложная задача, имеющая первостепен-
ную важность для проекта. Начните с «сырого материала» — наймите хороших
разработчиков, которые не знают всего на свете, но имеют желание развиваться.
Следующим шагом является формирование правильных отношений в группе —
чтобы добиться успеха, все члены группы должны работать вместе. Каждый дол-
жен принимать активное участие в разработке системы и заниматься моделиро-
ванием в группе, следуя одноименной методике гибкого моделирования. Чтобы
создать и обучить группу гибкого моделирования, требуется время, но это будет
лучшим капиталовложением в вашу организацию.
кек:
Сеансы гибкого
моделирования
Сеанс моделирования — такой вид деятельности, при котором несколько человек
занимаются разработкой одной или нескольких моделей. Сеансы моделирования
являются важной частью любой работы по созданию ПО, потому что во время них
людям предоставляется возможность сотрудничать с целью обсуждения проблем,
достижения взаимопонимания и принятия совместных решений. Обычно продук-
тивность сеансов моделирования либо очень велика, либо равна нулю. Из своего
опыта знаю, что для того, чтобы добиться успеха в гибком моделировании, вам не-
обходимо пересмотреть свой подход к сеансам моделирования и обратить внима-
ние на то, что получается, а также исключить то, что не выходит. Вам необходимо
учесть следующие моменты:
• продолжительность сеансов моделирования;
• типы сеансов моделирования;
• участники сеансов моделирования;
• формальность сеансов моделирования.
Продолжительность сеанса моделирования
Многим организациям следует пересмотреть количество времени, которое они
посвящают отдельным сеансам моделирования. Продолжительность эффективно-
го сеанса моделирования может быть различной: от нескольких минут до несколь-
ких дней. Большинство же сеансов длятся от десяти минут до получаса. Почему
сеансы настолько различны по- продолжительности? Для того чтобы ответить на
этот вопрос, сначала следует выяснить, на каких этапах работы проводятся сеан-
сы моделирования, ведь моделированием приходится заниматься в течение всего
процесса разработки. Вам необходимо понять, что на разных этапах жизненного
цикла проекта вы по-разному смотрите на проект. В начале жизненного цикла вы
Продолжительность сеанса моделирования 165
обычно сконцентрированы на понимании полной картины; в середине — на созда-
нии каких-то отдельных частей вашей системы, а в конце — на внедрении системы
в производство. Это изменение фокуса побуждает вас к проведению различных
. типов сеансов моделирования на разных этапах работы, включая различную про-
должительность этих сеансов.
Вероятнее всего, в начале жизненного цикла проекта вы будете проводить
длинные сеансы моделирования. На этом этапе работы существует потребность
определить цели проекта, первоначальные требования и варианты архитекту-
ры, основанной на этих требованиях. Вы обнаруживаете, что для достижения
этой цели нужны сеансы моделирования продолжительностью от нескольких
часов до нескольких дней, потому что в начале работы над проектом вам необ-
ходимо выяснить массу различных вещей. По своему опыту знаю, что сеансы
моделирования, длящиеся более чем два-три дня, подвергают ваш проект рис-
ку, так как чем дольше вы не получаете обратной связи, тем больше вероятность
того, что требования или архитектура не отражаются в процессе моделирова-
ния. Принцип AM «Быстрая обратная связь» требует от вас сокращения вре-
мени моделирования и проверки вашей модели либо посредством ее оценки со
стороны, либо — следуя методике «Подтверждайте модель кодом». Другая'про-
блема состоит в том, что моделирование может потребовать высокого умствен-
ного напряжения, и длинные сеансы моделирования приведут к утомлению и
снижению качества работы участников. Кроме того, участникам необходимо за-
ниматься своей повседневной работой, и они не могут уделять моделированию
более двух дней подряд.
Иногда вас вынуждают проводить длинные сеансы моделирования, мотиви-
руя это необходимостью выяснить требования как можно скорее. Но принцип
AM «Ожидайте изменений» говорит нам, что очень наивно ставить перед собой
подобную цель, потому что требования заинтересованных лиц будут изменяться
по мере развития системы. Другим распространенным аргументом в пользу про-
ведения более длинных сеансов моделирования является то, что представители
высшего руководства будут присутствовать на сеансе моделирования только один
раз, поэтому этим стоит воспользоваться. Обычно это объясняется тем, что не-
которым людям приходится, добираться издалека, чтобы принять участие в ва-
ших сеансах моделирования, или они слишком заняты на своей основной работе
и не могут присутствовать на нескольких сеансах подряд. Эту проблему, связан-
ную с удаленностью, можно решить, применяя альтернативные средства общения
'(например, проведение видеоконференции или переписка поуэлектронной почте),
> которые описаны в главе 8. Ссылка на занятость как оправдание для неучастия
является отвлекающим маневром. Гораздо легче выделить время для нескольких
коротких сеансов моделирования, чем для одного большого. Люди также будут
говорить о том, что организация сеанса моделирования — большая работа, и луч-
ше провести несколько продолжительных сеансов, чем много коротких. Я советую
вам умерить пыл, сделать сеансы менее официальными и, как следствие, не требу-
ющими больших усилий по организации.
Вероятнее всего, во время разработки вы будете проводить короткие сеансы
моделирования (обычно длящиеся 10-20 минут). В этот момент вы нацелены на
166 Глава 13 • Сеансы гибкого моделирования
реализацию конкретных требований, в идеале «маленьких порций требований».
Что является маленькой порцией требований? В проекте ХР (Бек, 2000) вы буде-
те реализовывать историю пользователя, в проекте Feature Driven Development
(FDD) (Коуд, Лефебр и ДеЛука, 1999) вы будете реализовывать какую-либо ха-
рактеристику, а в проекте Rational Unified Process (RUP) (Кратчен, 2000) — часть
элемента Use Case. Вы будете работать, постоянно возвращаясь к этому вопросу,
выясняя подходящие требования с заинтересованными лицами, возможно, созда-
вая основную модель UI или обсуждая логику бизнес-правила, а затем — пере-
ходя к обсуждению возможного решения для этих требований. Часто вы будете
рисовать схемы на белой доске для удобства обсуждения, а затем — кодировать
и тестировать то, что получилось. Гибкие разработчики быстро переходят от од-
ной итерации к другой, моделируя требования с заинтересованными лицами в те-
чение нескольких минут, а затем — моделируя вариант возможного их решения
(в идеале они делают это в группе, состоящей из пары-тройки разработчиков, сле-
дуя методике «Моделируйте в группе»). Если вы работаете над небольшими час-
тями требований и.применяете итерационный подход, вы вскоре обнаруживаете,
что коротких сеансов моделирования для этого достаточно.
Как сделать сеансы моделирования короткими? Во-первых, отдавайте пред-
почтение сеансам моделирования, во время которых участники будут стоять у бе-
лой доски или вокруг стола, так как большинство людей не любят стоять подолгу.
Во-вторых, возьмите себе за правило проводить короткие сеансы моделирования,
потому что когда сеансы затягиваются, люди начинают испытывать от этого не-
удобство. В-третьих, добивайтесь того, чтобы ваши сеансы моделирования были
посвящены одной теме. Именно поэтому лучше работать над небольшими частя-
ми требований. В-четвертых, принцип AM «Модель должна решать конкретную
задачу» советует нам прекращать моделировать, когда вы достигли поставленной
перед собой цели.
Типы сеансов моделирования
Успех гибкого моделирования частично зависит от типа сеанса моделирования,
проводимого вами. Я постоянно встречаюсь с одной и той же проблемой. Это так
называемый «сеанс моделирования одного артефакта». Эта проблема настолько
распространена, что я испытывал искушение описать его как антипаттерн про-
цесса (Браун, Маккормик и Томас, 2000). Наиболее распространенные примеры
сеанса моделирования одного артефакта включают сеанс моделирования элемен-
тов Use Case, сеанс моделирования данных и даже сеанс моделирования клас-
сов. Проблема в том, что работа по моделированию слишком узко направлена.
Хотя каждый из этих артефактов по-своему важен, все они недостаточно устой-
чивы для того, чтобы быть эффективными. Я был свидетелем сеансов моделиро-
вания, в результате которых создавались «раздутые» элементы Use Case, потому
что группа начинала записывать в них бизнес-правила, технические требования
и даже информацию об элементах предметной области, так как работа по моде-
лированию других артефактов не предусматривалась. Я также видел сеансы мо-
Типы сеансов моделирования 167
делирования, в результате которых получали замечательную модель данных, по
крайней мере, так казалось в начале, но впоследствии обнаруживалось, что она
требует значительного рефакторинга. Разработчики модели данных концентри-
ровались на проблемах, связанных с данными, и не рассматривали критического
поведения, потому что, по их мнению, об этом должны позаботиться прикладные
программисты. Также я видел сеансы моделирования классов, во время которых
создавались модели с ужасающей производительностью, потому что разработчи-
ки объектов не учитывали проблем, связанных с базой данных. Их методология
объектно-ориентированного анализа и дизайна (OOA&D) была основана только
на UML (промышленный стандарт), и в силу того, что UML не включает модель
данных, они не учитывали решающие проблемы дизайна. Кроме того, они счита-
ли, что администраторы данных сами займутся этими решающими проблемами
дизайна.
Почему же проводятся сеансы моделирования одного артефакта? Очень часто
они проводятся людьми, которые являются примерами антипаттерна «Разработ-
чик одного артефакта» (Амблер, 2001с). Такие разработчики сконцентрированы
на создании одного артефакта, например элементов Use Case, моделей данных или
классов. Естественно, если вы сконцентрированы на чем-то одном, вы проводи-
те сеансы моделирования, направленные на создание артефакта, который для вас
что-то значит. Это отношение явно противоречит принципам AM, которые гово-
рят о том, что вам нужно множество моделей в качестве ваших инструментов и
вам следует создавать несколько моделей параллельно.
Лучше проводить так называемые этапные сеансы моделирования. Этапные
сеансы моделирования — это такие сеансы, во время которых ваша работа направ-
лена на создание моделей, необходимых на основных этапах традиционной раз-
работки (создания требований, анализа, архитектуры и дизайна). Во время сеан-
са моделирования требований ваша работа будет направлена на выяснение того,
что хотят получить от вашей системы заинтересованные лица. Сеансы модели-
рования анализа направлены на конкретизацию требований; сеансы моделирова-
ния архитектуры — на определение стратегии построения системы, а сеансы мо-
делирования дизайна — на определение детальной стратегии для создания части
вашей системы. Во время каждого из этих сеансов ваша группа работает над со-
зданием нескольких моделей одновременно в соответствии с этапом. Например,
во время сеанса моделирования дизайна вы можете работать над созданием
UML-диаграммы классов, таблиц состояний в UML и физической модели дан-
ных. Обратите внимание на то, что группы, следующие процессу Rational Unified
Process (RUP), могут захотеть, чтобы эти сеансы моделирования рабочего процес-
са согласовывались с терминологией RUP.
А самый лучший подход к проведению сеансов моделирования — проводить
сеансы гибкого моделирования. Гибкая разработка ПО очень итеративна, осо-
бенно в повседневной работе, когда вы определяете требования, анализируете их
и предлагаете возможную стратегию дизайна за считанные минуты, а иногда даже
секунды. По своему опыту знаю, что именно так люди (и разработчики, и заинте-
ресованные лица) и работают. Например, когда заказчик говорит мне, что ему не-
обходимо фиксировать физический адрес покупателя, я сразу же начинаю думать
168 Глава 13 • Сеансы гибкого моделирования
об изменении параметров экрана, добавляю новый класс ПочтовыйАдрес, с которым
будет взаимодействовать класс Покупатель, а затем вношу изменения в базу данных
для поддержки этого нового требования. В течение нескольких секунд я перехожу
от требований к анализу и Дизайну. Что касается заинтересованных лиц, я часто
встречал среди них таких, которые не только выдвигали требования, но и предла-
гали стратегию выполнения этих требований. Квалифицированные пользовате-
ли, которые работают с системой и создают специальные отчеты по базе данных,
обычно имеют представление о том, как следует создавать систему. В таком случае
квалифицированные пользователи переходят от требований прямо к проектиро-
ванию. Конечно же, это не является задачей заинтересованных лиц — определить,
как будет создана ваша система. Это задача разработчиков (см. главу 9), поэтому
именно вам нужно решить этот вопрос в такой ситуации. Если люди действитель-
но работают таким образом, быстро переходя от одного этапа к другому, тогда не
имеет ли смысл отразить этот факт в вашем процессе разработки ПО? Вот имен-
но для этого стоит начать сеансы гибкого моделирования. В сеансах гибкого мо-
делирования вы применяете методики AM, а именно создаете несколько моделей
параллельно, применяете нужный артефакт (артефакты), как это и необходимо,
и переходите от одного артефакта к другому. Во время сеансов гибкого модели-
рования вы моделируете требования и дизайн, а также все остальное, когда вам
это нужно. Конечно же, вы по-прежнему хотите учитывать требования, анализ и
другие моменты, когда вы моделируете, но теперь вы будете переходить от одного
действия к другому.
Я советую вам не проводить сеансы моделирования одного артефакта даже
в том случае, если вы намереваетесь работать над созданием нескольких артефак-
тов сразу. Это может оказаться сложным в некоторых организациях, особенно в тех,
где в прошлом'применялись традиционные подходы, и поэтому они предрасполо-
жены к специализированной работе, например к сеансам моделирования данных.
Возможно, на эти организации оказала влияние маркетинговая политика, постро-
енная на элементах Use Case и доминирующая в объектно-ориентированных мето-
дах разработки в настоящий момент. Сеансы моделирования этапа рекомендуется
применять в начале проекта, когда определяются основные задачи (рамки проек-
та и какой должна быть архитектура). Сеансы моделирования этапа также умест-
ны, когда вы впервые внедряете методики гибкой разработки и ваша организация
с трудом принимает изменения, присущие этому процессу. В этом случае сеансы
моделирования этапа могут стать первой попыткой отойти от сеансов моделиро-
вания одного артефакта. Обычно сеанс гибкого моделирования — это короткий
сеанс моделирования в период конструирования. Для групп, имеющих опыт гиб-
кой разработки ПО, это могут быть длинные сеансы моделирования, обычные для
начала работы над проектом.
Участники сеансов моделирования
Кого следует привлечь к сеансам моделирования, чтобы добиться успеха?
Существуют два типа ролей в сеансах моделирования: активные участники и вспо-
Участники сеансов моделирования 169
могательные участники. Активные участники делятся на три основные группы:
заинтересованные в проекте лица, которые предоставляют информацию о роде
своей деятельности и помогают назначить приоритеты требований; аналитики,
которые специализируются непосредственно на работе с заинтересованными ли-
цами, чтобы выявить/собрать у них информацию, документировать и оценить эту
информацию; и разработчики, которые работают над моделями. Активные участ-
ники — участники № 1. Именно они выполняют работу по моделированию и име-
ют решающее значение для успеха проекта.
СОВЕТ: ПРЕИМУЩЕСТВА И НЕДОСТАТКИ
ПРИВЛЕЧЕНИЯ К РАБОТЕ АНАЛИТИКОВ --------------:-----------------------
Вы должны быть осторожны, привлекая к своему проекту аналитиков (иногда их называют
бизнес-аналитиками или аналитиками требований). Хотя они специализируются на работе
с заинтересованными в проекте лицами (что явно хорошо) и часто оказываются в роли
связующего звена между ними и ведущими разработчиками, которые иногда не обладают
необходимыми навыками общения, все же они иногда снижают продуктивность работы над
проектом. Когда бизнес-аналитик участвует в проекте, многие разработчики предпочитают
использовать его в качестве поддержки, позволяя ему направить усилия на общение с
заинтересованными в проекте лицами, тем самым освобождая себя и концентрируясь на
технологическом процессе. А вот это уже не очень хорошо. Вы хотите, чтобы разработчики
тесно сотрудничали с заинтересованными лицами и применяли свои технические навыки для
создания нужного ПО. В гибком моделировании аналитик может эффективно работать в двух
случаях. Первый: в ситуациях, когда разработчики сотрудничают с заинтересованными в
проекте лицами, аналитики могут способствовать взаимопониманию между ними и помогать
разработчикам в общении и моделировании. В то же время разработчики должны научить
аналитика технологии. Помните принцип AM «Учитесь друг у друга», чтобы добиться успеха в
работе. В этой ситуации вам нужно добиться того, чтобы ваши бизнес-аналитики как можно скорее
прекратили специализироваться только на сборе информации и начали полностью участвовать
в процессе разработки. Второй: когда ваша группа не может общаться с заинтересованными
лицами (что явно является серьезной проблемой и угрожает успеху проекта), аналитики
могут получать информацию от заинтересованных лиц и представлять эту информацию в том
виде, который необходим, разработчикам. Тем не менее, из-за отсутствия непосредственного
общения вы можете столкнуться со следующей проблемой: полученная информация может
быть искажена или неверно истолкована. Вспомните детскую игру «Испорченный телефон», в
которую вы наверняка играли, будучи ребенком. По правилам этой игры один из участников
шепчет на ухо другому какую-нибудь фразу, а потом она передается по очереди остальным
участникам до тех пор, пока ее не получит участник, придумавший ее. Чем больше людей
между отправителем и получателем, тем сильнее искажается фраза.
Вспомогательные участники выполняют три основные роли: координатор, сек-
ретарь и наблюдатель. Многие сеансы моделирования прекрасно проходят без их
участия, особенно короткие сеансы, которые проводятся разработчиками, модели-
рующими, чтобы понять какую-то часть дизайна системы, над которой они рабо-
тают. Однако же длинные сеансы моделирования, особенно на начальном этапе
проекта, требуют участия людей, выполняющих эти роли. Давайте рассмотрим
эти роли подробно.
Координатор. Координатор — это человек, который отвечает за планирование,
проведение и управление сеансами моделирования. Поэтому он должен обладать хо-
рошими навыками проведения собраний, понимать процесс моделирования, уметь
задавать толковые и грамотные вопросы для получения информации от активных
170 Глава 13 • Сеансы гибкого моделирования
участников. Роль координатора часто выполняет инструктор (роль в ХР) или руко-
водитель проекта. Обычно это опытный человек, который пользуется уважением
и доверием и имеет хорошие коммуникативные навыки и навыки моделирования.
Большие организации могут иметь профессиональных штатных координаторов, кото-
рые обычно проводят более официальные сеансы моделирования. Преимущество
профессиональных координаторов в том, что они выполняют свою работу очень
тщательно и хорошо. Главным их недостатком является то, что они больше подходят
для предопределенных процессов и им может потребоваться подготовка для работы
в гибком моделировании. Хотя для проведения коротких и неофициальных сеансов
моделирования координатор может и не понадобиться, все же может возникнуть не-
обходимость в ком-то, кто будет способствовать успеху проведения этих сеансов.
Секретарь. Секретарь — это человек, который отвечает за ведение записей
во время сеансов моделирования. Поэтому он должен уметь слушать и иметь хо-
рошие навыки общения, так как ему часто приходится задавать вопросы, что-
бы выяснить, что имеют в виду активные участники. Он должен разбираться
в бизнес-логике и технических деталях. Существуют два мнения по поводу того,
кого следует назначать на роль секретаря: профессионального секретаря или раз-
работчика. Я предпочитаю видеть в этой роли разработчика по двум причинам:
во-первых, это поможет разработчику развить свои коммуникативные навыки,
а во-вторых, я хочу быть уверенным в том, что секретарь, понимает, о чем идёт
речь. Чтобы выслушать пользователя, рассказывающего о том, чего он хочет от
системы (если вы думаете, что знаете это лучше него, то ошибаетесь) и как он ра-
ботает с вашим ПО, требуется терпение и время, поэтому роль секретаря, может
помочь разработчику научиться быть смиреннее. По справедливости следует пре-
доставить каждому члену вашей группы возможность улучшить свои навыки, по-
этому следует сделать эту роль переходящей и позволить каждому попробовать
себя в ней по очереди. Наконец, если вы хотите проводить сеансы моделирова-
ния с участием секретаря, вы можете решить просто записывать информацию обо
всех моделях, которые вы создаете. Тогда следует назначить двоих-троих людей
для ведения записей, так как никто не может записывать речь нескольких быстро
говорящих людей. Также в силу того, что у каждого человека свое неповторимое
восприятие, они будут записывать/пропускать различную информацию.
Наблюдатель. Обычно наблюдателем является человек, который присутству-
ет во время сеанса не для участия, а, наоборот, для наблюдения за тем, что про-
исходит, чтобы понять процесс. Возможно, им окажется будущий координатор
или человек, который будет участвовать в следующем проекте, где будет исполь-
зоваться этот же самый подход. Человек, который сидит и ничего не делает? Это
как-то не по-нашему. Гибким подходом привлечения наблюдателей к работе яв-
ляется их участие в сеансе в качестве активных участников (если они облада-
ют навыками моделирования и знаниями предметной области). На худой конец,
пусть они участвуют в роли секретаря. Цель наблюдателя — изучить процесс,
а лучший способ это сделать — в нем участвовать. Привлекая их к участию в се-
ансе моделирования, вы не только увеличиваете число людей, вносящих полез-
ный вклад в сеанс моделирования, но и расширяете их опыт. В общем, убиваете
двух зайцев сразу.
Формальность сеансов моделирования 171
Сколько человек должно участвовать в сеансе моделирования? Столько,
сколько нужно. Каждый из присутствующих должен иметь достаточно основа-
ний для участия. Это должна быть не просто политическая причина «Наталья
Петровна настаивает на том, чтобы .кто-нибудь из ее группы присутствовал».
Если Наталья Петровна присылает кого-нибудь на ваш сеанс, то этот человек
? должен быть готов работать и принимать участие в любой деятельности, необхо-
' димой во время сеанса моделирования. Например, получение дополнительной
информации или участие в последующей работе. Зачастую возникает весьма зна-
чительное давление по поводу участия в сеансе моделирования слишком большо-
го количества людей, особенно в начале проекта. Противостоять этому давлению
трудно. Я очень часто провожу большие сеансы по сбору требований в начале
. проекта, на которых присутствует очень много людей (обычно 20-30 человек).
Хотя иногда в некоторых ситуациях у вас может быть и несколько сотен человек
, просто для того, чтобы все знали, что их голос слышат, и чтобы помочь заинтере-
сованным лицам определиться с требованиями, что тоже неплохо. Я поступаю
так же, когда дело доходит до архитектуры, и привлекаю много техников со всей
организации. Но если вы обычно работаете с группами, состоящими из 7-8 чело-
век, то понимаете, что при большем количестве участников коэффициент отдачи
уменьшится. Уменьшится и вероятность того, что новые участники сообщат
группе какую-то новую информацию, так как вы и так уже тщательно отобрали
участников. Также многие не смогут получить возможность принимать активное
участие, так как «эфирное время» будет поделено между большим количеством
участников. Наконец, чем больше людей участвует в сеансе моделирования, тем
официальнее он должен проводиться, так как иначе становится невозможно
управлять работой.
Формальность сеансов моделирования
Первое и главное — не стоит думать, что приобретая более официальный харак-
тер, сеансы моделирования утрачивают свою гибкость. Конечно, формальность
имеет дурную репутацию среди разработчиков, но это вовсе не значит, что офи-
циальные сеансы не могут быть эффективными. С одной стороны, вы можете
проводить очень официальные сеансы моделирования. Например, сеансы сов-
местной разработки приложений (JAD) (Вуд и Силвер, 1995). Обычно сеансы
JAD являются тщательно скоординированными и структурированными собра-
ниями с четко распределенными ролями (координатор, участник, секретарь и на-
блюдатель), определенными правилами поведения (включая регламент выступ-
лений) и определенными требованиями к помещению для проведения сеанса
(чаще всего для этого необходим стол в виде буквы П). Перед сеансом JAD вы
обычно сообщаете повестку дня и рассылаете информационный пакет, с содер-
жанием которого должен ознакомиться каждый из участников. Ведутся прото-
колы официальных собраний, которые после сеанса раздаются его участникам,
включая список действий, определенных сеансом JAD, за выполнением которых
следит координатор. Полной противоположностью такого типа собраний явля-
172 Глава 13 • Сеансы гибкого моделирования
ются импровизированные/незапланированные сеансы моделирования, во время
которых участникам даже не предлагают присесть, и причиной для их проведе-
ния является зачастую понимание того, что вам необходима помощь. Участники
быстро собираются (будем надеяться, что нужные участники окажутся на месте),
вы совместно работаете, стоя вокруг белой доски, и, когда задача выполнена; все
быстро расходятся.
Формальность сеансов моделирования находится где-то посередине между
двумя этими крайностями. На самом деле сеансы JAD сейчас носят менее офи-
циальный характер. Таблица 13.1 показывает, в каком случае следует применять
различные стоили сеансов моделирования. На самом деле вам самим придется ре-
шать, насколько формальными будут ваши сеансы, потому что чаще всего усло-
вия проведения вашего сеанса будут находиться где-то между этими крайностями.
Например, насколько формальным должен быть сеанс моделирования с участи-
ем десяти человек, рассчитанный на полдня, во время которого все десять чело-
век будут работать в одном месте и о котором будет объявлено за два дня до про-
ведения? А как насчет сеанса моделирования, в котором участвуют пять человек,
двое из которых должны будут прилететь на него из другого города? Ответ бу-
дет одинаковым в обоих случаях: настолько формальными, насколько необходи-
мо. Чем формальнее сеанс моделирования, тем больше работы потребуется про-
делать для его проведения, а согласно принципу «Повышайте отдачу от ресурсов,
полученных от заинтересованных лиц», работа должна приносить пользу проекту.
Сообщите участникам повестку дня, если это поможет им подготовиться к сеансу.
Не забудьте о том, что она должна быть достаточно простой — обычное письмо по
электронной почте. Разошлите им протоколы, если это уместно. Протоколы тоже
должны быть достаточно простыми: просто список действий, которые предпола-
гается выполнить участникам, и URL, указывающий на адрес веб-страницы, где
вы разместили диаграммы, созданные во время сеансов моделирования.
Таблица 13.1. Стили сеансов моделирования в зависимости от условий их проведения
Стиль сеанса моделирования Условия проведения
1 2
Официальный (например, традиционный сеанс JAD) • Большие группы (более восьми участников) • Длинные сеансы моделирования (обычно более одного дня) • Участники из разных городов
• Участники из разных организаций или разных
организационных сфер
• Возможен профессиональный координатор
• Есть возможность увеличения времени
проекта для проведения официальных сеансов
моделирования
• Требования руководства о проведении .
официальных сеансов (попытайтесь устранить
эти требования путем переговоров)
Как это осуществить? 173
1 2
Неофициальные (например, незапланированные) • Маленькие, территориально находящиеся близко группы • Людям легко собраться вместе; они готовы и способны участвовать • Короткие сеансы моделирования (обычно менее часа) • Время — деньги. Вот решающий фактор в вашем проекте
Методика AM «Создавайте простое содержание» распространяется как на мо-
дели, так и на стиль управления.
СОВЕТ: ОФИЦИАЛЬНЫЕ СЕАНСЫ ВСЕ ЖЕ МОГУТ БЫТЬ ГИБКИМИ -------------------
В формальности нет ничего плохого, если применять ее в Нужных ситуациях. В конце
концов, для выполнения определенной задачи нужно найти верный способ, и очень часто
официальные сеансы моделирования являются лучшим решением (хотя я сам уже много лет
в них не участвовал).
Как это осуществить?
Существует две типичные проблемы, связанные с сеансами моделирования:
1. Сеансы моделирования вообще не проводятся. В некоторых организаци-
ях сеансы моделирования вообще не являются частью работы по разработке
ПО. В них либо нет людей, умеющих моделировать, либо разработчики не
желают этого делать, либо заинтересованные лица не желают тратить вре-
мя на участие в сеансах моделирования, либо организация раньше никогда
не участвовала в проектах по разработке ПО. Первым делом следует опре-
, делить причину, а потом взяться за ее устранение. Если у вас в штате нет ни
одного человека, умеющего моделировать, ваши работники должны пройти
соответствующий курс обучения. Возможно, вам следует пригласить на ра-
боту человека, обладающего этими умениями. Если разработчики или заин-
тересованные лица не желают участвовать в сеансах моделирования, необ-
ходимо провести разъяснительную работу.
2. Сеансы моделирования неэффективны. Эта очень распространенная про-
блема, возникающая тогда, когда в организации проводится слишком много
сеансов моделирования, они слишком длинные, на них присутствует слиш-
ком много людей или они слишком официальны. Прежде всего эти органи-
зации должны признать, что у них имеются проблемы, но также есть реаль-
ные альтернативы существующему подходу. Следующим шаг — определить
проблему и начать ее решать, следуя советам, приведенным в этой главе.
Очень часто это может стать политической проблемой, которую не любят
решать неквалифицированные менеджеры. По моему мнению; вам следует
принять решение: выбираете ли вы гибкий подход к разработке или нет? Если
174 Глава 13 • Сеансы гибкого моделирования
/
вы выбираете гибкий подход, то будьте готовы к небольшим конфликтам,
так как многие люди, не являющиеся членами вашей группы, думают и ра-
ботают отнюдь не в гибкой манере, что противоречит вашим целям и под-
ходам. В главе 29 я описываю методики преодоления сложностей, возника-
ющих при внедрении AM в вашей организации. Одно из лучших решений,
доступных вам в такой ситуации, — сохранять твердость в вашем намере-
нии быть гибкими.
Советы, представленные в этой части, продиктованы здравым смыслом. При-
менять эти методики вполне возможно — тысячи групп проводят эффективные се-
ансы моделирования каждый день. Вы просто должны сделать свой выбор и быть
одной из них.
Гибкая
документация
Оставляющий после себя письменное наставле-
ние, равно как и читающий его, в уверенности,
что оно окажется понятным и недвусмысленным,
должен быть чрезвычайно глуп.
Платон
Начиная работу на!д данной книгой, я собирался сосредоточиться исключительно
на принципах и методиках эффективного моделирования, но вскоре обнаружил,
что этого явно недостаточно. Следовало также выяснить, как добиться эффектив-
ности в создании документации и дальнейшей работе с ней. Какие-то модели со
временем превратятся в официальную документацию по системе, а какие-то (при-
чем большинство из них) — нет, следовательно, необходимо обсудить, как сохра-
нить при этом гибкость.
Для начала давайте разберемся с отношениями между моделями, документами,
исходным кодом и документацией (см. рис. 14.1). С точки зрения AM, по отноше-
нию к исходному коду документ является внешним артефактом, цель которого —
передавать информацию неким устойчивым способом. Это отличается от понятия
модели, которая является абстракцией, описывающей один или более аспектов
проблемы или ее потенциального решения. Некоторые модели станут докумен-
тами или их частью, а некоторые будут отброшены сразу после того, как они вы-
полнят свою задачу. Одни модели послужат основой для разработки исходного
кода, а другие — основой для разработки других моделей. Исходный код являет-
ся последовательностью команд для компьютерной системы, включая коммента-
рии к этим командам. Исходный код — это явная абстракция (хотя и довольно
сложно организованная), но с точки зрения AM исходный код не будет считаться
моделью, так как я хочу разделить эти два понятия. Далее давайте для удобства
обсуждения договоримся, что термин «документация» может означать как доку-
мент, так и комментарий к исходному коду.
В данной главе мы рассмотрим следующие вопросы:
• Зачем нужна документация?
• Когда модель становится документом?
176 Глава 14 • Гибкая документация
• Компромиссы, связанные с созданием документации.
• Что значит путешествовать налегке?
• Какой документ является гибким?
• Какая документация вам нужна?
• Эффективная передача документации.
• Методы повышения гибкости документации.
Рис. 14.1. Отношения между моделями, документами и исходным кодом
Зачем нужна документация?
Гибкие разработчики признают, что документация является неотъемлемой час-
тью любой системы, создание и ведение которой — сущее наказание для одних
и приятное занятие для других. В любом случае к этому аспекту разработки ПО
тоже можно применить гибкий подход, если вы захотите. Вот четыре веских при-
чины для создания документации:
1. Заинтересованные в проекте лица требуют документацию. Создание до-
кументации является чисто деловым решением, а не техническим. Вы вкла-
дываете средства заинтересованных лиц в разработку документаций, таким
образом, последнее слово остается за ними — хотят ли они, чтобы их деньги
были потрачены таким образом. Если заинтересованные лица хотят полу-
чить документацию (возможно, вы сами это им предложили) и понимают
связанные с этим затраты (подробнее об этом позже), то вам следует занять-
ся созданием документации. Важно отметить, что ХР четко определяет со-
здание документации как бизнес-решение (Джеффрис, 2001b), a UP (уни-
Зачем нужна документация? 177
фицированный процесс) не разделяет эту точку зрения, которую группам
UP все же следует принять, если они хотят эффективно применять гибкое
моделирование.
Получается, что вы должны создавать документацию только в том случае,
если того хотят заинтересованные в проекте лица? «Ерунда!» — скажете
вы. Позволю себе с вами не согласиться. В число заинтересованных лиц
входят разные люди, и в том числе те, кто будет так или иначе исполь-
зовать вашу систему, поэтому обычно они хорошо знают, что им нужно,
а что нет. Разработчики группы сопровождения или их представители
захотят иметь обзорную документацию по системе. Пользователи и их
руководство наверняка захотят иметь пользовательскую документацию.
Операторы потребуют документацию по эксплуатации. Да, вам придется
тесно сотрудничать с ними, чтобы выяснить, что им нужно на самом деле.
Кому-то придется решить, стоит ли выделить средства на создание и веде-
ние документации.
2. Вам нужно определить модель соглашения. Модели соглашения опре-
деляют, каким образом ваша система будет взаимодействовать с внешней
системой. Одни взаимодействия будут двусторонними, другие — односто-
ронними и очевидными для всех участников. Модель соглашения часто
необходима в тех случаях, когда внешняя группа контролирует информа-
ционные ресурсы, требующиеся вашей системе, например базу данных, на-
следуемое приложение или информационную службу. Согласно методике
AM «Формализуйте модели соглашения», модель соглашения — это то, на
что обе стороны соглашаются, документируют это и вносят изменения при
необходимости. Важно понять, что разработка модели соглашения зависит
от заинтересованных лиц — они за это платят, значит, им и решать, хотят ли
они пойти на риск и обойтись без модели соглашения.
3. Вам нужно поддерживать связь с внешней группой. Не всегда можно со-
средоточить группу разработчиков в одном месте и не всегда можно свобод-
. но общаться с заинтересованными лицами. Если вы работаете с удаленной
группой, то вам придется найти способ общения с ней. Один из вариантов —
это обмен документацией наряду с личным общением от случая к случаю,
телеконференциями, перепиской по электронной почте и средствами для
совместной работы. Однако использование документации в качестве основ-
ного способа общения будет ошибкой, так как письменный документ лег-
ко может получить неверное истолкование. Но его можно использовать как
вспомогательное средство. Лучше всего принять такую точку зрения: до-
кументация может быть средством общения только в крайнем случае, если
ничего другого не остается. На самом деле это можно рассматривать как
продолжение методики «Моделируйте, чтобы общаться» применительно к
документации.
4. Вам нужно что-то обдумать. Многие пишут документацию для того, что-
бы подтвердить работу, выполненную группой, или чтобы лучше понять
что-либо. Это продолжение методики «Моделируйте, чтобы понять» приме-
178 Глава 14 • Гибкая документация
нительно к документации1. Сам факт выражения ваших мыслей в письмен-
ной форме может помочь вам придать им законченный вид и выявить все
ошибки. То, что кажется простым и понятным, когда вы об этом думаете, мо-
жет оказаться весьма сложным при попытке подробно это описать, так что
чем раньше вы попытаетесь записать свою идею, тем лучшее развитие она по-
лучит. Именно поэтому я советую писать сначала комментарий, а уже потом
собственно код (Амблер, 2001а). Я следую этому правилу уже не один год.
Вы наверняка привыкли работать по-другому, и это следует учесть — именно
поэтому я говорю о том, как применять более гибкий подход к документации. В чем
разница между нашими подходами и почему мой подход является более гибким?
Я зйаю, что в негибкой среде разработчикам приходится создавать документацию
по весьма неубедительным причинам. Иногда этого требует внутренняя политика
организации, а иногда это делается просто по причине невежества. В таких случа-
ях разработчики просто не могут эффективно работать. Вот несколько неубеди-
тельных причин для создания документации и способы борьбы с ними:
Лицо, требующее документацию, хочет показать, что оно контролирует си-
туацию (хотя на самом деле не делает ничего полезного). Люди часто требуют
документацию (например, спецификации или подробную документацию по архи-
тектуре), на которой они могут поставить подпись и сказать: «Да, это то, что мне
нужно, приступайте к работе». В такой ситуации я обычно спрашиваю: «Примете
ли вы на себя ответственность за провал проекта, так как группа разработчиков
будет слишком занята созданием документации вместо того, чтобы создавать про-
граммное обеспечение?» Затем я предлагаю ознакомиться с собственно ПО (даже
если это только тестовая версия), чтобы этот человек мог внести конструктивные
замечания (дать обратную связь). Таким образом, этот человек примет'активное
участие в проекте, причем довольно продуктивным способом.
Тот, кто требует документацию, пытается показать, что он не напрасно си-
дит на своем месте. Это обычно происходит, когда тот, кто на самом деле является
«балластом», отчаянно хочет сделать вид, что он делает нечто полезное. Это весьма
порочная практика, так как обычно для этого находится веская (на первый взгляд)
причина; в конце концов, такие люди всегда требуют документацию, и руковод-
ство обычно считает, что она действительно необходима. Если вы с этим столкну-
лись, спросите,, что он собирается делать с документацией, зачем она ему нужна,,
почему создание документации для него важнее, чем остальная работа, которую
выполняет группа, и т. д. — попытайтесь выяснить, будет ли от этого какая-нибудь
польза. Имейте в виду, что перечисленные вопросы могут вызвать недовольство у
тех, кто на самом деле не вносит реально полезного вклада в разработку.
Человеку, требующему документацию, просто больше ничего не приходит
в голову. Многие работают в организациях, которые долгое время следовали не-
гибким процессам, сосредоточенным вокруг документации, в ходе которых снача-
1 Хотя я немного схитрил и применил методики «Моделируйте, чтобы общаться» и «Моделируй-
те, чтобы понять» к созданию документации, все же хочу отметить, что когда речь идет об AM, понятия
«модель» и «документ» являются ортогональными. Прощу прощения, если я вас немного запутал, но,
к сожалению, в жизни вообще все не так просто.
Зачем нужна документация? 179
ла создавалась и рецензировалась кипа документации, и только потом собствен-
но ПО. Такие люди требуют у вас документацию просто потому, что они к этому
привыкли. Им даже в голову не приходит, что ПО можно получить уже на ранних
стадиях проекта.
Создание документации обусловлено процессом. Это не относится к гиб-
ким процессам разработки ПО, но несомненно является частью предопределен-
ного процесса. Причина этой проблемы кроется в людях, которые ищут оправ-
дания собственному существованию, которые не понимают процесса разработки
ПО и даже причин, по которым они требуют документацию, а также в ситуациях,
где целью является не эффективная разработка ПО, а выставление счетов за поча-
совую оплату. Лучший способ решения проблемы — выяснить, действительно ли
создание документации будет стоить потраченных усилий.
Кто-нибудь желает убедйться, что все идет по плану. Заинтересованные лица
вкладывают значительные ресурсы в вашу группу, они делают на вас ставку, по-
этому они хотят убедиться в том, что их деньги потрачены не напрасно. Для этого
они просят вас предоставить им документацию,, например отчет о состоянии дел
или обзор проекта, не понимая того, что это отдаляет вас от истинной цели — раз-
работки ПО. Люди просто не понимают, что лучше будет оценить само ПО, неже-
ли его описание (как я уже говорил, им это и в, голову не приходит). Вам следует
научиться различать, в каких случаях заинтересованные лица действительно хо-
тят убедиться, что все идет нормально (это естественно в начале работы над про-
ектом, если они еще не вполне доверяют вашей группе), и найти альтернативный
способ убедить их в этом (может быть, вы покажете им работающее программное
обеспечение?).
Вы работаете вместе с удаленной группой. Хотя в первой главе я писал, что
в этом случае методы AM не действуют, все же это часто служит оправданием для
создания объемной документации. Документация — это один из способов обще-
ния, хотя и не самый лучший (см. главу 8). Попробуйте найти другой подход, на-
пример, встречайтесь с другой группой, если есть такая возможность, или исполь-
зуйте средства для совместной работы. Таким образом, вы будете меньше зависеть
от документации.
Ваш договор может быть передан другому исполнителю на конкурсной ос-
нове. Это довольно распространенная практика в организациях, выполняющих
правительственные заказы, хотя коммерческие организации также часто угрожа-
ют подрядчикам тем, что передадут контракт другой группе, если их группа не
справится с задачей. Ну и что? Если вы взялись за разработку программного обес-
печения, так и сосредоточьтесь на этом, и контракт останется за вами. Обычно
в такой ситуации прямой заказчик руководствуется заблуждением, что если вы
не выполните задачу, то можно передать созданную вами документацию друго-
му подрядчику, который продолжит работу. Это весьма пагубное заблуждение.
Если вы настолько плохо работаете, что теряете контракт, то наверняка созданная
вами документация тоже никуда не годится, так что вашему преемнику придется
её переработать. Даже если вы написали безупречную Документацию (но все же
потеряли контракт), то в группе другого подрядчика наверняка будут люди с дру-
гими навыками, да и требования к тому времени придется пересмотреть. В общем,
180 Глава 14 • Гибкая документация
неважно, как вы лично относитесь к подобной ситуации, но ваш преемник вряд ли
сможет воспользоваться созданной вами документацией.
Когда модель становится постоянной?
На первый взгляд, жизненный цикл гибкой модели довольно прост. Рисунок 14.2
показывает высокоуровневую UML-диаграмму состояний для моделей. Модель
начинается с фразы типа «Нам нужно разобраться, как мы будем это делать», или
«Как это должно работать с точки зрения пользователя?», или «Нам нужно пока-
зать, что мы собираемся представить в итоге». Эти вопросы и проблемы могут стать
моделями, а могут быть отброшены. (Для удобства обсуждения давайте считать,
что если вопрос, проблема или идея не превращаются в модель, то они отброше-
ны.) При появлении на свет модель имеет статус «временной», от которой вы из-
бавитесь, как только она выполнит свое назначение — обычная судьба большинс-
тва моделей, созданных гибкими разработчиками. Часто эти модели представляют
собой грубо нарисованные от руки схемы, возникшие в соответствии с методи-
кой «Моделируйте, чтобы понять», хотд модели, созданные в соответствии с ме-
тодикой «Моделируйте, чтобы общаться», тоже часто выбрасываются сразу после
того, как информация получена адресатом. Вы создаете временные модели, рабо-
таете над ними, совершенствуете их по мере надобности, а потом избавляетесь от
них. Это нормально. Большинство гибких моделей создается двумя-тремя людь-
ми за пару минут просто для удобства обсуждения, хотя некоторые модели со-
здаются при участии значительного количества людей на сеансе моделирования,
длящемся несколько часов. На рис. 14.2 показана любопытная эволюция, которую
претерпевает временная модель, становясь постоянной (например, если вы реши-
ли сделать ее частью официальной проектной документации). Временная модель
становится постоянной при следующих условиях:
• имеется веская причина для того, чтобы сделать модель постоянной;
• модель может быть полезна для определенного круга лиц;
• заинтересованные лица хотят, чтобы модель стала частью проектной доку-
ментации.
Присвоить
статус временной Версия
Рис. 14.2. Диаграмма состояний UML, изображающая жизненный цикл гибкой модели
Когда модель становится постоянной? 181
ПРИМЕЧАНИЕ: МОДЕЛЬ НЕ ОБЯЗАТЕЛЬНО ЯВЛЯЕТСЯ ДОКУМЕНТОМ ----------------—
Основная идея рис. 14.2 состоит в том, что модель не всегда является документом. Большинство
моделей являются временными по своей природе. Например, я не считаю моделью инструкцию
по эксплуатации для пользователя. Это важное различие, хотя многие думают иначе. Некоторые
люди понимают слово «модель» как «документ» со всеми присущими ему отрицательными
ассоциациями (хотя иногда бывают и положительные). А теперь все дружно повторяйте
за мной: модель не обязательно является документом, модель не обязательно является
документом, модель не обязательно является документом. Я бы даже сказал, что понятия
«модель» и «документ» являются ортогональными, поскольку одно вполне может существовать
без другого. Если вы примете эту идею, то это будет важным шагом на пути к гибкости.
Пункты № 1 и № 2 обусловлены принципом «Модель должна решать конкрет-
ную задачу». Если вы создаете модель, то для этого должна быть веская причина,
и это еще не все — документация также должна создаваться с определенной целью.
Вы должны знать, для кого предназначена эта документация (это может быть под-
разделение вашей группы разработчиков, ваши пользователи или группа (груп-
пы), которая будет сопровождать и эксплуатировать вашу систему), и что им нуж-
но от документации. Главная идея состоит в том, что создание и сопровождение
документации ложится тяжким бременем на вашу группу разработчиков, так что
для этого должны иметься веские причины. Все очень просто. Документация —
это тяжкое бремя, и когда люди это осознают, они начинают относиться к ней
по-другому. Проблемы, связанные с документацией, часто недооцениваются, од-
нако ее создание не только поглощает ресурсы (а значит, и бюджет) проекта, но
еще и отрицательно сказывается на состоянии духа разработчиков. Мало кто лю-
бит писать документацию, а особенно, — никому не нужную документацию.
Согласен, хорошая документация может оказаться полезной как для вашей груп-
пы разработчиков, так и для заинтересованных лиц, но не забывайте о принципе
«Повышайте отдачу от ресурсов, полученных от заинтересованных лиц», который
означает, что всякие затраты должны быть оправданы. Важно отметить, что иног-
да выгоду получает совсем не тот, кто вложил средства. Например, ваша группа
разработчиков создает системную документацию и несет все связанные с этим из-
держки, а пользу от этого получает ваша группа сопровождения. Смысл этого при-
мера в том, что при оценке плюсов и минусов создания документации следует рас-
сматривать общую картину. Подробнее об этом читайте в разделе «Компромиссы,
связанные с документацией». Пункт •№ 3 также обусловлен принципом «Повы-
шайте отдачу от ресурсов, полученных от заинтересованных лиц», и тем фактом,
что если ваш проект финансируется некими заинтересованными лицами, значит,
им и решать, как потратить свои средства.
Согласно рис. 14.2, вы можете изменить свое решение сделать модель посто-
янной. Часто это происходит, когда вы понимаете, что польза от этой модели не
оправдывает расходов, связанных с ее хранением. В этом случае вы либо избав-
ляетесь от нее немедленно, либо перестаете ее совершенствовать и она быстро
устаревает. Хотя иногда эти модели могут вновь понадобиться группе разработ-
ки или группе сопровождения, например, если система переделывается. Тогда мо-
дель пересматривается и, естественно, признается безнадежно устаревшей, так что
ее либо выбрасывают, либо используют в качестве шаблона для создания новой
версии модели. Как правило, новая версия модели гораздо стройнее предыдущей,
182 Глава 14 • Гибкая документация
потому что если первоначальная версия модели не приносила пользы, то от новой
версии, созданной по тому же принципу, также не будет особой пользы. Такие пре-
образования описаны в разделе «Методы повышения гибкости документации».
ПРИМЕЧАНИЕ: ВРЕМЕННАЯ МОДЕЛЬ МОЖЕТ ОКАЗАТЬСЯ ЖИЗНЕСПОСОБНОЙ —
Если модель является временной, это еще не значит, что вы немедленно от нее избавитесь.
Временные модели (на самом деле любые модели) должны выбрасываться тогда, когда они
больше не нужны. Многие модели выбрасываются почти сразу после создания — вы просто
стираете их с белой доски, где они были нарисованы. Другие модели живут гораздо дольше,
а иногда еще и развиваются за время своего существования. Например, группа разработчиков
рисует диаграмму архитектуры системы и оставляет ее на белой доске в течение нескольких
недель, внося изменения по мере того, как начинает лучше понимать архитектуру системы.
Многие модели являются временными по двум причинам. Во-первых, если мо-
дель выполнила свое назначение и больше не нужна, то от нее следует избавить-
ся, чтобы не обременять себя ее хранением. Помните о том, что путешествовать
нужно налегке. Во-вторых, многие модели превращаются в другие артефакты, на-
пример в другую модель, исходный код или контрольные примеры. При этом пер-
воначальная модель уже не нужна — тогда зачем ее хранить? Однако если перво-
начальная модель не вполне заменяется другим артефактом, вы можете решить
сохранить ее. Например, UML-диаграмма классов уступила место исходному
коду на Java, но вы решили сохранить диаграмму, чтобы в случае необходимости
можно было пересмотреть код. В этом случае диаграмма классов не уступает мес-
то другому артефакту полностью.
Компромиссы, связанные с документацией
Гибкие разработчики признают, что эффективная документация — это минималь-
но необходимое количество документации, предоставленное в нужное время нуж-
ному читателю. Чтобы понять, как это получается, давайте рассмотрим следую-
щие вопросы:
Разработка программного обеспечения или создание документации. Вот
главный вопрос, который нужно решить, потому что любое время, потраченное
на создание документации, — это время, отнятое от разработки ПО, которое нуж-
но вашим пользователям. Одна крайность — это проект, где вообще никакой до-
кументации не создается, другая крайность — проект, где не создается ПО. Вряд
ли вас устраивает один из этих вариантов. Помните о том, что ваша главная цель —
создание программного обеспечения. Вам нужно обеспечить поддержку деловой
активности ваших пользователей, вам нужно приносить доход своей организации,
вам нужно получать обратную связь, вам нужно доказать пользователю, что вы
можете выполнить свою задачу, но при этом не забывайте, что ваша следующая
цель — продолжать проект.
Разработчики умеют разрабатывать программное обеспечение, писатели
технической литературы умеют писать документацию. Нравится вам это или нет,
но мало кто из технических работников обладает хорошими навыками письмен-
ной речи по той простой причине, что они не потрудились их приобрести. Лучше
всего с созданием документации справится тот, кто понимает то, о чем нужно
Когда модель становится постоянной? 183
писать, в данном случае это будет разработчик системы. Многие группы просто
передают систему или ее часть писателю технической литературы и просят его
самостоятельно разобраться с системой и сделать ее описание. Это избавляет раз-
работчиков от необходимости прилагать какие-либо усилия со своей стороны, но
прибавляет работы писателю и увеличивает вероятность получения неэффектив-
ной документации. Лучше будет, если разработчик напишет «подстрочник», а пи-
сатель сделает его удобочитаемым. Это более эффективно, но имеет один недоста-
ток: разработчик часто не знает, с чего начать или вообще о чем писать. И, наконец,
третий способ, самый лучший: разработчик и писатель создают документацию
вместе1 и учатся друг у друга.
Подход к документации будет различным во время разработки и во время
пост-разработки. Для удобства обсуждения давайте называть пост-разработкой
периоды, когда происходит переход от версии к продукту и когда продукт за-
пускается в производство, то есть этапы «Переход» и «Производство» корпора-
тивного унифицированного процесса EUP (Амблер и Константайн, 2002). Во
время разработки вы изучаете проблему и варианты ее решения, пытаясь по-
нять, что именно вам нужно создать и как все это будет взаимодействовать. Во
время пост-разработки вы разбираетесь, что именно вы создали, почему это сде-
лано именно таким образом и как с этим работать. Соответственно, во время
разработки вас вполне устраивают грубые схемы и наброски, не обладающие вы-
сокой устойчивостью (в конце концов, это просто рабочий материал), а во вре-
мя пост-разработки требуется более официальная документация. Далее, во время
разработки документация нужна вам гораздо меньше (вы ведь путешествуете на-
легке), чем во время пост-разработки.
Желание писать документацию и желание ее читать. Как часто вам задавали
какой-либо вопрос, связанный с ПО, хотя ясный ответ на этот вопрос содержался
в документации, лежащей на столе у человека, задавшего этот вопрос? Постоянно.
Обычный ответ на такой вопрос в электронной почте — «RTFM» («Читай инс-
трукцию по эксплуатации»). Короче, если вы напишете документацию, это еще не
значит, что кто-нибудь будет ее читать, — зачем тогда ее писать?
Вы создаете документацию в процессе разработки или после ее окончания?
Первая крайность — создавать документацию параллельно с разработкой ПО.
При этом вы фиксируете важную информацию по мере развития проекта, но вмес-
те с развитием программного обеспечения документацию придется переработать.
Такой подход не только замедляет процесс разработки, но и приводит к напрасной
трате сил — завтра вам придется переработать или вообще выбросить ту докумен-
тацию, что вы написали сегодня. Получается, что вы уже не путешествуете налег-
ке. Если требования не определены окончательно, и вы применяете итеративный
подход к разработке, то ведение обширной документации становится все более об-
ременительным, потому что вам постоянно приходится вносить в нее изменения
по мере развития проекта. Другая крайность — начать создавать документацию
только после окончания разработки. Главное преимущество этого подхода состо-
1 Я не стал вводить термин «создание документации в паре» (по аналогии с методикой ХР «Про-
граммирование в паре»), но если этот термин вам понравился — не стесняйтесь, можете его исполь-
зовать.
184 Глава 14 • Гибкая документация
ит в том, что вы описываете нечто стабильное и законченное (версию только что
разработанного ПО). Однако такой подход имеет несколько существенных недо-
статков. Вы наверняка уже забыли причины, по которым были приняты те или
иные решения; из проекта уже ушли люди, которые могли написать документа-
цию; у вас закончились фонды или пропало всякое желание писать документа-
цию. Золотая середина — записывать важные решения, принятые в процессе раз-
работки (обычно это можно сделать в исходном коде), и сохранить копии самых
важных диаграмм и моделей. Другими словами, путешествуйте налегке, но не за-
будьте взять самое необходимое.
Внутренняя документация или внешняя документация. Вы встраиваете всю
вашу документацию в код, или вы пишете «самодокументированный» код, или
вы размещаете все документацию на внешних артефактах? Как обычно, нужно
выбрать золотую середину. Если документация предназначена для разработчи-
ков, лучше поместить большинство документации в исходный код. Да, для этой
«группы читателей» вам еще наверняка придется создать обзорную документацию
по системе, хотя на самом деле эти ребята не доверяют документации, которая не
встроена в код (такую документацию они вообще читать не станут), а если они
действительно хорошие разработчики, то они не станут доверять даже встроенной
в код документации. Однако документация нужна не только разработчикам. Вам
наверняка придется писать документацию для тех, кто не имеет доступа к исход-
ному коду или, по крайней мере, ничего там не поймет, например пользователи,
высшее руководство и операторы. Эти группы читателей потребуют внешнюю до-
кументацию, написанную для удовлетворения их потребностей.
Документация на уровне проекта или документация на уровне предприятия.
Не вся написанная вами документация предназначается только для вашей группы
или для групп, которым будет передана система. Методика AM «Используйте име-
ющиеся ресурсы» советует воспользоваться имеющимися артефактами, включая
системную документацию и созданные вами модели (но не ограничиваясь ими).
Сюда входят существующие определения бизнес-правил, интерфейсы наследу-
емых систем и документация по этим системам (особенно модели соглашения),
корпоративный архив метаданных, где хранится описание всех данных, имеющих-
ся в вашей организации, и корпоративная бизнес-модель. Каково происхождение
этих ресурсов? Эта информация исходит от других групп, подобных вашей, и на-
верняка управляется корпоративными специалистами. Бесспорно, такая ситуа-
ция способствует возникновению ненужной бюрократии, но вы все-таки можете
сохранить гибкость: централизованные административные группы должны найти
способ эффективно работать с вашей группой. Во время разработки они должны
предоставлять ресурсы (существующие модели и метаданные), которые вам не-
обходимы, и выступать в качестве консультантов, помогающих вам разобраться
и работать с этими ресурсами. В пост-разработке они должны помочь вам собрать
соответствующую информацию для обратной связи с общими корпоративными
ресурсами. Например, часть процесса запуска вашей системы в производство мо-
жет быть выполнена для того, чтобы выяснить, были ли внесены соответствую-
щие изменения в корпоративные бизнес-правила и хранилища метаданных. Для
того чтобы быть гибкими, централизованные административные группы должны
Когда модель становится постоянной? 185
ориентировать свою работу на заказчиков; их работа должна иметь коммерческую
ценность; также они должны стараться понять, каким образом и по какой причине
заказчик использует управляемые ими ресурсы.
Качество или количество. Главным компромиссом является следующее реше-
ние: использовать или не использовать документ в зависимости от его надежности.
Что вы выберете: 2000-страничный документ по системе, подробный, но наверня-
ка полный ошибок, или 20-страничный высокоуровневый обзор? Более объемный
документ наверняка содержит большинство информации, необходимой вам для
сопровождения и усовершенствования системы, но можете ли вы доверять этой
информации? В меньшем документе не будет нужной вам подробной информа-
ции, но там будет карта, с помощью которой вы сможете ориентироваться в ис-
ходном коде и прочих документах, если вам нужны детали. Меньший документ
наверняка вызовет больше доверия — в худшем случае вы можете легко усовер-
шенствовать его или вообще переписать, потому что он содержит высокоуровне-
вые понятия типа архитектуры системы, которая меняется гораздо медленнее, чем
подробные данные, содержащиеся в большом документе. Я не утверждаю, что чем
больше документ, тем он хуже, но это скорее всего так, если не доказано обратное.
Что значит путешествовать налегке?
Очень часто люди думают, что, путешествуя налегке, вообще не нужно создавать
документацию. На самом деле это большое заблуждение. Гибкое моделирование
предполагает, что путешествовать налегке — это значит создавать столько моде-
лей и документации, сколько нужно для решения какой-то задачи. В очень редких
случаях это может означать, что вы вообще не создаете моделей или даже доку-
ментации (такое бывает в очень маленьком проекте). Но для большинства проек-
тов вам необходимо создавать какие-то модели и документацию.
Как убедиться в том, что вы действительно путешествуете налегке? Возьмите
себе за правило не создавать модель или документ, если вам он еще не нужен.
Создавая документ заранее, вы рискуете потратить время впустую. Помню, я ра-
ботал над созданием коммерческой системы (из тех, которые можно купить и
установить или модифицировать в соответствии с потребностями организации),
и менеджер по продажам получил заказ от компании, которая хотела приобрести
нашу систему. Раньше мы не имели дела с подобными компаниями и не были зна-
комы с их деятельностью. Мы решили взяться за этот заказ и получили его, но
еще до встречи с заказчиками мы с коллегами решили начать моделировать пред-
полагаемые изменения, которые, по нашему мнению, было необходимо внести.
Потратив несколько дней на моделирование, мы пришли к заключению, что вне-
сти изменения будет легко, наша система — просто чудо, и нам будет очень лег-
ко удовлетворить требования заказчика. Затем мы побеседовали с заказчиками.
Из семидесяти требований, определенных нами самостоятельно, подтвердились
около 50 %, что на самом деле было неплохо, учитывая, что мы не имели необхо-
димого опыта (правда, мы упустили из виду несколько десятков других требо-
ваний). Естественно, наши модели, основанные на неверно определенных требо-
ваниях, не представляли никакой ценности. Мы были вынуждены выбросить их
186 Глава 14 • Гибкая документация
и начать моделировать заново, а это было непросто, так как для этого нужно было
избавиться от первоначального подхода, который не давал нам покоя. На первое
собрание мы явились гордые собой, потому что считали, что знаем про систему
все, и если бы наш менеджер по продажам не выбрал верную линию поведения, то
мы бы потеряли этого заказчика. Вывод один — нам не нужно было моделировать
заранее. Вместо этого нам следовало бы повременить с моделированием до под-
тверждения сделки и встречи с заказчиком.
В качестве другого примера давайте рассмотрим RUP (Кратчен, 2000), кото-
рый предлагает для определения архитектуры создавать документ «Описание
архитектуры ПО» (SAD). Безусловно, определение архитектуры вашей систе-
мы — дело хорошее, но стоит ли создавать этот документ на раннем этапе работы
над проектом? Иногда — да, иногда — нет. Пару лет назад я работал над созданием
ответственной системы. Во время работы мы разрабатывали модели архитектуры
на общей белой доске как набор диаграмм произвольной формы, эффективно сле-
дуя методике. «Демонстрируйте модели открыто». Из-за того что процесс, которо-
му мы следовали, требовал от нас создания SAD, мы так и поступили, хотя больг
шинство разработчиков работали с набросками на белой доске. В качестве основы
для работы мы использовали шаблон для создания SAD, так как продукт RUP
(Rational Corporation, 2001) его предоставляет. Некоторые разработчики распеча-
тали диаграммы из документа SAD (мы преобразовали наши наброски в Microsoft
Visio) и прикрепили их на стенке своих загородок, чтобы видеть диаграммы ла
своем рабочем месте. Каждый раз, когда мы изменяли наброски на белой доске,
нам приходилось изменять электронные версии диаграмм, а также соответству-
ющий раздел документа SAD. Наличие документа SAD помогало — там приводи-
лось описание того, что мы создавали. Этот документ был у руководства, и любой
человек из организации мог с ним ознакомиться. Но с моей точки зрения, никто не
использовал этот документ эффективно; Я уверен, что руководство в него даже не
заглядывало, а если и заглядывало, то это, скорее всего, был лишь быстрый про-
смотр, так как мы так и не получили никакой обратной связи. Те,разработчики,
которым были нужны копии диаграмм, могли сделать снимки этих набросков или
создать веб-страницу с общей архитектурой, наконец, просто распечатать их. Это
тоже являлось бы документом SAD, хотя и выполненным в другой форме соглас-
но принципу «Содержание важнее формы», потому что он все равно бы описывал
архитектуру нашей системы (что является целью документа SAD). Наши наброс-
ки на белой доске тоже являлись документами SAD, хотя они были временными
и не имели постоянного места. Мне кажется, что мы совершили три очень боль-
шие ошибки и поэтому путешествовали с большим багажом, чем требовалось: мы
выбрали неверный формат документации, мы создавали документацию слишком
рано и ее было слишком много. Кроме того, то, что мы поддерживали документ
SAD как документ Word, замедляло ход работы, потому что информация храни-
лась в нескольких местах — на белой доске, как документ Word (это было явно
лишним) и в исходном коде. Кроме того, мы могли бы вместо создания докумен-
тации разрабатывать ПО. А самое страшное заключалось в том, что один из веду-
щих разработчиков уделял большую часть времени работе по совершенствованию,
Когда модель становится постоянной? 187
поэтому он не мог помочь менее опытным разработчикам. Конечно же, в конце
проекта этот документ оказался полезным и стал частью документации для груп-
пы сопровождения, но он был вовсе не нужен во время разработки и явно принес
группе больше вреда, чем пользы. Когда вы путешествуете налегке, вам требуется
подумать о том, что вы делаете. В начале проекта спросите себя; «Что мне пона-
добится, учитывая особенности проекта?» Разработка системы контроля авиапе-
ревозок, скорее всего, потребует создания большей документации, чем разработка
веб-сайта из статических страниц HTML. По мере развития проекта вы обнару-
жите, что вашу первоначальную оценку документации стоит изменить, учитывая
особенности работы (вам может понадобиться больше или, наоборот, меньше до-
кументации). Хайсмит (2000) любит проводить аналогию с походами — слишком
большое количество вещей может привести к катастрофе так же, как и слишком
малое. В худшем случае вы погибнете, в лучшем — вернетесь назад и будете заново
продумывать вашу стратегию. Представьте себе, что вы путешествуете по пусты-
не, имея при себе слишком мало воды — вы путешествуете слишком уж налегке.
Если же вы пытаетесь пересечь ту же пустыню со-столитровым бидоном за спи-
ной, то в этом случае ваш багаж слишком велик. Теперь представьте создание от-
ветственного приложения для интернет-магазина без всякой документации по ра-
боте с ним. Ваш проект терпит неудачу, потому что вы путешествуете слишком
уж налегке. А теперь — создание той же системы с кипой документации, которую
вы должны пересматривать каждый раз, когда- вы вносите изменения в систему.
Ваш проект снова терпит неудачу, так как ваш багаж слишком велик, и вы не мо-
жете своевременно реагировать на рыночные изменения. Путешествовать налег-
ке — значит создавать необходимое количество моделей и документации. Если ее
слишком много или, наоборот, мало, вы подвергаете ваш проект риску.
Какой документ является гибким?
Гибкость документа — понятие относительное.
Об этом пусть судит читатель.
Что бы там ни говорили, на самом деле документация может быть очень эффек-
тивной. Какой документ является гибким? Тот, который соответствует следую-
щим критериям:
Гибкая документация повышает отдачу от ресурсов, полученных от заин-
тересованных лиц. Гибкий документ в значительной мере оправдывает затраты
на его создание и ведение; в идеале, если вы вкладываете ресурсы в создание до-
кумента, то это является лучшим применением этим ресурсам. Другими словами,
документация должна приносить прибыль, а еще лучше — значительную прибыль.
Например, если создание документации для пользователя дает 50 % прибыли от
вложений, а проведение курса обучения для пользователей — 100 %, то вам следу-
ет выбрать курс обучения, так как это лучший способ вложения средств.
Гибкая документация должна обладать максимальной эффективностью при
максимальной простоте. Гибкий документ содержит ровно столько информации,
188 Глава 14 • Гибкая документация
сколько необходимо. Другими словами, он максимально прост. Например, час-
ти гибкого документа могут быть написаны в краткой схематичной форме. При
этом вы все равно передаете важную информацию, но не тратите время на «обла-
гораживание» документа, руководствуясь принципом «Содержание важнее фор-
мы». Гибкая документация часто дает ссылки на другие источники информации.
Например, модель соглашения, описывающая интерфейс внешней системы, мо-
жет указывать на то, что используется протокол SOAP 1.1, и давать ссылку на
XML DTD и определение схемы, которая определяет документы XML, передава-
емые между системами. При написании гибкой документации помните принцип
«Добивайтесь простоты» (достаточно простейшей документации) и всегда, ког-
да это возможно, следуйте методике «Создавайте простое содержание». Один из
способов создавать гибкую документацию — следовать принципу прагматичного
программирования «Не повторяйте себя» (Хант й Томас, 2000). Также не забы-
вайте работать с аудиторией, на которую рассчитана ваша документация. То, что
вам кажется эффективным и простым, может оказаться совершенно неподходя-
щим для нее.
Гибкий документ решает какую-то задачу. Гибкая документация создается
с определенной целью. Если вы не знаете, зачем вы создаете документ, или цель
создания этого документа неясна (см. выше), тогда вам следует остановиться и по-
думать над тем, что вы делаете.
Гибкая документация содержит информацию, которая, вероятнее всего,
не изменится. Чем больше вероятность того, что информация изменится, тем
меньше усилий стоит затрачивать на написание внешней документации о ней.
Информация может измениться прежде, чем вы закончите работу, и вести ее бу-
дет трудно. Например, архитектура вашей системы, однажды достигнув стабиль-
ности, будет медленно изменяться со временем, поэтому она может быть объектом
внешней документации.
В гибкой документации содержится полезная информация. Гибкая докумен-
тация содержит важную информацию, которая не является очевидной. Например,
это может быть обоснование дизайна, требования, процедуры использования или
операционные процедуры. Гибкая документация не содержит очевидную инфор-
мацию. Например, документация, показывающая, что колонка ИМЯ в таблице
ПОКУПАТЕЛЬ отражает 'имя покупателя, не представляет для меня никакой
ценности. Документация, показывающая, что таблица покупателя не содержит
информацию для покупателей, проживающих в канадской провинции Юкон, по-
тому что эта информация хранится в «плоском» файле ASCII в другой системе,
вероятнее всего,.мне необходима.
Гибкая документация рассчитана на определенного пользователя и способс-
твует его работе. Системная документация обычно пишется для сотрудников со-
провождения, представляет собой обзор архитектуры системы и, возможно, сум-
мирует важные требования и решения дизайна. Пользовательская документация
часто содержит руководство по использованию системы и написана языком, по-
нятным пользователю, в то время как операционная документация описывает, как
работать с системой, и написана она языком, понятным для операторов. Разные
Когда модель становится постоянной? 189
клиенты, разные типы документации и, вероятнее всего, различные стили напи-
сания этой документации должны быть учтены. Вы должны работать совместно
с клиентом или потенциальным клиентом для создания документации, если вы
хотите создать то, что отвечает его нуждам. Например, я вряд ли возьмусь писать
документацию для сотрудников, сопровождения, не привлекая их к этой работе.
Конечно, иногда бывает трудно привлечь их к работе — может оказаться, что у вас
в данный момент вообще нет сотрудников сопровождения, или вы не можете оп-
ределить, кто из них будет работать с системой. Если вы не привлекаете к работе
клиентов, вы рискуете создать слишком обширную или бесполезную документа-
цию, тем самым утрачивая гибкость. Зачастую вы обнаруживаете, что, привлекая
клиентов, вы начинаете понимать, что им нужно на самом деле, и они сами могут
привести примеры того, что подходит им, а что нет.
Гибкая документация достаточно аккуратна, последовательна и подробна.
Вы когда-нибудь учились использовать новое ПО при помощи книги, описываю-
щей предыдущую его версию? Вам это удалось? Вероятно, да. Была ли эта ситу-
ация идеальной? Вероятнее всего, нет. Рассказывалось ли в книге о новых свойс-
твах ПО? Конечно же, нет, но все же она помогла вам разобраться с новой версией
ПО. Хотели ли вы потратить свои деньги, скажем, 500 рублей, на покупку послед-
него издания книги, которая была вам нужна? Вероятнее всего нет, потому что она
не представляла для вас ценности. Гибкая документация не должна быть идеаль-
ной. Она должна быть просто хорошей.
Гибкая документация снабжена указателем. Документация не является эф-
фективной, если вы не можете найти информацию, которая в ней содержится.
Купите ли вы справочник, в котором нет алфавитного указателя или оглавления?
Ваш указатель должен отражать потребности аудитории, для которой создается
документация. К счастью, текстовый процессор помогает с легкостью создавать
оглавление, алфавитный указатель и даже списки рисунков и таблиц.
ВНИМАНИЕ: ИНОГДА ДОКУМЕНТАЦИЯ ДОЛЖНА БЫТЬ ИДЕАЛЬНОЙ -------------------
Вы должны разумно следовать совету о том, что гибкая документация должна быть просто
хорошей. Если вы пишете руководства по эксплуатации ПО для атомной станции, я советую
вам сделать это как следует! Тем не менее, не все системы имеют такую важность, поэтому
не стоит затрачивать слишком много усилий на написание идеальной документации. Когда
дело доходит до написания документации, вы должны решить следующий вопрос: насколько
расплывчатым, но все же эффективным может быть документ, получаемый заказчиком?
ПРИМЕЧАНИЕ; ИНОГДА НЕГИБКОСТЬ СПОСОБСТВУЕТ ГИБКОСТИ ----------------------
Гибкая разработка ПО — новшество для многих организаций, поэтому существует страх и
неуверенность по поводу ее жизнеспособности. Хотя это немного разочаровывает, на самом
деле это неплохо, так как означает, что люди небезразлично относятся к своей работе. Из-
за этого страха ваши заинтересованные лица могут потребовать от вас создавать для их
спокойствия ненужную документацию. То же самое распространяется на высшее руководство,
которое, вероятнее всего, погорело на использовании других новых методов и технологий.
Часто создание одного документа (например, служебной записки) обеспечит вашим заинте-
ресованным лицам приятное спокойствие по поводу вашего проекта и позволит вам работать
выбранным вами способом (например, гибким).
190 Глава 14 • Гибкая документация
Какую документацию нам следует создавать?
Вам необходимо будет создавать документацию для вашего проекта. Без этого не
обойтись даже в самых «экстремальных» проектах ХР, не говоря уже о проектах
RUP. Но какую документацию вам неизбежно придется создавать? В табл. 14.1
перечислены наиболее распространенные документы, которые вы будете созда-
вать во время разработки. Это те документы, которые вы предоставите как часть
вашей системы. Таблица 14.1 не включает в себя артефакты управления (напри-
мер, расписание работы над проектом), комплектующие узлы (исходный код и
тестовые наборы) или временные рабочие продукты (временные модели).
Когда следует обновлять документацию?
В этом отношении с документацией дело обстоит так же, как с моделями, Я реко-
мендую следовать методике «Совершенствуйте только в случае необходимости».
Гибкая документация, как и гибкие модели, не обязательно должна быть идеаль-
ной — она должна выполнять свою задачу. Часто случается, что даже устаревший
документ остается достаточно эффективным.
Таблица 14.1. Примеры документов, создаваемых группой разработчиков
Документ Аудитория Описание Совет
1 2 3 4
Модели соглашения Другие группы Документ, описывающий технический интерфейс системы или ее части • Модели соглашения для существующих систем могут уже иметься в наличии
Решения дизайна Разработчики, Краткое изложение • Сконцентрируйтесь на
сотрудники важных решений, решениях, которые не
сопровождения, касающихся дизайна являются очевидными
менеджеры и архитектуры, и имели другие разумные
проектов которые были приняты альтернативы, или на тех,
в процессе разработки которые первоначально казались разумной альтер- нативой, а впоследствии оказались не подходящими для ваших нужд
• Цель этой работы —
избежать рефакторинга на каком-то этапе в будущем при переформулировке ранее принятого решения
• Решения дизайна часто документированы вместе с другими артефактами (например, с обзором системы, и исходным кодом), хотя когда этого требует ситуация, они могут быть
документированы отдельно
Когда модель становится постоянной? 191
1 2 3 4
Служебная записка Высшее ' руководство, руководство пользователя, руководство проекта Определение • видения системы, смета расходов, предполагаемая прибыль, риск, оценка кадрового обеспечения и поэтапный график разработки • Этот документ обычно используется для получения средств и поддержки проекта и для предоставления информации об изменении положения дел важным заинтересованным лицам, которые не могут активно участвовать в проекте каждый день Наберитесь смелости и сделайте этот документ доступным для всех, кого он касается, даже если информация, содержащаяся в нем, не слишком радостная, следуя принципу «Открытые и доброжелательные контакты»
Операционная документация 1 с Операторы Обычно эта • документация содержит информацию об отношениях, в которых участвует ваша система,о природе взаимодействия с другими системами, базами данных и файлами, о ссылках на процедуры поддержки. Также она содержит список точек соприкосновения с вашей системой информацию о том, как их найти, краткое изложение требований по пригодности/ надежности вашей системы, информацию об ожидаемой диаграмме загрузки и руководство по, устранению повреждений У ваших операторов обычно есть стандартный шаблон для этого типа документации или примеры подобной документации для других систем, которые могут послужить основой для создания собственной документации
Продолжение
192 Глава 14 • Гибкая документация
Таблица 14.1 (продолжение)
1 2 3 4
Обзор проекта Разработчики, менеджеры, сотрудники сопровождения и операторы Это краткое • Обычно я создаю изложение важной и использую этот документ информации, в процессе разработки например: видение . Пусть он будет коротким системы, связи и содержит только с непосредственным основную информацию, пользователем, Его размер не должен технологии и средства, превышать десять использованные для печатных страниц создания системы, _ ИМ» • Этот документ служит И □□/KnDlC „ отправным пунктом операционные 7 пооиессы (некотооые в работе новичка в гРУппе р ц р (включая сотрудников касаются разработки, 4 г7” например, как сопровождения), потому создать систему, чт0 он ““Р™1 °тветь| _ ' на важнейшие вопросы, а некоторые — с которые обычно у них производства, г 7 н ' возникают например, как поддерживать * Когда вы показываете хранение информации), кому-нибудь этот документ Также содержит впервые, попросите ссылки на важные этого человека отметить, артефакты проекта, какие основные моменты например, исходный был0 трудно понять при код (часто достаточно ознакомлении с этим названия проекта документом, не обнаружил в системе контроля ли он какой-либо неверной исходного кода), информации, чтобы учесть указывает на все эт0 ПРИ изменении местонахождение документа постоянных моделей, , касающихся системы (если таковые имеются) и других документов (если они имеются)
Документация, Сотрудники связанная сопровождения, с требованиями разработчики, пользователи, руководство пользователей Эта документация • В проектах ХР обычно определяет, что отдают предпочтение будет делать система, низкотехнологичным обобщая требованиям; таким или составляя артефактам, как истории артефакты пользователя и карточки требований: CRC
определения бизнес- . в проектах RUP правил, элементы предпочтение отдается Use Case, истории более формальным пользователя или требованиям, артефактам основные прототипы и документации пользовательского интерфейса
Когда модель становится постоянной? 193
1 2 3 4
Вспомогательная Обслуживающий Эта документация • Скорее всего, у вашего
документация персонал включает в себя руководства для обслуживающего персонала, пользовательскую документацию (справочную информацию для решения проблем), руководства обслуживающего персонала уже имеется стандартное руководство по решению серьезных проблем, поэтому нет необходимости создавать новое. У них, как и у операторов, есть . стандартные шаблоны или примеры, на основе которых можно создать
по устранению неисправностей и решению серьезных проблем, а также точки соприкосновения с группой сопровождения подобные руководства
Системная Сотрудники Этот документ • Системная документация
документация сопровождения, разработчики представляет собой обзор системы и помогает понять, как работает система. Этот документ содержит обзор технической архитектуры, бизнес-архитектуры и высокоуровневых требовании к системе. Он также может содержать подробные модели архитектуры и дизайна или ссылку на их местонахождение помогает уменьшить возможную угрозу проекту, предоставляя «страховку от кирпича» — уверенность в том, что если кто-нибудь из разработчиков уволится или станет жертвой несчастного случая (скажем, ему на голову упадет кирпич)1, важная информация о проекте сохранится. К сожалению, эта страховка обычно не помогает — если вы теряете кого-то из участников проекта, то какой бы хорошей ни была документация, перед вами все равно встает серьезная проблема. Новым людям нужно определиться, разобраться и изучить вашу систему. Вам следует сократить до минимума число людей, потеря которых подвергнет ваш проект угрозе, применяя такие методики, как «Активное участие заинтересованных лиц», «Совместное владение» и «Моделируйте в группе»
Продолжение J
7 Зак. 926
194 Глава 14 • Гибкая документация
Таблица 14.1 (продолжение)
1 2 3 4
Пользовательская Пользователи, Вашим пользователям • Обычно при написании '
документация руководство пользователей могут потребоваться справочники, руководство по использованию и поддержке и даже материалы для проведения тренингов. Вы должны уметь различать разные виды этой документа- ции, потому что они используются по- разному (одни — для . получения справочной информации, другие — для того, чтобы узнать, как работать с системой, третьи — для получения помощи в случае возникновения проблем, а четвертые — для проведения тренингов) руководства по использованию и материалов для проведения тренингов я применяю элементы Use Case для этой системы. Элементы Use Case описывают, как актеры работают с системой, поэтому они являются лучшей основой для этих двух видов документации Пользовательскую документацию следует рассматривать как часть пользовательского интерфейса системы, поэтому ее следует тестировать на практичность
1 Однажды во время работы над одним проектом ведущий разработчик, менеджер проекта и раз-
работчик архитектуры (ваш'покорный слуга) попали в аварию. Это было лобовое столкновение с гру-
зовиком. К счастью, мы остались живы, но в противном случае это был бы серьезный удар для проекта,
не говоря уже о наших семьях.
Например, во время работы над этой главой я работал над ранней версией
JDKvl.3.1, но постоянно обращался к справочникам по JDK 1.2.x. Это не самая
лучшая ситуация, но она меня вполне устраивала, потому что эти справочники
годятся для этой цели. Подойдут ли справочники по Java vl.O.x? Вероятнее всего,
нет. Многое изменилось со времени той версии, и мои потери в продуктивности
будут намного больше, чем стоимость новых справочников.
Кроме основных требований заинтересованных лиц, которые инвестируют
средства на выполнение работы, вы также должны учитывать следующие момен-
ты, чтобы решить, когда обновлять документацию:
• Обновляйте модели соглашения и переиздавайте их заранее или в крайнем
случае одновременно с выпуском той части системы, которую они описывают.,
• Документацию, которая является частью системы (например, руководство
по эксплуатации и руководство пользователя), следует обновлять и изда-
вать до выпуска системы или вместе с системой..
• Из-за того что документация не обновляется, заказчику наносится значи-
тельный ущерб, включая изрядные потери продуктивности.
Конечно же, недостаточно аккуратные модели и документация, не согласо-
ванные между собой, мешают работе. Эта помеха в работе компенсируется рос-
Когда модель становится постоянной? 195
. том продуктивности, достигнутым благодаря тому, что вы путешествуете налегке,
,'И вам не требуется постоянно совершенствовать и согласовывать модели и доку-
. ментацию. Вы хотите создавать ПО или писать документацию?
Эффективная передача документации
.Что такое передача документации? Это предоставление документации другой
группе или человеку. Гибкие разработчики изо всех сил стараются избежать пе-
: редачи документации, потому что это не самый лучший способ общения между
; людьми. К сожалению, в некоторых случаях передача документации неизбежна.
Часто бывает так, что группа настолько велика, что не может быть размещена в од-
ном месте (возможно, часть системы создается другой компанией), что подразу-
мевает создание модели соглашения. Возможно, важные заинтересованные лица
. не могут напрямую контактировать с вашей группой или же правила вашей ор-
ганизации или отрасли промышленности требуют предоставления определенной
. документации. Нижеперечисленные стратегии могут помочь повысить эффектив-
' ность передачи документации:
Избегайте передачи документации. При переходе к гибкому моделированию
вы будете постоянно встречать людей, которые не знакомы с гибким подходом и
не видят ничего плохого в передаче документации. Укажите им на то, что суще-
ствуют способы общения получше. Например, личные переговоры, видеоконфе-
ренции или обсуждение по телефону. Вам следует предусмотреть все эти сцособы,
прежде чем начать писать документацию, и при первой же возможности попы-
таться найти лучший способ, отвечающий вашим потребностям.
Применяйте другие средства общения при передаче информации. Если без
передачи информации не обойтись, вы должны, по крайней мере, попытаться сде-
лать это, применяя личное общение или другие подходы. Это будет способство-
вать сокращению объема документации и как следствие позволит вам направить
свою работу на другие аспекты, а также поможет вам преодолеть различные мину-
сы документации (например, неверное понимание материала).
Избегайте передачи документации. Велики шансы того, что люди, с которыми
вы сотрудничаете, тоже не любят писать и получать документацию. В конце кон-
цов, спросить-то об этом можно.
Пишите гибкую документацию. См. раздел «Методы повышения гибкости до-
кументации».
Избегайте передачи документации. Я уже достаточно говорил об этом.
Методы повышения гибкости документации
Если написание документа неизбежно, как сделать это, применяя гибкий подход?
Следующие методы должны помочь вам в этом:
Создавайте документ для заказчика (заказчиков). Определите, кто являет-
ся потенциальным заказчиком (заказчиками) вашей документации и каковы их
требования. Обсудите с ними минимальный набор документов, который им необ-
ходим. Для определения требований спросите, чем они занимаются, как они ра-
ботают, как они хотят работать с документацией к их системе, которую вам пред-
I
196 Глава 14 • Гибкая документация
стоит написать. Поняв потребности ваших заказчиков, вы сможете предоставить
им краткую, но достаточную документацию и разместить ее там; где они смогут
ее найти и где она действительно необходима, иначе какой прок от документации,
если никто не знает, что она вообще существует?
Пусть ваш документ будет достаточно простым, но не слишком простым.
Когда вы создаете документацию, следуйте методике «Используйте простейшие
инструментальные средства» и применяйте методики «Создавайте простое со-
держание» и «Изображайте модели просто». Лучшей документацией является
простейшая, но отвечающая своим целям документация. Не стоит создавать до-
кумент на пятидесяти страницах, когда подойдет и пятистраничный. Не создавай-
те документ на пяти страницах, когда вполне достаточно пяти главных пунктов.
Не создавайте сложных и запутанных диаграмм, если вполне сгодится набросок.
Не дублируйте информацию, если ее можно найти в справочнике. Пишите толь-
ко главное. Содержание — вот что важно в документе. Начните с создания ми-
нимального документа, отвечающего потребностям ваших заказчиков, а затем
дополните его в случае необходимости. Для того чтобы определить, каков мини-
мальный объем документации необходим моим клиентам, я выясняю, как они со-
бираются использовать документацию и почему они собираются использовать ее
таким образом.
Заказчик определяет, достаточно ли документации. Много лет назад я ра-
ботал в крупной канадской финансовой организации. Ее политика заключалась
в том^что нельзя передать систему заказчику, если тот не желает ее принять.
Заказчики изучали наш код и вспомогательные артефакты, и если они находили,
что артефакты не соответствуют, то мы должны были усовершенствовать систему
и попробовать передать ее снова. Иногда мы работали над совершенствованием
артефактов вместе, иногда — нет. Эта методика позволяла заказчикам справедли-
во и эффективно оценить качество работы разработчиков. Задача разработчика
документации — создать эффективную, приносящую пользу документацию, а за-
дача вашего заказчика — выяснить, сделали ли вы это.
Создавайте документ с определенной целью. Вам следует создавать доку-
мент только в том случае, если он отвечает четкой, важной и непосредственной
цели работы над всем проектом. Не забывайте, что эта цель может быть времен-
ной, а может — долгосрочной; она может непосредственно способствовать разра-
ботке, а может и нет.
Отдавайте предпочтение другим формам общения. Хайсмит (2000) считает,
что проблема № 1 — это понимание, а не документация, поэтому вам не следует
придавать документации слишком большое значение. Ваша цель — помочь сотруд-
никам сопровождения понять, как работает система, чтобы они могли совершенс-
твовать ее со временем, а не представить кипы документации, которой они, воз-
можно, не будут пользоваться. Ваша цель — эффективная работа пользователей с
системой, а не создание для них системы-помощника. Ваша цель — помочь обслу-
живающему персоналу и операторам, а не завалить их бумагами. Документация
способствует передаче знаний, но это всего лишь один из многочисленных до-
ступных вам способов, и зачастую не самый лучший, как уже говорилось в гла-
ве 8: Общение с заинтересованными лицами, их активное участие в разработке,
совместное решение проблем дают лучший результат, нежели самая лучшая доку-
Когда модель становится постоянной? 197
ментация. Документация становится лучшим способом общения только в случае
. удаленности (по месту или во времени) участников друг от друга.
Поместите документацию в надлежащем месте. Где лучше всего поместить
документацию? Где лучше всего поместить решение дизайна: записать его в коде
й дополнить пояснениями на диаграмме или лучше создать для этого отдельный
• документ? Ответ на этот вопрос можно, дать, учитывая потребности заказчика этой
информации. Где она им потребуется? Ответить на этот вопрос также можно, ру-
ководствуясь принципом «Качественная работа». Вам следует записать информа-
цию так, чтобы это способствовало вашей работе. При написании документации
вы также должны учитывать такие моменты, как создание указателей и ссылок,
а также доступность, потому что вы не всегда знаете, кто станет ее потребителем.
Дождитесь, пока ваша документация стабилизируется. Оттягивайте момент
создания документации до последнего. Пишите документацию тогда, когда она
вам потребуется. Например, обзор системы» лучше написать к концу работы над
выпуском, потому что вы уже знаете, что вы создали.
Демонстрируйте модели открыто. Когда вы демонстрируете модели от-
крыто (на белой или пробковой доске или внутреннем веб-сайте),' вы способс-
твуете передаче информации и общению посредством применения методики
«Информационного излучателя» (Кокберн, 2002). Чем лучше общение среди
участников вашего проекта, тем меньше необходимость создания подробной до-
кументации, потому что люди уже знают, что вы делаете. Не забудьте указать ста-
тус ваших моделей для того, чтобы люди могли понять их значимость. Вы будете
по-разному оценивать модель, которая является наброском, и модель, которая яв-
ляется основной в вашей версии ПО.
Начните с моделей, которые вы собираетесь поддерживать в течение всего
цикла. Если вы решили поддерживать диаграмму размещения UML, диаграмму
потоков пользовательского интерфейса и диаграмму физического представления
данных на протяжении всей разработки, это свидетельствует о том, что эти диа-
граммы представляют ценность и вам следует строить свою документацию в соот-
ветствии с ними. Модели, которые вы не поддерживали в течение цикла, не явля-
лись ценными и поэтому их не стоило поддерживать.
Требуйте от заинтересованных лиц обоснования для создания документа-
ции. Знают ли люди, что они просят создать и зачем им это нужно, или они де-
лают это потому, что им так приказали? Почему пользователи просят документа-
цию? Потому, что они или их коллеги были обмануты разработчиками в прошлом,
и теперь они требуют все в надежде хоть что-нибудь получить? Понимает ли про-
сящий соотношение выгод и потерь? Понимает ли он, что документация влета-
ет в копеечку? См. раздел «Компромиссы, связанные с документацией». Я знаю
из опыта, что когда вы начинаете обсуждать проблему документации с вашими
заинтересованными лицами, вы обнаруживаете, что они просят ее создать, потому
' что не доверяют вам, не понимают, каковы могут быть последствия, или не знают,
‘ что существуют другие альтернативы (например, меньшее количество документа-
ции). Очень полезно бывает спросить их о трм, с какой целью они собираются ис-
пользовать документацию и как они вообще ее используют. Когда вы задаете по-
добные вопросы, вы выясняете, что они не используют всю документацию. Они
просто хотят получить ее как гарантию безопасности. Существуют гораздо луч-
198 Глава 14 • Гибкая документация
шие способы преодоления страха, нежели написание документации. Вам также
следует объяснить им принцип AM «Повышайте отдачу от ресурсов, полученных
от заинтересованных лиц».
Создавайте документы с наименьшим количеством совпадений. Один из
способов добиться этого — создавать большие документы на основе маленьких.
Например, однажды я участвовал в проекте, где вся документация была написана
в виде страничек HTML, при этом каждая страничка была посвящена отдельной
теме. Одна страничка описывала архитектуру пользовательского интерфейса ва-
шей системы. Она включала в себя диаграмму потоков пользовательского ин-
терфейса и соответствующий текст, описывающий ее. Содержание системной
документации и руководство по эксплуатации были связаны с этой страничкой,
посвященной архитектуре пользовательского интерфейса. Эта информация раз-
мещалась только в одном месте, поэтому не возникало совпадений.
Наймите человека, имеющего опыт создания документации. Разработчики,
имеющие опыт создания документации, приносят огромную пользу проекту, по-
тому что знают, как организовать и представить документацию эффективно. У вас
нет такого человека? Прочитайте «UnTechnical Writing» (Бремер, 1999) и после-
дуйте советам, приведенным в этой книге, или организуйте вечерние курсы по на-
писанию основ. Также попытайтесь писать документацию вместе с коллегой. Как
и из программирования в паре (www.pairprogramming.com), вы можете извлечь ог-
ромную пользу из создания документации в паре. Вы также можете приобрести
систему преобразования текстовой информации в речевые сигналы, которая поз-
воляет прослушивать то, что вы написали. Это замечательный способ найти пло-
хо написанные куски.
Таблица 14.2. Важные моменты, касающиеся гибкой документации
1. Главная задача: эффективное общение, а не документация
2. Документация должна быть максимально эффективной при максимальной простоте
3. Путешествуйте налегке
4. Документация должна быть просто хорошей
5. Модели не всегда являются документами, а документы — моделями
6. Документация в такой же мере часть системы, как и исходный код
7. Главная цель вашей группы — разработка ПО. Еще одна цель — продолжать проект
8. Польза от создания документа должна быть больше, чем расходы на его создание и ведение
9. Никогда не доверяйте документации
10. Каждая система требует своей документации; она не может быть универсальной
11. Спросите, НУЖНА ли вам документация, и зачем, по вашему мнению, она вам НУЖНА.
Не спрашивайте, хотите вы ее создавать или нет
12. Расходы на создание системной документации являются не техническим решением,
а деловым
13. Создавайте документацию только в случае, если она вам нужна. Не создавайте
документацию по принципу «чтобы было»
14. Обновляйте документацию только в случае необходимости
15. Именно заказчик, а не разработчик определяет, достаточно ли документации
Когда модель становится постоянной? 199
Помогите вашей группе запомнить эти основные правила. В табл., 14.2 обобще-
ны важные моменты этой главы. Сделайте ксерокопию и поместите ее так, чтобы
она могла служить напоминанием вашим коллегам о том, как применять гибкий
подход к документации.
Как это осуществить?
Ваша группа должна направить свою работу на создание документации, которая
'принесет максимальную пользу вашим заказчикам. Вы должны создавать доку-
ментацию только в случае, если это будет лучшей альтернативой. Если сущест-
вуют какие-то другие лучшие варианты, вы, естественно, должны предпочесть их.
Ваша цель — создание простейшей документации, которая решит ваши задачи.
Как и гибкая модель, гибкая документация должна быть просто хорошей и отве-
чать требованиям аудитории, на которую она направлена. Как это осуществить?
Как это может работать? Хотя гибкие процессы разработки ПО (например, AM)
направлены на создание работающего ПО, а не документации, это не означает, что
вы вообще не будете создавать никакой документации. Вам просто следует созда-
вать необходимую документацию. Не следует ударяться в крайности, то есть либо
всегда писать документацию, либо никогда ее не писать. Сначала подумайте, а по-
том делайте.
Желание довести модели до идеала — одна из причин, по которой люди по-
падаются в ловушку «столбняка анализа». Они боятся отойти от моделирования,
потому что хотят добиться совершенства моделей. Я подозреваю, что по той же
причине они тратят много времени на создание и поддержку документации. Когда
что-то изменяется, они возвращаются назад и совершенствуют мириады артефак-
тов, на которых основывается эта часть системы. Это наполняет их чувством спо-
койствия, потому что они думают, что делают полезную работу. К сожалению,
с точки зрения гибкого моделирования, это является большим заблуждением.
Истинная цель разработчиков — создать ПО, отвечающее потребностям пользо-
вателей. Имеет ли создание кипы документации существенное значение для до-
стижения этой цели? Нет. Конечно, вам нужна документация, но ее не должно
быть очень много. Я еще раз напоминаю вам о методике экстремального програм-
мирования (ХР) «Путешествуйте налегке». Вы хотите иметь минимальное коли-
чество артефактов, необходимых в вашей ситуации. Для проекта ХР минималь-
ным количеством артефактов является исходный код и тестовые варианты, в то
время как в унифицированно^ проекте фирмы Rational (RUP), кроме упомяну-
тых артефактов, вы должны включить еще и модели требований и архитектуры.
Кроме того, вы хотите как можно меньше работать над артефактами, которые вы
будете поддерживать. Выполнение большей работы,* чем это необходимо, не име-
ет никакого смысла. Это означает, что вам придется совершенствовать ваши арте-
факты в рамках вашего проекта.
По ту
сторону UML
UML очень далек от совершенства.
Унифицированный язык моделирования (UML) (Object Management Group,
2001) определяет стандартную промышленную нотацию и семантику для приме-
нения этой нотации к моделям систем, созданных при помощи объектно-ориенти
рованных (00) или компонентных технологий. Артефактами UML, описанными
в приложении А являются: диаграмма деятельности, диаграмма классов, компо-
нентная диаграмма, диаграмма размещения, диаграмма последовательности, диа-
грамма состояний и диаграмма Use Case. На самом деле сейчас трудно найти книгу
или средство, где не говорилось бы об использовании UML. UML предоставля-
ет распространенную и устойчивую нотацию для описания 00 и компонентных
систем, тем самым снижая кривую трудоемкости обучения разработчиков, потому
что им будет необходимо освоить всего лишь один язык моделирования (по край-
ней мере, теоретически). UML, безусловно, является шагом в верном направле-
нии, хотя бы просто потому, что мы больше не устраиваем «войны нотаций», как
в середине 90-х, но он тоже далек от совершенства.
Цель этой главы — помочь разобраться с заблуждениями и маркетинговыми
уловками, связанными с UML, так как без четкого понимания реалий UML вы не
сможете добиться успеха в моделировании. В этой главе я расскажу о том, что:
• только UML недостаточно для разработки бизнес-ПО;
• UML сложнее, чем нужно большинству разработчиков;
• UML — это не методология или процесс;
• концепция исполняемого UML опережает свое время.
UML — это еще не все
Принцип AM «Множество моделей» говорит о том, что вам придется освоить мно-
жество методик моделирования, если вы хотите стать преуспевающим разработчи-
UML — это еще не все 201
ком. Приложение А представляет собой обзор множества распространенных арте-
фактов моделирования, включая унифицированный язык моделирования (UML),
но не ограничиваясь только им. Как видно из приложения, существует масса различ-
ных моделей. Каждая из моделей имеет свои плюсы и минусы, поэтому ни одна мо-
дель не является идеальной для нужд разработки. Хотя UML на самом деле доста-
точно устойчив, одного только UML недостаточно для моделирования. Например,
если я разрабатываю пользовательский интерфейс приложения, я обычно создаю
диаграмму потоков пользовательского интерфейса (рис.15.1). Эта диаграмма позво-
ляет моей группе представить полную картину взаимодействия пользователя с сис-
темой и выяснить важные вопросы, связанные с практичностью, задолго до создания
пользовательского интерфейса. К сожалению, UML не включает в себя подобную
диаграмму и никогда не будет ее включать. Поэтому если вы ограничите свой «ре-
пертуар» моделей только артефактами, определенными UML, вы отказываетесь от
потенциального увеличения продуктивности за счет этой методики. Разработчики
бизнес-приложений создают модели данных, представляющие физический дизайн
баз данных, но UML опять же-не включает в себя подобные модели. К счастью, ве-
дется работа по добавлению модели данных в UML (Найбург и Максимчук, 2001)1.
Рис. 15.1. Диаграмма, показывающая навигационный поток
внутри пользовательского интерфейса
1 Я не думаю, что нотация, представленная в данной книге, будет принята рабочей группой по
менеджменту объектов (OMG). Тем не менее я считаю, что данная книга является важным шагом
к возможности моделирования данных с помощью UML. В любом случае ее стоит прочитать.
202 Глава 15 • По ту сторону UML
Хотя U ML определяет набор важных моделей, я настоятельно рекомендую
применять их в соответствии с методикой «Применяйте стандарты моделиро-
вания». На самом деле UML сузил рамки обсуждения в мире моделирования.
Конечно, иногда возможно использовать диаграммы UML в ситуациях, для ко-
торых они на самом деле не предназначены. Например, диаграмма деятельности
UML очень часто используется при моделировании бизнес-процесса (рис. 15.2).
Однако это всегда далеко от идеала. Например, в диаграмме деятельности UML вы
не сможете отразить место хранения информации (например, папка «Входящие»
на чьем-то рабочем столе или реляционная база данных). Эту информацию важ-
но знать, когда вы изучаете текущий физический бизнес-процесс. Все же вы мо-
жете добавить в диаграмму кружок под названием «Разместить заказ в хранили-
ще», но это не будет иметь такого же зрительного эффекта, как символ хранилища
данных «Входящие», используемый в моделирующей процесс диаграмме потоков
данных (DFD). Существует множество ситуаций, в. которых диаграмма деятельно-
сти UML является наилучшим решением, но, к сожалению, моделирование суще-
ствующего физического процесса не является одним из них. Гибкие разработчики
следуют методике «Применяйте нужный артефакт (артефакты)» и предпочитают
применять лучшие методики, подходящие в данной ситуации. В этом случае со-
здание DFD является лучшим решением, чем диаграмма деятельности UML.
Рис. 15.2. Бизнес-процесс, изображенный при помощи диаграммы деятельности UML
UML — это не методология или процесс ' 203
По моему мнению, только UML недостаточно для разработки бизнес-прило-
жения, хотя это и является важной частью общей картины. Даже Rational Unified
Process (RUP) (Rational Corporation, 2001) (придуманный в той же организации,
которая впервые предложила UML) включает в себя артефакты, не относящиеся к
UML (например, бизнес-правила, модели баз данных и диаграммы потоков поль-
зовательского интерфейса). Почему так важно признать, что только UML недо-
статочно? Во-первых, используя другие артефакты, вам будет удобнее оценивать
средства разработки. Инструментальные средства для UML важны, но их недоста-
точно. Инструментальные средства также должны опираться на другие артефакты
моделирования, необходимые для вашего проекта. Во-вторых, вам легче будет оце-
нивать работу разработчиков (включая консультантов и подрядчиков). «Чего не
хватает в UML?» — это хороший вопрос для собеседования. Человек, действитель-
но имеющий опыт разработки различных систем, с легкостью на него ответит, а для
человека, не имеющего практического опыта, этот вопрос покажется сложным.
UML — это слишком сложно
Когда вы изучите артефакты, определенные для работы в UML, вы сразу же увиди-
те, что нотация и семантика для этой нотации слишком разнообразны и, вероятнее
всего, не понадобятся вам в полном объеме. На самом деле 80 % моделирования
объектов в объектно-ориентированной разработке можно выполнить, используя
20 % нотации UML. Закон Парето применительно к объектам состоит в том, что
в UML слишком уж много всего. UML громаден. Он наводит'ужас на человека, не
знакомого с объектно-ориентированной разработкой. UML — удивительная шту-
ка. С одной стороны, он слишком мал, с другой стороны — слишком велик.
UML — это не методология или процесс
Типичным заблуждением, связанным с UML, является то, что его считают процес-
сом. На самом деле это совсем не так. UML определяет нотацию для набора диа-
грамм и семантику (правила) для применения этой нотации — и ничего больше.
Он не определяет, когда создавать эти диаграммы и как это делать. Он всего лишь
определяет, какие это должны быть диаграммы. По моему мнению, существует не-
сколько причин для возникновения подобных заблуждений:
• Люди не удосужились изучить UML.
• Они путают его с унифицированным процессом (UP). UML и UP возникли
в одной организации Rational Corporation и имеют похожие названия. UP
действительно является процессом (я описываю его в четвертой части дан-
ной книги), но многие разработчики не отличают UML от UP.
. • Исторический прецедент. Языки моделирования (моделирование нотаций
данных или моделирование нотаций процесса), предшествующие UML, были
действительно связаны с методологией. На самом деле нотации, послужив-
шие основой для UML — нотация методики моделирования объектов (ОМТ)
204 * Глава 15 • По ту сторону UML
(Рамбо и др., 1991), нотация Буча (1994) и нотация Objectory (Джекобсон и
др., 1992) — были связаны с методологиями. Для многих разработчиков язык
моделирования связан с методологией, но UML не является таким языком.
Не рассчитывайте на появление
исполняемого UML в ближайшем будущем
Вы когда-нибудь мечтали о том, чтобы можно было нарисовать несколько диаграмм,
нажать на кнопку и получить работающую систему, отвечающую вашим требова-
ниям? Так не бывает, верно? Может быть, но именно это лежит в основе концеп-
ции исполняемого UML. Основная идея состоит в том, что вы будете использовать
CASE-средство для разработки подробных диаграмм UML, добавлять к ним специ-
фикации, написанные на формальном языке (вероятнее всего, на объектном языке
ограничений (OCL) от OMG (Уорнер и Клепп, 1999)). Базисная идея исполняемого
UML заключается в том, что системы можно моделировать на более высоком уров-
не абстракции, чем исходный код, обеспечивающем подтверждение правильности ва-
ших усилий, а затем транслировать в эффективный программный код. Более высокий
уровень абстракции должен помочь избежать преждевременного дизайна, позволит
вам изменять вашу систему по мере изменения требований и отсрочить решения по
реализации до последней минуты. Мне кажется, в теории все звучит просто велико-
лепно, но, к сожалению, возникает ряд проблем с применением этого на практике.
Только UML недостаточно. UML явно недостаточно для разработки бизнес-
приложений, как я ранее утверждал, поэтому попытки разработать систему, осно-
ванную только на моделях UML, на данном этапе не увенчаются успехом.
Интеграцию набора инструментальных средств для поддержки исполняемо-
го UML на данном этапе нелегко осуществить. Давайте предположим, что не-
сколько производителей инструментальных средств решат обеспечить инстру-
ментальными средствами концепцию исполняемого UML и устранить недостатки,
свойственные UML. Как они смогут это сделать? В идеале некоторые из компаний
направят свою работу на создание хороших средств моделирования, в то время как
другие — на выпуск работающих систем, в основу которых положены эти средства.
Одни производители будут выпускать системы для среды J2EE, другие — для сре-
ды .NET, а третьи — для мейнфрейм-среды. Для обеспечения этого необходим об-
щий стандарт для обмена информацией между средствами. Сразу же вспомина-
ется стандарт обмена метаданными (XMI) рабочей группы OMG на основе XML,
хотя из-за того, что XMI сам основывается на языке UML и метамодели общего
хранилища данных (CWM), его все равно недостаточно для полного определения
ПО. Несмотря на то что CWM обеспечивает определение информации об устой-
чивости системы, нам все равно нужно задать другие аспекты системы (например,
пользовательский интерфейс). Из-за того что не существует единого стандарта,
различные производители создают средства с различным расширением, что при-
водит к трудностям при интеграции средств различных типов.
Использование однотипных средств может оказаться слишком узким.
Другой подход, который могут применить производители инструментальных
Как применять UML на практике 205
средств, — это разработать инструментальные средства, поддерживающие и спо-
собность моделировать, и способность генерировать код. В теории это звучит до-
вольно убедительно. Но из-за огромного разнообразия платформ и вариантов ди-
зайна каждый производитель инструментальных средств должен будет занять
определенную нишу. Возможно, одни производители будут специализировать-
ся на производстве J2EE, поддерживающей Java Server Pages (JSPs), сервлеты,
Enterprise JavaBeans (EJBs) и реляционные базы данных. Другие будут специали-
зироваться на производстве приложений толстого клиента на Java, а третьи — на
производстве '\¥т32-приложений толстого клиента. Смысл состоит в том, что ор-
ганизациям, которые разрабатывают средства для нескольких платформ, потре-
буется несколько основных средств разработки. Их необходимо будет, покупать и
обслуживать, что потребует больших расходов. Более того, разнообразие необхо-
димых функциональных возможностей таких средств усложняет задачу, стоящую
перед производителями (сосредоточиться на одном аспекте концепции исполняе-
мого UML), что препятствует улучшению всей среды разработки.
Я нисколько не сомневаюсь, что через несколько лет мы станем свидетелями
появления некоторых интересных инструментальных средств1, основанных на
концепции исполняемого UML, но я подозреваю, что эта концепция (так же как
и похожие концепции прошлого) будет иметь недостатки. Программисты будут
нужны всегда. Будет ли такое средство гибким? Возможно. Если возможно раз-
работать средство, которое будет легко использовать, с помощью которого мож-
но производить ПО, подходящее для вашей среды, и которое приносит прибыль
от ваших вложений, в отличие от других подходов к разработке (в соответствии
d принципом «Повышайте отдачу от ресурсов, полученных от заинтересованных
лиц»), тогда я назову его гибким. Появится ли вскоре подобное средство, отвеча-
ющее этим требованиям? Нет. Возможно, я слегка пресыщен опытом 80-х, когда
производители CASE-средств наобещали работникам индустрии IT подобных ве-
щей. Я считаю, что сложности разработки ПО и темп технологических изменений
опередят производителей инструментальных средств, и они не смогут генериро-
вать подходящий исходный код, отвечающий требованиям. Другими словами, я
подозреваю, что сапожнику еще некоторое время придется обходиться без сапог
или, говоря языком разработчиков, без «основных средств». В главе 10 я рассмат-
риваю эффективность и реальность использования инструментальных средств
более подробно.
Как применять UML на практике
Следующие методики должны помочь в применении UML на практике:
Используйте UML в качестве основы моделирования. Для объектно-ориен-
тированной и компонентной разработки вам следует использовать UML в каче-
стве основного набора методик моделирования, к которому следует добавлять дру-
гие методики, соответствующие потребностям вашего проекта. Более того, я бы не
1 Существует несколько интересных инструментальных средств, поддерживающих идею об ис-
полняемых моделях, но они требуют расширения UML.
206 Глава 15 • По ту сторону UML
стал заменять UML другими артефактами. Хотя я убежден в том, что моя нотация
для моделирования классов (Амблер, 1995) является более совершенной, нежели
UML, но из-за того, что она менее распространена, ее использование для создания
диаграмм будет создавать сложности в их понимании другими разработчиками,
ухудшая общение в вашей группе.
Примите критическое подмножество нотации. Если для выполнения 80%
работы по моделированию вам требуется 20 % нотации UML, тогда начинай-
те с критических 20 %. Хорошим началом могут стать следующие пособия: UML
Distilled 2/е (Мартин Фаулер и Кендалл Скотт, 1999) и The Object Primer 2/е
(Амблер, 2001а).
Научите всех разработчиков работать в UML.
Не попадитесь на удочку рекламы UML. Отрицательной стороной популяр-
ности UML стало то, что он стал модным маркетинговым словечком для произ-
водителей инструментальных средств, консультантов и даже создателей методик.
Это хорошо, что консультант является экспертом в UML, но вам нужен эксперт
в разработке. С появлением новых технологий (таких как XML или .NET) или ме-
тодик (например, ХР) сторонники UML быстро принимают их и пишут книги под
названием «.XYZ++ и UML» или «UML для .XYZ++». Вместо того чтобы задать
вопрос: «Как применять UML с .XYZ++?», они спросят: «Как смоделировать при-
ложение на основе .XYZ++?».
Диаграммы, определенные UML, являются важными инструментальными
средствами в копилке опыта гибкого разработчика. В этой главе я рассмотрел не-
которые проблемы, связанные с применением UML, и надеюсь, что мне удалось
развеять связанные с ним заблуждения. . *
ЧАСТЬ
Гибкое моделирование
и экстремальное1
программирование (ХР)
В этой части я описываю совместное применение AM и ХР. Сюда входят сле-
дующие главы:
► Глава 16: Восстанавливаем справедливость. В данной главе рассматривается
идея и природа моделирования в ХР-проекте. Из не.е становится ясно, что мо-
делирование является важной частью ХР-проекта.
► Глава 17: Гибкое моделирование и экстремальное программирование. В этой
главе изучается соответствие между ХР и AM, а также рассматривается воз-
можность применения методик ХР «Рефакторинг» и «Сначала-тест-потом-
программа» в гибком моделировании.
► Глава. 18: Гибкое моделирование в жизненном цикле ХР-проекта. В ней при-
водится обзор жизненного цикла ХР-проекта. Также речь идет о применении
методик AM для повышения эффективности работы в ХР-проекте.
► Глава 19: Моделирование на этапе исследования в ХР-проекте. В этой гла-
ве рассматривается применение методик AM при выяснении первоначальных
требований в ХР-проекте и разработка вариантов архитектуры на примере
SWA Online.
► Глава 20: Моделирование во время ХР-итерации: поиск товара. В данной
' главе подробно изучается применение методик ХР во время реализации стра-
ницы поиска на примере SW A Online.
► Глава 21: Моделирование во время ХР-итерации: подсчет общей суммы за-
каза. В ней рассматривается моделирование подсчета общей суммы заказа
в ХР-проекте на примере SWA Online.
Восстанавливаем
справедливость
Пока вы закодируете один проект, вы могли бы
сравнить и сопоставить три проекта с помощью
рисунков.
Кент Бек. «Руководство
по экстремальному программированию»
Гибкое моделирование — это основанный на методиках упорядочивающий про-
цесс, объясняющий, как создавать модели и документацию эффективным и
гибким способом. В главе 1 я утверждал, что одна из целей гибкого моделиро-
вания — выяснить, как применять моделирование в процессах создания ПО с ис-
пользованием гибкого подхода типа экстремального программирования (ХР, Бек,
2000). Поскольку задачи ХР гораздо шире, чем задачи AM (ХР целиком охва-
тывает жизненный цикл проекта по разработке ПО), ХР является оптимальной
«испытательной площадкой» для применения методик гибкого моделирования.
Далее, хотя моделирование явно считается частью процесса ХР, нет подробных
объяснений, как выполнять моделирование удобным для большинства разработ-
чиков образом, — и именно гибкое моделирование призвано решить эту проблему.
К счастью, ХР, как и AM, является гибкой методологией, основанной на методи-
ках, что обуславливает концептуальное сходство между ними. Гораздо сложнее,
например, увязать вместе гибкое моделирование и предписывающий процесс типа
унифицированного процесса (Unified Process, Кратчен, 2000; Амблер, 2001b), ко-
торый будет рассмотрен в четвертой части этой книги.
Существует несколько распространенных заблуждений относительно модели-
рования в проекте ХР. Вот три основных заблуждения: вы не моделируете вообще;
вы не создаете никакой документации; если вы моделируете, то делаете это толь-
ко с помощью артефактов UML. В данной главе я рассмотрю эти заблуждения, но
сначала я объясню их происхождение, так что вы сможете справиться с другими
заблуждениями, если таковые возникнут. Изучив беседы, проводимые на форуме
www.agilemodeling.com/feedback.htm, я понял, что заблуждения обычно возникают
по следующим причинам:
Незнание ХР. Основным источником информации для большинства разра-
ботчиков является Интернет (группы новостей и переписка с коллегами). При
Моделирование является частью ХР 209
освоении новой технологии люди обычно подключаются к группе новостей или
списку рассылки, например на сервере Yahoo (groups.yahoo.com), и начинают изу-
чать группу или список. Допустим, кто-нибудь поместил там неверную информа-
цию, а другие приняли ее как официальную, особенно если у них еще не было воз-
можности испытать ее в деле. Не доверяйте всему, что вы видите и слышите.
Сомнительные источники информации по ХР. Качество опубликованной ин-
формации весьма сложно определить, будь она в печатном или в электронном
виде. Иногда ошибки получаются непреднамеренно (со мной это было не раз и не
два), а иногда неверная информация размещается с умыслом. Когда вы знакоми-
тесь с новым для вас предметом, вы часто не можете отличить надежные источни-
ки информации от сомнительных. Если вы пользовались сомнительными источ-
никами, то очень легко понять идею ХР превратно. Я рекомендую вам посетить
страницу ресурсов -гибкого моделирования www.agilemodeling.com/resources.htm.
Там вы найдете постоянно обновляющийся список заслуживающих доверия ре-
сурсов по ХР и прочим гибким процессам разработки ПО.
Неспособность видеть дальше собственного носа. Многие разработчики
находятся в условиях, далеких от идеала. Методики ХР часто оказываются со-
вершенно чуждыми для вашей среды. Такие методики, как «Программирование
в паре» или «Сначала-тест-потом-программа», являются новшеством для боль-
шинства организаций. Если вы не можете принять методику программирования
в паре, то ХР вам не поможет. Однако вместо того, чтобы признать, что ХР не ра-
ботает в их среде, многие люди заявляют, что ХР не работает вообще. На самом
деле ХР работает в подходящей для него среде. Возможно, ваша ситуация просто
не подходит для применения ХР.
Люди пугаются слова «экстремальный». Само название «экстремальное про-
граммирование» является одновременно самой сильной и самой слабой стороной
этого подхода. Когда люди слышат, что ХР советует путешествовать налегке и со-
кратить объем документации, они понимают это как полный отказ от создания
документации. Это экстремально, не так ли? Или возьмем совет ХР относитель-
но применения простых способов моделирования типа историй пользователя или
карточек CRC. Некоторые понимают это как призыв не заниматься моделирова-
нием вообще. Это тоже экстремально, да? Ну что тут скажешь...
В данной главе я восстановлю справедливость относительно трех наиболее
важных проблем моделирования и ХР:
1. Моделирование является частью ХР.
2. Документация существует, и с этим приходится считаться.
3. ХР и UML.
Моделирование является частью ХР
Истории пользователя, так же как и карточки CRC, являются фундаментальным
аспектом экстремального программирования. Истории пользователя обеспечи-
вают высокоуровневый обзор требований к системе; они служат напоминанием
210 Глава 16 • Восстанавливаем справедливость
о том, что вам нужно обсудить требования вместе с заинтересованными лицами;
они также являются стартовой точкой для составления сметы и расписания про-
екта, а еще они помогают определить задачи разработки и приемочных тестов.
Карточки CRC используются для изучения структуры, для концептуального мо-
делирования с целью понимания проблемы или для проектирования с целью вы-
яснить структуру создаваемого вами ПО. Как истории пользователя, так и карто-
чки CRC являются моделями (см. приложение А),-следовательно, моделирование
является частью ХР. ХР-разработчики также создают схемы или грубые наброс-
ки, обычно на белой 'Доске или просто на клочке бумаги, если истории пользова-
теля или карточки CRC не подходят в той или иной ситуации. В первой книге об
ХР «Экстремальное программирование» (Бек, 2000) Кент Бек приводит наброски
диаграмм классов и другие, диаграммы произвольной формы. Короче говоря, мо-
делирование является фундаментальным аспектом экстремального программиро-
вания.
Документация существует,
и с этим приходится считаться
Документация также является важной частью ХР. Вот что говорит по этому пово-
ду Рон Джеффрис (2001b):
«За пределами ХР-проекта вам наверняка понадобится документация, так что
не сомневайтесь в необходимости ее написания. Внутри же проекта вам обычно
вполне достаточно устного общения. Почувствуйте разницу».
Давайте рассмотрим данное высказывание подробно. Во-первых, ХР признает,
что документация создается для людей, которые не входят в вашу группу, (в гиб-
ком моделировании они называются «заинтересованные лица»). Во-вторых, уст-
ное общение между членами группы снижает необходимость создания внутрен-
ней документации. Это достигается за счет того, что группа сосредоточена в одном
месте, что облегчает общейие, и таких аспектов ХР, как «Программирование в
паре» и «Совместное владение», которые способствуют общению между разработ-
чиками. В главе 14 говорится, что документация — лишь один из способов обще-
ния, причем наименее эффективный, который легко может быть заменен личным
общением. В-третьих, ХР признает, что иногда вашей группе необходима внутрен-
няя документация. Это перекликается с советом, содержащимся в книге «Extreme
programming installed» (Джеффрис, Андерсен и Хендриксен, 2001). Авторы отме-
чают, что информация, полученная в результате общения с заинтересованными
лицами с целью создания истории пользователя, фиксируется в дополнительной
документации, прикрепляемой к карточке. Я подробно рассмотрю этот вопрос в
главе 18. В-четвертых, данное высказывание подразумевает, что члены группы ХР
сами знают, в каких случаях нужно создавать документацию, и действуют соот-
ветственно. В-пятых, вы должны позволить своей группе действовать по собствен-
ному усмотрению, хотя во многих организациях на это сложно решиться. Если
ваша группа не заслуживает доверия, то у вас серьезные проблемы, которые надо
решать независимо от того, какому процессу вы следуете. Если же группа заслу-
Документация существует, и с этим приходится считаться 211
живает доверия, но политика вашей организации не позволяет вам действовать
на основе доверия, то это тоже серьезная проблема. Если вы не входите в груп-
пу ХР и не принимаете активного участия в обсуждениях и прочей деятельности,
которая уменьшает необходимость создания документации, то вам может пока-
заться, что вам предоставляют недостаточно документации. В таком случае вмес-
то того, чтобы заставлять группу писать документацию, найдите время, чтобы вы-
яснить, так ли важна эта документация, как вам кажется. Обсудите это с группой,
и если эта документация действительно важна, то они ее сделают. Как говорит Рон
Джеффрис: «Мы занимаемся экстремальным программированием, а не дурака ва-
ляем» (Джеффрис, 2001е). И, наконец, самое главное для ХР-группы — если до-
кументация необходима, то ее следует создать.
ХР-проекты меньше нуждаются в создании документации, что обусловле-
но некоторыми методиками ХР. Во-первых, разработка строится по принципу
«Сначала-тест-потом-программа» и сосредоточена на приемочных тестах, так что
сразу видно, работает ли система и отвечает ли она поставленным требованиям.
Для разработчиков эти тесты играют роль важной документации, так как они по-
казывают, как на самом деле работает код. Что вы выберете для ознакомления с
системой: кипу документации или образец исходного кода? Многие разработчи-
ки предпочитают начать с образцов исходного кода, а они содержатся в тестовом
наборе. Во-вторых, ХР добивается простоты, а методика рефакторинга позволяет
получить ясный и понятный код. Если код и так понятен, то зачем писать сопут-
ствующую документацию? Это касается как внешней, так и внутренней докумен-
тации — зачем писать комментарий к ясному и понятному коду? Если код непо-
нятен, усовершенствуйте его с помощью рефакторинга или уж, на худой конец,
напишите документацию. Даже если среда разработки легко позволяет встроить
документацию в код (например, Javadoc в Java), все равно имейте в виду следую-
щее: документацию нужно создавать не тогда, когда это легко, а когда это необхо-
димо.
Многих смущает тот факт, что ХР не называет конкретно документы, которые
нужно создать в процессе разработки, в отличие от унифицированного процесса
(Кратчен, 2000; Амблер, 2001b), который перечисляет множество артефактов, не-
обходимых для проекта. ХР предлагает работать совместно с заинтересованными
лицами в условиях, обеспечивающих быструю обратную связь, и доверить им ре-
шать, что нужно для успеха проекта, будь то документация или что-нибудь еще
(Джеффрис, 2001b). Еще раз повторяю, вам нужно научиться доверять всем лю-
дям, участвующим в проекте. В главе 14 я перечислил документы, которые вы мо-
жете создавать, и объяснил, в каких случаях это следует делать.
Одно из величайших заблуждений, связанных с ХР, касается принципа «Путе-
шествуйте налегке». Многие понимают это как полное отсутствие необходимости
создания документации. Ничего подобного! Смысл «путешествия налегке» за-
ключается в том, что вы создаете ровно столько моделей и документации, сколько
необходимо. Большее или меньшее количество может грозить провалом проекта.
В главе 14 я дал вам хороший практический совет: чтобы убедиться, что вы путе-
шествуете налегке, не создавайте модель или документ, пока в этом нет необходи-
212 Глава 16 • Восстанавливаем справедливость
мости. Если вы поторопитесь, то рискуете потратить время на создание того, что
вам на самом деле не пригодится.
Создание документации в ХР-проекте, как и в AM-проекте, является чисто де-
ловым, а не техническим решением. Лучше всего по этому поводу высказался Рон
Джеффрис (2001b):
«Если заказчику необходим какой-либо документ, то он должен потребовать
создания этого документа, так же как он требует создания какой-либо возможно-
сти в системе, то есть с помощью карточки истории пользователя. Группа оценит,
во что обойдется создание документа, и заказчик может включить эти расходы
в любую из итераций проекта»,
ХР и UML
Поскольку понятие «ХР» стало модным в сфере информационных технологий (на-
зовем этот феномен .XYZ++), многие начинают задавать вопросы типа: «Можно
ли использовать .XYZ++1 вместе с .XYZ++2?». Если вы отвечаете утвердительно,
то они спрашивают: «Как использовать .XYZ++1 вместе с .XYZ++2?». Дальше —
больше, и теперь люди начинают спрашивать, можно ли использовать ХР вмес-
те с сетевой службой, CORBA, EJB ’, .NET, Linux, OSS (открытые программные
средства) и, конечно, UML, так что давайте обсудим два основных вопроса:
1. Можно ли использовать UML вместе с ХР? Да. Вы можете применять арте-
факты UML (диаграммы деятельности, диаграммы классов, диаграммы сотрудни-
чества, диаграммы последовательности, диаграммы состояний и диаграммы Use
Case), если при разработке вы используете подход ХР.
2. Как использовать UML вместе с ХР? Как минимум, вы должны следовать
методике AM «Применяйте нужные артефакты» и применять артефакты UML
в ХР-проектах только там, где это возможно. В идеале при этом вы должны при-
менять все принципы и методики AM.
Погодите минутку. Принцип AM «Множество моделей» говорит, что вы долж-
ны уметь моделировать различные типы артефактов. Согласен, с помощью UML
можно смоделировать много артефактов, но этого недостаточно. Как я уже говорил
в главе 15, для разработки современных коммерческих приложений UML явно не-
достаточно. К счастью, помимо UML-артефактов, существует множество других,
в чем мы можем убедиться, открыв приложение А. Сдается мне, что у нас возник-
ла проблема. Если UML недостаточно для разработки современных коммерчес-
ких приложений, а вы пытаетесь разработать такое приложение с помощью мето-
дик ХР, то нельзя ставить вопрос следующим образом, то есть: «Как использовать
UML вместе с ХР?» Одна из проблем, связанная с использованием модных поня-
тий в разработке ПО, заключается в том, что если вы оперируете лишь модными
понятиями, то вы ограничиваетесь теми решениями, которые могут быть опреде-
лены в рамках этих понятий. Таким образом, я считаю, что к приведенным выше
вопросам по модным словам следует добавить еще парочку: «Правильно ли за-
1 Как применять в этом случае методики и принципы ХР и AM, рассказывается на примере про-
екта EJB в книге «Mastering EJB 2/е» (Роман, Амблер и Джуэлл, 2002).
XPmUML 213
давать вопрос о возможности совместного использования .XYZ++1 и .XYZ++2?»,
а если ответ отрицательный, то: «Как правильно задать вопрос?». Если задать эти
вопросы применительно к ХР и UML, то быстро понимаешь, что уместнее задать
вопрос типа «Как эффективно применять моделирование в ХР-проекте?». Ответ
на этот вопрос успешно дает методика AM, и именно в этой главе.
СОВЕТ: НЕ ВСЕ АРТЕФАКТЫ UML ОДИНАКОВО ПОЛЕЗНЫ ------------------------
Истории пользователя (Бек, 2000) являются важной частью ХР, так как они служат основой
для формирования требований к системе и планирования проекта (Игра планирования). Также
они являются основными артефактами, определяющими фронт работ вашей группы в течение
той или иной итерации конструирования. Кроме того, истории пользователя служат основой
для разработки приемочных тестов. Истории пользователя не входят в UML, который вместо
них предлагает другой артефакт — диаграмму Use Case, изображающую взаимоотношения
между актерами, взаимодействующими с системой, и элементами Use Case, описывающими
требования к системе, основанные на практичности. Приложение А ясно показывает, что
элементы Use Case и истории пользователя взаимозаменяемы. Хотя это явно разные артефакты,
они оба применяются для описания требований к системе, основанных на практичности. Таким
образом, если вы уже применяете один из них, вам вряд ли понадобится другой. Суть в том,
что раз истории пользователя являются неотъемлемой частью ХР, то вы не станете применять
элементы Use Case в проекте, а значит, не будете создавать UML-диаграммы Use Case. Еще раз
напоминаю вам о методике AM «Применяйте нужный артефакт (артефакты)».
Другая интересная комбинация модных слов — как использовать основанную
на моделях архитектуру (Model Driven Architecture, MDA) (Object Management
Group, OMG, 2001b) вместе с XP? MDA является частью представления OMG
и поддерживает взаимодействие спецификаций, определяющих отношения меж-
ду стандартами OMG (такими как UML и CORBA) и их совместное использо-
вание координированным способом. MDA определяет подход к системной спе-
цификации, которая учитывает различия между не зависимыми от платформы
моделями (Platform Independent Models, PIM), определяющими систему путем
абстрагирования от технических деталей, и специфичными для платформ мо-
делями (Platform Specific Models, PSM), зависящими от технических условий.
MDA также учитывает различия между формальными и неформальными моде-
лями. Формальные модели основаны на языке (например, UML), имеющем сло-
жившийся синтаксис и семантику, а также определенный способ подтверждения
пригодности его конструкций — правила анализа, заключения и доказательства.
Неформальные модели, как вы и предполагали, не имеют сложившейся структу-
ры. MDA требует применения именно формальных моделей, так как они направ-
лены на определение взаимодействия между системами. Короче MDA определяет
набор правил для структуризации системных спецификаций, выраженных в виде
формальных моделей.
Теперь вернемся к вопросу «Можно ли использовать ХР и MDA вместе?».
Согласно точному определению. MDА, ответ отрицательный. Такие модели, как
карточки CRC (Каннингэм и Бек, 1989; Вилкинсон, 1995) и истории пользо-
вателя (Бек, 2000), являются неотъемлемой частью процесса разработки мето-
дом ХР, а поскольку они формально не определены, то теоретически вы не мо-
жетё использовать MDA вместе с ХР, хотя практически это вообще-то возможно.
MDA используется производителями CASE-средств в качестве концептуальной
214 Глава 16 • Восстанавливаем справедливость
основы, из которой они заимствуют некоторые идеи. Вообще-то идея с не зави-
симыми от платформы моделями и моделями, обусловленными платформой, су-
ществует уже несколько десятилетий, так что можно предположить, что вскоре
MDA-совместимые средства станут так же обычны, как UML-совместимые сред-
ства сегодня. UML-совместимость — понятие относительное, и каждое CASE-
средство имеет свои особенности применения UML. То же самое, по нашему мне-
нию, происходит и с MD А. Поскольку ХР-группа может применять любое средство,
какое пожелает (с условием, что применение этого средства повышает продуктив-
ность), то ХР-группа может также применять MDA-совместимое средство, если
того требует ситуация. Конечно, MDA-совместимые средства должны создавать
истории пользователя и карточки CRC без потерь их возможностей, многие из
которых основаны на создании этих артефактов с помощью простых средств типа
карточек. Так что я склоняюсь к мысли, что ответ на обсуждаемый нами вопрос
все же будет отрицательным.
Итак, каково резюме почтенного собрания?
Моделирование ^ документация являются важными аспектами ХР, так же как
и других методов разработки программного обеспечения. Однако ХР советует вам
сократить этот вид работы до необходимого минимума. К счастью, задачей AM яв-
ляется максимальное повышение вашей продуктивности при создании моделей
и документации. В следующей главе мы подробно рассмотрим возможности сов-
местного использования этих двух методологий.
Гибкое f
моделирование
и экстремальное
программирование
Рутина является организацией в такой же мере,
в какой паралич является порядком.
Сэр Артур Хелпс
В главе 1 я говорил о том, что гибкое моделирование (AM) должно применяться
совместно с какой-либо существующей методологией полного жизненного цик-
ла, для того чтобы улучшить ее подход к моделированию. В силу того что модели-
рование является частью экстремального программирования (ХР, Бек, 2000) (см.
главу 16), существует вероятность того, что применение гибкого моделирования
принесет пользу ХР-проекту. Конечно, это становится возможным только в том
случае, если подогнать AM к ХР, при этом не нанося ущерба ХР. Такие методики
ХР, как «Рефакторинг» и «Сначала-тест-потом-программа», весьма способству-
ют достижению двух важных целей: созданию четкого проекта и его продумыва-
нию до написания кода (именно эти цели преследуются традиционным подхо-
дом к моделированию). Мне известно из предыдущего опыта, что обе методики
(«Рефакторинг» и «Сначала-тест-потом-программа») служат хорошим дополне-
нием к гибкому моделированию и способствуют применению некоторых его ме-
тодик. В данной главе я рассматриваю следующие проблемы:
• Совместимость AM и ХР.
• «Рефакторинг» и гибкое моделирование.
• Методика «Сначала-тест-потом-программа» и гибкое моделирование.
• Какие методики гибкого моделирования следует принять?
Совместимость AM и ХР
Нам следует решить важный вопрос: как совмещаются AM и ХР. В табл. 17.1 пе-
речислены методики AM и установлено соответствие между ними и существую-
216 Глава 17 • Гибкое моделирование и экстремальное программирование
щими методиками ХР, а также обсуждается проблема подгонки методик AM, не
имеющих соответствия с ХР. Как обсуждалось в главе 1, многие методики AM
имеют полное соответствие с методиками ХР из-за того, что ХР легло в основу
AM. Однако поскольку целью AM является моделирование, некоторые методики
являются абсолютно новыми, поэтому существует вероятность того, что примене-
ние гибкого моделирования принесет пользу проекту ХР.
Но того, что методики AM и ХР являются комплиментарными, явно недо-
статочно. Должна существовать еще и философская согласованность между эти-
ми двумя методологиями. Я полагаю, что она существует. Во-первых, гибкое
моделирование принимает четыре ценности экстремального программирова-
ния — «Смелость», «Простота», «Общение» и «Обратная связь», при этом добав-
ляя пятую — «Смирение», которая явно не противоречит ХР. Во-вторых, принци-
пы AM согласуются с принципами ХР. Девять из восемнадцати заимствованы
из ХР, а остальные девять («Главная цель — программное обеспечение», «Еще
одна цель — продолжать проект», «Модель должна решать конкретную зада-
чу, «Множество моделей», «Содержание важнее формы», «Учитесь друг у дру-
га», «Знай свои модели», «Вам нужен набор методик»1 и «Повышайте отдачу от
ресурсов, полученных от заинтересованных лиц») не идут вразрез с философи-
ей ХР. Три принципа, характерных только для моделирования, могут заставить
опытного ХР-разработчика задуматься на мгновение, но, поразмыслив, он най-
дет их подходящими. Принцип «Модель должна решать конкретную задачу» со-
ветует нам не создавать модель без веской на то причины. Принцип «Множество
моделей» говорит о том, что существует множество приемов, которые мы можем
применять (включая карточки CRC, истории пользователей и диаграммы UML,
но не ограничиваясь ими), а принцип «Знай свои модели» советует вам понять,
что вы делаете, чтобы добиться успеха в. работе.
«Рефакторинг» и гибкое моделирование
«Рефакторинг» (Фаулер, 1999) является методикой для реструктурирования
кода дисциплинирующим образом. Эта методика является основополагающей в
ХР. Основная идея состоит в том, что вы вносите небольшие изменения (они на-
зываются рефакторингами) в код для поддержки новых требований и сохране-
ния максимально простого дизайна. Важным аспектом «Рефакторинга» являет-
ся то, что вносимые в код изменения не меняют его первоначальной семантики.
Например, если вы изменяете название операции, то весь исходный код, запуска-
ющий эту операцию, будет по-прежнему запускать эту операцию, используя но-
вое имя. Преимуществом «Рефакторинга» является то, что он помогает програм-
мистам легко и без потерь изменять код в соответствии с новыми требованиями
или для улучшения его качества.
Совместим ли «Рефакторинг» и AM? Безусловно. «Рефакторинг» — это мето-
дика, касающаяся кода, и в силу того, что AM не рассматривает проблемы, связан-
1 В авторский текст, очевидно, прокралась опечатка, и в этом разделе автор ошибочно называет
данный принцип как «Знай свои инструментальные средства». — Примеч. научи, ред.
Рефакторинг и гибкое моделирование 217
ные с программированием, они никак не связаны в техническом смысле. А как
насчет идейной связи? AM занимается проектным моделированием, а «Рефакто-
ринг» — улучшением исходного кода проекта. Возникает вопрос: «Что делать, ког-
да у вас есть существующая проектная модель, а вы подвергаете «Рефакторингу»
ваш исходный код?» Хотя этот вопрос интересен, проблема состоит в том, что вы
имеете дело с двумя артефактами: проектной моделью и исходным кодом, который
описывает проект вашей системы. Исходный код изменился. Теперь вам предсто-
ит решить, хотите ли вы изменять свою модель. Способ, при помощи которого вы
первоначально получили модель, не имеет значения. Вы могли получить ее, при-
менив гибкое моделирование или подход BDUF («Сначала все спроектируем»),
или изменив существующую модель и написав к ней код (например, несколько
организаций разработали устойчивую среду, опираясь на проект, который я пред-
лагаю на сайте www.ambysoft.com/persistenceLayer.html).
Таблица 17.1. Применение методик AM в ХР-проекте
Методика AM Совместимость с ХР
1 2
Активное участие заинтересованных лиц Эта методика является новым видением методики ХР «Локальный заказчик». В гибком моделировании вместо термина «заказчик» используется термин «заинтересован- ные лица» и речь идет об их активном участии, поэтому «Активное участие заинтересованных в проекте лиц» и «Локальный заказчик» — это не одно и то же
Применяйте стандарты моделирования Это версия методики ХР «Стандарты кодирования»
Не увлекайтесь паттернами Эта методика отражает принцип YAGNI («Это вам никогда не понадобится»), касающийся эффективного применения паттернов, и соответствует методике ХР «Простое проектирование»
Применяйте нужный артефакт (артефакты) Эта методика не описывается принципами и методиками ХР, хотя она совпадает с философией ХР «Делайте это, если это вам необходимо» и использованием наиболее подходящего инструментального средства или методики для выполнения работы
Совместное владение AM заимствовало методику ХР «Коллективное владение кодом»
Учитывайте тестируемость Эта методика является отражением методики ХР «Тестирование» в моделировании. Когда вы что-нибудь моделируете при помощи карточек CRC или набросков, вы должны учитывать тесты, которые вам понадобятся для проверки ваших идей, отраженных в моделях. Обратитесь к главе 10, где подробно обсуждается тестирование в AM
Создавайте несколько моделей параллельно Эта методика характерна для моделирования. Разработчики ХР могут работать над несколькими моделями (карточки CRC, тесты приемки, наброски), если им это будет необходимо
Продолжение &
218 Глава 17 • Гибкое моделирование и экстремальное программирование Таблица 17.1 {продолжение)
1 2
Создавайте простое содержание Эта методика является дополнением к методике ХР «Простое проектирование», которая советует создавать максимально простые модели
Изображайте модели просто Эта методика является дополнением к методике ХР «Простое проектирование», которая говорит е том, что ваши модели не обязательно должны быть совершенными для того, чтобы быть эффективными (карточки CRC и истории пользователя — прекрасный тому пример)
Избавляйтесь от временных моделей Эта методика отражает принцип ХР «Путешествуйте • , налегке», который был заимствован AM. Он предлагает избавляться от моделей, когда они больше не нужны
Демонстрируйте модели открыто Эта методика отражает ценность ХР (и AM) «Общение его принцип «Открытые и доброжелательные контакты» (заимствованный AM) и методику «Коллективное владение кодом»
Формализуйте модели соглашения Эта методика не отражена в ХР, хотя, возможно, ее можно обнаружить в его философии «Делайте это, если вам это нужно». Эта методика вошла в состав AM, чтобы стать руководством по решению стандартных проблем интеграции с другими системами
Переходите от одного артефакта к другому Эта методика соответствует применяемой ХР-разработ- чиками методике перехода от одного артефакта к другому (исходный код, карточки CRC и тесты)
, Моделируйте постепенно Эта методика опирается на итеративный и инкрементный подходы ХР к разработке. Для ХР и AM характерен последовательный подход к разработке и не свойствен подход «Сначала все спроектируем» (BDUF)
Моделируйте, чтобы общаться Методика «Моделируйте, чтобы общаться» характерна для моделирования. Она предлагает одну из причин создания модели и является отражением принципа ХР и AM «Открытые и доброжелательные контакты»
Моделируйте, чтобы понять Эта методика характерна для моделирования. Она объясняет первоначальную причину создания модели. Эта методика согласуется с методикой ХР об использовании карточек CRC дл'я изучения проблем дизайна и является обобщением этой идеи
Моделируйте в группе . Это вариант применения в AM методики ХР «Парное программирование»
Подтверждение модели кодом Эта методика является версией принципа ХР «Конкретное экспериментирование» д'ля AM. На самом деле, в AM она первоначально также называлась «Конкретное экспериментирование», хотя впоследствии была переименована
Используйте имеющиеся ресурсы • Эта идея не включена в ХР, хотя ХР и не исключает ее. Разработчики ХР практичны. Если что-то можно использовать повторно, они так и поступят
Методика «Сначала-тест-потом-программа» и гибкое моделирование 219
1 2
Совершенствуйте только в случае необходимости Эта методика отражает принцип ХР «Путешествуйте налегке»; который был заимствован AM. Он предлагает вам совершенствовать артефакт только в случае, если это необходимо
Используйте простейшие инструментальные средства Эта методика отражает принцип AM и ХР «Добивайтесь простоты» и соответствует подходу ХР, в котором предпочтение отдается простым средствам моделирования (например, набору карточек)
Эта проблема не имеет ничего общего с типом проектной модели, будь то диа-
грамма классов UML, карточки CRC, физическая модель данных или процедур-
ная структурная схема. Плюсом является то, что AM дает советы о том, как спра-
виться с такой ситуацией. В частности, методика «Избавляйтесь от временных
моделей» предлагает вам подумать, нужна ли вам модель структуры. Если нет —
избавьтесь от нее. Методика «Совершенствуйте только в случае необходимости»
говорит о том, что нет смысла хранить такие артефакты, как проектная модель
и код, если они не синхронизированы.
Как применять AM совместно с «Рефакторингом»? Применяйте методики
AM во время моделирования, как это требуется, используйте модели в качестве
отправной точки для начала работ по программированию и подвергайте рефак-
торингу исходный код, как вы это обычно делаете. Если вы обнаружите, что вам
нужно произвести глобальный рефакторинг, соберите свою группу и обсудите с
ней эту проблему, моделируя, когда это будет необходимо, а потом приступайте к
глобальному рефакторингу, как вы это делали обычно: совершите несколько не-
больших рефакторингов.
Если вы подвергаете код «Рефакторингу», вам могут пригодиться средства об-
ратного моделирования и конструирования, особенно если вы незнакомы с этим
кодом. У многих разработчиков хорошо развита зрительная память. Они легко за-
поминают информацию, представленную в виде изображений, но хуже запомина-
ют текст. Поэтому вам могут пригодиться CASE-средства, которые быстро импор-
тируют часть кода и создают из него диаграммы. Довольнр часто CASE-средства
используют для того, чтобы импортировать объектно-ориентированный исход-
ный код, написанный на Java или C++, и создавать диаграммы классов UML, ко-
торые показывают статичную структуру кода, а также диаграммы последователь-
ности UML, отображающие его динамичную природу. Эти диаграммы могут быть
использованы для того,, чтобы быстро понять существующий код, что является
первым шагом к его «Рефакторингу».
Методика «Сначала-тест-потом-программа»
и гибкое моделирование
Методика «Сначала-тест-потом-программа» предполагает работу короткими цик-
лами: вы задумываете тест, пишете тест и программный код для него, применяе-
те тест и продолжаете работать. Такие тесты включают в пакет для тестирования
220 Глава 17 • Гибкое моделирование и экстремальное программирование
интеграции системы, который запускается каждый раз, когда код отправляется в
общее хранилище. Эта методика является неотъемлемой частью ХР.
Совместимы ли методика «Сначала-тест-потом-программа» и гибкое модели-
рование? Безусловно. Как и «Рефакторинг», методика «Сначала-тест-потом-про-
грамма» в большей степени касается кода, поэтому они мало соприкасаются в
техническом плане. Однако существует возможность идейной связи, так как эта
методика касается детальной проектной структуры. Она дает разработчикам воз-
можность продумать код до его написания (это так же важно, как и получение об-
ратной связи по коду). Если вы решили заняться моделированием до написания
кода, например, для того чтобы обдумать проблему, охватывающую нечто боль-
шее, чем один тест, тогда все в порядке. На самом деле это может облегчить при-
менение методики «Сначала-тест-потом-программа», особенно если вы приняли
методику-AM «Учитывайте тестируемость».
Следуя методике «Сначала-тест-потом-программа», гибкие разработчики быст-
ро выясняют, работают их идеи или нет. Тесты либо подтвердят правильность мо-
дели, либо нет, что обеспечит быструю обратную связь с учетом идей, которые
выражены в моделях.
Как применять AM вместе с методикой «Сначала-тест-потом-программа»?
Как и в случае с «Рефакторингом», применяйте методики AM во время моделиро-
вания, как это требуется, используйте модели в качестве отправной точки для на-
чала работ по программированию, переходите от моделирования к тестированию
и программированию, когда это необходимо.
Какие методики гибкого
моделирования следует принять?
Принимайте только те методики, которые принесут пользу вашей группе в той ра-
боте, которой она сейчас занимается. В идеале примите хотя бы базовые методи-
ки AM, чтобы иметь право утверждать, что вы и в самом деле занимаетесь гибким
моделированием (я указываю на это в главе 5). Может быть, вы сможете принять
также и дополнительные методики. Имейте в виду, что. ваша цель — не просто ут-
верждать, что вы занимаетесь гибким моделированием. Ваша цель — повысить
продуктивность вашей работы по созданию ПО.
Совместное использование ХР и AM вполне возможно. Как вы уже убеди-
лись, AM и ХР имеют общие идеи, а методики ХР «Рефакторинг» и «Сначала-
тест-потом-программа» являются дополнением к AM. Остается только выяс-
нить, как методики AM могут быть использованы для повышения эффективности
ХР-проектов. Этой проблеме посвящены четыре следующие главы.
Гибкое
моделирование
в жизненном
цикле ХР-проекта
В его безумии есть метод.
Вильям Шекспир
Воистину безумен сей подход.
Однако, как Кент Бек нам обещает,
Сработать должен. Всякое бывает,
Чего уж там...1
Чтобы объяснить, каким образом гибкое моделирование применяется в ХР-про-
екте (Бек, 2000), я рассмотрю в качестве примера интернет-магазин SWA Online
(см. главу 1) и покажу, как моделирование выполняется в жизненном цикле
ХР-проекта. А что, у проекта ХР есть жизненный цикл? Да, есть. На рис. 18.1 по-
казана высокоуровневая схема жизненного цикла ХР-проекта (Уэллс, 2001), из-
мененная таким образом, чтобы продемонстрировать последовательность этапов
проекта по Беку (этап «Смерть», следующий за этапом «Сопровождение», на дан-
. ном рисунке не показан).
Прежде всего, не цепляйтесь за слово «этап». Хотя данное слово может вызвать
. ассоциации с каскадной разработкой, на самом деле этапы могут сменяться
итеративно, что ясно показано на рисунке — вы видите, что можно свободно пере-
двигаться между этапами «Планирование», «Итерации реализации» и «Произ-
водство». Этап не обязательно должен длиться долго — планирование, например,
может занять всего лишь несколько часов. Далее, группы ХР не задумываются о
том, что они работают поэтапно, — они просто работают, и все. К тому же часто не-
сколько этапов выполняются одновременно. Этап «Производство», например, час-
то совмещен с этапом «Итерации реализации». Мягко говоря, в ХР-проектах по-
нятие «этап» выражено нечетко, а участники проекта об этом почти не
задумываются. Однако понятие «этап» является важным, так как вносит динами-
ку в проект ХР. К тому же нам нужно воспользоваться этим понятием, чтобы раз-
1 Эпиграф от переводчика.
222 Глава 18 • Гибкое моделирование в жизненном цикле ХР-проекта
бить эту главу на разделы и рассмотреть каждую задачу разработки в виде отде-
льного этапа.
Т
Истории
пользователя
Сценарии тестирования
Требования
Архитектурная
проба
। Метафора •' Планирование 1 _ План
I системы . । реализации । реализации
,, । 1
Новая история пользователя.
Скорость проекта
Ошибки
Последняя Приемочные _Одобрение_
версия тесты
Малые U
заказчика ” реализации |
Неопределенные Определенные
оценки оценки
Следующая-
итерация
Проба
Этап
исследования
I j Этап
11 планирования
Итерации
реализации.
Этап
производства
Этап сопровождения
Рис. 18.1. Жизненный цикл ХР-проекта
Этап исследования
ХР-проект начинается с этапа исследования (Бек, 2000), который включает в себя
разработку архитектурных проб и первоначальных историй пользователя. Что ка-
сается требований, Бек советует, чтобы истории пользователя содержали доста-
точно материала для создания хорошей первой версии. Кроме этого, разработчи-
ки должны быть уверены в том, что лучший способ оценить проект — реализовать
систему. Всякий проект имеет свои задачи, обычно обусловленные первоначаль-
ными требованиями к системе. Хотя жизненный цикл ХР-проекта, изображенный
на рис. 18.1, явно не включает задачу определения объема проекта, понятно, что
истории пользователя являются основой для планирования реализации. Истории
пользователя вообще являются движущей силой методологии ХР — они обеспе-
чивают высокоуровневые требования к системе и служат основой для планирова-
ния. В общем, чтобы запустить ХР-проект, вам требуется некоторое количество
(скажем, от пяти ho пятидесяти) историй пользователя.
Однако возникает следующая проблема. Когда вы начинаете работу над про-
ектом, ваш подход к созданию ПО может быть еще не определен. Решение прини-
мается после того, как определены задачи проекта и его участники. Тип процесса
разработки должен максимально соответствовать вашему проекту, группе и куль-
туре организации (Кокберн, 2002). Если решение об использовании ХР еще не
принято, то люди, выполняющие работу по моделированию базовых требований
(IRUF), могут начать создавать что-нибудь другое (обычно это директивы, харак-
теристики или элементы Use Case), а не истории пользователя. Если именно так
и произошло, вам придется преобразовать эти артефакты в истории пользователя,
при необходимости работай вместе с заказчиком (в целях сохранения термино-
логии ХР, я буду говорить «заказчик», а не «заинтересованное лицо»). К счастью,
Этап планирования 223
директивы и характеристики во многом сходны с историями пользователя, так
что здесь не возникнет никаких проблем. Поскольку элементы Use Case обычно
содержат больше информации, чем истории пользователя, то проще всего объ-
явить их историями пользователя и разделить на части, чтобы с ними было легче
работать. Примеры моделирования на этапе исследования в ХР-проекте приво-
дятся в главе 19.
Этап планирования
За этапом исследования идет этап планирования (Бек, 2000), цель которо-
го — путем переговоров между вами и заказчиком назначить дату, когда бу-
дет реализован минимальный, но в то же время самый важный набор историй
пользователя. При планировании реализации вам придется использовать ме-
тод «мозговой атаки» (Уэйк, 2002) путем создания карточки задач для каждой
задачи из истории пользователя, что обеспечит вам понимание истории поль-
зователя, достаточное для оценки сложности ее реализации. Карточка задач
(рис. 18.2) обычно представляет собой текстовое описание того, то вам нужно
сделать для выполнения задачи. Иногда вместо текстового описания карточка
задач содержит модель. Например, Ньюкирк и Мартин (2001) приводят при-
мер задачи, представленной в виде наброска страницы HTML, подобного изоб-
раженному на рис. 18.3 (в их книге рис. 6.2). Должно быть, группа просто на-
бросала рисунок на белой доске или воспользовалась стикерами и планшетом,
чтобы создать сущностный прототип пользовательского интерфейса. После
достижения желаемого результата прототип был перенесен на карточку. Белая
доска или стикеры являются более гибкими инструментами по сравнению с
ручкой и бумагой, и поэтому им отдается предпочтение при начальном проек-
тировании подобных компонентов пользовательского, интерфейса. Возможно,
вы захотите перенести ваши наброски на карточку, чтобы сохранить ее в ка-
честве основы для кодирования в следующей итерации. Карточки являются
превосходным средством для сохранения — удаленные группы могут записы-
вать задачи в электронном виде, например, с помощью Wiki (Леф и Каннингэм,
2001) или других электронных средств для совместной работы. В этом слу-
чае схема содержимого экрана является более эффективным описанием зада-
чи, чем текст в произвольной форме.
На данном этапе вам явно придется уделить много времени моделированию.
Например, на рис. 18.4 изображен набросок, представляющий логику задачи, —
группа решила создать этот набросок, вместо того чтобы представить задачу в
виде текста, потому что для них это было проще. Вот и отлично, так как принцип
AM «Модель должна решать конкретную задачу» говорит о том, что вам следует
знать, для кого предназначена та или иная модель, и придать ей соответствующий
вид (в данном случае карточки задач предназначены для вашей же группы), а ме-
тодика AM «Применяйте нужный артефакт» советует вам создавать такой тип мо-
дели, который наиболее подходит для решения конкретной задачи.
224 Глава 18 • Гибкое моделирование в жизненном цикле ХР-проекта
Передать поиск в БД
• Проанализировать параметры, определенные
' покупателем на странице поиска.
' - ♦ Преобразовать трафаретные символы (* . _)
в SQt-эквиааленты,
' 1 • Создать SQL-олоратор отбора на основе
параметров поиска при заказе товара по номеру.
♦ Запустить операторе БД.
Создать страницу результатов поиска
• При ошибке базы данных или сети
создать стандартный отчет об ошибке
с описанием проблемы. Или:
♦ Вверху страницы указать номер товара
в поле результатов поиска. '
• Если товар не найден, показать
-' сообщение: «По вашему запросу ничего
не найдено». Или:
• Перечислить строки базы данных
с указанием номера товара, наименования
товара, цены за штуку и ссылки
на подробную информацию о товаре.
Рис. 18.2. Примеры карточек задач, относящихся к поиску товара
Рис. 18.3. Набросок, поясняющий требования к странице поиска товара
Рис. 18.4. Набросок, поясняющий логику задачи
Этап итераций реализации .225
СОВЕТ: ХР-ГРУППЫ ХРАНЯТ СВОИ МОДЕЛИ В КОРОБКЕ ---------------------------------
ХР-группы предпочитают простые инструменты. Самыми популярными среди них являются кар-
точки — они применяются для создания историй пользователя, задач (см. примеры на рис. 18.2,
18.3 и 18.4) и моделей CRC. Где лучше всего хранить кучу карточек? Правильно, в коробке.
Этап итераций реализации
Во время итераций реализации (Бек, 2000) происходит основная часть разработ-
ки, включая моделирование, программирование, тестирование и интеграцию.
Жизненный цикл итерации представлен на рис. 18.5 (Уэллс, 2000). Планирование
итерации — точно такой же вид деятельности, как и планирование реализации.
Единственное отличие заключается в том, что внимание здесь направлено на исто-
рии пользователя, относящиеся к текущей итерации. При работе над итерацией N
вы можете обнаружить, что к ней были добавлены новые, еще не оцененные исто-
рии пользователя. В этом случае вам придется заняться определением задач, что-
бы вы могли точно оценить каждую историю пользователя. После оценки новых
(и, возможно, пересмотра существующих) историй пользователя может оказаться,
что их слишком много или слишком мало для данной итерации, так что вам при-
дется перенести часть историй пользователя в другие итерации или наоборот.
Новая история пользователя
Скорость проекта
План
реализации
История пользователя
Незаконченные
задачи "
Изучать Новая
и общаться функциональность
. Следующая ___Скорость
итерация
Планирование_____ План _______Разоаботка ______Исправление ь Последняя
проекта ' итерации итерации ошибок версия
Тест приемки
не проеден
День
за д нем
Ошибки
Рис. 18.5. Жизненный цикл ХР-итерации
План Незаконченные
Изучать Новая
День _Текст приемки Установочная или тест приемки Совместное _Тест приемки Исправление
за днем не пройден встреча не проеден ^владение планом проеден ошибок
Рис. 18.6. Жизненный цикл элемента ХР «Разработка»
8 Зак. 926
226 Глава 18 • Гибкое моделирование в жизненном цикле ХР-проекта
Что касается моделирования, то интересующий аспект итерации показан в ви-
де элемента «Разработка» (см. рис. 18.5). На рис. 18.6 показан более подробный
жизненный цикл этого элемента (Уэллс, 2000). Моделированием в основном за-
нимаются на так называемых «установочных» встречах, когда группа собирает-
ся, чтобы обсудить текущую работу или получить совет по каким-либо вопросам.
Все собираются вокруг белой доски, на которой для наглядности обсуждения ри-
суются наброски. Участники таких встреч обычно стоят, что способствует непро-
должительности встречи (Бек и Фаулер, 2001). На рис. 18.6 подразумевается, что
после установочной встречи группа разобьется на пары, которые будут работать
с отдельными частями системы.
Установочная встреча
в 9:00
▼
Домой в 17:00
Рис. 18.7. Обычный день ХР-разработчика
На рис. 18.7 представлен обычный распорядок дня ХР-разработчика (Уэйк,
2002). Тут ясно показано, что после установочной встречи участники разбива-
ются на пары. Часто после этого они выполняют сеанс быстрого проектирования.
Главная особенность ХР состоит в том, что люди работают в паре'согласно мето-
дике «Парное программирование». На самом деле правильней было бы назвать
это «Разработка в паре», то есть сотрудничество двоих людей, которые вместе
программируют (а также анализируют, проектируют и тестируют), пытаясь по-
нять, как это лучше сделать. Если ХР-разработчики не уверены, что знают, как
программировать что-либо, они обычно проводят сеанс быстрого проектирования
(Джеффрис, Андерсен и Хендриксен, 2001). В AM это называется импровизиро-
Производство 227
ванным сеансом моделирования (см. главу 13). Во время таких сеансов несколь-
ко человек обсуждают проблему и находят способы ее решения (сравните с ме-
тодикой AM «Моделируйте, чтобы понять»). Вам наверняка придется следовать
- методике «Применяйте нужный артефакт (артефакты)» и работать с тем типом
моделей, который больше всего подходит для обсуждаемой проблемы. Например,
карточки CRC идеально подходят для изучения структуры кода, а для изучения
' дизайна пользовательского интерфейса лучше всего подойдет сущностный про-
тотип пользовательского интерфейса. Иногда для решения вопросов, связанных с
проектированием, вам понадобятся несколько моделей. Возможно, вам придется
создать как модель CRC, так и сущностный прототип пользовательского интер-
фейса, для того чтобы полностью изучить проблему, так что вам придется следо-
вать методикам «Создавайте несколько моделей параллельно» и «Переходите от
одного артефакта к другому». Обычно эти сеансы моделирования очень коротки
(10-30 минут), а потому и называются сеансами быстрого проектирования. Чтобы
получить обратную связь по проектированию, нужно срочно заняться кодирова-
нием в соответствии с методикой «Подтверждайте модель кодом». Так вы може-
те определить, насколько верен ваш подход. Если подход правильный — хорошо,
а если нет — возвращайтесь к белой доске и проводите еще один сеанс быстрого
проектирования.
В главе 20 рассмотрен пример моделирования во время итерации (выбор под-
хода к реализации поиска товара как части реализации системы для SWA Online).
В главе 21 подобным образом рассмотрен другой пример — как смоделировать вы-
числение налогов, скидок и общей суммы заказа.
Производство
ХР-этап «Производство» (Бек, 2000) предназначен для подтверждения готов-
ности ПО к запуску в производство. Я называю это «тестированием в большом»
(Амблер, 1999; Амблер и Константайн, 2002); сюда входит тестирование системы,
тестирование под нагрузкой, тестирование, инсталляции и другие испытания. Во
время этого этапа скорость разработки ПО снижается. Эволюция не прекраща-
ется, но важно определить, что войдет в следующую версию, а что нет. Обратите
внимание на то, что во многих проектах этот этап мало чем отличается от обыч-
ной итерации конструирования. Основное отличие в том, что система помещается
в производственную среду, а не в ограниченную среду разработки (песочницу).
На данном этапе AM применяется двумя способами. Во-первых, вам, возмож-
но, опять придется заняться моделированием в процессе доработки, необходи-
мой в свете обнаруженных дефектов. Во-вторых, это подходящий момент для
того, чтобы привести в порядок документацию. Хотя философия ХР заключается
в написании ясного, понятного кода, включающего в себя необходимые коммен-
тарии, реальность такова, что вам все равно придется написать сопровождающую
документацию. Помните о том, что существует множество заинтересованных лиц,
включая пользователей, высшее руководство, операторов и группу сопровожде-
ния. Эти люди не имеют доступа к коду, а если бы и имели, то все равно ничего
228 Глава 18 • Гибкое моделирование в жизненном цикле ХР-проекта
бы не поняли, так что они потребуют от вас другие формы документации (см. гла-
ву 14). Данная документация должна быть предоставлена по требованию заин-
тересованных лиц. Согласно принципу AM «Повышайте отдачу от ресурсов, по-
лученных от заинтересованных лиц», именно заинтересованные лица решают,
как они хотят потратить свои деньги, значит, за ними остается последнее слово.
Я предпочитаю писать документацию именно в конце жизненного цикла проекта,
так как система становится относительно стабильной, значит, и документация бу-
дет стабильной. Возможно, вам также придется создать еще кое-что, а именно:
Документация по системе. Это самый важный тип документации для разра-
ботчиков, включая профессиональных работников сопровождения. Данный до-
кумент представляет собой обзор системы и служит для облегчения ее понима-
ния. Обычно этот тип документации содержит обзор технической архитектуры
и бизнес-архитектуры, высокоуровневые требования, к системе, краткий обзор
важнейших проектных решений, диаграммы на уровне архитектуры и важные
проектные модели (если таковые имели место).
Документация по эксплуатации. Этот тип документации обычно перечисляет
отношения, в которых участвует ваша система; природу взаимодействия с други-
ми системами, базами данных и файлами; ссылки на процедуры резервирования;
список точек соприкосновения с вашей системой и их местонахождение; краткое
описание требований работоспособности/надежности системы; показатель пред-
полагаемого профиля нагрузки системы и советы по. устранению неисправностей.
Документация по обслуживанию. Данная документация включает в себя учеб-
ные материалы для группы обслуживания; всю пользовательскую документацию,
используемую в качестве справочного материала при устранении проблем; советы
по устранению неисправностей; процедуры решения сложных проблем и список
точек соприкосновения с группой сопровождения.
Пользовательская документация. Пользователи могут потребовать справоч-
ное руководство, инструкцию по эксплуатации, инструкцию по сопровождению
или даже материалы для обучения. Вам следует различать эти типы документов,
так как все они используются по-разному: один документ имеет справочный ха-
рактер, другой предназначен для изучения работы' с системой, третий — для полу-
чения дополнительной помощи, четвертый — для обучения.
Сопровождение
ХР-этап сопровождения (Бек, 2000) является нормальным состоянием ХР-про-
ектов, потому что им свойственно развиваться с течением времени. Данный э(тап
охватывает этапы планирования, итераций реализации и производства, начи-
ная со второй реализации вашей системы и заканчивая реализацией номер N.
Данный этап по определению включает в себя деятельность, связанную с произ-
водством, например эксплуатацию и обслуживание системы. Системы, создан-
ные при использовании ХР-подхода, запускаются в производство точно так же,
как и системы, созданные при использовании любого другого подхода, несмотря
на то, что вопросы, связанные с производством, не входят в задачи AM или ХР.
Как это осуществить? 229
Однако следует признать, что вашей группе необходимо принять во внимание
вопросы, связанные с производством, вот почему AM относит операторов и груп-
пу обслуживания к потенциальным заинтересованным лицам. Запомните: нет
смысла создавать систему, которую вы не можете разместить и запустить в про-
изводство.
Как это осуществить?
Какой подход к моделированию следует использовать при разработке в ХР-про-
екте? Бек (2000) предлагает применять методику ХР «Небольшие начальные вло-
жения» и рисовать несколько схем одновременно. Он утверждает, что стратегия
ХР заключается в том, что любой может спроектировать все, что угодно, с помо-
щью рисунков, но если возникает вопрос, на который можно ответить только с
помощью кода, то проектировщики должны использовать код. Другими словами,
добивайтесь «Быстрой обратной связи», чтобы выяснить, соответствуют ли ваши
рисунки действительности, и «Подтверждайте модель кодом».
Когда следует заниматься моделированием при 'разработке в ХР-проекте?
Каждый раз, когда создание модели более эффективно, чем написание кода.
Другими словами, следуйте принципу AM «Повышайте отдачу от ресурсов, по-
лученных от заинтересованных лиц» и методике AM «Применяйте нужный арте-
факт (артефакты)».
Как следует моделировать? Следуйте методике AM «Используйте простей-
шие инструментальные средства». Пользуйтесь такими инструментами, как кар-
точки, белая доска и стикеры, а не сложными CASE-средствами. Простые сред-
ства способствуют сотрудничеству и общению, то есть факторам, ведущим к
успеху проекта. Хотя ХР предпочитает использовать карточки, для того чтобы
записывать истории пользователя, модели CRC и задачи, можно пользоваться
и CASE-средствами, если последние являются более эффективными в данной
ситуации. Использование средств моделирования подробно рассмотрено в гла-
ве 10.
Как следует создавать документацию? ХР-группы предпочитают писать яс-
ный, понятный исходный код — они считают, что с исходным кодом может быть
синхронизирован только исходный код. Не забывайте о принципе AM «Модель
должна решать конкретную задачу»; следует учитывать интересы тех, для кого
предназначены модель или документ. Если документация предназначена для
пользователей вашей системы или вашего высшего руководства, то даже понят-
ный исходный код не годится в качестве документации. Для этой группы «читате-
лей» вам придется разработать внешнюю документацию. Заинтересованные лица
должны потребовать такую документацию, но они также должны понимать свя-
занные с этим издержки (в частности, тот факт, что во время создания документа-
ции вы не создаете программного обеспечения) и согласиться их оплатить.
ХР-разработчики должны сознавать, что ХР-проект допускает моделиро-
вание, более того, моделирование является частью ХР-проекта вместе с приме-
нением историй пользователя и карточками CRC. Еще важнее, чтобы ХР-раз-
230 Глава 18 • Гибкое моделирование в жизненном цикле ХР-проекта
работники избавились от предвзятого мнения, которое у них могло сложиться
о моделировании (например, что единственный подход к моделированию — это
«Сначала-все-смоделируем», что модели являются постоянными документами,
которые следует совершенствовать, что для моделирования требуются сложные
CASE-средства или что вы можете моделировать только с помощью UML), и по-
смотреть на моделирование другими глазами. Такая возможность была описа-
на в данной главе: вы можете использовать гибкое моделирование в ХР-проекте
и при этом оставаться эффективными разработчиками программного обеспече-
ния. Следующие три главы посвящены примерам, доказывающим этот тезис.
Моделирование
на этапе
исследования
в ХР-проекте
\
Сложные вещи мы делаем сразу же. На выпол-
нение невозможных требуется время.
Американский
инженерно-строительный корпус
Первым этапом проекта ХР является этап исследования (Бек, 2000), который
включает в себя разработку первоначальных историй пользователя и архитектур-
ных проб. В каждом проекте должна быть отправная точка, даже в проекте ХР.
.. В данной главе рассматривается применение методик гибкого моделирования во
; время этого этапа в ХР-проекте и обсуждаются следующие темы:
• прежде всего — базовые требования (IRUF);
• метафоры, архитектура и архитектурные пробы;
• закладываем основы проекта.
Прежде всего — базовые требования (IRUF)
Что касается требований, Бек советует, чтобы истории пользователя содержа-
ли достаточно материала для создания хорошей первой реализации. Кроме это-
го^ этот материал должен убедить разработчиков, что/лучший способ оценить
проект — реализовать систему. Всякий проект имеет свои задачи, обычно обус-
ловленные первоначальными требованиями к системе. Хотя жизненный цикл
ХР-проекта, представленный в главе 18, явно не включает задачу определения
объема проекта, понятно, что истории пользователя являются основой для пла-
нирования реализации. Истории пользователя вообще являются движущей си-
лой методологии ХР — они обеспечивают высокоуровневые требования к сис-
теме и служат основой для планирования. В общем, чтобы запустить ХР-проект,
вам требуется некоторое количество (скажем, от пяти до пятидесяти) историй
пользователя.
232 Глава 19 • Моделирование на этапе исследования в ХР-проекте
Однако возникает следующая проблема. Когда вы начинаете работу над про-
ектом, ваш подход к созданию ПО может быть еще не определен. Решение при-
нимается после того, как определены задачи проекта и его участники. Тип про-
цесса разработки должен максимально соответствовать вашему проекту, группе и
культуре организации (Кокберн, 2002). Если решение об использовании ХР еще
не принято, то люди, выполняющие работу по моделированию базовых требова-
ний (IRUF), могут начать создавать что-нибудь другое (обычно это директивы,
характеристики или элементы Use Case), а не истории пользователя. Если имен^
но так и произошло, вам придется преобразовать эти артефакты в истории поль-
зователя, при необходимости работая вместе с заказчиком (в целях сохранения
терминологии ХР, я буду говорить «Заказчик», а не «Заинтересованное лицо»),
К счастью, директивы и характеристики во многом схожи с историями пользова-
теля, так что здесь не возникнет никаких проблем. Поскольку элементы Use Case
обычно содержат больше информации, чем истории пользователя, то проще все-
го объявить их историями пользователя и разделить на части, чтобы с ними было
легче работать.
Допустим, что ваша работа по созданию первоначальных требований привела
к возникновению диаграммы Use Case, изображенной на рис. 19.1, и соответству-
ющего набора элементов Use Case,- а вы решили применять ХР в разработке ваше-
го проекта.
Рис. 19.1. Высокоуровневая диаграмма Use Case для SWA Online
Прежде всего — базовые требования (IRUF) 233
1, Элемент Use Case начинается* когда заказчик решает разместить заказ*
2., Заказчик ищет товары при помощи элемента Use Case «Поиск товара» <
3, Заказчик добавляет выбранный Товар к своему заказу*
4. Заказчик указывает количестве товара, который он желает заказать.
5, Система подсчитывает промежуточную сумму товара, умножая цену одного
предмета на количество выбранных предметов,
6> Заказчик повторяет шаги с 2 по 5, если это необходимо дня продолжения заказа.
7. Заказчик прекращает добавлять выбранный товар к своему заказу
6, Заказчик предоставляет информацию о доставке и оплате (имя, телефон, адрес).
2. Система подсчитывает промежуточную сумму всего заказа, складывая
промежуточныесуммы частей заказа.
10. Система подсчитывает налоги, применимые к заказу согласно безнес-правилу
«Высчитать налоги с заказа».
11, Система подсчитывает скидки, применимые к заказу согласно бизнестравилу
«Высчитать скидки с заказа».
12. Система показывает применимые налоги и скидки,
13, Система подсчитывает общую сумму заказа, добавляя применимые налоги
К промежуточной сумме заказа й вычитая скидки, -
14, Система показывает описание заказа, ;
1б: Покупатель проверяет заказ.
1 б, Система отправляет заказ на выполнение (см,.элемент Use Case
«Выполнить заказ»).
17, Система выдает покупателю счет, содержащий описание заказа.
Рис. 19.2. Основные действия по размещению заказа
Покупатель может добавлять товары в. уже
созданный заказ.
Система показывает название товара,
идентификационный код товара в каталоге,
цену товара, количество заказанного товара
и сумму до вычисления налогов и скидок
для каждой единицы заказа.
Покупатель может указать адрес доставки
заказа.
Покупатель может удалять товар из уже
созданного заказа.
Покупатели могут искать товары по каталогу,
Система высчитывает и показывает ,
промежуточную сумму до вычисления
налогов, скидок, стоимости доставки
и обработки заказа.
Система подсчитывает и показывает
применимые к заказу налоги, скидки,
стоимость доставки и обработки заказа.
Система создает e-mail, содержащий
описание заказа и отправляет покупателю
после подтверждения заказа.
Покупатель может указать адрес,
по которому можно отправить счет (он может
совпадать с адресом доставки, а может быть
другим).
Система подсчитывает общую сумму заказа.
„Система позволяет покупателю просмотреть
' и проверить заказ до его подтверждения.'
Система позволяет покупателю внести
изменения в заказ до его подтверждения.
Рис. 19.3. Истории пользователя для элементов Use Case
«Размещение заказа» и «Поиск товара (товаров)»
234 Глава 19 • Моделирование на этапе исследования в ХР-проекте
Историй пользователя, представленных на рис. 19.3, может быть достаточно
для того, чтобы начать разработку. Конечно, по мере развития проекта нам при-
дется выяснять истории пользователя для других аспектов системы (в частно-
сти — для выполнения заказа и учета), но размещение заказа, безусловно, явля-
ется главным аспектом SWA Online, поэтому мы можем начать с этих историй
пользователя. Не забывайте о том, что мы разрабатываем ПО небольшими пор-
циями, а не все сразу, так что это вполне допустимо. Учитывая вышесказанное,
мы можем переработать элементы Use Case, представленные на рис. 19.1, и со-
здать значительное количество историй пользователе которые можно использо-
вать в начале этапа «Планирование реализации». Можно выбрать «золотую сере-
дину», то есть реализовать наиболее важные элементы Use Case, например «Учет»
и «Выполнение заказа» (в дополнение к элементам «Размещение заказа» и «Поиск
товаров по каталогу»). Какой из подходов нам следует выбрать? Тот, при котором
нужно будет выяснить наименьшее количество историй пользователя. Тот, кото-
рый поможет вам разобраться с требованиями заинтересованных лиц, определить
задачи системы и перейти к разработке первой реализации.
СОВЕТ: ВОЗМОЖНО, ВЫ НЕ СМОЖЕТЕ ВЫЯСНИТЬ
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ С САМОГО НАЧАЛА -----------::-------------------
В ХР, как и в AM, ваши заказчики (заинтересованные лица) являются основным источником
требований. Бывает, они не определяют техническую сторону историй пользователя
(например, производительность и работоспособность системы) (Уэйк, 2000). Конечно, вы
можете предложить им эти требования, но последнее слово остается за ними. Они решают,
что станет историями пользователя, а что — нет. Они могут понять, что им необходимы эти
требования на более позднем этапе жизненного цикла, поэтому вам придется подвергнуть вашу
систему рефакторингу, чтобы реализовать эти требования. Ничего не поделаешь, изменения
в последнюю минуту — дело обычное.
Метафоры, архитектура и пробы архитектуры
Вторым аспектом работы во время этапа исследования является архитектура сис-
темы. Архитектура в проектах ХР менее формальна, нежели в традиционных ме-
тодологиях, отдается предпочтение архитектурам для гибких систем. ХР советует
ожидать изменений (как и AM), в то время как традиционные подходы рекомен-
дуют создавать сначала скелет системы, потому что некоторые вещи трудно из-
менить (Уэйк, 2002). Подход ХР советует определять метафору, описывающую,
как вы будете строить систему. Эта метафора играет роль концептуальной осно-
вы, определяющей ключевые объекты и понимание их интерфейсов. Эта метафо-
ра определяется во время пробы архитектуры в самом начале проекта (во время
первой итерации или пред1 итерации, которую иногда называют нулевой верси-
ей ZFR) (Уэйк, 2002). Бек (2000) предлагает в первой итерации отдавать предпо-
чтение историям заказчика, поскольку вы будете вынуждены «создавать всю сис-
тему, пусть даже в виде скелета». Определяете ли вы метафору системы во время
пред-итерации/архитектурной пробы или во время первой итерации? Это не име-
ет большого значения, если вы определили метафору системы в начале проекта.
Метафоры, архитектура и пробы архитектуры 235
То, что ХР отталкивается от метафоры системы, вовсе не означает, что у вас не
будет архитектуры или вы не будете создавать диаграммы' архитектуры. Например,
Ньюкирк и Мартин (2001) создали высокоуровневую диаграмму (рис. 4.1 в их кни-
ге), которая отражает архитектуру, позволяющую им лучше понять создаваемую
систему. Похожий набросок для SWA Online представлен на рис. 19.4. Обратите
внимание на сочетание нотаций для актеров, применяемых в UML-диаграммах
(проволочных фигурок), и элементов свободной формы. Принцип AM «Содержание
важнее формы» говорит нам о том, что важнее смоделировать ваши идеи, чем ис-
пользовать предписанные нотации диаграмм или довести диаграмму до совершенс-
тва. Эти диаграммы также показывают нам применение методик AM «Изображайте
модели просто» и «Создавайте простое содержание». Достаточно лишь отобразить
предполагаемую техническую архитектуру и ничего больше.
Группа разработчиков нарисует диаграмму, изображенную на рис. 1'9.4, стоя во-
круг белой доски (следуя методике «Моделируйте в группе»). Эта диаграмма осно-
вана на историях пользователя (см. рис. 19.3), диаграмме Use Case и соответствую-
щих элементах Use Case (см. рис. 19.1). Группа не станет пренебрегать материалом,
содержащимся в диаграмме Use Case и элементах Use Case только потому, что они
не являются официальными артефактами ХР. Наоборот, они последуют методике
AM «Используйте имеющиеся ресурсы» и воспользуются преимуществами диа-
граммы Use Case и элементов Use Case. Вы видите, что наш вариант архитектуры
выполняет и размещение заказа, и выполнение заказа. Группа также выделила два
аспекта архитектуры, которые кажутся неопределенными. На ее взгляд, она может
посылать транспортировщикам информацию о доставке в виде XML и высчиты-
вать применимые налоги при помощи готовой коммерческой системы (COTS). На
диаграмме это отмечено знаками вопроса (Амблер, 2001а; Амблер, 2002). В опреде-
ленный момент им будет необходимо сделать архитектурные пробы этих аспектов
системы, чтобы определить, осуществимо ли это, и, возможно, включит^ эти зада-
чи в первоначальную архитектурную пробу (немного кодирования, для того чтобы
выяснить, сработает ли данный вариант архитектуры).
Рис. 19.4. Архитектурное представление для SWA Online
236 Глава 19 • Моделирование на этапе исследования в ХР-проекте
СОВЕТ: ВАЖНЫ НЕ МОДЕЛИ, А МОДЕЛИРОВАНИЕ -------------------------------
Применяя методики AM в проекте ХР, не забывайте о том, что важной ценностью ХР, как
и AM, является общение. Ценность представляют не модели, которые вы создаете, — намного
важнее сам процесс моделирования. Создание модели помогло вам понять, чего хотят
заинтересованные лица, как вы собираетесь выполнить их требования, или помогло вам
продемонстрировать важность выполняемой вами работы. Хотя если вы решите следовать
методике AM «Демонстрируйте модели открыто» и оставите рис. 19.4 на белой доске, то этот
рисунок больше не будет представлять никакой ценности для вашей группы (может быть,
только для напоминания о том, что вам предстоит решить две важные проблемы). Данный
рисунок был создан вашей группой; разработка основана на техническом видении системы,
отображенном в диаграмме, значит, ваша группа знает техническую архитектуру и вряд ли
станет обращаться к этой диаграмме в дальнейшем. Другие люди смогут ознакомиться с вашей
архитектурой, используя осмотическое общение (Кокберн, 2002) (см. главу 8). Может быть,
вы решите показать диаграмму заинтересованным лицам, чтобы обосновать ваш подход (что
будет хорошим примером применения методики AM «Моделируйте, чтобы общаться»).
Хотя рис. 19.4 дает представление о вашей технической архитектуре, он не отража-
ет метафору вашей системы. Обычно вариантом архитектуры для SWA Online яв-
ляется метафора магазина самообслуживания. Заказ очень прхож на продуктовую
тележку. Покупатели «бродят» по интернет-магазину, «укладывая» товары в теле-
жку, «вынимая» из нее ненужные им товары, а потом направляются к кассе, где вы-
считываются налоги, скидки, выплаты и подсчитывается сумма заказа. Затем вы-
бранные товары будут упакованы и доставлены. Группа разработчиков обсудит эту
метафору параллельно с созданием диаграммы обзора, например, сделав грубый
набросок (рис. 19.5) на другой части белой доски, согласно методике «Создавайте
несколько моделей параллельно». Этот рисунок, скорее всего, сотрут, когда группа
обсудит эту метафору (группа следовала методике «Моделируйте, чтобы понять»,
а теперь применит методику «Избавляйтесь от временных моделей»). Набросок на
рис. 19.5 делать вовсе не обязательно. Некоторым людям нравится сопровождать
свою речь рисунками. Другие этого не любят. Поступайте так, как вам удобно.
СОВЕТ: НЕ СТОИТ ЗАНИМАТЬСЯ ОБЩЕЙ
ИНФРАСТРУКТУРОЙ В НАЧАЛЕ ПРОЕКТА --------------------------------------
Главная идея ХР — не перегружать вашу систему, а разрабатывать только то, что вам необ-
ходимо в данный момент, и быть уверенным в том, что вы сможете разработать завтра то,
что вам будет нужно завтра. Многие не-ХР-группы начинают проект с работы над общей
архитектурой, например с разработки уровня устойчивости сохранения данных (Амблер,
2001d) или среды для обмена сообщениями, на основе которой они намереваются разработать
остальную часть системы. Хотя эта работа очень интересна, она не дает той функциональности,
которая нужна заинтересованным лицам. Если вам нужны эти общие возможности, они станут
очевидными со временем, и вы разработаете их тогда, когда это будет необходимо, и под-
вергнете код рефакторингу, для того чтобы воспользоваться ими (это и есть так называемое по-
следовательное проектирование). Почему группы ХР предпочитают этот подход? Потому, что
они действуют по принципу YAGNI («Вам это никогда не понадобится») и не хотят тратить вре-
мя на создание ПО до тех пор, пока в этом не будет необходимости. Если вы не будете
создавать общую инфраструктуру прямо сейчас, тогда не следует моделировать ее в данный
момент. Ваша работа по моделированию архитектуры на раннем этапе проекта должна быть
направлена на поиск наипростейших решений, отвечающих высокоуровневым требованиям,
которые были определены. Разработка инфраструктуры на раннем этапе дает вам ложное чув-
ство защищенности, потому что у вас есть работающий код, который может показать, что
вы реализуете требования заинтересованных лиц, хотя на самом деле этого не происходит
(Ньюкирк и Мартин, 2001).
Закладываем основы проекта 237
Рис. 19.5. Набросок, нарисованный во время определения метафоры системы
Закладываем основы проекта
Ваш набор историй пользователя и проб архитектуры является основой всего
проекта. Во время итераций вы будете реализовывать эти истории пользователя,
перерабатывая их так, чтобы по мере развития проекта они отражали изменение
вашего понимания разрабатываемой системы. Метафора вашей системы поможет
вам координировать разработку, в результате чего будет создана архитектура сис-
темы. В следующих двух главах я расскажу о моделировании во время итераций
реализации.
Моделирование
вовремя
ХР-итерации:
поиск товара
Мы экстремалы, а не дураки.
Рон Джефрис
Во время итераций реализации (Бек, 2000) происходит основная часть разработки,
включая моделирование, программирование, тестирование и интеграцию. Жизнен-
ный цикл итерации представлен на рис. 20.1 (Уэллс, 2000). Планирование итерации
— точно такой же вид деятельности, как и планирование реализации, описанное в
главе 18. Единственное отличие состоит в том, что внимание здесь направлено на
истории пользователя, относящиеся к текущей итерации. При работе над итераци-
ей N вы можете обнаружить, что к ней были добавлены новые, еще не оцененные
истории пользователя. В этом случае вам придется заняться определением задач,
чтобы вы могли точно оценить каждую историю пользователя. После оценки но-
вых (и, возможно, пересмотра существующих) историй пользователя может ока-
заться, что их слишком много или слишком мало для данной итерации, так что вам
придется перенести часть историй пользователя в другие итерации или наоборот1.
План
реализации
История пользователя
Новая история пользователя
Скорость проекта
А
Незаконченные
задачи '
Изучать Новая
и общаться ^^функциональность'
Следующая ____Скорость Планирование_______ План ______ _ I — ___________Исправление ь Последняя
итерация проекта*’ итерации итерации * a3^a ошибок * версия
Тест приемки
не пройден
заднем
Ошибки
Рис. 20.1. Жизненный цикл ХР-итерации
1 Наверное, здесь автор практически отрабатывает тезис «Повторение — мать учения», посколь-
ку этот абзац слово в слово повторяет текст из главы 18. — Примеч. науч. ред.
Задача 239
CoggfilKb (JSP ЭЯОа. оя/>м<щы
(4I I
| |
/Ссим/гл/>м; (▼[
(4ма: ок | о | | # |
[/Z\Л,0к0й\
Рис. 20.2. Набросок страницы поиска товара
Задача
Чтобы понять, как применять методики AM в ХР-проекте, давайте рассмотрим
следующий пример. На рис. 20.2 представлена карточка задачи, на которой изоб-
ражен набросок страницы HTML для поиска товаров, а на рис. 20.3 — карточка
задачи о передаче результатов поиска в базу данных (вы уже видели эти рисун-
ки в главе 18). Давайте представим, что мы уже закончили работу по созданию
страницы HTML и собираемся реализовать код для непосредственного осущест-
вления поиска. Давайте также представим, что мы уже разрабатывали подобные
вещи в прошлом — нам необходимо извлечь информацию из HTML-ответа, заме-
нить трафаретные символы в соответствии с критериями языка структурирован-
ных запросов (SQL) (например, заменить * на %), создать строку, представляю-
щую собой SQL-оператор, и передать эту строку в базу данных, поэтому нам не
нужно делать проб.
Передать поиск в базу данных
• Проанализируйте Критерии* определенные пользователем на странице поиска,
« Преобразуйте трафаретные символы (*, J в SQL-эквиваленты.
• Создайте SQL-оператор SELECT, основанный на критерии поиска заказа по номеру товара,
• Примените оператор к базе данных.
Рис. 20.3. Карточка задачи для поиска в базе данных
Что нам придется моделировать? Извлечение информации из ответа HTML до-
статочно легко закодировать. Так же обстоят дела с заменой трафаретных симво-
лов в тексте. Вы даже можете предусмотреть рефакторинг существующего кода
(Фаулер, 1999), если еще не сделали этого, чтобы включить классы и компонен-
ты, которые реализуют эти две функции. Создание SQL-оператора также доволь-
но легко осуществить. Вы просто пишете код, чтобы связать строки, хотя Создание
SQL-оператора подразумевает моделирование проектного решения базы данных.
240 Глава 20 • Моделирование во время ХР-итерации: поиск товара
СОВЕТ: РЕШАЙТЕ НЕЗНАКОМЫЕ ЗАДАЧИ МЕТОДОМ ПРОБЫ -------------------------------
Если вы никогда ранее не реализовывали какой-то аспект задачи (возможно, вы изменяете
информацию в унаследованной базе данных) и впервые сталкиваетесь с какой-либо харак-
теристикой, тогда вам следует немного поэкспериментировать, чтобы узнать, как реализовать
эту характеристику. Подобного рода эксперимент называется пробой или выбросом (Джефрис,
Андерсон и Хендриксон, 2001). Его цель — решение проблемы одним махом. В случае с изменением
унаследованной базы данных вы можете написать код для изменения одной записи или даже
одного столбца в записи базы данных. Когда вы работаете над пробой, то часто проводите
быстрые сеансы быстрого проектирования, для того чтобы изучить аспект задачи, а затем перейти
к разработке. Конечно же, перед проведением пробы следует спросить других членов вашей
группы, решали ли они подобные задачи. Если им доводилось это делать — попросите их помочь
вам.
Моделирование физической схемы базы данных
Чтобы разработать SQL-оператор, нам необходимо знать компоновку базы дан-
ных, включая названия таблиц, столбцов и типов этих столбцов. Знание суще-
ствующих индексов в таблице, к которой мы обращаемся, а также хранимых про-
цедур для поиска этих таблиц дает нам представление о возможном решении и
реализации рассматриваемых нами проблем. Многие группы разработчиков со-
здают и поддерживают физическую модель данных, в которой эта информация от-
ражена полностью или частично. Существуют очень хорошие средства моделиро-
вания данных. Они не только генерируют DDL (ЯОД, язык определения данных),
который необходим нам для создания таблиц в базе данных и триггеров к этим
таблицам, но и выполняют обратную разработку существующих унаследованных
схем, тем самым помогая вам понять унаследованные схемы данных, к которым
вам может понадобиться доступ.
На данном рисунке используется нотация моделирования данных на основе
UML. Я впервые применил эту нотацию в книге «The Object Primer 2/е» ('Амблер,
2001а), а затем она была подробно рассмотрена в книге «Mastering EJB 2/е»
(Роман, Амблер, Джуэлл и Маринеску, 2002).
По мере развития проекта группа решает поддерживать и совершенствовать
физическую модель данных, автоматически генерируя код для нее, чтобы отразить
новые требования. Решая данную задачу, нам нужно убедиться в том, что в базе
данных имеются столбцы, где хранится информация о названии товара, его но-
мере и категории (например, одежда, электротовары и т. д.) и цена (см. рис. 20.3).
К счастью, текущая модель данных, изображенная на рис. 20.4, показывает, что
большая часть этой информации отражена в базе данных. Существуют две рас-
пространенные проблемы:
1. Первичный ключ в таблице товаров не являетсй номером товара. Столбец
Номер_Товара не является первичным ключом. Вместо него первичным клю-
чом является столбец Идентификатор_товара. Идентификатор_товара являет-
ся устойчивым идентификатором (Амблер, 2001е). Иногда специалисты по
моделированию данных называют его суррогатным ключом. Согласно кар-
точке задачи, мы должны осуществлять заказ по номеру заказа. Это легко
Моделирование физической схемы базы данных 241
осуществить посредством оператора SQL «Заказ по...», хотя этот процесс
может быть довольно медленным из-за того, что первичный ключ не явля-
ется тем столбцом, по которому выполнена сортировка. Если мы обнаружи-
ваем, что у нас возникли проблемы с быстродействием, у нас может возник-
нуть желание использовать CASE-средства для того, чтобы генерировать
и добавить вторичный индекс, основанный на Номере_Товара.
Рис. 20.4. Простая модель данных для SWA Online
2. Отсутствует категория товара. Хотя страница HTML позволяет пользова-
телям выбирать категорию из выпадающего-- окна списка (см. рис. 20.5), мы
обнаруживаем, что список категорий был записан в исходном коде, который
генерирует данную страницу HTML. В свое время этого было достаточно, но
сейчас нам это не подходит. Во-первых, мы должны изменить модель дан-
ных и добавить туда таблицу поиска Категория товара. Нам также необходи-
мо добавить в таблицу Товар столбец Идентификатор_категории_товара, кото-
рый обеспечит связь между товарами и категориями. Во-вторых, мы должны
придумать и написать тестовый код, проверяющий, как эти новые возмож-
242 Глава 20 • Моделирование во время ХР-итерации: поиск товара
ности работают в базе данных. В-третьих, мы должны сгенерировать код DDL
для изменения схемы базы данных, а затем запустить этот код в базе данных.
(Безусловно, мы сделаем резервную копию базы данных, прежде чем начнем
вносить какие-либо изменения.) В-четвертых, нам нужно будет написать код
для внесения данных в новую схему. Для этого необходимо сначала поместить
информацию, описывающую категории, в новую таблицу и обновить столбец
Идентификатор_категории_товара в таблице Товар, чтобы обеспечить ссылоч-
ную целостность в базе данных. В-пятых, нам следует произвести рефакто-
ринг кода, который генерирует данную страницу HTML, чтобы читать данные
из таблицы Категория_товара, а не вписывать эти категории в код. И, наконец,
нам нужно запустить набор тестов интеграции для всего кода, чтобы прове-
рить, не повредили ли внесенные нами изменения другую часть системы.
В случае обнаружения каких-либо проблем нам необходимо будет их решить.
Вероятнее всего, проблемы возникнут в той части кода, которая обращается к
таблице Товар и которая могла быть повреждена в результате изменений схе-
мы таблицы Товар. В этом случае можно произвести рефакторинг.
Как члены группы успеют отследить все изменения в схеме базы данных?
Во-первых, во время ежедневных установочных встреч (см. главу 18) каждый член
группы, который вносил изменения в базу данных накануне, должен сообщить об
этом остальным. Во-вторых, модель данных является той моделью, которую нуж-
но распечатать и повесить на Стене, следуя методике «Демонстрируйте модели от-
крыто». Таким образом, если во время проведения сеансов быстрого проектиро-
вания вам нужно рассмотреть изменения схемы базы данных, эта схема окажется
под рукой, и вы сможете рисовать их на ней, рассказывая о внесенных изменени-
ях. Нет необходимости распечатывать диаграмму после внесения малейшего из-
менения, следуя методике «Совершенствуйте только в случае необходимости».
(Большинство людей переживут наличие в диаграмме нескольких нарисованных
от руки элементов.) Если ,вы начнете часто распечатывать диаграммы, я советую
вам приобрести плоттер (склеивать листы вам быстро надоест!).
Наблюдения
Я сделал несколько важных наблюдений по поводу реализации этой задачи:
Работа по моделированию была короткой. У нас не возникало необходимо-
сти много моделировать, чтобы реализовать эту задачу. На самом деле все, что нам
пришлось сделать, — это внести небольшие изменейия в существующую физиче-
скую модель данных, из которой мы сгенерировали код, необходимый для изме-
нения схемы базы данных.
Моделирование сэкономило наше время. Данный подход был более эффек-
тивным, нежели написание кода DDL. Наше инструментальное средство гене-
рировало не только простой код, необходимый для того, чтобы добавить новый
столбец и таблицу, но и триггеры базы данных, необходимые для поддержания
ссылочной целостности в базе данных. Триггер — это операция, которая автома-
тически вызывается в результате изменений внутри базы данных. К необходимым
Наблюдения 243
триггерам относятся триггер удаления в таблице Категория_товара, который пре-
дотвратит случайное удаление, если запись, которая относится к данной катего-
рии, существует в таблице Товар. Триггер вставки в таблице Товар проверяет, есть
ли категория, на которую ссылается новый товар, а триггер обновления в табли-
це Товар выполняет ту же операцию. Безусловно, этот код легко написать, но еще
легче его генерировать. Также физическая модель данных довольно понятно отра-
жает схему базы данных; она содержит информацию, важную для разработчиков,
работающих с базой данных.
Рис. 20.5. Усовершенствованная модель данных
244 Глава 20 • Моделирование во время ХР-итерации: поиск товара
Сначала мы моделировали. Сначала мы моделировали, закладывая основу
для дальнейшей работы. Небольшие изменения в базе данных повлекли за собой
несколько рефакторингов класса Товар. Эти изменения заключались в добавлении
триггеров вставки и обновления для таблицы Товар. Теперь вставка и обновление
Товаров в базе данных проверяется и корректируется с помощью кода триггеров.
СОВЕТ: НЕТ НЕОБХОДИМОСТИ УЧИТЬ ВСЕХ РАЗРАБОТЧИКОВ
РАБОТАТЬ СО ВСЕМИ ИНСТРУМЕНТАЛЬНЫМИ СРЕДСТВАМИ ----------------------
Идея использовать Case-средство для поддержки базы данных в ХР-проекте порождает
интересную проблему — нужно ли учить всех разработчиков работать с Case-средствами?
В нашей группе разработки SWA Online есть один человек, который намерен получить сер-
тификат администратора баз данных Oracle и с радостью выполняет любую работу, связанную
с базами данных. Он уже много лет работает с Case-средствами. У нас также есть другой
человек, имеющий богатый опыт в разработке и моделировании баз данных, который также
работал с Case-средствами. Другие разработчики время от времени работают с ними в паре при
создании различных аспектов базы данных, но их опыт работы с Case-средствами минимален.
Нужно ли обучать других работе с Case-средствами? Работа над проектом в данный момент
проходит слаженно: у вас есть два человека, умеющих работать с Case-средствами, остальные
могут использовать их, если в том есть необходимость. Если кто-то захочет узнать побольше
об использовании Case-средств, он может поработать в паре с тем, кто умеет работать с
данным средством. Если ему понадобится хорошая подготовка, я, безусловно, отправлю его
учиться. Стану ли я отправлять всю группу на обучение? Вряд ли. Я не думаю, что в этом есть
необходимость.
Моделирование
во время
ХР-итерации:
подсчет общей
суммы заказа
Всегда имейте свое суждение.
Руководство по корпоративной
политике компании «Нордсторм»
Разработчики проекта ХР (Бек, 2000), безусловно, будут заниматься моделирова-
нием в процессе создания системы. В главе 20 мы рассмотрели применение прин-
ципов и методик AM во время разработки функции «Поиск товара» в системе
SWA Online. Теперь давайте рассмотрим другой пример. Эти задачи отличаются
друг от друга, и мы увидим, что для их решения нужно использовать различные
методики моделирования.
Задача
/
На рис. 21.1 изображены'две истории пользователя, описывающие подсчет об-
щей суммы заказа и показывающие, как система высчитывает применимые нало-
ги, скидки, оплату доставки и обработки заказа. Проработав методику ХР «Игра
планирования», вы решите создать грубый прототип пользовательского интер-
фейса для этой части заказа (он изображен на рис. 21.2), чтобы выяснить, что вам
требуется создать, следуя методике «Моделируйте, чтобы понять». Вы быстро
поймете, что первая история пользователя слишком громоздка, и решите поде-
лить ее на четыре отдельные истории: одну — для общей суммы, другую — для
налогов, третью — для скидок и четвертую — для оплаты доставки и обработки
заказа (рис. 21.3). Вы обсуждаете эти новые истории пользователя в группе и оце-
ниваете каждую из них, чтобы представить их заказчику, которого вы попроси-
те назначить приоритеты для историй пользователя. Заказчик решает, что исто-
рия пользователя, посвященная скидкам, имеет низкий приоритет, и вы кладете
ее последней в вашу стопку карточек. Остальным историям пользователя присва-
ивается высокий приоритет, и вы выбираете их для этой итерации.
246- Глава 21 • Моделирование во время ХР-итерации: подсчет общей суммы заказа
Система высчитывает и показывает Система подсчитывает и показывает
промежуточную сумму де вычисления конечную сумму заказа,
налогов, скидок и указания адреса
доставки и обработки заказа.
Рис. 21.1. Истории пользователя, показывающие полученную информацию о заказе
Истории пользователей, касающиеся подсчета промежуточной и конечной
суммы заказа, легко реализовать, так как они являются простым дополнением. Две
другие истории пользователя явно намного сложнее. Поскольку SWA Entreprise
ранее не занималась розничной торговлей, то и не сталкивалась со сложными про-
блемами типа налогообложения или доставки. Что будем делать?
™....................'
Рис. 21.2. Набросок на белой доске, изображающий часть заказа «Подсчет общей суммы»
Моделирование требований ведет к спасению
Прежде всего вам нужно определить требования для этих двух историй пользова-
теля. Обратитесь к источнику этой информации — локальному заказчику. Вы про-
сите вашего заказчика (давайте дадим ей имя, например Венди) объяснить вам эти
истории пользователей — вот вам пример игры «Вопрос—Ответ» (см. рис. 21.4,
который уже приводился в главе 18). Во время этой игры заказчик может дать от-
вет сразу же и принять решение о том, как та или иная часть системы будет рабо-
тать, или только предоставляет информацию разработчикам. К счастью, Венди
раньше работала в отделе доставки и имеет представление о вычислении оплаты
доставки и обработки, но она понятия не имеет о вычислении налогов. Она пред-
лагает'вам высчитывать $5 за доставку и транспортировку и налог 6,5% со всех
товаров SWA Online. Она соглашается добавить тесты приемки для этих двух ре-
шений в набор тестов, которые она создавала для всей системы. Она также обеща-
ет вам исследовать две эти проблемы и сообщить результаты через пару дней.
Моделирование требований ведет к спасению 247
Система подсчитывает и показывает Система подсчитывает и показывает
промежуточную сумму заказа. скидки, применимые к заказу. ' ;
Система подсчитывает и показывает оплату Система подсчитывает и показывает
доставки и обработки заказа. налоги, применимые к заказу,' , '
Рис. 21.3. Переработанные истории пользователя, показывающие
полученную информацию о заказе
СОВЕТ: В ХР-ПРОЕКТЕ ТЕСТЫ ПРИЕМКИ ЯВЛЯЮТСЯ
АРТЕФАКТАМИ ТРЕБОВАНИЙ --------------------------------;---------------
Очень часто заказчиков просят написать тест приемки, ответив на ряд вопросов, или написать
новую историю пользователя (Уэйк, 2002). Тесты приемки являются интересным аспектом ХР,
применяющимся вместо написания подробных требований, на основе которых проводится
разработка. Группы ХР вместе с заинтересованными лицами создают несколько тестов приемки
и проверяют, соответствует ли система этим тестам. Поэтому многие разработчики говорят
о том, что тесты приемки являются требованиями, и они абсолютно правы.
Установочная встреча
в 9:00
Домой в 17:00
Рис. 21.4. Обычный день ХР-разработчика
Теперь вы знаете, с чего начать, потому что ваш заказчик принял решение.
Безусловно, кое-что, вероятнее всего, изменится по мере поступления новой ин-
формации, но вы внесете изменения, когда это потребуется. В конце концов, это
248 Глава 21 • Моделирование во время ХР-итерации: подсчет общей суммы заказа
ХР-проект, так что будьте готовы к изменениям. Как показывает рис. 21.4, вы начи-
наете цикл «Тест-Код-Рефакторинг» и приступаете к кодированию. В ХР вы начи-
наете с теста и поэтому знаете, когда остановиться. Следует выполнить проектиро-
вание и реализацию в объеме, достаточном для тестирования, а затем вы упрощаете
структуру посредством рефакторинга, когда предоставляется такая возможность.
Помощь специалиста со стороны
Вы с вашим напарником продолжаете программировать, когда снова появляется
Венди. Она сообщает вам, что отправила знакомому бухгалтеру голосовое сообщение
с просьбой объяснить вам правила налогообложения. Она также связалась со своим
приятелем Джейком. Он работает в транспортной компании «Fly-By-Night», которую
SWA Enterprise намеревается использовать для работы с первой версией системы.
Завтра в 9 утра Джейк может уделить нам полчаса, и Венди просит нас присутствовать
на совещании. Пользуясь случаем, вы показываете Венди результаты своей работы —
доработанную историю пользователя, в которой вы добавили строку, показываю-
щую оплату доставки товаров и обновленный подсчет суммы заказа (промежуточная
сумма плюс новые издержки). Ей не нравится, как это выглядит на экране, потому
что вы неверно выполнили выравнивание. Вы обещаете ей исправить эту ошибку.
На следующее утро вы, ваш напарник и Венди собираетесь вместе и звоните
Джейку. Вы договариваетесь вести записи втроем во время разговора с ним, чтобы
избежать неточностей. Джейк сообщает вам, что компания «Fly-By-Night» обсуж-
дает со своими клиентами размеры оплаты доставки и ежеквартально составля-
ет таблицы. Кстати, он отправил такую таблицу для Венди по электронной почте.
Они составляют таблицы ежеквартально по двум причинам: могут измениться об-
щие тарифы, которые напрямую связаны со стоимостью перевозок для компании
(главным образом они зависят от цен на топливо), а также важную роль играет
объем перевозок (чем больше объем, тем ниже стоимость доставки). Эти таблицы
составляются бухгалтерией компании «Fly-By-Night» и рассылаются покупате-
лям как минимум за две недели до изменения тарифов. Тарифы в таблице зависят
от веса доставляемого товара, размера упаковки и расстояния. Вес и размер изме-
ряются приблизительно (например, меньше 1 кг, от 1 до 5 кг и т. д.). Расстояние,
в свою очередь, измеряется зонами. Джейк обещает прислать вам карту зон, выяс-
нив номер вашего факса. Карта составлена очень просто: центром считается торго-
вый склад, а от него зоны расходятся кругами неправильной формы (штат должен
покрываться зонами целиком). Эта система зон работает уже десять лет, причем
за последние семь лет в нее не вносилось никаких изменений. Джейк сообщает
вам еще некоторую информацию и, прощаясь, говорит, что готов в любое время
ответить на ваши вопросы по телефону или электронной почте.
Сеанс быстрого проектирования
После совещания вы решаете провести сеанс быстрого проектирования, что-
бы понять ваш подход к реализации подсчета расходов на доставку и обработ-
Сеанс быстрого проектирования 249
ку заказа. Венди указывает нам на то, что мы должны учесть не только тари-
фы компании «Fly-By-Night», но и свои собственные. Она говорит, что бухгал-
терия считает, что 50 центов — это нормальная цена доставки, но она должна
уточнить это еще раз. Вам же важнее понять, как высчитывать оплату доставки.
Вы втроем начинаете работать с карточками CRC (рис. 21.5), чтобы определить
классы и обязанности, которые вам необходимы. Параллельно вы рисуете на бе-
лой доске UML-диаграмму последовательности (рис. 21.6), которая показыва-
ет взаимодействие между классами, обеспечивающими эту функцию. Карточки
CRC и диаграмма последовательности описаны в приложении А. Вы работае-
те с этими моделями некоторое время и находите, что у вас есть хорошая страте-
гия реализации этих подсчетов. Теперь вы можете начать кодирование. Работая
над этими моделями, вы также обсуждаете возможность тестирования этих
функций. Эту информацию Венди записывает, на карточках для каждого теста
приемки отдельно.
Подсчет расходов на доставку
Матрица расходов на доставку
Знает затраты SWA
Подсчитывает
затраты на доставку заказа
Определяет размер
упаковки заказа
Определяет вес заказа
Определяет зону заказа
Штат
Знает зону доставки,
находящуюся в пределах
штата
Заказанные товары
Знает количество
заказанных товаров
Знаеттовары
Матрица расходов
на доставку
Штат
Товар
Знает сроки доставки заказа
Знает допустимые
размеры упаковки
Знает д опустимый
дипазон веса
Знает зоны доставки
Знает стоимость
доставки для данной
упаковки определенного
веса а пределах
определенной зоны
Заказ;
Знает адрес доставки
Знает, какие товары
заказаны
Подсчитывает расходы на
доставку и обработку заказа
Подсчет расходов
на доставку
Заказанные
товары
Знает вес
Знает ширину
Знает высоту
Знает длину
Рис. 21.5. Карточки CRC, относящиеся к подсчету расходов по доставке
Карточки CRC и UML-диаграмма последовательности не очень хорошо соче-
таются друг с другом. Ничего страшного. В большинстве случаев гибкие модели
не обязательно должны быть синхронизованы друг с другом. Они просто долж-
ны быть хорошими, а эти две модели вполне отвечают этому требованию. Когда
250 Глава 21 • Моделирование во время ХР-итерации: подсчет общей суммы заказа
вы обнаруживаете, что два артефакта не синхронизованы, вы должны следовать
методике «Совершенствуйте только в случае необходимости» и дорабатывать их
только в том случае, если это принесет пользу проекту.
Во время этого процесса вы применяли следующие методики AM:
• Применяйте нужный артефакт (артефакты), когда вы выбрали для ра-
боты карточки CRC, чтобы определить статичную структуру вашего ПО и
диаграмму последовательности для определения динамической природы
взаимодействия между классами. Конечно, вы могли нарисовать диаграмму
классов UML вместо использования карточек CRC, но как вы узнали в гла-
ве 10, с карточками гораздо легче работать и они более содержательны.
• Создавайте несколько моделей параллельно, когда вы приняли решение ра-
ботать с двумя моделями одновременно.
• Переходите от одного артефакта к другому, когда переходили от карточек
к диаграмме.
• Учитывайте тестируемость, когда создали тесты приемки, работая с диа-
граммой последовательности и карточками CRC.
• Избавляйтесь от временных моделей, когда закончили кодирование инфор-
мации, содержащейся в ваших моделях. Скорее всего, они больше не представ-
ляют для вас ценности, поэтому диаграмму можно стереть с доски, а карточ-
ки выбросить.
Рис. 21.6. Диаграмма последовательности UML для подсчета расходов по доставке
А как насчет изменений в, будущем? 251
Формализуйте модели соглашения
Вы уже готовы приступить к кодированию, когда Венди сообщает, что работа
еще не закончена. Вам необходимо ввести новую историю пользователя для по-
лучения таблиц от компании «Fly-By-Night» и ввода новых данных в систему.
Она подчеркивает, что это очень важный пункт и его следует включить в следу-
ющую итерацию. Вы понимаете, что ваша группа должна последовать методике
«Формализуйте модели соглашения» и создать короткий документ для компании,
занимающейся доставкой, в котором будет описан этот интерфейс. Этот документ
будет состоять из пары абзацев, описывающих процесс получения таблицы, при-
мер самой таблицы и описание процесса отправки (вам решать, будет ли он авто-
матизирован или будет осуществляться вручную). Этот документ станет частью
вашей системной документации.
СОВЕТ: ВЫ МОЖЕТЕ ИСПОЛЬЗОВАТЬ ПАТТЕРНЫ В ХР-ПРОЕКТЕ------------
Противоречит ли применение паттернов методике ХР «Простое проектирование»? Все зависит
от того, как вы будете их использовать. Джошуа Кериевски (2001) замечательно сказал по
этому поводу: «Начните с простого, не забывайте о паттернах, но держите их про запас,
совершайте маленькими порциями рефакторинг и применяйте паттерн (паттерны), только
если в этом действительно есть необходимость». Другими словами, следуйте методике AM «Не
увлекайтесь паттернами».
А как насчет изменений в будущем?
К середине дня Венди получает информацию от бухгалтера по поводу налогов.
Оказывается, что если вы доставляете товар в этом же штате, то он облагается на-
логом в 6,5 %. В других случаях этого не происходит. Этот бухгалтер'также со-
общил, что некоторые штаты рассматривают принятие закона о взимании налога
с продаж в интернет-магазинах в случае доставки внутри штата. По его мнению,
этот закон будет принят в течение года. Также он сказал, что федеральное прави-
тельство считает нужным применять трехпроцентный налог на добавочную стои-
мость к покупкам в интернет-магазинах, но вероятность того, что это произойдет
скоро, невелика. В завершение разговора он сказал, что во многих странах за ру-
бежом взимаются пошлины и налоги, которые тоже нужно будет учитывать, когда
SWA Online станет международной.
Услышав это, Венди разнервничалась. Что, если в системе налогообложения
произойдут изменения? Вы ответили.ей, что ваша группа на это быстро отреаги-
рует. Она спросила, нужно ли проводить сеанс большого проектирования, что-
бы выяснить, как система справится с этими изменениями, на что вы ответили,
что не хотите перегружать систему функциями, которые, возможно, никогда не по-
надобятся, и не хотите писать код, который нужно будет со временем обновлять.
Но это ее не успокоило. Она желает убедиться в том, что группа понимает, что
способ взимания налогов нужно будет со временем менять. Вы предлагаете комп-
252 Глава 21 « Моделирование во время ХР-итерации: подсчет общей суммы заказа
ромиссное решение. Вместо того чтобы перегружать систему, лучше записать воз-
никшие требования и рассказать о них завтра всей группе во время установоч-
ной встречи. Венди принимает это предложение. Подобные вещи удавались в про-
шлом, и вы быстренько заполняете несколько карточек (рис. 21.7).
Вариант изменения: отдельные платы вводят налог с продаж через Интернет
Вероятность: в течение 6-12 месяцев
Возможные последствия:
• Нам придется вычислять налоги согласно законам каждого штата
♦ Нам придется предоставлять каждому штату необходимую информацию
по налогам и сделкам
Вариант изменения: федеральное правительство вводит налоге продаж через Интернет.
Вероятность: в течение двух последующих лет
Возможные последствия: -
• Нам придется вычислять налоги согласно федеральным законам.
• Нам придется предоставлять правительству необходимую информацию
по налогам и сделкам
Ш....Г 4НПИПНЖ.И .ИНН .....Г111 i I И111Г11.11.14-11111 4W* *.........НН
Вариант изменения: зарубежные страны вводят пошлины и налоги на доставку
Вероятность: когда SWA Online станет международной
Вожможные последствия: > ' ' ,
* Если мы найдем транспортную компанию, которая будет сама разбираться
. с налогами и пошлинами, то последствия будут минимальными
• Если нет, то нам придется предоставлять в каждую страну необходимую
информацию по налогам и сделкам
Рис. 21.7. Запись возможных требований, касающихся налогов, в виде вариантов изменений
И AM, и ХР убеждают нас принимать изменения, хотя на практике это доволь-
но трудно сделать. Сначала вы'решаете рискнуть и считаете нужным решать про-
блемы по мере их поступления, поэтому стараетесь не перегружать вашу систему
в данный момент. Вашим заинтересованным лицам сложно принять подобную по-
зицию, особенно если они уже имели опыт неудачного сотрудничества с разработ-
чиками или успех их собственной карьеры зависит от вашего проекта. То, что вы
готовы к изменениям, будет звучать банально и не убедительно, если вы не смо-
жете доказать, что вы способны решать проблемы по мерё их поступления. Вам
нужно будет найти компромисс, коим и являются варианты изменений. Создавая
варианты изменений, вы показываете заинтересованным лицам, что вы осознае-
те риск возникновения изменений, и успокаиваете их. Варианты изменений уве-
личат их доверие к вашей группе хотя бы до такой степени, что они согласятся с
тем, что следует ожидать изменений (при отсутствии доверия вам будет сложно
двигаться дальше, так как вы не получите поддержки со стороны заинтересован-
ных лиц). Создание вариантов изменений позволит вам взглянуть по-новому на
Как это осуществить? 253
существующие проектные решения, но это еще не лицензия на перестройку вашей
системы по этим вариантам.
Наблюдения
Мы еще раз убедились, что моделирование можно эффективно применять в про-
ектах ХР. Быстро сделав набросок всего заказа, мы смогли направить свою рабо-
ту в нужное русло. Сеанс быстрого проектирования, во время которого мы изучи-
ли способ вычисления оплаты доставки и обработки заказа, оказался успешным,
а моделирование помогло нам найти простой подход к проектированию.
Большинство описанных в этой главе моделей были созданы при помощи про-
стых средств.. Мы использовали набросок UML-диаграммы последовательности
и прототип пользовательского интерфейса. Для создания историй пользовате-
ля, карточек CRC и вариантов изменений мы использовали обычные карточки.
Единственным исключением была модель соглашения, описывающая интерфейс
для нашей транспортной компании. Эту модель лучше всего создавать при помо-
щи текстового редактора.
Хотя нам и пришлось выяснять требования, касающиеся вычисления налогов,
нам не нужно было ничего моделировать. Собрать требования было довольно лег-
ко, поэтому мы сразу же перешли к конструированию. Да, мы использовали исто-
рию пользователя, касающуюся налогов, которую с натяжкой можно было бы на-
звать высокоуровневым требованием, но она и близко не лежала с традиционной
моделью требований. Тесты приемки, созданные заказчиком для оценки нашей
работы, больше похожи на документированные требования. Они описывают фун-
кции, которые должна реализовывать наша система, поэтому из всех документов
по налогам они больше всего похожи на документированные требования. Все это
сработало просто отлично, потому что тесты приемки, направленные на создание
необходимых заказчикам функций, отвечали их требованиям (помните принцип
«Главная цель — программное обеспечение»).
Познакомившись с третьей частью этой книги, вы увидели, что моделирова-
ние является (и всегда являлось) важной частью ХР-проектов, что бы там ни го-
ворили злопыхатели. Вы также убедились в том, что принципы и методики AM
и ХР прекрасно сочетаются друг с другом, что весьма закономерно, учитывая,
что AM заимствовало многие аспекты ХР и может быть успешно использовано
в ХР-проектах. В четвертой части мы рассмотрим, как сочетаются AM и UP.
Как это осуществить?
Моделирование действительно является частью ХР, но по сравнению с про-
граммированием и тестированием эта часть очень мала. Оно работает, посколь-
ку многие из первичных целей моделирования (поддержка общения, исследова-
ние важнейших вопросов) достигаются во взаимодействии с другими средствами.
Отметим интересные особенности использования AM в сочетании с ХР:
254 Глава 21 • Моделирование во время ХР-итерации: подсчет общей суммы заказа
• AM следует использовать понемногу для повышения эффективности ХР.
• Добивайтесь.простоты. Несмотря на то что в приложении А описывается
множество методик моделирования, для работы ХР-группам могут понадо-
биться лишь нёмногие из них.
• ХР-разработчики должны понимать, что моделирование не должно превра-
щаться в бесполезную бумажную работу, которую они терпеть не могут.
• AM может помочь некоторым организациям научиться применять ХР, осо-
бенно тем, которые с подозрением относятся к его кажущейся простоте.
Часть
Гибкое моделирование
и унифицированный
процесс
В данной части я описываю применение гибкого моделирования (AM) в унифици-
рованном процессе (UP) (Джекобсон, Буч и Рамбо, 1999; Кратчен, 2000; Амблер,
2001b). Сюда входят следующие главы:
► Глава 22: Гибкое моделирование и унифицированный процесс. В данной гла-
ве рассматриваются моделирование в UP-проекте и совместимость AM и UP.
> Глава 23: Гибкое моделирование в жизненном цикле унифицированного про-
цесса. В данной главе подробно рассмотрены рабочие потоки унифицирован-
ного процесса.
► Глава 24: Гибкое бизнес-моделирование. В данной главе рассмотрено примене-
ние принципов и методик AM для бизнес-моделирования в AM/UP-проекте.
► Глава 25: Гибкое определение требований. В данной главе рассмотрено при-
менение принципов и методик AM для определения требований в АМ/
UP-проекте.
► Глава 26: Гибкий анализ и проектирование. В данной главе рассмотрено при-
менение принципов и методик АМ для анализа и проектирования в АМ/
UP-проекте.
► Глава 27: Гибкое управление инфраструктурой. В данной главе рассмотрено
применение принципов и методик АМ для моделирования в рабочем пото-
' ке «Управление инфраструктурой», включая возможности применения АМ
в крупных проектах.
► Глава 28: Применение АМ в UP-проекте. В данной главе рассматриваются
методы преодоления сложностей, с которыми вы можете столкнуться, приме-
няя гибкое моделирование в унифицированном процессе.
Гибкое
моделирование
и унифицированный
процесс
Как мы уже выяснили, гибкое моделирование — это упорядочивающий, основан-
ный на методиках процесс создания ПО, объясняющий, как моделировать и созда-
вать документацию гибким способом. Методики AM используются (желательно
использовать все методики сразу) для повышения эффективности других процес-
сов создания ПО, например экстремального программирования (ХР, Бек, 2000),
унифицированного процесса фирмы Rational (RUP, Rational Corporation, 2001)
и корпоративного унифицированного процесса (EUP, Амблер, 2001b). Эти про-
цессы имеют более широкие границы, чем AM. ХР и RUP являются процесса-
ми разработки, a EUP — это полный процесс создания ПО, включающий в себя
разработку и производство. Хотя эти процессы содержат моделирование и созда-
ние документации в той или иной форме, всегда есть возможность для усовершен-
ствования. В случае с ХР моделирование должно быть более четко выражено, как
мы уже обсудили в третьей части этой книги. Что касается RUP и EUP, то моде-
лирование в этих процессах можно сделать более гибким.
В этой главе я подробно рассмотрю возможности использования гибкого моде-
лирования в унифицированном"процессе, включая RUP и EUP, но не ограничи-
ваясь этим. Для этого нам нужно рассмотреть следующее:
• Моделирование в унифицированном процессе.
• Как сочетаются AM и UP?
• Как добиться гибкости.
Моделирование в унифицированном процессе
Все виды деятельности, включая моделирование, в UP поделены на различные
рабочие потоки и выполняются с применением итеративного и инкрементного
подхода. Жизненный цикл корпоративного унифицированного процесса (EUP)
Моделирование в унифицированном процессе 257
изображен на рис. 22.1 — это расширенная версия жизненного цикла унифици-
рованного процесса фирмы Rational. Я бы сказал, что унифицированный процесс
в большом периодичен, в малом итеративен, а с течением времени поставляет
инкрементные реализации. Пять этапов EUP последовательно сменяют друг
друга. На этапе «Начало» выполняется запуск проекта. Как только границы
проекта определены, вы занимаетесь анализом требований и разработкой
архитектуры (этап «Развитие»), На этапе «Конструирование» вы занимаетесь
собственно конструированием системы. На этапе «Переход» вы приближаетесь к
.реализации системы и, наконец, вы занимаетесь эксплуатацией и поддержкой
вашего ПО на этапе «Производство». Однако вы работаете итеративно, ежеднев-
но занимаясь всем понемногу — моделированием, реализацией, тестированием
и управлением.
В унифицированном процессе фирмы Rational можно выделить три рабочих
потока1, связанных с моделированием: «Бизнес-моделирование», «Сбор требова-
ний», «Анализ и проектирование». В корпоративном UP прибавляется четвертый
рабочий поток — «Управление инфраструктурой», который включает в себя сбор
требований в масштабе предприятия и моделирование архитектуры. Эти четыре
рабочих потока описаны в табл. 22.1. В главе 23 подробно рассматриваются рабо-
чие потоки унифицированного процесса и возможности эффективного примене-
ния принципов и методик АМ.
Виды деятельности
Бизнес-моделирование—
Требования ___________
„ Анализ и проектирование
Реализация _
Тестирование
Размещение.----------------
Эксплуатация и сопровождение
Управление конфигурацией
и изменениями--------------
Управление проектом________
Среда______________________
Управление инфраструктурой _
Этапы
Итерации
Рис. 22.1. Жизненный цикл корпоративного унифицированного процесса (EUP)
1 Рабочий поток «Реализация», вероятно, тоже можно включить в их число, так как в пего вхо-
дит деятельность, называемая «Интеграция модели реализации», цель которой — пересмотреть модель
проектирования для устранения проблем при интеграции и конструировании.
9 Зак. 926
258 Глава 22 • Гибкое моделирование и унифицированный процесс
Насколько совместимы AM и UP?
Теперь, когда мы поняли, как моделирование применяется в унифицированном
процессе, давайте выясним, насколько совместимы AM и UP. К счастью, многие
принципы и методики AM уже стали- частью UP, хотя и не настолько явно, как
бы мне хотелось. В табл. 22.2 рассматриваются возможности применения методик
AM в унифицированном процессе. По собственному опыту могу сказать, что груп-
па, участвующая в унифицированном процессе, легко может принять методики
AM (если захочет, конечно), потому что унифицированный процесс весьма гибок.
Основной принцип унифицированного процесса заключается в том, что вы може-
те изменять его в соответствии со своими задачами, следовательно, методики AM
легко можно применять в унифицированном процессе.
Таблица 22.1. Рабочие потоки, связанные с моделированием в унифицированном процессе
Рабочий поток Цель
Бизнес-моделирование Моделирование бизнес-среды системы, ее задач
Сбор требований Сбор требований для проекта, включая их определение, моделирование и документирование. Главный компонент системы, который создается в этом рабочем потоке, — спецификации требований к ПО (SRS). Этот компонент иногда называется моделью требований, которая включает в себя собранные требования
Анализ и проектирование Разработка устойчивой архитектуры системы на основе требований и преобразование требований в проектную модель. Следует убедиться, что проектная модель учитывает особенности среды реализации
Управление
инфраструктурой
(только корпоративный
унифицированный
процесс)
Сюда входят задачи, которые невозможно решить в рамках одного
проекта:
• моделирование требований в масштабе предприятия, создание и
развитие моделей, отражающих высокоуровневые требования вашей
организации
• моделирование архитектуры в масштабе предприятия, создание
и развитие моделей, отражающих бизнес-среду и техническую
инфраструктуру вашей организации
Таблица 22.2. Совместимость AM и UP
Методика Совместимость
1 2 -
Активное участие Гибкое моделирование называет множество заинтересованных лиц,
заинтересованных включая пользователей, руководство, операторов и группу обслуживания.
лиц То же самое можно сказать и об унифицированном процессе, где заинтересованные лица (пользователи и заказчики) принимают участие во всех рабочих потоках. В целях эффективности UP-группы должны позволить заинтересованным лицам участвовать в моделировании, например, в роли «проектировщик бизнес-процесса» или «спецификатор требований». В унифицированном процессе нет ничего, что препятствовало бы такому сотрудничеству. Чем более активное участие принимают заинтересованные лица, тем меньше понадобится проверок, презентаций для руководства и тому подобных вещей, снижающих скорость разработки
Насколько совместимы AM и UP? 259
1 2
Применяйте стандарты моделирования Применение стандартов моделирования, в частности, UML-диаграмм, является важным аспектом унифицированного процесса. Более того, унифицированный процесс фирмы Rational включает указания по созданию многих артефактов моделирования. Вашей группе следует взять эти указания на вооружение (не забывайте, что их можно изменять в соответствии с вашими задачами). Чтобы сохранить гибкость, UP-группы должны понять, что от указаний и стандартов иногда нужно отступать
Не увлекайтесь паттернами UP-группы могут применять паттерны моделирования. Унифицированный процесс фирмы Rational описывает множество паттернов моделирования, применяемых в рабочих потоках, связанных с моделированием. Данная методика облегчает применение паттернов, но в унифицированном процессе она выражена недостаточно четко
Применяйте нужный артефакт (артефакты) Одна из сильных сторон унифицированного процесса заключается в советах, когда создавать тот или иной тип модели. Поздние версии унифицированного процесса Rational включают в себя советы по созданию UML-артефактов типа модели данных и последовательности кадров пользовательского интерфейса (диаграммы потоков пользовательского интерфейса)
Совместное владение AM-концепция совместного владения может быть использована для повышения эффективности UP-проекта, способствуя открытым и доброжелательным контактам внутри группы. Унифицированный процесс поддерживает совместное владение, фокусируясь при этом на управлении конфигурацией (существует соответствующий рабочий поток), хотя управление изменениями может стать проблемой, если разработчики и заинтересованные лица не способны решить, когда следует контролировать изменения официально, а когда нет. Если честно, то эта проблема может возникнуть независимо от того, применяете ли вы AM в UP-проекте или любом другом проекте. Группы, занятые в UP-проекте, могут повысить эффективность управления конфигурациями, позволив любому участнику работать с любым артефактом, включая модели и документы
Учитывайте тестируемость В жизненный цикл UP-проекта входит рабочий процесс «Тестирование». Таким образом, тестирование является неотъемлемой частью унифицированного процесса, о которой должен помнить каждый участник проекта. Унифицированный процесс также предусматривает возможность проверки артефактов моделирования. Если вы решите принять эту методику, следует подходить к моделированию с вопросом: «Можем ли мы это протестировать?»
Создавайте несколько моделей параллельно Эта идея явно используется в унифицированном процессе. Достаточно взглянуть на диаграммы деятельности, изображающие все рабочие потоки, чтобы убедиться в том, что работа идет над несколькими артефактами одновременно. Однако эта идея должна быть выражена более четко, так как квазипериодичный поток в диаграммах деятельности для основных видов работы по моделированию этого не показывает. На самом деле эта методика имеет гораздо более широкую сферу применения, и вы это поймете, если рассмотрите жизненный цикл как одно целое. Поскольку в унифицированном процессе моделирование выполняется в отдельных рабочих потоках (на то есть веские причины), то может быть не совсем понятно, что вы можете работать одновременно не только над несколькими артефактами бизнес-моделирования, но и над артефактами требований, артефактами анализа, архитектуры и проектирования. UP-группы могут работать гораздо эффективнее, если будут выполнять виды деятельности из различных рабочих потоков, вместо того чтобы слепо следовать диаграммам рабочих потоков и диаграмме жизненного цикла унифицированного процесса
Продолжение
«в».
260 Глава 22 • Гибкое моделирование и унифицированный процесс
Таблица 22.2 (продолжение)
1 2
Создавайте простое содержание Разработчики моделей решают, применять эту методику или нет, но это решение должна поддерживать вся группа. UP-группы должны принять стандарты моделирования, согласно которым модель может быть удовлетворительной — ей незачем быть совершенной. Те, для кого эти модели предназначены (программисты, заинтересованные лица, рецензенты и т. д.), также должны с этим согласиться. Это не техническое решение. Оно относится к культуре организации, и многим организациям будет сложно на это решиться
Изображайте модели просто См. Создавайте простое содержание
Избавляйтесь от временных моделей Разработчики моделей в унифицированном процессе могут избавляться от того, что им не нужно. Вместе с методиками категории «Простота» ваша организация должна принять принцип «Путешествуйте налегке», то есть разрабатывать и поддерживать ровно столько моделей и документов, сколько действительно необходимо, но не более того
Демонстрируйте модели открыто UP-группы могут применять эту методику. Они могут сделать общение более эффективным, если будут следовать принципу «Открытые и доброжелательные контакты», открыв доступ ко всем артефактам и открыто демонстрируя важные модели, используемые группой,.занятой в проекте
Формализуйте модели соглашения Унифицированный процесс поддерживает идею интеграции с внешними системами. Такие системы обычно определяются в моделях Use Case; унифицированный процесс фирмы Rational предлагает ввести «граничные классы» для реализации интерфейса с этими системами. Во время создания этой книги унифицированный процесс фирмы Rational показал свою слабость в отношении анализа наследуемых систем и интеграции корпоративных приложений (EAI). Если UP примет эту методику, это значительно усилит его возможности по интеграции. Данная методика сочетается с идеей UP о реализациях элементов Use Case — взаимодействие между системами может быть обусловлено одним или более элементами Use Case; в этом случае реализация Use Case становится формализованной моделью соглашения
Переходите от одного артефакта к другому UP-группы легко могут принять эту методику. Я уже говорил, что унифицированный процесс весьма неудачно представляет моделирование в виде квазипериодичных процессов, а разделение моделирования на отдельные рабочие потоки может препятствовать формированию итеративного образа мышления, который необходим разработчику гибких моделей
Моделируйте постепенно Данная методика, несомненно, является аспектом унифицированного процесса. Итеративный подход, используемый в унифицированном процессе, подразумевает, что вы можете разрабатывать модели постепенно в ходе проекта. UP-группы легко могут улучшить на пару порядков свои итеративный и инкрементный'подходы, если будут разрабатывать небольшие и несложные модели, которые легко реализовать и тестировать
Моделируйте, чтобы общаться Эта идея явно используется в унифицированном процессе. Если UP-группы последуют принципу «Модель должна решать конкретную задачу» (следует знать, для кого предназначена та или иная модель и что от нее требуется), то их общение станет более эффективным
Моделируйте, чтобы понять См. Моделируйте, чтобы общаться
Насколько совместимы АМ и UP? 261
1 2
Моделируйте в группе Эта идея явно используется в унифицированном процессе. Каждый рабочий поток моделирования,выполняется с помощью различных ролей; на каждую роль требуется один или несколько человек. Если UP-группы будут применять инструментальные средства, способствующие моделированию в группе (например, белые доски или средства для совместного моделирования), то их общение станет более эффективным
Подтверждение модели кодом Эта методика явно используется в унифицированном процессе. Унифицированный процесс четко говорит, что в конце каждой итерации (кроме итераций на этапе «Начало») у вас должен быть работающий прототип (Амблер и Константайн, 2000а). Более того, UP настаивает на том, что к концу этапа «Развитие» у вас должен быть работающий сквозной прототип, который подтверждает правильность архитектуры (Амблер и Константайн, 2000b) '
Используйте имеющиеся ресурсы Повторное использование, как и управление имеющимися ресурсами, явно присутствует в корпоративном -унифицированном процессе. Однако можно повысить эффективность, если использовать имеющиеся ресурсы более активно, вместо того чтобы создавать их с нуля. Это касается моделей, компонентов, открытых программных средств (OSS), инструментальных средств и т. д.
Совершенствуйте только в случае необходимое™^ Теоретически эта методика может быть легко принята в унифицированном процессе, так как это значительно сократит работу, по поддержке артефактов. Однако на деле многие организации (особенно те, которые привыкли к «трассируемости») принимают ее с трудом. Трассируемость — это способность передачи свойств между различными артефактами.проекта. Унифицированный процесс поддерживает трассируемость, так как она является важным аспектом рабочего потока «Управление конфигурацией и изменениями». Более того, унифицированный процесс фирмы Rational включает в себя средства обучения для работы с Rational RequisitePro (http://www.rational.com) — инструментом для поддержания трассируемости требований, что легко позволяет сопровожать матрицу трассируемости артефактов. По опыту могу сказать, что организации, поддерживающие трассируемость, обычно регулярно совершенствуют свои артефакты, даже если в том нет особой необходимости, и обновляют матрицу трассируемости, которая обеспечивает связь между артефактами. С целью повышения продуктивности UP-группы должны принять принцип «Путешествуйте налегке» — следует немного отпустить гайки и перестать ревностно следить за синхронизацией артефактов. Матрицу трассируемости следует поддерживать только в том случае, если это явно приносит пользу. Важно, чтобы заинтересованные лица понимали это и сами решали, следует ли это делать. Матрица трассируемости несомненно является документом, следовательно, решение о ее создании и поддержке является чисто деловым и принимается заинтересованными в проекте лицами
Используйте простейшие инструментальные средства Унифицированный процесс фирмы РаЬопа1'включает в себя средства обучения, которые облегчают использование утилит, производимых этой фирмой. На самом деле UP-группы могут использовать любое инструментальное средство разработки. Средства производства фирмы Rational не лучше и не хуже средств других производителей. UP-группы могут значительно повысить продуктивность, если будут пользоваться простыми инструментами (карточками, белой доской и стикерами) наряду с САБЕ-средств,ами
262 Глава 22 • Гибкое моделирование и унифицированный процесс
Как добиться гибкости
Итак, мы убедились, что моделирование является важной частью унифицированно-
го процесса. Одно из его проявлений, унифицированный процесс, фирмы Rational,
делит работу по моделированию натри рабочих потока: «Бизнес-моделирование»,
«Сбор требований», «Анализ и проектирование». В корпоративном UP прибав-
ляется четвертый рабочий поток, «Управление инфраструктурой», который тоже
включает в себя значительную работу по моделированию. Вы также убедились,
что при желании вполне можно совместить унифицированный процесс и гйбкое
моделирование. В следующей главе мы рассмотрим, как гибкое моделирование
может увеличить эффективность рабочих потоков унифицированного процесса.
В главах 23-27 рассматриваются возможности совместного использования UP
и AM на примере SWA Online. В главе 28 перечислены особенности примене-
ния гибкого моделирования в UP-проекте. Главная трудность состоит в том, что
UP-группа может использовать гибкий подход к разработке, но на это нужно ре-
шиться, а это не всегда просто. Помните, что успех сопутствует тем, кто его доби-
вается.
Гибкое
моделирование
в жизненном
цикле
унифицированного
процесса
1то может быть более абсурдно, чем перспектива
тоявления паровозов, едущих вдвое быстрее
щлижанса?
Ежеквартальное обозрение, Англия, 1825
Чтобы понять, как надо применять принципы и методики AM в проектах, исполь-
зующих унифицированный процесс (Джекобсон, Буч и Рамбо, 1999), мы долж-
ны рассмотреть, как можно использовать моделирование в жизненном цикле уни-
фицированного процесса (UP). Чтобы сделать это, мы должны исследовать UP
с точки зрения расширенного жизненного цикла корпоративного унифицирован-
ного процесса (Амблер, 2001b), поскольку на данный момент это наиболее пол-
ный жизненный цикл для UP. В отличие от обычного унифицированного про-
цесса, жизненный цикл корпоративного унифицированного процесса включает
в себя этап «Производство» и два новых рабочих потока — «Управление инфра-
структурой» и «Эксплуатация и сопровождение». Для того чтобы понять, Как мо-
делировать в UP/AM-проектах, давайте сначала рассмотрим рабочие потоки, свя-
занные с моделированием, а затем сконцентрируемся на остальных.
Рабочие потоки, связанные с моделированием
В данном разделе подробно рассмотрены четыре рабочих потока, связанных с мо-
делированием. Особое внимание уделяется типам артефактов моделирования,
которые вам, скорее всего, понадобятся. Все эти рабочие потоки допускают при-
менение методик гибкого моделирования. Мы рассмотрели возможности совме-
стного'применения AM и UP в главе 22. В главах 24-27 мы рассмотрим примене-
264 Глава 23 • Гибкое моделирование в жизненном цикле унифицированного процесса
ние методик АМ в каждом из рабочих потоков UP, связанных с моделированием,
на примере SWA Online. Ниже приводятся эти четыре рабочих потока:
1. Бизнес-моделирование.
2. Требования.
3. Анализ и проектирование.
4. Управление инфраструктурой.
Виды деятельности
Бизнес-моделирование___
Требования ____________
Анализ и проектирование
Реализация _
Тестирование
Размещение_________________
Эксплуатация и сопровождение
Управление конфигурацией
и изменениями--------------
Управление проектом________
Среда______________________
Управление инфраструктурой _
Этапы
Итерации
Рис. 23.1. Жизненный цикл корпоративного унифицированного процесса
Бизнес-моделирование
Целью бизнес-моделирования является исследование бизнес-среды, в которой бу-
дет эксплуатироваться система. Большая часть работы по бизнес-моделированию
приходится на этапы «Начало» и «Развитие», хотя может выясниться, что вам при-
дется этим заняться и на этапах «Переход» и «Производство». Итак, ваша цель:
• йсследовать бизнес-среду организации, в которой будет размещена ваша '
система;
• определить задачи, которые заказчик будет решать с помощью вашей сис-
темы;
• убедиться в том, что ваша группа разработчиков и заказчик одинаково ви-
дят бизнес-среду организации;
• определить требования заказчика к системе (Rational Corporation, 2001).
Рабочие потоки, связанные с моделированием 265
По большому счету, бизнес-моделирование — это традиционный системный
анализ (Гейн и Сарсон, 1979; Йордон, 1989), но с использованием элементов Use
Case.
В табл. 23.1 перечислены части UP-поставки, которые обычно создаются в про-
цессе бизнес-моделирования, артефакты моделирования (см. приложение А), кото-
рые вам могут при этом понадобиться, и способы использования группой разработ-
чиков каждого из перечисленных компонентов. Следуйте методике «Применяйте
нужный артефакт (артефакты)» и создавайте только те, без которых вы не можете
обойтись. Помните о том, что мы путешествуем налегке, и сохраняйте только те
артефакты, которые будут использоваться в дальнейшем. В табл. 23.1 приведены
различия между моделью предметной области, применяемой в унифицированном
процессе фирмы Rational, и гибкой моделью предметной области. Выбирайте мо-
дель, которая в большей степени соответствует вашей задаче.
В главе 24 ‘бизнес-моделирование рассматривается на примере SWA Online
с учетом возможности применения методик AM. Наибольшее значение для
бизнес-моделирования и определения требований имеет методика «Активное
участие заинтересованных лиц». Тесное сотрудничество с пользователями явля-
ется частью унифицированного процесса, а гибкое моделирование без этого прос-
то немыслимо.
Требования
Чтобы определить требования, необходимо путем переговоров с заинтересован-
ными лицами выяснить, что должна делать система (любые изменения требова-
ний должны согласовываться между обеими сторонами). Кроме того, необходимо
убедиться, что разработчики понимают эти требования, выявить рамки системы,
обеспечить основания для оценки и определить пользовательский интерфейс сис-
темы (Rational Corporation, 2001). Как показано на рис. 23.1, большая часть рабо-
ты по моделированию требований приходится на этапы «Начало» и «Развитие»,
хотя на остальных этапах также4 выполняется определение и исследование требо-
ваний (особенно на этапе «Конструирование»),
Таблица 23.2 содержит артефакты, которые вам могут понадобиться при опре-
делении требований (см. также приложение А). Обратите внимание, что для обоз-
начения артефактов используются термины AM, а не унифицированного процесса
фирмы Rational. Последовательность кадров для элементов Use Case приводит-
ся дважды: для версии AM, в которой используются ne-UML-артефакты, и для
версии унифицированного процесса фирмы Rational, которая ограничивается
UML-артефактами.
Артефакты, над которыми вы работаете в процессе бизнес-моделирования, час-
то превращаются в версии артефактов требований, согласно стратегии управле-
ния версиями (см. приведенный далее раздел «Управление конфигурацией и из-
менениями»). Эти два рабочих потока весьма похожи: бизнес-моделирование
направлено на понимание бизнес-среды и сбор высокоуровневых требований.
Определение требований фокусируется на выяснении детализированных тре-
бований. Разработчики гибких моделей не делают различия между этими двумя
266 Глава 23 • Гибкое моделирование в жизненном цикле унифицированного процесса
типами артефактов. Например, вместо применения бизнес-спецификации и прос-
то спецификации они используют одну спецификацию (если используют вообще).
В главе 25 описывается рабочий поток «Определение требований» на примере
SWA Online.
Анализ и проектирование
Целью анализа и проектирования является создание устойчивой архитектуры
системы, разработка подробного проекта системы на основе требований и адапта-
ция проекта к среде реализации (Rational Corporation, 2001). Что касается моде-
лей, наибольшее значение для данного рабочего потока имеют артефакты требова-
ний, хотя бизнес-модели также важны. Понятно, что тут не обойтись без обратной
связи с программистами и тестировщиками, так что лучше принять принцип гиб-
кого моделирования «Быстрая обратная связь» и методику «Подтверждение мо-
дели кодом». Как вы видите на рис?23.1, большая часть моделирования, связан-
ного с анализом и проектированием, происходит на этапах «Конструирование»
и «Развитие».
В табл. 23.3 перечислены артефакты, которые вам, возможно, понадобится со-
здать в процессе анализа и проектирования. Приводится два варианта реализа-
ции элементов Use Case: один используется в унифицированном процессе фирмы
Rational, а другой (гибкий) больше подходит для разработчиков гибких моделей.
Следует отметить, что, несмотря на название, реализации элементов Use Case опи-
сывают реализацию не только элементов Use Case, но и соответствующих арте-
фактов требований, например бизнес-правил и ограничений.. Глава 26 рассматри-
вает рабочий поток «Анализ и проектирование» на примере SWA Online.
Таблица 23.1. Артефакты бизнес-моделирования
UP-поставка Артефакт Назначение
1 2 3
Документация по бизнес- Схема организации архитектуре Технические требования Определение ограничений Обзор бизнес-среды; может содержать предложения по реконструированному представлению этой среды. Описывает структуру и культуру организации, предлагает изменения и стратегию их выполнения. Документ содержит технические требования и ограничения, касающиеся размера системы, ее производительности и параметров качества. Также содержит подмножество контекстных моделей — важные для архитектуры элементы Use Case или деловые процессы, характеризующие деловую активность и основные аспекты организации
Рабочие потоки, связанные с моделированием 267
1 2 3
Бизнес-глоссарий Глоссарий Определяет общую для всех артефактов терминологию
Бизнес-объектная модель (АМ) CRC-модель UML-диаграмма классов Описывает бизнес-среду. Поскольку в фирме Rational большая часть работы по созданию бизнес- объектных моделей (создание диаграмм деятельности, сотрудничества, последовательности и схем состояний) приравнивается к высокоуровневому анализу (Амблер, 200ia), то часто применяется более простой подход — моделирование предметной области посредством создания CRC-моделей или UML- диаграмм классов
Бизнес-объектная модель (UP фирмы Rational) UML-диаграмма деятельности UML-диаграмма сотрудничества UML-диаграмма последовательности UML-диаграмма схем состояний Информация по предметной области (определение бизнес- объектов и их связей) описывается с помощью UML-диаграмм классов. Динамические взаимодействия между этими объектами могут быть смоделированы путем использования UML-диаграмм сотрудничества или UML-диаграмм последовательности, а динамическая природа самих объектов — с помощью UML- диаграмм схем состояний. UML-диаграммы деятельности используются для описания бизнес- процессов
Бизнес-правило Бизнес-правило Определяет бизнес-правила вашей системы
Бизнес-модель Use Case UML-диаграмма Use Case Основные элементы Use Case Описывает предполагаемые функции бизнеса, в идеале — независимо от технологии. Важной частью модели являются спецификации бизнес- элементов Use Case, независимых от технологии элементов Use Case, которые в данной книге называются сущностными (основными) элементами Use Case
Бизнес-спецификация 1 Варианты изменений Определение ограничений Характеристики Технические требования Представляет все необходимые бизнес-определения, не вошедшие в контекстную модель или модель предметной области. Это могут быть требования к поведению или практичности, документированные с использованием характеристик или ограничений, равно как и требования к надежности, производительности и масштабируемости, документированные в виде ограничений или технических требований
268 Глава 23 • Гибкое моделирование в жизненном цикле унифицированного процесса
Таблица 23.2. Артефакты моделирования требований
UP-поставка Артефакт Назначение
1 2 3
Контекстная модель Диаграмма потоков данных (DFD) UML-диаграмма Use Case Описывает текущий бизнес- процесс, обычно в рамках задач разрабатываемой системы. Прочитав главу 25, вы поймете, что для этой цели больше подходит диаграмма потоков данных, а не UML-диаграмма Use Case (Rational Corporation, 2001)
Глоссарий Глоссарий Определяет общую для всех артефактов терминологию
Спецификация Варианты изменений Определение ограничений Характеристики Технические требования Бизнес-правила \ \ Содержит все необходимые требования, не1 вошедшие в модель Use Case. Может содержать бизнес-правила, требования к поведению или практичности, документированные с использованием характеристик или ограничений, равно как и требования к надежности, производительности и масштабируемости, документированные в виде ограничений или технических требований
Модель Use Case UML-диаграмма Use Case Системные элементы Use Case Служит основным артефактом требований в UP. Модель Use Case обычно состоит из UML-диаграммы < Use Case, спецификаций элементов Use Case и определений актеров •
Последовательность кадров для элементов Use Case (AM) Диаграмма потоков пользовательского интерфейса Диаграмма устойчивости Показывает, как тот или иной элемент Use Case поддерживается пользовательским интерфейсом системы. Диаграмма устойчивости используется для анализа элементов Use Case и для идентификации различных управляющих классов, граничных классов й классов- сущностей. Диаграмма потоков пользовательского интерфейса обеспечивает полный обзор пользовательского интерфейса для отдельно взятого элемента Use Case. (Иногда диаграмма потоков пользовательского интерфейса создается для обзора пользовательского интерфейса системы целиком.) Имейте в виду, что последовательность кадров составляется только для одной из диаграмм
Рабочие потоки, связанные с моделированием 269
1 2 3
Последовательность кадров для элементов Use Case (UP фирмы Rational) Характеристики или ограничения UML-диаграмма классов Диаграмма последовательности или диаграмма сотрудничества Сценарий использования Для описания требований практичности используются характеристики и ограничения (обычно в свободной текстовой форме) пользовательского интерфейса. Для определения классов (включая граничные классы/ классы интерфейса, управляющие классы и классы-сущности), необходимых для поддержки Use Case, используются UML- диаграммы последовательности или UML-диаграммы сотрудничества. UML-диаграмма классов обычно используется для изучения структуры определяемых классов. Сценарии использования могут быть написаны для описания взаимодействия пользователя с системой
Прототип пользовательского интерфейса Прототип пользовательского интерфейса (или сущностный прототип пользовательского интерфейса) Это «традиционная» модель пользовательского интерфейса системы, созданная при помощи инструмента прототипирования интерфейса или языка реализации (например, Visual Basic или Java). Разработчики гибких моделей часто используют сущностные прототипы пользовательского интерфейса для изучения требований, а прототипы пользовательского интерфейса — для анализа и проектирования совместно с заказчиками
СОВЕТ: МОДЕЛИРОВАНИЕ В UP СОПРЯЖЕНО С НЕКОТОРЫМИ ТРУДНОСТЯМИ-
Во время моделирования в унифицированном процессе вы можете столкнуться с некоторыми
проблемами. Во-первых, унифицированный процесс чрезвычайно сложен. Честно говоря, он
и должен быть сложным, для того чтобы создавать множество различных типов приложений.
Создатели UP из фирмы Rational открыто говорят о том, что процесс необходимо «подгонять»
под конкретную среду реализации (например, отсекать лишнее). Во-вторых, рабочие потоки
UP должны быть переработаны. Определение требований производится в рабочих потоках
«Бизнес-моделирование» и «Определение требований». В-третьих, некоторые из артефактов
должны быть переосмыслены. Как мы видим из табл. 23.1, 23.2 и 23.3, существует прекрасная
возможность упростить основные UP-артефакты. Общая идея — создание артефактов при
помощи простых инструментальных средств, описанных в главе 10, вместо артефактов, которые
требуют применения сложных CASE-средств (например, Rational Rose). '
Управление инфраструктурой
Целью рабочего потока «Управление инфраструктурой» является осуществление
деятельности, необходимой для разработки, изменения и сопровождения арте-
фактов инфраструктуры организации (например, модели организации/предпри-
270 Глава 23 • Гибкое моделирование в жизненном цикле унифицированного процесса
ятия, процессы создания ПО, стандарты, руководства и артефакты', которые могут
быть использованы повторно). Управление портфелем программного обеспече-
ния также осуществляется в этом рабочем потоке. Короче говоря, управление ин-
фраструктурой происходит на протяжении всего проекта, что пока не осуществля-
ется в унифицированном процессе фирмы Rational (Кратчен, 2000). В табл. 23.4
перечислены артефакты, предлагаемые корпоративным унифицированным про-
цессом, включая стандарты моделирования. С первого взгляда кажется, что ра-
бочий поток «Управление инфраструктурой» противоречит идеям АМ (на самом
деле так может произойти,, если вы будете реализовывать его не-гибким образом),
но прочитав главу 27, вы поймете, что гибкий подход вполне применим в рабочем
потоке «Управление инфраструктурой».
Таблица 23.3. Артефакты моделирования для анализа и проектирования
UP-поставка Артефакт Назначение
1 2 3
Модель анализа UML-диаграмма классов Реализации элементов Use Case (см. ниже) Описывает анализ модели требований, представляя собой обзор системы. Часто носит временный характер, поскольку может стать моделью проектирования, а может быть и отброшена. Гибкие разработчики обычно преобразуют бизнес- объектные модели целиком или частично (в случае, если они вообще создают такие модели) в модель анализа
Модель данных Модель данных Описывает физическое (и иногда логическое) представление устойчивых данных системы, включая любое поведение, определенное в базе данных
Модель размещения UML-модель размещения Описывает узлы аппаратного обеспечения, компоненты ПО, распределенные по этим узлам, и посредническое ПО, которое соединяет узлы системы. Часто является наиболее важной архитектурной моделью системы
Модель проектиро- вания UML-диаграмма классов Реализации элементов Use Case (см. ниже) Набор моделей, которые описывают реализации элементов Use Case и служат в качестве абстрактного представления исходного кода
Реализации элементов Use Case (AM) UML-диаграмма последовательности Диаграмма устойчивости CRC-модель Используются для анализа отдельно взятого элемента Use Case, привязывая требования, описанные при помощи данного элемента Use Case, к модели анализа и/или модели проектирования. Разработчики гибких моделей часто создают UML-диаграммы последовательности для 1
сложной логики элементов Use Case (иногда они
перерабатывают логику, что еще лучше). Для
изучения структуры классов, поддерживающих
элементы Use Case, лучше использовать карточки
CRC, а не UML-диаграммы классов, как предлагает'
унифицированный процесс фирмы Rational.
Другим вариантом является создание диаграммы
устойчивости элементов Use, Case для определения
возможных классов (см. главу 26);
Рабочие потоки, связанные с моделированием 271
1 2 3
Реализации элементов Use Case (унифицированный процесс фирмы Rational) Сценарий использования UML-диаграмма последовательности или UML-диаграмма сотрудничества Сценарий использования в текстовой форме описывает потоки логики в элементах Use Case. Каждый поток логики затем может быть исследован при помощи диаграммы взаимодействия (обычно это UML-диаграмма последовательности или сотрудничества). Диаграммы последовательности являются наиболее распространенным вариантом, поскольку они хорошо подходят для исследования последовательной бизнес-логики (что ясно из названия)
Таблица 23.4. Артефакты моделирования для управления инфраструктурой
UP-поставка Артефакт Назначение
Модель корпоративных требований Диаграмма Use Case Основной элемент Use Case Бизнес-правило Ограничение Техническое требование Отражает высокоуровневые требования предприятия (Джекобсон, Грис, Джонсон, 1997). Высокоуровневая диаграмма Use Case часто является основным артефактом, который поддерживается основными элементами/бизнес- элементами Use Case, не зависящими от технологии (и потому долгоживущими), и который дает ссылки на другие артефакты требований (например, бизнес-правила и определения ограничений). Модель требований проекта должна подробно отражать часть полной модели
Модель архитектуры предметной области UML-диаграмма компонентов или модель данных . Отражает высокоуровневую бизнес-структуру системы. UML-диаграмм’а компонентов достаточно часто используется в среде компонентов/ объектов, поскольку отражает крупномасштабные, используемые повторно элементы предметной области, которые изменяются разработчиками со временем. Отдельные компоненты в свою очередь описываются UML-диаграммой компонентов или UML-диаграммой классов (если они моделируются). В информационно-ориентированных средах лучше всего для этого подходит модель корпоративных данных, которая идеально показывает предметные области высокоуровневых объектов данных. Предметные области объектов, в свою очередь, описываются другими, более подробными моделями данных
Техническая модель архитектуры Сетевая диаграмма Отражает высокоуровневую техническую инфраструктуру, которая обеспечивает деловую активность организации. Сетевая диаграмма часто используется для отображения аппаратных/сетевых сред, хотя диаграммы свободной формы также используются
Стандарты моделирования Разработчики гибких моделей следуют методике «Используйте имеющиеся ресурсы», изменяя и модифицируя (если это необходимо) существующие стандарты и руководства, как того требует методика «Применяйте стандарты моделирования»
272 Глава 23 • Гибкое моделирование в жизненном цикле унифицированного процесса
Потоки, не относящиеся к моделированию
У инфицированный процесс охватывает не только моделирование. Моделирование
является важной частью UP, и поскольку рабочие потоки, связанные с моделиро-
ванием, влияют на другие рабочие потоки (и наоборот), мы должны рассмотреть,
как принципы и методики AM могут отразиться на других рабочих потоках. Мы
рассмотрим следующие рабочие потоки, не связанные с моделированием:
• реализация;
• тестирование;
• управление проектом;
• управление конфигурацией и изменениями;
• среда; .
• размещение;
• эксплуатация и сопровождение.
Реализация
Целью рабочего потока «Реализация» является написание и первичное тестирова-
ние программного кода ПО, а также интеграция результатов работы отдельных раз-
работчиков в рабочую систему. Ваша модель проектирования является отправной
точкой в этой работе. Применяя UP/AM подход к разработке ПО, вы сконцентри-
руетесь на данном рабочем потоке согласно принципу «Главная цель — программ-
ное обеспечение» и методике «Подтверждайте модель кодом». Конструкторы,
включая прикладных программистов и администраторов баз данных (DBA),- бу-
дут обеспечивать обратную связь по модели проектирования, а вы будете работать
в соответствии с полученной обратной связью. В идеале конструктором и разра-
ботчиком модели должен быть один и тот же человек. Эта идея поддерживается
в унифицированном процессе, где люди могут исполнять несколько ролей.
Тестирование
Целью данного рабочего потока является проверка и оценка качества и правиль-
ности системы. Он включает в себя как виды деятельности, связанные с тестирова-
нием ПО (тестирование единичных модулей й тестирование интеграции), так и
тестирование пользователем (тестирование практичности и приемлемости систе-
мы для пользователя). Важной-целью данного рабочего потока является выявле-
ние и устранение дефектов до развертывания системы. Модель проектирования
и модель требований наиболее важны для проведения тестирования. В процессе
моделирования гибкие разработчики следуют методике «Учитывайте тестируе-
мость», для того чтобы убедиться в том, что их работу не просто можно протести-
ровать, а можно протестировать просто. Поскольку разработчики гибких моделей
ценят простоту, они следуют методикам «Изображайте модели просто» и «Созда-
вайте простое содержание», что приводит к созданию моделей, которые понятны
Потоки, не относящиеся к моделированию 273
людям, для которых они создаются. Другими словами, модели должны быть по-
„ нятны тем, кто. будет их тестировать.
Управление проектом
Целью данного рабочего потока является руководство проектом UP/AM (пла-
нирование, управление риском, управление персоналом и мониторинг проекта).
В UP-проекте, независимо от того, следуете ли вы принципам и методикам AM, вы
работаете инкрементно и итеративно. Разработка проекта организована в виде ите-
раций, показанных на рис. 23.1. График работы над проектом основывается на эле-
ментах Use Case, которые написаны либо в рабочем потоке «Бизнес-моделирование»,
либо «Определение требований». Элементы Use Case или их части распределены по
итерациям, это позволяет определить, что должно быть создано в процессе той или
иной итерации. По мере развития проекта вы начинаете лучше понимать требова-
ния и возможность реализации этих требований, в связи с чем вам придется внести
изменения в план работы над проектом (помните принцип AM «Ожидайте измене-
ний»), Получается, что моделирование зависит от управления проектом. Это зна-
чит, что нужно сосредоточиться на элементах Use Case (и не только) для текущей
итерации, чтобы не нарушать графика работы над проектом и установить зависи-
мость управления проектом от моделирования. Для этого следует вносить измене-
ния в график работы в зависимости от текущего состояния моделей.
Рабочий поток «Управление проектом», безусловно, допускает применение
некоторых принципов AM. Во-первых, принцип «Открытые и доброжелательные
контакты» предполагает, что руководители проекта не будут ничего скрывать ни
от группы, ни от заинтересованных в проекте лиц даже тогда, когда им не захочет-
ся никого информировать. Во-вторых, принципы «Главная цель — программное
обеспечение», «Еще одна цель — продолжать проект» и «Путешествуйте налегке»
помогают расставить приоритеты проекта. Работа в группах, применяющих UP/
AM-подход, направлена в первую очередь на создание ПО, а не на создание доку-
ментации. Применение этих принципов влияет на артефакты, которые вы созда-
ете, на способы создания Этих артефактов и на конечный продукт, поставляемый
вашим заказчикам.
Управление конфигурацией и изменениями
Целью рабочего потока «Управление конфигурацией и изменениями» являет-
ся обеспечение успешного развития системы, контроль изменений и обеспече-
ние целостности артефактов системы. Применяя UP/AM-подход к разработке,
вы увидите, что вам не придется так много работать над данным рабочим пото-
ком. Во-первых, вы будете иметь дело с меньшим количеством артефактов, пото-
му что вы путешествуете налегке и используете простейшие инструментальные
средства. Вы не станете хранить все модели, и поэтому будете избавляться от вре-
менных моделей при первой же возможности. Во-вторых, вы не будете изменять
артефакты моделирования, которые вы решите поддерживать, так часто, как вы
это делали в прошлом, потому что вы следуете методике «Совершенствуйте толь-
ко в случае необходимости».
274 Глава 23 • Гибкое моделирование в жизненном цикле унифицированного процесса
, Хотя этот рабочий поток и становится проще, он также приобретает большую
важность, потому что вы следуете методике «Совместное владение». Каждый
член вашей группы должен иметь доступ к системе управления конфигурацией,
должен понимать процесс и соответственно ему следовать. Кроме того, в ситуа-
циях, когда ваша система должна быть интегрирована с другой системой (что до-
вольно часто происходит на практике), АМ предлагает вам формализовать модели
соглашения, которые описывают эту интеграцию. Эти модели соглашения Должны
контролироваться системой управления конфигурацией, тем самым подчеркивая
важность данного рабочего потока.
ВНИМАНИЕ: ХОРОШО ПОДУМАЙТЕ, ПРЕЖДЕ ЧЕМ СОЗДАВАТЬ
МАТРИЦУ ТРАССИРУЕМОСТИ ТРЕБОВАНИЙ ---------------------------;---------
Трассируемость — это способность связывать артефакты проекта друг с другом. Матрица
трассируемости требований является артефактом, который создается для того, чтобы отразить
эту связь. Создание матрицы начинается с выяснения отдельных требований, развитие которых
затем прослеживается во всех моделях анализа, архитектуры, модели проектирования, исходном
коде или тестовых вариантах, которые вы поддерживаете. Я знаю по опыту, что организации,
поддерживающие трассируемость, постоянно совершенствуют артефакты, игнорируя методику
«Совершенствуйте только в случае необходимости», поэтому они добиваются согласованности
всех артефактов (включая матрицу), которые поддерживают. Это противоречит принципу
«Путешествуйте налегке». Польза от наличия такой матрицы заключается в том, что с ее
помощью просто проводить анализ влияния, касающийся измененных требований, потому
что вам легко выяснить, какие аспекты системы подверглись изменениям. Однако если у вас
. есть люди, знакомые с системой, и вы желаете добиться успеха в совершенствовании системы,
тогда гораздо .проще и дешевле попросить этих людей проанализировать эти изменения.
Матрицы трассируемости довольно дорого обходятся, потому что затрать! на поддержку такой
матрицы (даже при наличии специального средства) гораздо выше, нежели извлекаемая из нее
польза. Информируйте своих заказчиков о соотношении затрат и прибыли, и пусть они сами
решат, нужно ли ее создавать. В конце концов, матрица — это документ1. Создание документа
является деловым решением, которое принимается заказчиком.
Среда
Целью рабочего потока «Среда» является формирование процессов, средств, стан-
дартов и руководств, используемых группой разработчиков. Гибкое моделирова-
ние, с одной стороны, опирается, а с другой стороны — оказывает влияние на этот
рабочий поток. Методика АМ «Применяйте стандарты моделирования» зависит
от наличия доступа к стандартам моделирования и руководствам по моделиро-
ванию, а одним из аспектов этого рабочего потока является определение и изме-
нение применяемых стандартов и руководств для вашей группы. Этим рабочим
потоком поддерживается принцип АМ «Приспосабливаем по месту», поскольку
изменение процесса разработки ПО в соответствии с потребностями группы и от-
дельных лиц является важным аспектом рабочего потока «Среда». Применение
методики АМ «Используйте простейшие инструментальные средства» упрощает
процесс конфигурации инструментальных средств. Можете себе представить, на-
сколько это просто, если вы имеете дело с карточками, белой доской и стикерами.
MATRIX IS A SYSTEM, разве не так? — Примеч. перев.
Как это осуществить? 275
Размещение
Целью рабочего потока «Размещение» является обеспечение успешного размеще-
ния вашей системы. Ваша работа в данном рабочем потоке в основном зависит от
того, насколько хорошо вы продумали само размещение, что, в свою очередь, зави-
сит от моделирования размещения в рабочем потоке «Анализ и.проектирование».
Принцип AM «Доверяйте человеческим инстинктам», поможет вам осуществить
работу по размещению. Если кто-нибудь из ваших коллег или заказчиков считает,
что ваша стратегия размещения недостаточно хороша, вам следует ее пересмотреть.
Эксплуатация и сопровождение
Целью рабочего потока «Эксплуатация и сопровождение» является осущест-
вление деятельности, необходимой для успешной эксплуатации и сопровожде-
ния вашего ПО. Наличие этого рабочего потока в жизненном цикле показывает,
что работе по эксплуатации и сопровождению уделяется существенное внимание
в вашей организации, и работники по эксплуатации и сопровождению являются
важными заинтересованными лицами. Понимание этого связано с применением
методики AM «Активное участие заинтересованных лиц».
Как это осуществить?
Первое и главное: для того чтобы AM нашло успешное применение в UP, необхо-
димо переработать UP и сделать его более гибким, потому что AM лучше всего ра-
ботает в гибком процессе (эта идея освещается в пятой части книги). UP возмож-
но изменить и сделать более гибким, хотя его можно так изменить, что он станет
лишь обузой для разработчиков. Чтобы добиться успеха в применении UP/AM-
подхода, вы должны сохранять твердость в вашем намерении быть гибкими.
Во-вторых, вы должны направить свою работу на создание качественно-
го ПО, а не документации. Об этом я уже говорил в пункте первом: вы долж-
ны быть гибкими. Многие организации, которые применяют унифицированный
процесс фирмы Rational (Rational Corporation, 2001), им довольны, потому что
он многогранен, описывает множество ролей разработки, он устойчив и описыва-
ет создание множества артефактов. Проблема состоит в том, что из-за разносто-
ронности UP многие группы забывают о том, что их главная цель — создание ПО,
отвечающего потребностям заинтересованных лиц, и блуждают в дебрях доку-
ментации. Документация хороша в умеренных количествах, но как мы знаем из
главы 14, создание слишком большого количества документации подвергает ваш
проект риску. Унифицированный процесс фирмы Rational может принести боль-
шую'пользу, если его правильно использовать, но вам совершенно не обязатель-
но создавать дополнительную бизнес-спецификацию только потому, что процесс
того требует. Гибкие разработчики путешествуют налегке и создают лишь те ар-
тефакты, которые им необходимы для достижения цели, и не более того. Группы,
применяющие UP/AM-подход к разработке, сведут свои усилия к минимуму.
276 Глава 23 • Гибкое моделирование в жизненном цикле унифицированного процесса
В-третьих, примите к сведению разнообразие артефактов. Хотя унифициро-
ванный процесс предлагает вам определенные модели, в следующих главах вы
увидите, что их легко заменять другими артефактами, созданными с помощью
простых инструментальных средств. Например, карточки CRC можно использо-
вать вместо UML-диаграммы классов; можно создать прототип пользовательско-
го интерфейса при помощи стикеров и планшета, вместо того чтобы делать это с
помощью утилиты прототипирования. В приложении А описаны различные ар-
тефакты моделирования, которые можно использовать вместо более сложных
и трудоемких технологий, предлагаемых унифицированным процессом фирмы
Rational или даже корпоративным унифицированным процессом.
Гибкое бизнес-
моделирование
Одно из самых страшных мучений для человека —
это муки восприятия новой идеи.
Вальтер Бейджхот
Прочитав главу 23, вы узнали, что целью рабочего потока «Бизнес-моделирование»
является изучение бизнес-среды, в которой работает систем'а. В данной главе мы
рассмотрим возможности применения принципов и методик АМ для увеличения
эффективности бизнес-моделирования в унифицированном процессе на примере
системы SWA Online, описанной в главе 1.
Как вы будете выполнять бизнес-моделирование в UP/AM-проекте? Во-пер-
вых, в самом начале проекта проведите начальный сеанс моделирования совмест-
но с заинтересованными лицами, чтобы изучить начальные требования к системе
и выработать общее видение бизнес-среды проекта. В главе 13 приведены советы
по применению гибкого подхода к организации и проведению таких сеансов, а так-
же дальнейшей работе после сеанса. В зависимости от того, насколько подробными
будут ваши модели, а также от количества времени, которое вы можете посвятить
начальному сеансу моделирования, в сеанс можно включить определение требо-
ваний (глава 25) и, возможно, даже анализ и проектирование (глава 26). Не вол-
нуйтесь, никто не обвинит вас в нарушении ходадтроцесса. Во-вторых, вы должны
быть готовы к проведению последующих сеансов, если нет возможности достиг-
нуть договоренности на первом. В-третьих, как только будет выработано общее
видение бизнес-среды, вы наверняка будете заниматься бизнес-моделированием
на коротких импровизированных сеансах, а не на формальных и длительных за-
седаниях.
Если 'для разработки проекта SWA Online вы выберете UP/AM-подход, то
в рабочем потоке «Бизнес-моделйрование» вы будете работать со следующими
артефактами: ’ .
• бизнес-модель (основная модель) Use Case;
• простая бизнес-объектная модель;
278 Глава 24 • Гибкое бизнес-моделирование
• гибкая бизнес-спецификация;
• видение бизнес-среды.
Бизнес-модель (основная модель) Use Case
Очень важно понимать высокоуровневые требования к системе, особенно на ран-
ней стадии, когда вы пытаетесь определить рамки проекта. Для изучения высоко-
уровневых требований к системе унифицированный процесс фирмы Rational
(Rational Corporation, 2001) предлагает создание бизнес-модели Use Case, вклю-
чая создание диаграммы Use Case и сопровождающей документации. На рис. 24.1
приведен цифровой снимок наброска высокоуровневой диаграммы Use Case, сде-
ланный на белой доске во время сеанса моделирования. Тогда же была получена
другая важная информация (бизнес-правила, ограничения и технические требо-
вания), которая была записана в бизнес-спецификации (см. далее). Целью началь-
ного сеанса моделирования являлось выяснение высокоуровневых требований,
а не просто определение высокоуровневых элементов Use Case, поэтому мы сле-
довали методике «Создавайте несколько моделей параллельно» и работали над
несколькими артефактами одновременно.
Рис. 24.1. Высокоуровневая диаграмма Use Case для SWA Online
В ходе сеанса моделирования мы использовали в диаграмме стереотип
«include». Как вы видите на рисунке, элемент Use Case «Поиск товара» вклю-
чается элементами Use Case «Размещение заказа» и «Управление каталогом». Для
Простая бизнес-объектная модель 279
части заинтересованных лиц это было непонятно, поэтому в начале сеанса моде-
лирования мы провели небольшой ликбез по моделированию элементов Use Case.
На это ушло некоторое время, но в результате мы добились следующего:
• Улучшилось взаимопонимание, поскольку все понимали созданную диа-
грамму. '
• Было достигнуто взаимопонимание с заинтересованными лицами, посколь-
ку всем пришлось чему-то учиться: мы изучали бизнес-среду организации,
а заказчики — процесс разработки ПО.
• Приобретенные навыки моделирования помогли заинтересованным лицам
активнее участвовать в работе над проектом.
Если посмотреть на рис. 24.1, стандвится понятно, ЧТО должна выпол-
нять система SWA Online, но не то, КАК она это выполняет. Эта модель пред-
ставляет независимое от технологии видение системы, поэтому ее, вероятно,
можно назвать основной диаграммой Use Case (Константайн и Локвуд, 1999;
Амблер, 2001а) — то, что в унифицированном процессе фирмы Rational называ-
ется бизнес-диаграммой Use Case. На основе этой диаграммы вы можете разра-
ботать систему с ручным или автоматическим управлением. Разумеется, элемент
Use Case «Отправить описание товара» лучше назвать «Записать описание то-
вара», чтобы он имел более широкое значение, но у заинтересованных лиц име-
лись свои соображения на этот счет. Вы должны всегда стараться сделать тре-
бования технологически независимыми, но на самом деле многие системы уже
ограничены неким подмножеством архитектурных возможностей. Например,
возможности SWA Online ограничены в рамках интернет-решения, так что по-
пытки абстрагироваться от этого ограничения вряд ли принесут реальную поль-
зу проекту. Помните о принципе «Повышайте отдачу от ресурсов, полученных
от заинтересованных лиц», и сосредоточьтесь на моделировании действительно
важных задач.
Элементы Use Case следует описывать просто; разработчики гибких моделей
обычно довольствуются схематичным описанием логики для каждого элемен-
та Use Case. Нет необходимости детально описывать систему; вам нужно лишь
выработать общее представление о том, что система должна выполнять, и опре-
делить ее рамки. Для этого достаточно схематичного описания каждого элемен-
та Use Case и актера. Если нет возражений со стороны заинтересованных лиц,
то бизнес-моделирование можно сделать еще проще — возможно, на текущий
момент достаточно определить три-четыре элемента Use Case. Если так, то да-
лее следуйте принципу «Модель должна решать конкретную задачу», отложите ,
бизнес-моделирование и переходите к детальному моделированию или даже реа-
лизации того, что вы уже определили.
Простая бизнес-объектная модель
Одной из основных целей рабочего потока «Бизнес-моделирование» являет-
ся понимание бизнес-процессов. организации. Один из способов этого добить-
280 Глава 24 • Гибкое бизнес-моделирование
ся — концептуальное моделирование или моделирование предметной области.
Унифицированный процесс фирмы Rational предлагает создать набор UML-
артефактов, описанных в главе 23, но для многих проектов (включая SWA
Online) это будет практически невыполнимо. Для SWA Online лучше создать
простую бизнес-объектную модель, которая рассматривает только структуру
бизнес-процессов и определяет главные бизнес-сущности и их взаимосвязь.
Структурированные методики обычно предлагают использовать для этой цели
логическую модель данных (LDM) — то, что нужно при создании системы с
помощью структурированных или процедурных технологий. Традиционные
объектно-ориентированные методы разработки обычно предлагают создание диа-
граммы классов.
Разработчики гибких моделей следуют методикам «Используйте простейшие
инструментальные средства» и «Применяйте нужный артефакт (артефакты)» —
и поэтому выбирают более простые средства (например, карточки CRC) для кон-
цептуального моделирования. Карточками CRC легко научиться пользоваться
(обучение не займет и 10 минут), поэтому .они более предпочтительны для кон-
цептуального моделирования. Карточки CRC можно и нужно использовать для
изучения требований совместно с заинтересованными лицами.
И окркакьль
Ра^кещаьк
Рк я а^ббкко
/4у,рбб «уЗе, б к б к
Рокбр а^ббкбк
Рбкорая а^Зббкка
Закл^,
3&КА2,
Дака ра^кбцбкая а^ббкка Дака р>бка/>к,а аоЗббкка ОЗи^ая б^кка а^оббкяа ДбйбкЗующаб налога а^Зббкны Р окбр ^.аюа^а а^ббкбк Заказан к ый койар а^Зббкбк Заьараккыа ко&ар
Рис. 24.2. Карточки CRC для классов «Покупатель» и «Заказ»
На рис. 24.2 изображены две карточки CRC, которые являются частью кон-
цептуальной модели SWA Online. Сверху написано наименование класса, слева —
Гибкая бизнес-спецификация 281
обязанности класса (то, что класс «знает» — данные, и то, что класс «делает» —
поведение), справа — классы, с которыми данный класс должен сотрудничать для
выполнения своих обязанностей. Сотрудники указывают на отношения между
классами. Например, известно, что покупатели связаны с заказами, поскольку
в карточке «Покупатель» класс «Заказ» указан как один из его сотрудников. Нам
неизвестны детали этого отношения (этим мы займемся позже), но пока нам это-
го достаточно, чтобы понять бизнес-среду, в которой работает наша система. Кроме
карточек «Покупатель» и «Заказ», в нашу CRC-модель наверняка войдут карточ-
ки «Товар заказа», «Налог», «Оплата доставки и обработки», «Товар каталога»,
«Доставка» и «Склад» и др., которые отражают важные понятия предметной
области.
СОВЕТ: НЕТ НЕОБХОДИМОСТИ СОЗДАВАТЬ ВСЕ АРТЕФАКТЫ -----------------------
Часто возникает заблуждение, состоящее в том, что нужно создавать все артефакты,
предложенные унифицированным процессом. На самом деле это не так, что ясно выражено
как в унифицированном процессе фирмы Rational (Кратчен, 2000; Rational Corporation, 2001),
так и в корпоративном унифицированном процессе (Амблер, 2001b). Следуйте принципу
«Приспосабливаем по месту» и изменяйте UP в соответствии с вашими конкретными нуждами.
Создавайте артефакт или его части только в том.случае, если это принесет пользу проекту.
Гибкая бизнес-спецификация
При использовании UP/AM-подхода артефакт «бизнес-спецификация» (SBS)
содержит такие требования бизнес-моделирования, которые нельзя включить в
другие артефакты. Когда разработчики гибких моделей исследуют высокоуров-
невые требования (подобно тому, как это делается на начальных сеансах модели-
рования требований, проводимых совместно с заинтересованными лицами), они
зачастую определяют соответствующее бизнес-правило, ограничения, техничес-
кие требования и даже возможные будущие требования к системе. Разработчики
гибких моделей фиксируют эти требования, обычно с помощью стикеров, карто-
чек или белой доски. При этом сохраняется минимум информации о требовании,
достаточный для его детального исследования в ходе конструирования. Этот ми-
нимум информации должен обеспечить понимание и оценку требования, плани-
рование его выполнения в последующей итерации. Именно такая информация
должна быть отражена в бизнес-спецификации.
Если заинтересованные лица согласны с тем, что вы «путешествуете налегке»,
то вам достаточно собрать ваши бумажки и карточки, а также сделать цифровые
снимки рисунков на белой доске — действия определяются теми средствами, ко-
торые использовались в ходе начального сеанса моделирования требований. Если
же заинтересованные лица более консервативны, вам придется обработать эту ин-
формацию с помощью более сложных инструментальных средств, например тек-
стового редактора или- CASE-средства. В главе 10 обсуждалось использование
простейших инструментальных средств, а в главе 14 рассматривались способы на-
писания гибкой документации. UP/AM-группы могут повысить эффективность
работы, применяя изложенные в данных главах советы. Что касается SWA Online,
282 Глава 24 • Гибкое бизнес-моделирование
то мы смогли убедить заинтересованных лиц позволить использование простей-
ших инструментальных средств, хотя они настояли на наличии документа, кото-
рый содержал бы краткие описания (иногда просто наименование) каждого пунк-
та бизнес-правила, ограничений, технических требований и возможных будущих
требований. , '
Возможные будущие требования? Важной частью определения рамок проек-
та является определение как реальных, так и возможных задач. Если вы опреде-
ляете требование как вариант изменения, то это значит, что сейчас данное требо-
вание находится вне рамок проекта. В рабочих потоках «Бизнес-моделирование»
и «Определение требований» группа разработчиков определяет как требования
для последующих версий системы, так и возможные требования, которые вам, мо-
жет быть, придется реализовать в какой-то момент. Вы не хотите терять эту ин-
формацию; в то же время вы не хотите тратить время на ее исследование или чрез-
мерно усложнять ваше ПО. Однако эта информация представляет некоторую
ценность для создания архитектуры — возможные требования могут выявить пре-
имущества одного варианта архитектуры над другим.
Варианты изменений, описанные в приложении А, представляют собой прос-
той способ документирования возможных требований. На рис. 24.3 показаны
два варианта изменений для SWA Online, каждый из которых был записан на
отдельной карточке во время моделирования совместно с заинтересованными
лицами. Варианты изменений описывают требования, которые потребуется (или
не потребуется) реализовать в будущем, но не в настоящий момент. Варианты
изменений часто являются результатом применения метода «мозговой атаки»
при совместной работе с заинтересованными лицами, например, при обсужде-
нии вопросов типа «Как может измениться бизнес?», «Каковы могут быть послед-
ствия изменений’в законодательстве?», «Что мы делаем, чтобы быть конкурен-
тоспособными?» или «Кто еще может использовать систему и каким образом?».
С технической точки зрения, разработчики часто могут задавать вопросы типа
«К чему приведет изменение технологии?» или «С какими системами должна
будет взаимодействовать наша система?», что также способствует определению
вариантов изменений. Варианты изменений должны быть реалистичны. «Мы
выходим на рынок страхования» или «Система должна учитывать новейшие
технологии» — реалистичные варианты изменений, а «Работники отдела продаж
похищены инопланетянами» — нет. Более того, варианты изменений обычно
описывают требования,, которые существенно отличаются от того, над чем вы
сейчас работаете, и которые могут привести к фундаментальной переработке.
Определяя варианты изменений, вы получаете возможность предусмотреть аль-
тернативные архитектурные и проектные решения, Варианты изменений следу-
ет учитывать при принятии решений только в том случае, если текущих требова-
ний недостаточно для выбора между имеющимися альтернативами. С помощью
вариантов изменений вы также можете объяснить заинтересованным лицам, по-
чему вы выбрали тот или иной подход, иначе говоря, грамотно навешать лапши
на уши. Однако варианты изменений не должны использоваться как оправдание
реализации ненужных возможностей системы. Будьте гибкими и не усложняйте
систему.
Гибкая бизнес-спецификация 283
Изменение: Расширение деятельности а Северной Америке
Вероятность: Высокая
' Сроки: 12-18 месяцев
||1!|И||ВВ|В^||ОШ^Ж1!1М1Ив11И1ЯМ!ИМ1Я1й1й11ИИМ1ИИМ1И11И1йй111!1М^И№11Ж1ИМ1ИИМ1№
Необходимо обеспечил» доставку товаров покупателям в Канаду и Мексику.
Понадобится сотрудничество с ноэыми спужбами доставки.
Необходимо рассчитать соответствующие налоги и пошлины.
Ассортимент товаров, продаваемых на местном рынке, будет другим
в соответствии с местным законодательством и покупательским спросом.
Поддержка многоязыкового сайта (английский и французский являются
государственными языками в Канаде, испанский язык—в Мексике),
Изменение: Продажа виртуальных товаров (online-музыка, видео, книги,,.,)
Вероятность: Высокая
- Сроки: 8-12 месяцев
Отпадет необходимость физической доставки товара.
Вероятна необходимость обеспечения цифрового лицензирования некоторых
ЯИИМ111^^ЙЯ1Йй1ИЯвИ111ИИВИ1ИЯ11В11ЯИИИИИЯ11И11*И1В1^»ИВ1
Следует ввести ограничения (срок действия, количество копий) при продаже
некоторых товаров.
Рис. 24.3. Два варианта изменений для SWA Online
Итак, что делать, если имеется вариант изменений, который, по вашему мне-
нию, должен быть реализован прямо сейчас? Все очень просто. Обсудите его с
заинтересованными лицами. Узнайте, является ли вариант изменений срочным
требованием, и если да, то действуйте соответствующим образом. Если это не сроч-
ное требование, то просто примите его к сведению и двигайтесь дальше. Никогда
не забывайте, что расставить приоритеты требований — обязанность заказчика,
а не ваша.
Стоит ли моделировать на будущее? Вообще-то это опасная штука — если раз-
работчик что-то моделирует, то велика вероятность, что он это реализует. Надо
быть очень дисциплинированным, чтобы не усложнять систему без надобности.
(Если вы уже представили себе идею в виде кружочков и линий, то очень просто
убедить себя в том, что система не станет намного сложнее от того, что вы доба-
вите эту возможность.) В заключение скажу, что нет ничего плохого в том, чтобы
сделать пару временных набросков при обсуждении варианта изменений, но не
надо усложнять модели, которые вы намерены сохранить.
СОВЕТ: ПЕРЕХОДИТЕ ОТ ОДНОГО РАБОЧЕГО ПОТОКА К ДРУГОМУ -----------------------
Хотя данная глава посвящена только рабочему потоку «Бизнес-моделирование», на самом
деле вы быстро переходите от одних рабочих потоков к другим. Например, немного бизнес-
моделирования, затем немного моделирования требований, немного анализа, еще немного
моделирования требований, снова анализ, за которым следует проектирование; и т. д.
Разработчики гибких моделей не делают различий между видами моделирования, они просто
моделируют то, что нужно в данный момент.
284 Глава 24 • Гибкое бизнес-моделирование
Видение бизнес-среды
Важной причиной проведения начального сеанса моделирования требований
совместно с заинтересованными лицами является достижение общего видения
бизнес-среды. Легко говорить о достижения согласия между заинтересованны-
ми лицами, но гораздо труднее достичь этого на практике. Каждое заинтересован-
ное лицо имеет свой опыт, свои приоритеты и предпочтения. Для достижения со-
гласия необходимо учитывать вышеизложенное; каждый должен объяснить, чего
он ждет от системы, выслушать мнения других и подготовиться к переговорам.
Каждый раз, когда группа не может прийти к согласию, я записываю каждое мне-
ние на белой доске, где все могут их видеть и обсуждать. Таким образом,, нагляд-
но отражаются разногласия, подлежащие обсуждению. Если автор того или ино-
го мнения понял, что оно лишнее или не так важно по сравнению с остальными,
запись можно стереть с доски или просто зачеркнуть (что даже лучше, посколь-
ку она потом пригодится при определении рамок проекта). Также удобно прово-
дить линии (лучше маркером другого цвета) между взаимоисключающими идея-
ми, подчеркивая необходимость их обсуждения.
Унифицированный процесс фирмы Rational (Rational Corporation, 2001) пред-
лагает документировать результаты обсуждения видения бизнес-среды. Но раз-
работчики гибких моделей понимают, что главная цель общение, а не доку-
ментация. Необходимо достичь согласия по вопросу видения бизнес-среды. На
практике документация по видению 'бизнес-среды представляет собой опасность.
Если у вас уже есть общее видение бизнес-среды, то создание документации бу-
дет пустой тратой времени и средств. Гораздо лучше потратить время на создание
ПО, чтобы показать заинтересованным лицам, что вы добиваетесь практических
результатов (согласно принципу «Главная цель — программное обеспечение»).
Если согласие еще не достигнуто, то документация может использоваться для
описания этой проблемы. Однако как только это будет изложено на бумаге, каж-
дый, прочитавший документ, может сказать, что общее видение достигнуто, хотя
на самом деле это не так. В этом случае вы рискуете столкнуться с большими про-
блемами в будущем. Вместо того чтобы тратить время на составление документа-
ции по ложному видению, вам следует работать с заинтересованными лицами для
дальнейшего выяснения их требований.
Как это осуществить
Бизнес-моделирование является самым непонятным рабочим потоком унифи-
цированного процесса. Я подозреваю, что это является результатом совпадения
с рабочим потоком «Требования». Как вы увидите, во многих случаях артефак-
ты бизнес-моделирования являются высокоуровневыми предпосылками для ар-
тефактов определения требований. Это нормально, но все равно вызывает за-
труднения у многих разработчиков. Пусть эта двусмысленность вас не тревЬжит.
В данном рабочем потоке разработчики гибких моделей должны сосредоточиться
на понимании бизнес-среды и определении начальных рамок системы (по край-
ней мере, на высоком уровне), а для этого необходимо тесно сотрудничать с заин-
тересованными лицами.
Гибкое
определение
требований
Собрания жизненно необходимы, если вы хотите
ничего не делать.
Джон Кеннет Галбрейт
Из главы 23 мы узнали, что целью рабочего потока «Требования» является выяс-
нение требований для проекта. Это значит, что вы совместно с заказчиками долж-
ны выяснить, что система должна выполнять, убедиться, что разработчики пони-
мают требования, определить рамки системы, обеспечить основания для оценки
и определить пользовательский интерфейс системы (Rational Corporation, 2001).
В данной главе мы рассмотрим, как принципы и методики AM могут повысить
эффективность определения требований в UP-процессе на примере SWA Online,
описанном в главе 1.
Как выполняется моделирование требований в UP/AM-проекте? Как уже об-
суждалось в главе 24, мы начнем с того, что проведем один (или больше, если по-
надобится) формальный сеанс моделирования на этапе «Начало», во время ко-
торого определим начальные требования к системе и выработаем общее видение
системы. В ходе этих сеансов также потребуется определить область действия
системы или хотя бы область действия версии, над которой мы сейчас работаем.
После этого моделирование требований происходит во время коротких нефор-
мальных импровизированных сеансов (см.тлаву 13). Поскольку мы применяем
AM в унифицированном процессе, для того чтобы определить требования и назна-
чить им приоритеты, нам необходимо постоянно поддерживать связь с заинтере-
сованными лицами, следуя методике «Активное участие заинтересованных лиц».
Создаваемые вами артефакты требований формируют то, что в унифицированном
процессе фирмы Rational (Rational Corporation, 2001) называется «спецификация
требований к ПО» (SRS), ранее известная как «модель требований».
Если к разработке системы SWA Online мы применяем UP/AM-подход, то в ра-
бочем потоке «Требования» нам предстоит работать со следующими артефактами:
• контекстная модель;
, • модель Use. Case; .
286 Глава 25 • Гибкое определение требований
• последовательность кадров для элементов Use Case;
• спецификация.
Контекстная модель
Хотя бизнес-модель Use Case, описанная в главе 24, может быть использована для
обзора системы, она рассматривает систему отдельно от контекста. Модель Use
Case полезна при описании функций системы, но не очень подходит для описа-
ния поведения системы во внешней среде. Функции системы и ее контекст опре-
деляют ваши задачи. Унифицированный процесс фирмы Rational (Кратчен, 2000;
Rational Corporation, 2001) предполагает, что информация об области действия
системы входит в документацию по видению системы, если такой артефакт во-
обще создается (помните о том, что разработчики гибких моделей «путешеству-
ют налегке»). Определение области действия системы может состоять из одного
утверждения. В случае с SWA Online это будет примерно так: «Продажа товаров
покупателям через Интернет», или более подробно — «Продажа физических (не
виртуальных) товаров существующим или новым покупателям на территории
Соединенных Штатов».
СОВЕТ: УЧИТЫВАЙТЕ МОДЕЛЬ КОРПОРАТИВНЫХ ТРЕБОВАНИЙ ------------------
Возможно, у вас имеется модель высокоуровневых требований (артефакт рабочего потока
«Управление инфраструктурой»), которая описывает организацию заказчика (см. главу 27).
В таком случае разработчики гибких моделей используют эту модель в процессе моделирования
требований, согласно методике «Используйте^ имеющиеся ресурсы». С помощью модели
корпоративных требований можно рассмотреть систему в контексте. В конце концов, цель
проекта — реализовать некое подмножество общих корпоративных требований.
Более сложный вариант — разработка контекстной модели, показывающей, как
система «вписывается» в общую среду организации. Контекстные модели обычно
создаются в виде диаграммы Use Case (рис. 25.1) или диаграммы потоков данных
(DFD) (рис. 25.2). Диаграммы такого типа часто называются диаграммами пото-
ков данных нулевого уровня. Чтобы оценить объем разработки, важно понять об-
ласть действия системы. Первое утверждение было достаточно расплывчатым —
непонятно, шла ли речь о продаже товаров по всему миру. Можно было подумать,
что имелись в виду покупатели в разных странах, что значительно увеличивает
объем работ сравнительно с продажами только в США. То же самое с продажей
виртуальных товаров — например, продажа музыки online потребует введения
системы online-доставки. Вы должны понимать, что область действия системы со
временем может измениться в соответствии с желаниями заинтересованных лиц,
так что ожидайте изменений.
Итак, какой артефакт лучше подходит для описания области действия систе-
мы — утверждение, диаграмма потоков данных (DFD) или диаграмма Use Case?
Это зависит от ситуации. Утверждения просты, но не так информативны, как диа-
грамма. Диаграмма’потоков данных на рис. 25.2 демонстрирует взаимоотноше-
Контекстная модель 287
ния системы с внешними объектами — организациями, людьми и другими сис-
темами (то есть объектами, которые вы не контролируете, но которые все равно
взаимодействуют с системой). Главное преимущество данного подхода состоит в
том, что он достаточно подробно отражает обмен данными между системой и внеш-
ним миром. На диаграмме Use Case на рис. 25.1 изображена система и актеры (ор-
ганизации, люди), которые с ней взаимодействуют. При этом учитываются как
внешние, так и внутренние актеры,'взаимодействующие с системой (в отличие от
диаграммы потоков данных, которая отражает только внешние объекты), но не
приводится никаких деталей взаимодействия системы и актеров.
Рис. 25.1. Бизнес-диаграмма Use Case для моделирования контекста SWA Online
Рис. 25.2. Диаграмма потоков данных для моделирования контекста SWA Online
Какую же диаграмму надо создать? Обе имеют свои достоинства и недостатки,
так может быть, стоит создать и ту и другую? Ни в коем случае! Ведь это не от-
вечает принципам гибкого моделирования. Лучше немного нарушить правила
и создать одну диаграмму, сочетающую в себе достоинства обеих диаграмм
288 Глава 25 • Гибкое определение требований
(см. рис. 25.3). Обратите внимание, что внутренние объекты отмечены буквой «I»1
(мое собственное обозначение), а цифровые указатели отсутствуют. С идентифи-
кационными номерами сложно работать, гораздо проще присвоить каждому объ-
екту уникальное имя, которое и будет служить идентификационным указателем.
На данном рисунке можно было использовать нотацию диаграммы Use Case, но
поскольку он показывает потоки данных, я бы нарушил важное правило модели-
рования элементов Use Case. К счастью, заинтересованные в данном проекте лица
привыкли к диаграммам потоков данных, поэтому им была понятна нотация, ис-
пользованная на рис. 25.3. Помните о том, что, согласно принципу «Модель долж-
на решать конкретную задачу», вы должны знать, для кого предназначается та или
иная модель, и подобрать наиболее подходящий артефакт. ’
СОВЕТ: НЕ БОЙТЕСЬ НАРУШАТЬ ПРАВИЛА -----------------------------------
Хотя внутренние объекты не принято включать в диаграммы потоков данных нулевого уровня,
дело в том, что их следует вводить тогда, когда вы начинаете углубляться в детали. Мы так
и сделали на рис'. 25.3, поскольку это позволило нам не рисовать еще одну диаграмму. Конец
света из-за этого не наступил, и никто не предъявил нам обвинения в нарушении правил
создания ПО. Может, мы и не применяли стандарты моделирования, зато снизили затраты на
разработку и сопровождение.
Рис. 25.3. Диаграмма потоков данных с внутренними объектами
для моделирования контекста SWA Online
Модель Use Case
Итак, как мы будем моделировать подробные требования для SWA Online?
Во-первых, допустим, что проект находится на этапе «Конструирование» и что
первоначальный вариант диаграммы Use Case, ^представленный на рис. 25.4, яв-
Internal (англ.) — внутренний. — Примеч. перев.
Модель Use Case 289
ляется наиболее адекватным на текущий момент. Мы работаем в паре, и наша
Труппа реализует описание и размещение заказа как часть основного потока пове-
дения элемента Use Case «Размещение заказа» в данной итерации. Мы не будем
реализовывать поиск товара, обработку любых типов ошибок и исключений, рас-
чет налогов или скидок, поскольку вся эта работа запланирована на следующие
итерации1. Основной поток поведения элемента Use Case часто называется «пра-
вильным путем», поскольку это такой логический путь, где все работает правиль-
но. Альтернативные действия описывают логические пути в случае, если что-то
происходит не так, как нужно. В случае с размещением заказа это может быть от-
сутствие на складе нужного покупателю товара. В данной итерации мы сосредо-
точимся на части «правильный путь». Над другими требованиями будут работать
другие подгруппы разработчиков или мы сами, но позднее.
Рис. 25.4. Высокоуровневая диаграмма элементов Use Case для SWA Online
Мы решили конкретизировать логику основного потока поведения, представ-
ленного на рис. 25.5, и параллельно работать над сущностными прототипами поль-
зовательского интерфейса, относящимися к данному элементу Use Case (один из
них показан на рис. 25.6). Мы работали над этими двумя артефактами параллель-
но, поскольку они подходят к вопросу с разных сторон: элемент Use Case описывает
1 Данный пример показывает общую для всех элементов Use Case проблему — обычно они слиш-
ком велики для того, чтобы реализовать их в одной итерации. Поэтому часто приходится реализо-
вывать один элемент Use Case на протяжении нескольких итераций (что неудобно с точки зрения
управления проектом) или разбить большой элемент Use Case на более мелкие элементы Use Case
(что неудобно с точки зрения моделирования).
10 Зак. 926
290 Глава 25 • Гибкое определение требований
действия системы и покупателя при размещении заказа, а сущностный прототип
пользовательского интерфейса определяет, что должен включать интерфейс SWA
Online для обеспечения выполнения этих действий. Обратите внимание, что вы-
зов элемента Use Case «Поиск товара» во втором пункте основного потока соответ-
ствует применению в приложении стереотипа «include» (см. рис. 25.4). Хотя эта
функциональность вызывается из той части элемента Use Case, над которой мы сей-
час работаем, мы не будем ее сейчас реализовывать, поскольку это не входит в наши
задачи. Поэтому мы поставим заглушку и перейдем прямо к странице результатов,
отражающей теоретические результаты поиска. Мы должным образом реализуем
возможность поиска позже, в ходе дальнейшей работы над проектом (помните, что
мы работаем инкрементно). Также отметим, что элемент Use Case пока не учиты-
вает технические вопросы, которые мы решим позже, во время анализа (см. главу
И) или проектирования (см. главу 12). Сейчас же нам необходимо понять основной
процесс размещения заказа, а деталями реализации мы займемся позже (возможно,
через несколько минут). Элемент Use Case описывает логику, которую мы не реали-
зуем на данной итерации (например, расчет налогов и скидок — функциональность,
вместо которой мы поставим заглушку до момента написания кода).
1. Элемент Use Case начинается, когда заказчик решает разместить заказ.
2. Заказчик ищет товары при помощи элемента Use Case «Поиск Товара».
3. Заказчик добавляет Заказанный товар к своему заказу
4. Заказчик указывает количество товара, который он желает заказать.
5. Система подсчитывает промежуточную сумму умножая цену предмета
на количество выбранных предметов.
6. Заказчик повторяет шаги со 2-го по 5-й, если это необходимо для
продолжения заказа.
7. Заказчик прекращает добавлять выбранный товар к своему заказу
3. Заказчик предоставляет информацию о доставке и оплате (имя, телефон, адрес).
9, Система подсчитывает промежуточную сумму всего заказа, складывая
промежуточные суммы частей заказа.
10. Система подсчитывает налоги, применимые к заказу согласно бизнес-лравилу
«Высчитать налоги с заказа»,
11. Система подсчитывает скидки, применимые к заказу согласно бизнес-лравилу
«Высчитать скидки с заказа».
12. Система показывает применимые налоги и скидки.
13. Система подсчитывает общую сумму заказа, добавляя применимые налоги
к промежуточной сумме заказа и вычитая скидки.
14, Система показывает описание заказа.
15. Покупатель проверяет заказ.
16. Система отправляет заказ на выполнение (см. элемент Use Case «Выполнить
17. Система выдает покупателю счет, содержащий описание заказа.
Рис. 25.5. Основной поток поведения при размещении заказа
Модель Use Case 291
Рис. 25.6. Сущностный прототип пользовательского интерфейса,
отражающий требования к экрану/странице
Хотя мы знаем, что будем реализовывать пользовательский интерфейс в бра-
узере, мы все равно предпочитаем работать со стикерами и карточками, а не
с HTML-редактором, поскольку простые средства являются более гибкими,
а именно гибкость нам сейчас и нужна. Поскольку мы занимаемся начальным изу-
чением требований, мы будем добавлять новые элементы пользовательского ин-
терфейса и менять их местами. Это нужно делать очень быстро, поэтому мы будем
использовать средства, которые допускают такую возможность. Впоследствии,
когда требования к странице (страницам) стабилизируются, мы перейдем
к HTML-редактору, потому что пользовательский интерфейс должен быть более
или менее стабильным для того, чтобы заинтересованные лица могли его оценить.
А сейчас нас устраивает пользовательский интерфейс именно в таком виде.
На данном этапе мы следуем нескольким методикам гибкого моделирования.
Мы явно применяем методику «Создавайте несколько моделей параллельно»,
292 Глава 25 • Гибкое определение требований
поскольку мы работаем над моделью Use Case и сущностным прототипом пользо-
вательского интерфейса; методику «Моделируйте в группе», так как наша груп-
па на данный момент состоит из двух разработчиков и по крайней мере одного
представителя заинтересованных лиц, который определяет требования. Также
мы следуем методике «Изображайте модели просто». Готов поспорить, что на
рис. 25.6 изображена простая модель требований для страницы размещения зака-
за. Также я утверждаю, что рис. 25.5 является хорошим примером применения ме-
тодики «Создавайте простое содержание», поскольку он достаточно подробно (но
не более того!) отражает бизнес-логику элемента Use Case. Не забыта и методика
«Применяйте нужный артефакт (артефакты)» — бизнес-правило рассматривается
отдельно от элемента Use Case и представляет собой самостоятельный артефакт,
хотя можно поспорить насчет того, является ли логика подсчета итоговой сум-
мы заказа простой бизнес-операцией (возможно, вы введете метки-заполнители
вместо операций «Подсчет налогов по заказу» и «Подсчет скидок по заказу», ко-
торые опишете отдельно, в виде текстовых документов или отдельных карточек).
Более того, требования к пользовательскому интерфейсу содержатся в отдельном
артефакте — сущностном прототипе пользовательского интерфейса. При необхо-
димости и «требования к данным» могут быть выделены в концептуальную мо-
дель (см. главу 24). Также мы следуем методике «Переходите от одного артефакта
к другому», занимаясь то элементом Use Case, то сущностным прототипом пользо-
вательского интерфейса — например, мы добавили новые возможности к прототи-
пу пользовательского интерфейса и поняли, что нужно изменить логику элемента
Use Case или наоборот. И, наконец, мы следуем методике «Используйте простей-
шие инструментальные средства» — прототип пользовательского интерфейса был
создан на бумаге, а логика элемента Use Case была записана на белой доске.
Проблема, с которой обычно сталкиваются все UP-разработчики, — эффек-
тивное создание элементов Use Case. Обычно они пытаются включить туда все,
что только возможно, вплоть до бизнес-правил, ограничений, требований к дан-
ным и даже требований к пользовательскому интерфейсу. Разработчики же гиб-
ких моделей следуют методикам «Применяйте нужный артефакт (артефакты)»,
«Создавайте несколько моделей параллельно» и «Переходите от одного артефакта
к другому». Они не пытаются набить элемент Use Case «под завязку», а вместо это-
го используют каждый тип артефактов наиболее подходящим образом. Например,
на рис. 25.5 вы видите, что шаг № 10 запускает бизнес-операцию «Подсчет налогов
по заказу». Вместо того чтобы включить бизнес-операцию в элемент Use Case (что
в принципе легко сделать), мы определили ее как самостоятельную сущность, на
которую ссылается элемент Use Case. При таком подходе сохраняются простота и
понятность артефактов, а также облегчается вызов бизнес-операции с помощью
ссылки из другого артефакта, например ссылки на исходный код, который реали-
зует эту функцию. Далее, если даже мы сейчас не знаем деталей вычисления на-
логов, недокументированная бизнес-операция заменяется меткой-заполнителем,
которая напомнит нам о том, что над ней еще нужно поработать. Мы можем про-
должить работу по моделированию оставшейся части элемента Use Case (см. гла-
ву 25) и, возможно, быстро реализовать его (помните о методике «Подтверждение
модели кодом»).
Последовательность кадров для элементов Use Case 293
СОВЕТ: ХОРОШО ПОДУМАЙТЕ, ПРЕЖДЕ ЧЕМ ПРЕОБРАЗОВАТЬ
ДИАГРАММУ USE CASE В ЭЛЕКТРОННУЮ ФОРМУ —---------------------------—
В UP-проекте диаграмма Use Case является основным артефактом, вокруг которого вращается
определение требований. Рисунок 25.4 не изменился со времени начальных сеансов бизнес-
моделирования (см. главу 24). Это та же самая диаграмма. Однако со временем диаграмму,
возможно, придется усовершенствовать. В последующих итерациях мы наверняка введем
новые элементы Use Case, разделим на части существующие элементы Use Case (если
окажется, что альтернативные потоки поведения стали более сложными, чем предполагалось)
или даже перенесем существующие элементы Use Case в следующие версии. Если вы решите
поддерживать какой-либо артефакт требований, то это лучший кандидат в долгожители. Я
советую вам просто не стирать диаграмму с доски. Я видел диаграммы, которые оставались,
на белой доске (и при этом совершенствовались вплоть до развертывания) в течение девяти
месяцев работы над проектом, так что можно вполне обойтись без аккуратных диаграмм,
созданных с помощью графических утилит или CASE-средств. Конечно, иногда без этого не
обойтись, но если можно, путешествуйте налегке и просто не стирайте диаграмму с доски. Вы
удивитесь, насколько уменьшится объем документации, если вы последуете нашему совету.
Допустим, что мы удовлетворены результатами моделирования (которое за-
. няло не больше часа). Теперь мы либо перейдем к анализу (см. главу 11), проек-
тированию (см. главу 13) и последующей реализации, или же сначала потратим
несколько минут на усовершенствование объектной модели, добавив туда то, что
мы только что рассмотрели. Предпочтительнее хранить объектные модели в са-
мом простом виде, используя карточки CRC (см. главу 24), поскольку с ними лег-
ко работать и они понятны заинтересованным лицам. Они могут быть использо-
ваны для демонстрации не только основных объектов в предметной области, но и
/ их обязанностей, включая как данные, так и поведение.
Последовательность кадров
для элементов Use Case
Последовательность кадров Для элемента Use Case показывает, как элемент Use
Case поддерживается пользовательским интерфейсом системы. Возможно, это
уже анализ или даже проектирование, так как с помощью последовательности
кадров для элементов Use Case вы изучаете возможности реализации требований,
описанных в Use Case. Разработчики гибких моделей не беспокоятся о таких раз-
личиях, они больше думают о применении нужного артефакта — в гибком моде-
лировании нет методики «Выполняйте различные типы моделирования в соот-
ветствующих рабочих потоках». Другое дело унифицированный процесс — здесь
надо классифицировать создание последовательности кадров для элементов Use
Case и связанную с этим работу по созданию прототипа пользовательского интер-
фейса как задачу по моделированию требований.
Диаграммы устойчивости (Розенберг и Скотт, 1999) являются весьма эффек-
тивным артефактом для создания последовательности кадров для элементов Use
Case, а также для анализа логики элементов Use Case в целом. Диаграммы устой-
чивости отражают основные объекты (граничные объекты/объекты интерфейса,
объекты-сущности или объекты управления/процесса), которые участвуют в вы-
полнении взаимодействия актера с системой согласно сценарию использования.
294 Глава 25 • Гибкое определение требований
Граничные объекты/объекты интерфейса представляют элементы пользователь-
ского интерфейса — экраны, отчеты, страницы HTML или электронные пись-
ма, с которыми взаимодействуют актеры, такие как, например, страница поиска
и страница покупательской корзины. Объекты-сущности — это объекты, которые
входят в модель предметной области, например «Заказ» или «Товар». Объекты
управления/процесса служат «связкой» между граничными объектами / объек-
тами интерфейса и объектами-сущностями, реализуя логику, необходимую для
управления различными объектами и их взаимоотношениями. На рис. 25.7 по-
казан набросок на белой доске. Мы снова следуем методике «Используйте про-
стейшие инструментальные средства», представляя логику элемента Use Case
«Размещение заказа» (см. рис. 25.5). Граничные объекты/объекты интерфейса
изображены в виде кружков с буквой «Т», объекты управления/процесса отмече-
ны вверху стрелкой, а объекты-сущности подчеркнуты.
Создав диаграмму устойчивости, мы быстро можем оценить задачи, которую
необходимо решить для реализации данного элемента Use Case. Как вы видите,
нам необходимо создать шесть основных элементов пользовательского интер;
фейса (скорее всего, это будут HTML-страницы, так как мы развертываем сис-
тему в Интернете). Также необходимо создать семь классов процессов и четыре
класса-сущности. Конечно, это высокоуровневая оценка задач, и когда мы дойдем
до детального проектирования и реализации, объем задач может вырасти, но для
начала и этого достаточно.
Удовлетворяет ли рис. 25.7 нашим нуждам, которые заключаются в изуче-
нии пользовательского интерфейса на предмет поддержки данного элемента Use
Case? Разработчики постоянно задают себе подобные вопросы, так как принцип
«Модель должна решать конкретную задачу» предлагает прекратить моделирова-
ние, как только цель достигнута. Хотя мы определили необходимые граничные
классы/классы интерфейса, нам неизвестно, что каждый из них должен выпол-
нять. Поэтому мы можем решить создать сущностные прототипы пользователь-
ского интерфейса, подобные тому, что показан на рис. 25.6, и, возможно, даже тра-
диционный прототип пользовательского интерфейса. Также мы пока не владеем
информацией о взаимосвязях между различными граничными классами/класса-
ми интерфейса — здесь нам может помочь диаграмма потоков пользовательского
интерфейса. Кроме этого, мы можем разработать UML-диаграмму последователь-
ности для изучения возможностей реализации данного элемента Use Case (нечто
подобное мы будем делать в главе 26).
Диаграмма потоков пользовательского интерфейса может быть использова-
на для изучения взаимосвязей между основными элементами пользовательско-
го интерфейса (в случае с SWA Online это будет HTML-страница). При UP/
АМ-йодходе к моделированию диаграмма потоков пользовательского интерфей-
са будет отражать либо отдельный элемент Use Case, либо всю систему целиком.
Мы решили создать диаграмму для системы в целом (рис. 25.8), поскольку поль-
зовательский интерфейс для данной версии системы SWA Online невелик. Если в
системе планируется большое количество страниц (15 — это неплохо, а вот 50 уже
многовато), то не следует создавать «всеобъемлющую» диаграмму. Рисунок 25.8
демонстрирует взаимодействие покупателя с SWA Online, так сказать, «с высоты
Последовательность кадров для элементов Use Case 295
птичьего полета», поэтому мы можем выяснить все проблемы, связанные с прак-
тичностью, до создания пользовательского интерфейса. Имеет ли смысл реали-
зовывать переход с одной страницы на другую? Нужно ли предоставлять поку-
пателю возможность прямого перехода со страницы подтверждения заказа на
страницу информации о товаре? Если мы посмотрим на пользовательский интер-
фейс «под нов,ым углом», у нас возникнут новые вопросы к заинтересованным ли-
цам; возможно, это приведет к определению новых требований, что позволит усо-
вершенствовать систему.
Рис. 25.7. Диаграмма устойчивости для элемента Use Case «Размещение заказа»
На рис. 25.8 изображены несколько элементов Use Case, образующих диаграм-
му, которую мы будем со временем совершенствовать. Наша группа с самого на-
чала отвела часть белой доски для дальнейшего усовершенствования диаграммы
(мы используем специальные обои, на которых можно рисовать, поэтому у нас
достаточно свободного рабочего пространства). При этом нам не нужно преоб-
разовывать диаграмму с помощью сложных средств (например, Microsoft Visio),
296 Глава 25 • Гибкое определение требований
вместо этого мы просто совершенствуем ее по мере необходимости. В дальнейшем
мы решим либо стереть диаграмму (следуя методике «Избавляйтесь от времен-
ных моделей»), либо снять ее на цифровую камеру (если она еще представляет
ценность, но нам нужно место на белой доске), либо преобразовать ее в электрон-
ную форму, если в этот момент возникнет такая необходимость.
__ Двяашяяв
О M/KKWUL
ъ МА
Рис. 25.8. Диаграмма, представляющая навигационные потоки пользовательского интерфейса
Спецификация
Спецификация — это документ, где содержится большинство требований к сис-
теме. Спецификация дополняет элемент Use Case и содержит определения дело-
вых операций, ограничения, технические требования и другие требования к сис-
теме, не входящие в элемент Use Case. Поскольку большая часть спецификации
представляет собой текстовый документ, вы будете использовать текстовый ре-
дактор. Однако если нет необходимости в создании и сопровождении специфи-
кации как официального документа, то вы можете использовать другой подход.
Разработчики гибких моделей следуют принципу «Путешествуйте налегке» и поэ-
тому предпочитают обходиться минимумом документации. Например, на рис. 25.9
Спецификация 297
приведены две бизнес-операции, которые были записаны на карточках, а не с по-
мощью текстового редактора. Мы следовали методике «Используйте простей-
шие инструментальные средства», как и подобает разработчикам гибких моделей.
Когда мы обсудили плюсы и минусы создания и сопровождения спецификации в
виде текстового документа (включая соответствующие издержки), то решили, что
использовать карточки будет эффективнее и дешевле. Решение о создании доку-
ментации принимают заинтересованные лица (см. главу 14); в нашем случае они
решили избежать дополнительных расходов, связанных с документацией.
Максимальная сумма заказа '
Максимальная сумма Заказа ограничена $10 ООО без учета налогов и стоимости
. доставки и обработки. Таким образом снижается риск мошенничества.
Подсчет налогов по заказу
1, Все товары, проданные по SWA Online, облагаются государственным налогом
(на данный момент составляет 6,5 %).
2. Налоги высчитываются по промежуточной сумме после вычета всех положенных
3. Доставка и обработка налогом не облагаются.
Рис. 25.9. Бизнес-операции в спецификации SWA Online
СОВЕТ: ПРОСТЕЙШИЕ ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА
ЭФФЕКТИВНО РАБОТАЮТ В РЕАЛЬНОМ МИРЕ -----------------------------------------
Общее заблуждение разработчиков, особенно тех, кто знаком с предопределенными процессами
(например, UP), состоит в том, что простых инструментов, таких как карточки и белая доска,
недостаточно для разработки приложений в реальном мире. Чушь! ХР-разработчики (Бек, 2000)
постоянно используют простые инструментальные средства. На самом деле в ХР вся модель
требований умещается в коробке в виде карточек, и при этом чрезвычайно эффективна. CASE-
средства, конечно, нужны (см. главу 10), но и простые средства тоже весьма эффективны.
Когда AM-разработчики работают над различными аспектами спецификации
(например, над отдельными бизнес-операциями), принцип «Повышайте отдачу от
ресурсов, полученных от заинтересованных лиц», требует записывать минималь-
но необходимое количество информации. Например, бизнес-операции, приведен-
ные на рис. 25.9, достаточно просты — они включают в себя только наименова-
ние бизнес-операции и ее краткое описание. Остальная информация (которую мы
могли бы записать, но не сделали этого) представляет собой имя автора (напри-
мер, Лиза Огурцова), дату и время записи бизнес-операции, запись о ее провер-
ке или уникальный идентификатор. В наши планы не входила работа с этой ин-
формацией, поэтому мы не стали ее записывать. Возможно, после мы еще об этом
пожалеем, но все равно не намерены тратить время на ее запись до тех пор, пока
это не требуется. AM-разработчики обладают смелостью и считают, что справятся
с любой проблемой тогда, когда она появится.
Ограничения, показанные на рис. 25.10, и бизнес-операции (рис. 25.9) являют-
ся хорошими примерами применения двух методик категории «Простота».
298 Глава 25 • Гибкое определение требований
Изображайте модели просто. Для написания требований мы могли бы ис-
пользовать более сложный язык, например объектный язык описания ограниче-
ний ОСЬ (Ворнер и Клепп, 1999). Вместо этого мы использовали обычный язык,
поскольку это было быстрее и более понятно заинтересованным лицам (которые,
кстати, многие требования написали самостоятельно).
Создавайте простое содержание. Каждое требование должно быть связанным.
Оно описывает только одну идею. Например, мы могли написать требование для
описания всех ограничений, связанных с техническими условиями, вместо того
чтобы написать требование только для базы данных. Такое требование описывало
бы базу данных, промежуточное ПО, сервер прикладных программ и т. д., то есть
все, что мы собирались использовать.
В первой версии SWA Online будет использовать уже сотрудничающую с ними
транспортную компанию «Fly-By-Night Shipping».
SWA Online будет использовать Oracle 11 i для хранения данных, поскольку SWA уже
имеет лицензионное соглашение с Oracle Corporation.
Рис. 25.10. Два ограничения для SWA Online
СОВЕТ: ТЕХНИЧЕСКИЕ ОГРАНИЧЕНИЯ — ЭТО НОРМАЛЬНО -----------------------------
Почему это заинтересованные лица определяют технические решения за нас? Разве это
«законно» в мире разработки ПО? Да. В AM-проекте высшее руководство и группа эксплуатации
являются заинтересованными в проекте лицами, а также выполняют множество других
функций в вашей организации. Очень часто эти две группы определяют ограничения, которым
вы должны следовать. Сюда входят и технические ограничения, например, касающиеся выбора
базы данных. Гибкие разработчики, конечно, проверяют эти ограничения с точки зрения
здравого смысла — если руководитель предлагает использовать Oracle, потому что у вас уже
имеется лицензионное соглашение с этой компанией, то это действительно веская причина;
если же он предлагает Oracle, потому что читал об этом в каком-то журнале, то следует просто
поблагодарить его за предложение.
Как это осуществить?
Рабочий поток «Требования» может поначалу привести в уныние кого угодно,
а обилие документации и моделей, предлагаемых унифицированным процессом
фирмы Rational (Rational Corporation, 2001), может привести к тому, что разра-
ботчики сосредоточатся исключительно на документации. В этой главе я поста-
рался доказать, что этого можно избежать. Для гибкого определения требований
нужно иметь в виду следующее:
1. Вы создаете программное обеспечение, а не документацию. Когда вы
применяете гибкое моделирование в унифицированном процессе, помните
Как это осуществить? 299
о том, что главная цель — ПО, а не документация. Ставьте под сомнение не-
обходимость создания каждого артефакта, которые рекомендует UP, и со-
здавайте только те, которые действительно необходимы.
2. Добивайтесь простоты. Создавайте минимально необходимую версию
каждого артефакта. Вы убедились, что определения бизнес-операций на
рис. 25.9 отражают основную идею и не содержат ничего лишнего.
3. Работайте итеративно. В UP/AM-проекте вы не следуете принципу «Сна-
чала все смоделируем» (BMUF) и не создаете всеобъемлющих специфика-
ций требований к ПО (SRS). Начните с идентификации высокоуровневой
модели, в которой достаточно информации для выбора верного направ-
ления разработки, но эта информация не перегружена деталями. Гибкие
разработчики выясняют детали по ходу дела, при необходимости возвра-
щаясь к моделированию требований, и планируют реализацию этих дета-
лей в последующих итерациях (или версиях). Например, когда вы начне-
те работать над механизмом размещения заказа, то обнаружите, что не до
конца понимаете, как все это должно работать; возможно, имеются ограни-
чения по количеству заказываемых товаров какого-либо типа. В таком слу-
чае вы имеете новую функциональность, которую нужно оценить, назна-
чить ей приоритет и запланировать ее реализацию на одну из последующих
итераций. Возможно, имеются ошибки в логике — может быть, покупатель
должен сначала предоставить информацию о способе оплаты и доставке.
Возможно, должен быть предусмотрен способ введения такой информации
«раз и навсегда», что является новым требованием, которое должно быть ре-
ализовано в последующей итерации.
4. Добивайтесь простоты. Используйте простые инструментальные средства.
Например, наша спецификация представляла собой набор карточек, а не
текстовый документ, и это было вполне эффективно. Достоинством унифи-
цированного процесса фирмы Rational является то, что он предусматрива-
ет шаблоны для основных артефактов; с другой стороны, это может спрово-
цировать вас на создание разнообразной документации, и вы уже не будете
«путешествовать налегке».
5. Работайте в группе. Создатели гибких моделей тесно сотрудничают с раз-
работчиками; они часто принимают активное участие в реализации и тести-
ровании. Тесное сотрудничество с другими людьми, участвующими в про-
екте, повышает эффективность общения и снижает необходимость создания
документации (которая, как уже говорилось в главе 8, является низкоэф-
фективным коммуникативным средством). Если тестировщики активно
участвуют в разработке требований, им не нужна объемная документация
по приемочным испытаниям, поскольку они знают эти требования. В тре-
тьей части книги вы узнали, что в ХР-проекте заинтересованные лица отве-
чают за создание тестов приемки (возможно, с помощью профессионалов-
тестировщиков), и им не нужна обширная документация для этого. И если
это возможно для экстремального программирования, это должно быть воз-
можно и для UP.
Гибкий анализ и
проектирование
Не может быть творчества по правилам.
Император Лето II
Из: Фрэнк Герберт. << Бог-император Дюны»
Цель рабочего потока «Анализ и проектирование» — разработать устойчивую ар-
хитектуру системы, создать подробный проект системы на основе требований
и адаптировать этот проект к среде реализации (Rational Corporation, 2001). Для
этого прежде всего нам понадобятся артефакты требований (см. главу 25), а так-
же бизнес-модели (см. главу 24). В данной главе мы рассмотрим применение гиб-
кого подхода к рабочему потоку унифицированного процесса «Анализ и проек-
тирование» (Джекобсон, Буч и Рамбо, 1999), используя для этого принципы и
методики гибкого моделирования.
Как выполняется моделирование, связанное с анализом и проектированием
в UP/AM-проекте? Во время этапа «Начало» работа будет направлена на анализ
бизнес-моделей и моделей требований, хотя иногда придется заняться и проекти-
рованием. На этапе «Развитие» вы в основном будете работать над архитектурой,
не забывая при этом об анализе и проектировании, которому вы будете уделять
все больше времени по мере подтверждения правильности архитектуры. На этапе
«Конструирование» вы сосредоточитесь на анализе и проектировании. До завер-
шения этапа «Развитие» архитектура должна быть приведена к базовому уровню,
хотя изменения могут произойти и позже — гибкие разработчики следуют прин-
ципу «Ожидайте изменений» и допускают возможность изменения подхода к ар-
хитектуре, если в результате переосмысления требований последний окажется
недостаточно эффективным. На этапе «Переход» моделированием придется за-
няться в связи с устранением недостатков, выявленных в результате тестирова-
ния системы (в том числе тестирования системы заказчиком).
Важно понимать, что подход к планированию UP-проекта обусловлен эле-
ментами Use Case (а точнее — требованиями), при этом требования (часто ос-
нованные па элементах Use Case) распределяются по итерациям. Основная
идея состоит в том, что система (а вместе с ней и артефакты, которые вы ре-
шили поддерживать) будет развиваться от итерации к итерации. Вы буде-
Пересмотр модели анализа и модели проектирования в UP 301
те анализировать требования, предписанные для каждой итерации, возможно,
создавая реализации для каждого элемента Use Case и связанных с ним допол-
нительных требований. Если вы применяете объектно-ориентированный под-
ход (00) к разработке (что предполагает данная глава), то вы будете созда-
вать присущие данному подходу модели, например UML-диаграммы классов
и UML-диаграммы состояний. Если вы предпочитаете структурный/процедур-
ный подход к разработке, то вам придется создавать структурные схемы. Если
ваша система работает с данными (а таких большинство), то вам придется со
временем изменять модель данных1.
Для изучения рабочего потока «Анализ и проектирование» в UP/AM-проекте
мы должны рассмотреть следующие проблемы, касающиеся разработки системы
для SWA Online:
• Пересмотр модели анализа и модели проектирования в UP.
• Моделирование архитектуры.
• Создание реализаций элементов Use Case.
• Не пора ли совершенствовать элементы Use Case?
• Не пора ли использовать CASE-средства?
• Моделирование классов проектирования.
• Моделирование данных.
• Ожидайте изменений.
• Как это осуществить?
Пересмотр модели анализа
и модели проектирования в UP
Вы уже узнали из главы 23, что в унифицированном процессе модель анализа опи-
сывает анализ модели требований и служит концепцией вашей системы. Чаще все-
го это временная модель, и от нее либо избавляются в процессе работы, либо она
становится моделью проектирования. Вы также узнали, что в UP модель проек-
тирования на самом деле является набором моделей, описывающим реализацию
элементов Use Case и служащим в качестве абстракции исходного кода. По опыту
знаю, что UP-группы могут утратить гибкость из-за этих двух моделей, а именно
тогда, когда они начнут приводить версии моделей к базовому уровню и попыта-
ются поддерживать некое подобие трассируемости между ними.
1 Многие приложения должны работать с наследуемыми данными и поэтому лишены возмож-
ности изменять схему данных или могут делать это лишь в незначительной мере. В таком случае сле-
дуйте методике «Формализуйте модели соглашения» и получите доступ к модели физических данных
наследуемой БД, если таковая имеется. В противном случае вам придется ее разработать.
302 Глава 26 • Гибкий анализ и проектирование
Рис. 26.1. Трассируемость между основными артефактами унифицированного процесса
На рис. 26.1 рассмотрена идея трассируемости между основными наборами
артефактов UP: спецификацией системных требований (SRS), моделью анализа,
моделью проектирования и моделью реализации. На нем не рассматриваются дру-
гие наборы артефактов (например, бизнес-модель и тест-модель) и под-артефакты,
которые существуют внутри каждой модели (например, элементы Use Case и клас-
сы), потому что диаграмма и без того сложна. Следуя итеративному и инкремент-
ному подходу к разработке (обычно UP/AM-группы отдают предпочтение имен-
но ему), интересно проследить трассируемость между артефактами. Основная
идея диаграммы: показать, что для итерации п разработана модель проектирова-
ния, основанная на анализе итерации п и существующей модели проектирования
из итерации п-1, поэтому чтобы поддерживать трассируемость, вам необходима
трассировка для обеих моделей. Для этого вам нужно получить соответствующие
артефакты базового уровня (возможно, вы уже занимались этим в рабочем пото-
ке «Управление изменениями и конфигурацией») и поддерживать матрицу трас-
сируемости между артефактами предыдущей версии модели. В данном случае это
модель проектирования п-1 и текущая версия любых исходных артефактов, то
есть модель п. Само собой, вам будет нужно поддерживать матрицу трассируемо-
сти между артефактами каждой из основных моделей, а также учесть приведение
матрицы к базовому уровню в конце каждой итерации, для того чтобы поддержи-
вать Трассируемость на протяжении всего проекта.
Моделирование архитектуры 303
Да, группы, которые выбирают данный подход, явно «путешествуют не налег-
ке». Даже если нужно всего лишь поддерживать матрицу трассируемости в том
виде, в каком она существует в данной итерации, развивая ее вместе с другими ар-
тефактами и не беспокоясь по поводу трассируемости между версиями, то на это
уйдет масса времени и сил, причем вы не будете заниматься непосредственно раз-
работкой ПО.
Как поступят гибкие разработчики? Во-первых, они понимают, что концеп-
ции модели анализа и модели проектирования очень полезны, но не станут терять
на них время. Во-вторых, они понимают, что у них нет модели анализа и модели
проектирования как таковых. У них есть лишь артефакты моделирования, кото-
рые они будут или не будут поддерживать с течением времени. «Модель анализа»
и «модель проектирования» являются всего лишь категориями, посредством ко-
торых организованы данные артефакты. Другими словами, они следуют методике
«Применяйте нужный артефакт (артефакты)» и не слишком заботятся о категори-
зации своей работы. В-третьих, они не придают большого значения трассируемо-
сти. Они понимают, что матрица трассируемости является всего лишь документом
(не имеет значения, при помощи какого средства она создана и поддерживается),
а решение о том, ^следует ли его создавать и поддерживать, принимают заинте-
ресованные лица. Поэтому они обсуждают эту идею с заинтересованными лица-
ми, указывая на преимущества (легкость управления изменениями) и недостат-
ки (увеличение количества создаваемой документации), и предлагают им решить,
хотят ли они платить за эту работу, что согласуется с принципом «Повышайте от-
дачу от ресурсов, полученных от заинтересованных лиц».
Моделирование архитектуры
Обычно UP-группы занимаются первоначальным моделированием архитектуры
во время этапа «Начало», а во время этапа «Развитие» рабочий поток «Анализ .
и проектирование» направлен на создание архитектуры. Во время данного этапа
создается прототип архитектуры как часть рабочего потока «Реализация», чтобы
подтвердить устойчивость архитектуры, следуя методике «Подтверждение моде-
ли кодом». Основной артефакт архитектуры в унифицированном процессе назы-
вается документом архитектуры системы (SAD). Этот документ обобщает архи-
тектуру системы. Следуя UP/AM-подходу, гибкие разработчики создадут SAD,
если он будет необходим в проекте и если заинтересованные лица будут готовы
платить за его создание и сопровождение, как и в случае с любым другим докумен-
том. Если ваша группа создает SAD, он обычно содержит:
• обобщение важных архитектурных требований (если подобный документ
уже существует, вы просто ссылаетесь на эти требования, чтобы сохранить .
гибкость);
• . диаграммы обзора системы, представляющие собой видение важных мо-
ментов системы (см. ниже);
• документацию, описывающую эти диаграммы.
304 Глава 26 • Гибкий анализ и проектирование
Гибкие разработчики обычно создают одну или несколько диаграмм обзора (они
также называются навигационными диаграммами), которые представляют собой
обзор «ландшафта» вашей системы. Подобно дорожной карте, на которой изобра-
жен город, диаграммы обзора системы отображают организацию вашей системы.
Диаграммы обзора являются воплощением вашего представления архитектуры сис-
темы. Кратчен (1995) описывает представление архитектуры «4+1», которое было
положено в основу унифицированного процесса фирмы Rational, азатем усовер-
шенствовано. Вот эти пять представлений, в которых рассматривается архитектура:
1. Логическое представление. Данное представление моделирует функцио-
нальные возможности, которые система предоставляет пользователю.
2. Представление процессов. Это представление 'моделирует выполнение
системой требований, не относящихся к функциональным возможностям
(например, производительность, работоспособность, параллельность и рас-
пределенность, целостность системы и отказоустойчивость). Оно также
определяет, какой из потоков управления выполняет операции классов,
определенных логическим представлением.
3. Представление разработки1. Данное представление моделирует организа-
цию фактических программных модулей (компоненты, подсистемы), кото-
рые, как правило, организованы в виде уровней. Их может создать один или
несколько разработчиков.
4. Физическое представление. Данное' представление моделирует размеще-
ние системы и часто включает в себя представления для сред разработки,
тестирования и размещения.
5. Представление сценариев (элементов Use Case). Данное представление
моделирует подмножество важных для архитектуры элементов Use Case
или сценариев использования, которые показывают, как элементы первых
четырех представлений соотносятся между собой.
Гибкие разработчики понимают важность идеи различных архитектурных
представлений, так как в этом заключается принцип «Множество моделей». Но
они также понимают, что нет универсальной совокупности представлений, под-
ходящей для всех проектов. Вместо этого они следуют методике «Применяйте
нужный артефакт (артефакты)» и определяют типы создаваемых моделей в соответ-
ствии с природой проекта. Вид диаграмм обзора также зависит от типа создавае-
мой системы. Например, группа создает сложное бизнес-приложение с исполь-
зованием технологии J2EE. В процессе работы разработчики поймут, что для
создания диаграмм архитектурного обзора.подойдут UML-диаграмма компонен-
тов и UML-диаграмма размещения, в то время как группа, которая создает хра-
нилище корпоративных данных, будет использовать для создания архитектуры
модель данных и UML-диаграмму размещения. Разные проекты и разные виды
архитектуры — различные типы диаграмм обзора. Вы должны быть гибкими в
своем подходе, потому что не существует ничего универсального.
1 На самом деле Кратчен называет это представлением реализации. — Примеч. науч. ред.
Моделирование архитектуры 305
Как следует моделировать архитектуру для SWA Online? Начнем работу с про-
ведения начального сеанса моделирования, на котором присутствует вся группа.
Таким образом вы получаете возможность выслушать множество мнений и достичь
согласия по поводу выбора подхода к архитектуре. Вы не просто хотите получить
работающую архитектуру, вы хотите, чтобы каждый участник проекта был убеж-
ден в ее правильности. Вместо того чтобы доверить создание архитектуры одно-
му человеку (даже если он уже создавал подобную систему), следуйте методике
«Моделируйте в группе». Помните о том, что моделированием, как и плаванием,
опасно заниматься в одиночку. Этот сеанс должен быть коротким, хотя при необхо-
димости будьте готовы собраться еще раз и провести более длинный сеанс модели-
рования. Принцип «Быстрая обратная связь» советует нам моделировать понемногу
и постоянно оценивать модели, создавая архитектурные прототипы, следуя Методи-
ке «Подтверждайте модель кодом». Выбрав менее гибкий подход, вы будете моде-
лировать в течение нескольких дней или даже недель, пытаясь тщательно опреде-
лить подробную архитектуру и убедиться в ее правильности. Однако чем дольше вы
не получаете обратной связи, тем болыпё шансов, что ваша архитектура содержит
ошибки. Лучше всего продумать важные проблемы сразу же, а затем приступить к
созданию прототипа «скелета» (Джекобсон, Буч и Рамбо, 1999) приложения и убе-
диться в том, что наш подход верен, или определить те места, которые следует пере-
делать. Вывод один — на белой доске все выглядит убедительно, но до тех пор, пока
вы не проверите все на практике, вы-не узнаете, что работает, а что нет.
Рис. 26.2. UML-диаграмма размещения для SWA Online
306 Глава 26 • Гибкий анализ и проектирование
Во время сеанса моделирования вы работаете с двумя диаграммами — UML-диа-
граммой размещения (рис. 26.2) и UML-диаграммой компонентов (рис. 26.3), ко-
торые мы нарисовали на белой доске, следуя методике «Создавайте несколько
моделей параллельно». Модель размещения помогла нам изучить предложенную
конфигурацию системы, а модель компонентов — возможные бизнес-компоненты
и их взаимосвязь. Понятно, что две эти диаграммы связаны между собой. Диа-
грамма размещения показывает, как размещаются некоторые компоненты ПО,
что мотивирует нас работать с обеими диаграммами одновременно.
7
(l XMI ф &
Мсхлхк^к
омшкы
7 Auiksriz
7 Ckar-p*-
\f
7 XML
Смык
П \ 7 ,
\\ 7 XML
w
Заыр
Ойщря мымао. I
I
ХХшЗХШш
яяШшш
, Рис. 26.3. UML-диаграмма компонентов для SWA Online
Достаточно ли этих двух диаграмм? В начале проекта достаточно, причем нам
следует прекратить работу над ними, так как они выполнили свою задачу (сле-
дуем методике «Модель должна решать конкретную задачу»). Теперь мы можем
продолжать работу в среде разработки, на основе информации, содержащейся на
рис. 26.2. В ходе работы мы выясни^, является ли выбранный нами подход эффек-
тивным. Вероятнее всего, мы обнаружим, что что-то упустили или что-то работает
не так, как мы ожидали, но это нормальное явление. На рис. 26.3 представлен ва-
риант организации исходного кода, хотя во время сеанба моделирования один из
разработчиков указал нам на то, что ему не совсем понятно, как мы будем создавать
крупномасштабные бизнес-компоненты, используя технологию EJB (именно ее
мы выбрали в качестве платформы). Начинается обсуждение, и один из разработ-
чиков подходит к белой доске и излагает подход, который уже применялся и оп-
равдал себя (см. диаграмму на рис. 26.4). Он объясняет, что интерфейс компонен-
Моделирование архитектуры 307
та определяется одной или несколькими bean-сущностями EJB, поэтому (как он
уже убедился на опыте) не нужно обеспечивать прямой доступ к bean-сущностям
EJB. Bean-сессия будет взаимодействовать или с bean-сущностями EJB, или с дру-
гой bean-сессией, нормальными Java-объектами, или внутренним интерфейсом
базы (баз) данных. На диаграмме стрелками показан тип объекта, который-мо-
жет запускать операции в других объектах. Например, следуя данному подходу,
bean-сущности EJB не могут запускать операции в bean-сессиях, но могут взаимо-
действовать с другими bean-сущностями. Группа обсуждает преимущества и недо-
статки данного подхода и соглашается на его применение. Являясь гибкими разра-
ботчиками, они следуют методике «Применяйте стандарты моделирования», хотя
оставляют за собой право изменять их, если в ходе работы по созданию архитек-
турных прототипов выясняется, что они не подходят для применения в проекте.
Рис. 26.4. Набросок, описывающий стратегию реализации бизнес-компонента
СОВЕТ: ПРИНЦИП «ПУТЕШЕСТВУЙТЕ НАЛЕГКЕ»
РАСПРОСТРАНЯЕТСЯ И НА АРХИТЕКТУРУ ----------------------------------
Когда вы лично общаетесь с заказчиком, вы понимаете, что ваши диаграммы обзора (даже
если они нарисованы от руки) вполне годятся для описания архитектуры. К сожалению, многие
UP-разработчики тратят время на создание подробного документа SAD, когда вполне можно
обойтись без этого.
Мы пригласили двоих представителей заинтересованных лиц на сеанс модели-
рования архитектуры. Нам нечего от них скрывать, потому что мы следуем прин-
ципу «Открытые и доброжелательные контакты». Это было правильным решением,
потому что у нас возникло несколько вопросов, касающихся требований, которые
легко разрешились, когда мы обсудили варианты архитектуры. Применение мето-
дики «Активное участие заинтересованных лиц» себя вполне оправдало, потому
что мы сразу же получили ответы на наши вопросы. Конечно, когда заинтересо-
ванные лица обнаруживают, что разработчики чего-то не знают, может сложиться
неловкая ситуация. Например, но время первого сеанса моделирования архитек-
туры выяснилось, что нескольких разработчиков нужно было обучить работать
с EJB и базами данных Oracle (именно эти две технологии было решено приме-
308 Глава 26 • Гибкий анализ и проектирование
пять в проекте). Остальные разработчики это сразу поняли, а заинтересованные
лица могли и не заметить, хотя позже это все равно выяснится, так как именно они
будут оплачивать счет за обучение. Мы тоже люди и не можем знать всего на свете.
В основу нашей работы во время создания двух этих диаграмм обзора был по-
ложен принцип «Добивайтесь простоты». Применение методики «Создавайте
простое содержание» указывает на то, что мы хотели определить наиболее прос-
той подход к архитектуре. Чем сложнее архитектура, тем больше вероятность того,
что ее не поймут многие разработчики; также возрастает вероятность возникнове-
ния ошибок и сбоев. Мы руководствовались принципом «Доверяйте человеческим
инстинктам» во время определения простейшего подхода. Реализация быстро по-
кажет, что было просто, а что — нет, а пока мы можем лишь предполагать. Более
того, мы стремились к тому, чтобы наши диаграммы содержали информацию нуж-
ного уровня, показывая, как различные аспекты нашей системы работают вместе,
но не вдавались в подробности (подробности будут рассмотрены во время сеансов
проектирования). Таким образом, мы следовали методике «Изображайте модели
просто». Для выполнения работы.мы также применяли методику «Используйте
простейшие инструментальные средства». Все, что нам требовалось для модели-
рования важных аспектов архитектуры, — это наброски на белой доске.
Вы должны понимать, что модели архитектуры будут показывать отноше-
ния вашей системы с другими системами или отношения внутри вашей системы.
Например, ваша система может взаимодействовать через Интернет с системой об-
работки кредитных карточек, иметь доступ к данным соответствующей наследу-
емой базы данных или создавать структуру данных XML для другого внутрен-
него приложения. Сетевые диаграммы и UML-диаграммы размещения оч^нь
пригодятся для определения этих отношений. Также полезными могут оказать-
ся процессо-ориентированные модели (например, диаграмма рабочих потоков,
UML-диаграмма деятельности и диаграмма потоков данных). Дело в том, что вне-
шние связи указывают на необходимость последовать методике «Формализуйте
модели соглашения», чтобы согласовать их между вашей группой и владельцами
той системы, с которой взаимодействует ваша. В идеале многие из этих моделей
уже имеются в наличии. Система обработки кредитных карточек имеет строго опре-
деленный протокол, которому вы должны следовать, а наследуемая база данных
уже имеет определенную физическую модель данных, хотя новые функции (на-
пример, структуру данных XML) необходимо будет определить дополнительно.
Может быть, вам придется произвести анализ интерфейса унаследованной систе-
мы (в том случае, если по ней нет документации), а может случиться так, что при-
дется спроектировать новый интерфейс. В обоих случаях необходимо создать со-
ответствующую модель соглашения. Это может сделать как ваша, так и другая
группа, или вы сделаете это совместно.
Создание реализаций элементов Use Case
Реализация элементов Use Case — это искусственный артефакт, представляющий
собой одну или несколько моделей, описывающих реализацию одного элемента
Создание реализаций элементов Use Case 309
Use Case. Вы создаете реализацию элемента Use Case, анализируя его и «привя-
зывая» содержащуюся в нем информацию к вашему анализу и/или проектиро-
ванию. Хотя унифицированный процесс фирмы Rational (Rational Corporation,
2001) связывает реализацию элементов Use Case с системными элементами Use
Case, но если задуматься о системных элементах Use Case, то их можно считать
реализацией бизнес/сущностных элементов Use Case. Теперь нашей целью будет
реализация системных элементов Use Case.
1, Элемент Use Case начинается, когда заказчик решает разместить заказ.
2. Покупатель ищет товары при помощи элемента Use Case «Поиск Товара».
3. Покупатель добавляет заказанный товар в заказ.
4. Покупатель указывает в заказе номер выбранного товара.
5. Система подсчитывает промежуточную сумму, умножая цену товара
на заказанное количество.
6. Покупатель для составления заказа повторяет шаги со 2-го по 5-й
при необходимости.
7. Покупатель заканчивает добавлять товары в заказ.
8. Покупатель предоставляет информацию о доставке и оплате, включая имя,
телефон и почтовый адрес.
9. Система подсчитывает промежуточную сумму всего заказа, складывая
промежуточные суммы за отдельные товары.
10. Система подсчитывает налоги, применимые к заказу согласно бизнес-правилу
«Подсчитать налови с заказа».
11. Система подсчитывает скидки, применимые к заказу согласно бизнес-правилу
«Подсчитать скидки с заказа». '> / ’ ’
12. Система показывает применимые налоги и скидки.
13- Система подсчитывает итог заказа, добавляя применимые налоги и вычитая
14, Система показывает полученный заказ. ' • .
15. Покупатель проверяет правильность заказа.
16. Система отправляет заказ на выполнение (см. элемент Use Case «Выполнение
17. Система выдает покупателю квитанцию с описанием заказа.
Рис. 26.5. Основной поток поведения элемента Use Case для размещения заказа
Унифицированный процесс фирмы Rational предлагает изучить логические
потоки внутри элементов Use Case, которые часто называют сценариями исполь-
зования. Сделать э(то можно посредством диаграмм взаимодействия (например,
UML-диаграмм последовательности или UML-диаграмм сотрудничества).
Диаграммы последовательности наиболее часто используются для этих целей, так
как они лучше подходят для изучения последовательной бизнес-логики (что по-
нятно из названия), описанной в сценариях использования. По мере разработки
каждой из диаграмм взаимодействия вы определяете сотрудничество объектов,
которое преобразуется в операции, реализуемые классами, и идентифицируете
отношения этих классов. Сотрудничество одного объекта с другим предполагает
и»
310 Глава 26 • Гибкий анализ и проектирование
прямое или косвенное отношение между соответствующими классами. UML раз-
личает несколько видов отношений между классами, включая ассоциацию, агрега-
цию, композицию, наследование и зависимость. Дело в том, что когда вы создаете
диаграммы взаимодействия, вы определяете важные аспекты статичной структу-
ры ПО. Эта информация обычно содержится в UML-диаграмме классов в RUP.
Если вы моделируете диаграммы взаимодействия от руки, вы можете одновремен-
но работать с диаграммой классов. Если вы применяете для этих целей сложное
CASE-средство, оно выполнит эту работу автоматически. В любом случае вы успеш-
но применяете методику АМ «Создавайте несколько моделей параллельно».
Рис. 26.6. Диаграмма устойчивости для элемента Use Case «Размещение заказа»
Подход, применяемый в унифицированном процессе фирмы Rational для ре-
ализации элементов Use Case, не единственный. Гибкие разработчики создают
UML-диаграмму последовательности для сложной логики элемента Use Case или
перерабатывают логику. Чаще всего они предпочитают UML-диаграмме классов
карточки CRC, потому что следуют методике «Используйте простейшие инстру-
ментальные средства» и выбирают для работы карточки, а не белую доску или
Создание реализаций элементов Use Case 311
CASE-средство. Гибкие разработчики не любят начинать работу с UML-диаграм-
мы последовательности. Они предпочитают сначала создавать диаграмму устой-
чивости для определения возможных классов, а затем диаграмму последователь-
ности (Розенберг и Скотт, 1999). Важно понимать, что у вас всегда есть выбор, что
вы должны следовать принципу «Приспосабливайте по месту» и выбирать подход
в соответствии с навыками, опытом и предпочтениями вашей группы.
СОВЕТ: НЕ СУЩЕСТВУЕТ ОФИЦИАЛЬНОГО СПОСОБА --------------------------------
Для изучения логики элемента Use Case одни разработчики решают создавать диаграммы
устойчивости, другие же сразу переходят к созданию диаграмм последовательности. Для
изучения статичной структуры ПО кто-то применяет карточки CRC, а кто-то — UML-диаграммы
классов. Вы можете чередовать эти модели.
—“— ------------
;/tur :0mIi
ffMfWMM
ж
йЛ
epapttutat
ftреугмныня ijayw*
Рис. 26.7. UML-диаграмма последовательности для элемента Use Case «Размещение заказа»
На рис. 26.6 (вы уже видели его в главе 25) показан набросок диаграммы устой-
чивости, выполненный на белой доске. Она отражает логику элемента Use Case
для размещения заказа, представленную на рис. 26.5. Набросок изображает высо-
коуровневые классы, которые нам понадобится создать для реализации функци-
ональных возможностей, описанных с помощью элемента Use Case. Наличие дан-
ных классов облегчает создание UML-диаграммы последовательности для этого
элемента Use Case (рис. 26.7). Параллельно мы разработали диаграмму классов
на уровне анализа, которая также представляет собой набросок на белой доске
(рис. 26.8). Мы использовали диаграмму классов вместо карточек CRC, выбрав
312 Глава 26 • Гибкий анализ и проектирование
нечто среднее между двумя подходами, описанными выше. (Обычно я в таких слу-
чаях использую карточки CRC, но в следующем разделе я хочу поговорить о про-
блемах, связанных с преобразованием наброска на белой доске в модель при помо-
щи CASE-средств, поэтому я решил использовать UML-диаграмму классов).
TToxhoAim appta
Ухшщ
Захар
- 7 Рарнелщьи
Схе-к хрмхам
\0J
ТТро<жмбае-к\
(xo appuyJT^
7..
О..
ТТок,^хам^хь
/Гия
Ронер нелероха
1 t.
/Тоерманаиь
хрон^Ж'риочхрю оернирО
Вычшмшхе, хмага()
Вычшмшхь axpaxAfJ
ТТорсншхань оаомм орнир
ОихроТчмь ха выхехх^ха^О
Вырань xexf)_____________
Залараххыа. иобар
ЗмА-рМКОС' хахичмибо
(Л4 hojx
Сирма
ТТ'ч ио Tim арры
То/ор
(£ыа
ра ермшцр побора
ОхмыТаык
ТТорммеань
хроныюрмчх^ю
0..
Рис. 26.8. UML-диаграмма классов уровня анализа, основанная
на элементе Use Case «Размещение заказа»
Посмотрите внимательно на диаграмму устойчивости и элемент Use Case. Они
не согласованы. Когда мы нарисовали диаграмму устойчивости, мы поняли, что
забыли включить в нее шаги, касающиеся оплаты заказа. Мы сразу позвонили
Венди (она является представителем наших заказчиков и помогает нам выяснять
требования), и она подтвердила, что да, вообще-то мы намерены получать деньги
за проданные товары. Несмотря на то что данное требование очевидно и нет необ-
ходимости советоваться с заказчиками, одна из основных идей AM состоит в том,
что заинтересованные лица являются единственным источником верных требова-
ний. Поэтому мы всегда советуемся с Венди по поводу новых требований, каки-
ми бы очевидными они ни были. Хотя мы и работали в рабочем потоке «Анализ
и проектирование», мы смогли быстро вернуться к рабочему потоку «Требования».
Такое происходит часто. UP/AM-группы постоянно переходят от одного рабоче-
го потока к другому.
Не пора ли совершенствовать
элементы Use Case?
Следует ли изменять логику элементов Use Case? Нам явно не достает важного
требования — к сбору оплаты заказа. Более того, рис. 26.5 все еще является биз-
нес/сущностным элементом Use Case, потому что не отражает решений по тех-
нологии/реализации. Будет вполне разумно переработать элементы Use Case так,
Не пора ли совершенствовать элементы Use Case? 313
Имя явкулателя: Огурцова Елизавета
Немер пвкупателя: 1234567
И захиг. 8675309
Дата: 14 февраля, 2002 .
Текущий заказ:
- ^товара Олясаххе Цеха Колхчеспа Промежуточя. сумма Удалит*
. 12245 .Бидон 19,997 j “ ' , 139,93 : П
’23456 Змеевик 9,99 j " "" " : 29,97 Г’
: 12697 Половик 2999,99 | : 2999,99 Г
Промежуточная сумма 3169,89
Налети 206,04
' Доставка 17,50
' Скидка' "150,00
Сумма 3243,43 \
Доставить:
ГГ Т е же поля,чтои втаблице "Доставить"
Имя:
Адрес:
Город:
Область:
Страха:
Примечания
Рис. 26.9. HTML-прототип пользовательского интерфейса для размещения заказа
314 Глава 26 • Гибкий анализ и проектирование
чтобы они описывали то, над чем мы работаем. .Сначала мы переработаем перво-
начальную версию элементов, Use Case посредством выбранной конфигурации
управления (данная процедура описана в рабочем потоке «Управление конфигу-
рацией и изменениями»). Мы решили поддерживать элементы Use Case в виде
официальной документации, так как заинтересованные лица хотят получить чет-
кое описание требований, которое ляжет в основу создания и поддержки диаграм-
мы Use Case и самих элементов Use Case. Наш элемент Use Case не согласован с
прототипом пользовательского интерфейса для размещения заказа, изображенно-
го на рис. 26.9. Поэтому нам необходимо разобраться с вычислением оплаты до-
ставки и обработки заказа. Рассматриваемый прототип был создан другими раз-
работчиками нашей группы на основе сущностного прототипа пользовательского
интерфейса, разработанного нами ранее, и дополнительной информации, полу-
ченной от Венди. Мы видим, что в данном случае уместно применить методику
«Совершенствуйте только в случае необходимости».
На рис. 26.10 изображен измененный элемент Use Case. Обратите внимание на
то, как он ссылается на аспекты пользовательского интерфейса, указывая страни-
цы HTML, которые использует покупатель для размещения заказа. В результате
таких ссылок элемент Use Case больше не является не зависимым от технологии.
Если бы мы решили реализовать данную систему, используя технологию графи-
ческого пользовательского интерфейса (например, Visual Basic или Java Swing),
то элемент Use Case был бы, скорее всего, записан иным образом (для отражения
стиля работы данного интерфейса). Заметьте, что мы не вносим в данный элемент
Use Case решения на уровне проектирования. Например, мы не указываем того,
что класс «Механизм проверки заказа» проверяет заказ, хотя это изображено на
рис. 26.6. Также обратите внимание на то, что добавлены ссылки на альтернатив-
ный поток, что обычно происходит при преобразовании бизнес/сущностного эле-
мента Use Case в системный элемент Use Case. Мы также уточнили язык элемен-
та Use Case. Например, в первоначальной версии были использованы термины
«Товар заказа» й «Часть заказа», а в новой используется только «Товар заказа».
Это было несущественно, но Венди сказала, что «Товар заказа» — более подходя-
щий термин, поэтому мы внесли изменения.
Когда мы переписали элемент Use Case, мы обнаружили проблему, касающу-
юся прототипа пользовательского интерфейса. Покупателю не была предостав-
лена возможность указать, что заказ завершен и он желает подсчитать его стои-
мость. Мы поняли, что необходимо создать еще одну кнопку «Проверка», которая
запускает процесс подтверждения заказа (рис. 26.6). Здесь нам очень пригодилась
методика «Создавайте несколько моделей параллельно», которая помогла быстро
найти ошибку и исправить ее в тот момент, когда это еще легко было сделать.
Также нет никаких указаний на адрес электронной почты покупателя, по которо-
му следует отправлять подтверждение заказа. Для решения данной проблемы воз-
можны два варианта. Для идентификации покупателя вместо идентификационного
номера, (см. рис. 26.9) можно использовать адрес электронной почты. Покупателя
легко идентифицировать при помощи адреса e-mail, к тому же покупатель наверня-
ка помнит данную информацию. Мы предлагаем это Венди, и она говорит, что ей
нравится эта идея, но она должна подумать, прежде чем принять решение.
Не пора ли совершенствовать элементы Use Case? 315
1, Элемент Use Case начинается, когда покупатель решает разместите заказ,
2. Система показывает страницу «Корзина покупателя» для размещения заказа,
3. Покупатель ищет товары с помощью элемента Use Case «Поиск товара».
4. Покупатель добавляет товары в заказ, [Альтернативный поток: Покупатель
удаляет товар из заказа.]
5. Покупатель указывает номер товара, который хочет'заказать.
6. Покупатель решает обновить страницу.
7, Система подсчитывает промежуточную сумму товара, умножая цену товара на
коя ичество за казанного товара.
б; Система снова показывает «Корзину покупателя»,
9. Покупатель повторяет шаги с 3-го по 8-й для составления заказа.
10. Покупатель прекращает добавлять товары в заказ.
11, Покупатель предоставляет информацию о доставке и оплате, включая имя,
телефон и почтовый адрес.
12. Покупатель решает посчитать сумму заказа. [Альтернативный поток: Покупатель
продолжает заказывать,]
' 13’., Система подсчитывает промежуточную сумму всего заказа, складывая
промежуточные суммы заказа.
14, Система подсчитывает налоги, применимые к заказу согласно бизнес-правилу
«Подсчитать налоги с заказа»,
1S. Система подсчитывает скидки, применимые к заказу Согласно бизнес-правилу
' «Подсчитать скидки с заказа»,
16. Система подсчитывает оплату доставки и обработки заказа согласно бизнес-правилу
« Подсч итать оплату доставки и обработки ».
17, Система подсчитывает общую сумму заказа, добавляя к промежуточной сумме
применимые налоги и вычитая скидки,
18. Система подсчитывает страницу «Итог».
19, Покупатель проверяет правильность заказа,
20. Покупатель указывает способ оплаты. [Альтернативный поток: Покупатель
продолжает заказывать.]
21. Система подтверждает оплату [Альтернативный поток Оплата не
подтверждена,]
22. Система отправляет заказ на выполнение (см. элемент Use Case «Выполнение
23, Система доказывает страницу «Подтверждение заказа»,
24. Система создает и отправляет подтверждение заказа по электронной почте
Рис. 26.10. Основной поток поведения элемента Use Case
для размещения заказа (усовершенствованный вариант)
Следует ли нам усовершенствовать рис. 26.6, так как он не синхронизирован
с остальными? Диаграмма не содержит элемента для подсчета оплаты доставки
и обработки заказа. Я думаю, что не стоит. Диаграмма устойчивости нам боль-
ше не нужна. Мы избавимся от нее, как только закончим моделирование классов
на уровне проектирования (см. следующий раздел), которое мы будем выполнять
на основе информации, содержащейся в диаграмме. Мы могли бы усовершенство-
316 Глава 26 • Гибкий анализ и проектирование
вать диаграмму, добавив в нее два дополнительных кружка — один для класса
контроля/обработки «Счетчик оплаты доставки» и другой для класса-сущности
«Оплата доставки», но лучше сразу дополнить этой информацией модель классов
на уровне проектирования. Диаграмма устойчивости выполнила свою задачу, по-
этому мы избавимся от нее, следуя методике «Избавляйтесь от временных моде-
лей».
СОВЕТ: БУДЬТЕ ГОТОВЫ К ОШИБКАМ В ТРЕБОВАНИЯХ ----------------------------
Во время создания реализаций элементов Use Case довольно часто обнаруживаются проблемы
в логике элементов Use Case. Одним из плюсов применения методики «Создавайте несколько
моделей параллельно» является то, что вы обнаруживаете ошибки благодаря рассмотрению
проблемы с разных сторон. Гибкие разработчики рассматривают это как форму тестирования
г моделей, так как вы оцениваете содержание одной модели с помощью другой. Конечно же,
обе модели могут содержать ошибки, но вы убедились на приведенном примере, что их можно
обнаружить и ликвидировать.
Не пора ли использовать CASE-средства?
Глядя на рис. 26.6-26.8, мы понимаем, что перед нами стоит весьма интересная
проблема. Каждый из них представляет собой разную точку зрения на одну и ту
же информацию. В них достаточно сходств, чтобы предложить использование
CASE-средства вместо набросков на белой доске. Гибкие разработчики зачастую
используют CASE-средства для создания диаграмм на уровне проектирования,
особенно при наличии CASE-средства, с которым легко работать и которое гене-
рирует качественный исходный код для рабочей среды. К счастью, существует не-
сколько CASE-средств, поддерживающих платформу J2EE, на которой разраба-
тывается SWA Online.
СОВЕТ: ИНОГДА CASE-СРЕДСТВО ЯВЛЯЕТСЯ ПРОСТЕЙШИМ РЕШЕНИЕМ ----------
Методика «Используйте простейшие инструментальные средства» советует нам выбрать для
работы самое простое средство. Когда нужно написать исходный код, проще использовать CASE-
средство, которое генерирует качественный исходный код, а не средство программирования,
используя которое, вы вынуждены писать исходный код вручную.
Мы обсуждаем имеющийся опыт моделирования и решаем, что имеет смысл
создать диаграмму классов при помощи CASE-средства, потому что оно генери-
рует исходный код на Java. Диаграммы последовательности также лучше созда-
вать с помощью CASE-средства, так как оно преобразует классы (а вместе с ними
и диаграммы классов) таким образом, чтобы отразить информацию, содержащу-
юся в диаграммах последовательности. Однако мы не собираемся превращать
диаграммы последовательности в официальные документы, поэтому мы реша-
ем предоставить их отдельным разработчикам. Если они не захотят использовать
CASE-средство для создания диаграмм последовательности, в этом не будет ниче-
го страшного, но им все равно придется его использовать для того, чтобы получить
информацию о структуре нашей системы. Мы решаем продолжить рисовать диа-
граммы устойчивости от руки, так как обнаружили, что они могут принести поль-
зу в качестве временных артефактов анализа, но не нужны нам постоянно.
Моделирование классов на уровне проектирования 317
Чтобы убедиться в эффективности использования CASE-средства, наша груп-
па решает регулярно проводить обратное конструирование на основе нашего кода;
это обеспечит синхронизацию диаграммы классов с исходным кодом, как было
предложено в главе 10. Благодаря этому решению CASE-средство становится
главным средством не только моделирования, но и разработки. Кстати, произво-
дители CASE-средств, генерирующих исходный код, обычно стремятся поддержи-
вать интеграцию этих средств с распространенными для этого языка интегриро-
ванными средами разработки (IDE).
Моделирование классов
на уровне проектирования
Мы потратили много времени на моделирование, но при этом почти не занимались
кодированием. Это плохо, потому что чем дольше мы не получаем обратной связи,
тем больше риск того, что в создаваемых нами моделях содержатся ошибки. Гибкие
разработчики помнят о принципе «Быстрая обратная связь» и предпочитают сле-
довать методике «Подтверждение модели кодом», поэтому они немного модели-
руют, затем немного кодируют и переходят к следующей итерации. Поразмыслив,
мы поняли, что пытались решить слишком много задач путем моделирования.
Сосредоточившись на довольно большом элементе Use Case «Размещение заказа»,
мы слишком .много на себя взяли. Например, наша диаграмма устойчивости ука-
зывает на необходимость создания восемнадцати различных классов, и это еще на
уровне анализа, а на уровне проектирования их количество может достичь сорока
или пятидесяти. Такой подход уместен в начале проекта, когда мы определяем пер-
воначальные требования, но когда мы переходим к подробному проектированию,
лучше сфокусироваться на небольшом подмножестве задач. Поэтому мы решили
немного сбавить скорость и разобраться с функциями обработки заказа. Функции,
касающиеся покупателей, оплаты и адресов, можно будет рассмотреть позднее.
Мы начинаем преобразовывать диаграмму классов анализа (рис. 26.11) с помо-
щью CASE-средства. Хотя на уровне анализа у нас получилась неплохая диаграм-
ма, она не отражает архитектурного подхода, основанного на компонентах пред-
метной области. На рис. 26.3 показано, что нам необходим компонент заказа, а на
рис. 26.4 видно, что нам следует ввести одну или более bean-сессий EJB для реали-
зации его публичного интерфейса (эту функцию данный компонент предоставля-
ет внешним компонентам и приложениям). На рис. 26.11 изображена информа-
ция, содержащаяся в диаграмме анализа, но преобразованная на уровне проекти-
рования, для того чтобы показать нашу компонентную стратегию.
Мы ввели bean-сессию EJB под названием «КомпонентЗаказа», чтобы реализо-
вать публичный интерфейс данного компонента. При этом мы успешно применя-
ли паттерн проектирования «Фасад» (Гамма, Хельм, Джонсон и Влиссидес, 1995).
Этот паттерн советует нам вводить класс, который инициирует вызовы методов
других классов, к которым вы не хотите предоставлять доступ извне, тем самым
снижая сцепление внутри всей системы. Гибкие разработчики обычно следуют
методике «Не увлекайтесь паттернами» и применяют паттерны с осторожностью.
В данном случае мы сразу применили паттерн «Фасад», потому что он очень прост.
318 Глава 26 • Гибкий анализ и проектирование
Гибкие разработчики предпочитают следовать методике «Применяйте стан-
дарты моделирования». Обычно такие стандарты включают в себя соглашения
для наименования элементов моделей (например, классов). Поскольку данный
компонентный подход является фундаментальным аспектом нашей архитекту-
ры, нам нужно ввести соглашения по наименованию для этих фасадных классов.
Мы советуемся с другими разработчиками и выясняем, что мы впервые реализуем
компонент предметной области (в данном случае — компонент «Заказ»), поэтому
для него еще нет соглашения по наименованию. Соглашение по наименованию
КомпонентСбизнесИменем ни у кого не вызывало возражений, в результате чего воз-
никли такие наименования, как КомпонентЗаказа и КомпонентПокупателя. Мы хоте-
ли принять условное наименование ФасадСбизнесИменем, но некоторые члены на-
шей группы предпочли первый подход.
Рис. 26.11. UML-диаграмма классов на уровне проектирования,
основанная на элементе Use Case «Размещение заказа»
Диаграмма классов недостаточно ясно объясняет логику операций элемента
КомпонентЗаказа. Мы можем лишь строить предположения, основанные на на-
званиях. Применение UML-диаграммы классов является очень удачным реше-
нием для моделирования статичной структуры объектно-ориентированного ПО
или- отражения классов и отношений между ними, но не очень подходит для мо-
делирования динамической природы или отражения взаимодействия объектов
друг с другом для исполнения их обязанностей. На каком-то этапе нам придет-
ся следовать методике «Применяйте нужный артефакт (артефакты)» и исследо-
вать реализацию каждой из операций. Для этого могут подойти исходный код,
UML-диаграммы последовательности и UML-диаграммы сотрудничества. Выбор
того или иного артефакта будет зависеть от сложности каждой операции и ваших
знаний той или иной модели. Чем сложнее операция, тем больше вероятность
того, что вы предпочтете сначала моделировать, а потом кодировать.
Моделирование классов на уровне проектирования 319
КомпонентЗаказа имеет отношение зависимости с классом Товар, потому что
он взаимодействует с экземплярами «Товара» для их поиска, запуская операции
поиска EJB. Операции поиска? Какие еще операции поиска? Операции поиска не
показаны на рис. 26.11 по двум причинам:
1. CASE-средство генерирует средства поиска. CASE-средство легко может
генерировать операции поиска, так как в EJB существует стандартный спо-
соб реализации таких операций, поэтому у нас нет необходимости указы-
вать их на диаграмме с самого начала. CASE-средства обычно.не показы-
вают генерируемый код (вы быстро привыкаете к тому, что они пишут код
за вас), поэтому не стоит отображать на диаграммах лишнюю информацию.
Гибкие разработчики изображают модели просто. Кроме операций поис-
ка EJB, CASE-средство также генерирует удаленные интерфейсы, операции
«получатель», которые обеспечивают доступ к отдельным атрибутам дан-
ных, операции «установщик», которые изменяют отдельные атрибуты дан-
ных и вспомогательный код, необходимый для поддержки отношений меж-
1 ду объектами (Амблер, 2001а).
2. Средства поиска легко кодировать. Нам уже приходилось кодировать опе-
рации поиска, так что нам будет легко это сделать. Включать операции поиска
в нашу модель не имеет смысла. Пусть CASE-средство генерирует то, что мо-
жет, а мы при необходимости усовершенствуем код, а потом выполним об-
ратную разработку измененного кода, превратив его в модель (см. главу 10).
Достаточно ли хороша диаграмма классов, изображенная на рис. 26.11? Это за-
висит от того, зачем вам нужна эта диаграмма (помните принцип «Модель должна
решать конкретную задачу»/ В данном случае нашей целью было создать модель
для того, чтобы начать кодировать, но мы явно зашли слишком далеко. Мы могли
начать с моделирования классов КомпонентЗаказа и Товарка затем приступить к их
кодированию, направив свою работу на создание функциональности поиска то-
вара (см. главу 20, чтобы узнать, как это выполнялось в ХР-проекте). Если бы мы
разобрались с этой функциональностью, мы могли бы вернуться к нашей модели
классов и смоделировать Заказ и ТоварЗаказа, запрограммировать и протестиро-
вать эту функциональность. Мы могли бы поочередно добавить СчетчикНалогов,
СчетчикСкидок и СчетчикОплатыДоставки. Выбранный нами подход очень близок к
подходу «Сначала-все-спроектируем» (BDUF), а второй подход, только что опи-
санный мною, более соответствует методике «Моделируйте постепенно».
СОВЕТ: НЕ СПЕШИТЕ -----------------------------------------------------—
В этой главе я намеренно отошел от более экстремального подхода к моделированию,
описанного в третьей части книги. Я сделал это, чтобы показать, что существует масса
возможностей для применения принципов и методик AM в проектах по созданию ПО. Вы можете
применять высокоитеративный, основанный на программировании подход, используемый в ХР-
проектах, или не менее итеративный, но основанный на моделировании подход^ описанный
в этой главе. Многие разработчики, знакомые со стилем работы по принципу «Сначала-все-
спроектируем», найдут данный подход весьма радикальным. По мере'того как они привыкнут
к гибкой разработке, они станут все более экстремальными.
320 Глава 26 • Гибкий анализ и проектирование
Моделирование данных >
Мы решили сначала реализовать КомпонентЗаказа и Товар. Мы использовали
CASE-средство, чтобы генерировать исходный' код, который послужит нам от-
правной точкой. Теперь наша цель — реализовать и протестировать функциональ-
ность поиска товаров. Первым шагом для этого является реализация метода поис-
ка для класса товаров. Данная операция должна:
1. Взять набор параметров, которые представляют критерии поиска. Для
того чтобы сделать это, нам нужно определить параметры операции.
Кое-что. мы уже сделали, создав прототип пользовательского интерфейса
(рис. 26.12). Из этого рисунка понятно, что возможными критериями по-
иска будет название товара, его номер, категория, к которой он относится,
минимальная и максимальная цена. Покупатель может решить определить
один или более критериев.
2. Проанализировать критерии. Анализ критериев поиска тоже прост,
v Единственная сложность — преобразовать трафаретные символы типа «*»
в их SQL-эквиваленты «%». Мы можем сделать это при помощи специаль-
ного класса.
3. Создать SQL-оператор ВЫБОР, представляющий критерий поиска.
Из-за того что мы решили использовать подход BMP (Ьеап-управляемая
устойчивость) вместо подхода СМР (устойчивость, управляемая контейне-
ром), нам необходимо написать SQL-код для взаимодействия с базой дан-
ных (Роман, Амблер, Джуэл и Маринеску, 2002). Чтобы сделать это, мы
должны отобразить атрибуты, соответствующие отдельным критериям по-
иска, в столбцы базы данных. Нам необходимо знать схему существующей
базы данных и при необходимости усовершенствовать ее. Мы реализуем эту
систему, используя реляционную базу данных для хранения информации.
Схемы таких БД обычно моделируют при помощи физической модели дан-
ных. На рис. 26.13 изображена существующая модель данных с использова-
нием неофициальной нотации UML (Амблер, 2001а), которая была созда-
на членами нашей группы при помощи CASE-средства для моделирования
данных. Подобно объектно-ориентированному CASE-средству, которое мы
использовали для моделирования UML-диаграммы классов, данное сред-
ство может генерировать исходный код схемы (а также выполнять обрат-
ную разработку) на языке определения данных (DDL), соответствующий
нашей базе данных, а также триггеры, необходимые для поддержки цело-
стности ссылочных данных в базе данных. Как вы видите, необходимые
столбцы уже включены в базу данных.
4. Возврат результатов поиска. Ответ, полученный из базы данных (который
может оказаться и исключением), необходимо обработать должным обра-
зом. На рис. 26.11 показано1, как операция поискТовара() КомпонентаЗаказ
1 Увы, здесь автор выдает желаемое за действительное — на рис. 26.11 это не показано. — Примеч.
науч. ред.
Моделирование данных 321
возвращает XML-документ, поэтому нам нужно написать код для оформле-
ния ответа в этом формате. Для этого мы вводим две операции в класс Товар:
одну для создания отчета об ошибках в XML-документе, а другую — для
создания XML-документа, содержащего несколько представлений товаров,
соответствующих критериям.
Рис. 26.12. Набросок, показывающий, что требуется для создания страницы поиска товара
СОВЕТ: МНОГИЕ АРТЕФАКТЫ МОГУТ БЫТЬ
ИСПОЛЬЗОВАНЫ В РАЗНЫХ МЕТОДОЛОГИЯХ --------------------------------
Вы уже видели несколько моделей, представленных в данной главе. Например, рис. 26.12
был использован' в главе 20 для объяснения процесса моделирования во время ХР-итерации,
а рис. 26.13 встречался в главе 21. Важно понять, что вы можете использовать тот же
тип артефактов (например, UML-диаграмму классов или варианты изменений) в проектах,
следующих различным процессам создания ПО. Вы также можете получить одинаковый
результат, следуя различным процессам, хотя способы его получения могут быть совершенно
различными.
Мы реализуем функциональность поиска, начинаем ее тестировать и обнару-
живаем, что время получения ответа может быть разным. Проблема состоит в том,
что существует возможность задать очень широкие границы поиска. Например,
нажав кнопку поиска, можно получить содержание всей таблицы «Товар». Это
никуда не годится. Мы просим Брендана, администратора баз данных нашей груп-
пы, помочь нам. Он предлагает два варианта. Первый — представить запрос в базу
данных и попросить ее оценить размер результата поиска. Если последний слиш-
ком велик, мы просто просим покупателя сузить границы поиска. В другом случае
мы представляем запрос в базу данных и передаем покупателю результат. Второй
вариант — настроить курсоры базы данных таким образом, чтобы- покупатель мог
видеть блок из 20 позиций товара и прокручивать блоки вверх-вниз. Этот вариант
более сложен, так как он требует обработки запросов прокрутки. Есть еще один
11 Зак. 926
322 Глава 26 • Гибкий анализ и проектирование
важный момент. В наших требованиях не определено, что нам следует делать, по-
этому нам ну>кен совет заинтересованных лиц. Поэтому мы еще раз возвращаемся
к рабочему потоку «Требования» и объясняем Венди суть проблемы и варианты
ее решения. Мы оцениваем фронт работ для каждого из подходов и просим ее сде-
лать выбор. Венди выбирает вариант с курсором, потому что он более удобен для
покупателя.
Рис. 26.13. Текущая модель данных для SWA Online
Ожидайте изменений 323
' Мы перерабатываем код в связи с нашим новым подходом, тестируем его по
ходу работы и, наконец, решаем перейти к созданию системы управления версия-
ми. Мы хотим привести в порядок общее хранилище артефактов, следуя методике
«Совместное владение». В хранилище содержатся исходный код, все постоянные
модели (диаграммы классов и данных) и вся постоянная документация, которую
мы решили вести. Мы продолжаем работу над элементрм Use Case «Размещение
заказа», разрешив все проблемы (например, кто-то мог внести изменения в класс
«Товар», который нам теперь необходимо согласовать с нашей работой). Процесс
управления версиями описан в рабочих потоках «Управление изменениями и кон-
фигурацией» (см. главу 23).
Ожидайте изменений
Следующим нашим шагом будет написание кода для создания страницы корзины
покупателя, размещающего заказ. На рис. 26.9 вы видите, что мы предполагаем
указать номер покупателя наверху страницы. Мы обсуждали эту проблему с Вен-
ди пару дней назад, предлагая использовать адрес электронной почты вместо но-
мера. Она обещала подумать над этим, хотя мы еще не получили ответа. Мы еще
раз обратились к ней. Она была занята работой с другими разработчиками нашей
группы, поэтому нам пришлось подождать, пока она освободится. Пока мы жда-
ли Венди, мы посмотрели на существующие модели, чтобы определить, что нам
придется менять. Независимо от того, какое решение.примет Венди по поводу ис-
пользования адреса электронной почты в качестве идентификатора покупателя,
нам все равно придется разобраться с адресом электронной почты, для того чтобы
отправлять покупателю описание заказа. Дело в том, что нам может понадобиться
записывать адрес, по которому отправляется описание заказа. Возможно, мы даже
будем записывать адрес по умолчанию для каждого покупателя, чтобы упростить
процесс заказа. Оба этих решения зависят от новых требований. Если мы сохра-
няем адрес электронной почты для отправки описания заказа, нам следует сде-
лать что-то для осуществления данной операции. Если мы поддерживаем адрес
по умолчанию, то страница информации о покупателе должна включать эту фун-
кцию. Это также необходимо обсудить с Венди.
Наконец, Венди заходит к нам, чтобы обсудить эти вопросы. Она соглашает-
ся с нашей идеей использования адреса электронной почты в качестве иденти-
фикатора, но желает также сохранить номер покупателя. Она говорит о том, что
наша система должна позволять покупателям изменять адрес и реагировать на эти
изменения. Она одобряет нашу идею использования адреса электронной почты
по умолчанию для отправки описания заказа, хотя не считает нужным сохранять
в базе данных запись о том, куда было отправлено описание.
Из-за появления этих новых требований нам необходимо переработать суще-
ствующие функции. Являясь гибкими разработчиками, мы следуем принципу
«Ожидайте изменений», поэтому эти изменения не выбивают нас из колеи, как это
было раньше. Мы понимаем, что нужно изменить первоначальный вариант глав-
ной страницы и соответствующие EJB. В таблицу «Покупатель» (см. рис. 26.13)
324 Глава 26 • Гибкий анализ и проектирование
также необходимо добавить столбец «Адрес электронной почты». Эту функцию не-
обходимо протестировать и разместить в системе управления версиями. Брендан
предлагает усовершенствовать модель данных и схему базы данных, а мы реша-
ем реализовать и другие изменения. К счастью, код, который генерирует страни-
цу HTML и контролирует вход в систему, уже приведен к базовому уровню. Мы
проверяем это и приступаем к работе. Другие члены группы работают над классом
«Покупатель», и мы просим их сообщить нам, когда с ним можно будет работать.
Тем временем мы делаем копию последней версии и начинаем вносить изменения.
Через несколько часов нам сообщают, что новая версия класса «Покупатель» гото-
ва и протестирована. Мы забираем ее из системы управления версиями и вносим
свои изменения. По окончании этой работы мы тестируем код и возвращаем его
в систему управления версиями.
Как это осуществить?
Мы видим, что принципы и методики AM можно применять в рабочем потоке
«Анализ и проектирование», что в общем-то неудивительно, потому что его целью
является моделирование. Однако вам.необходимо принять сознательное решение,
что моделировать вы будете гибким образом, — в этой главе мы немного отошли от
гибкого подхода. Это может случиться с кем угодно, поэтому я и решил привести
соответствующие примеры. Когда вы обнаруживаете, что' моделируете не гибко
(как произошло с нами во время работы над реализацией элементов Use Case), вы
останавливаетесь и задаете себе вопрос: «Почему это произошло?», чтобы учесть
эту ошибку в будущем'.
Как вы понимаете, обратная связь с программистами и тестировщиками очень
важна во время проектирования. Мы обращали на это внимание во время разра-
ботки UML-диаграммы классов (уровня проектирования) и модели данных. Обе
эти модели близки к коду, и многие разработчики часто программируют, исполь-
зуя CASE-средство и интегрированную среду разработки, поэтому при переходе от
одного артефакта к другому лучше всего перейти к исходному коду. Разработчики,
следующие принципу AM «Быстрая обратная связь» и методике «Подтверждение
модели кодом», обнаруживают, что их работа по проектированию становится куда
более гибкой по сравнению с ранее применявшимся подходом, когда они с самого
начала создавали всеобъемлющие модели.
Мы должны быть .готовы переходить не только от одного артефакта к другому,
но и от одного рабочего потока к другому. Несколько раз нам приходилось «от-
ступать» и работать над требованиями с заинтересованными лицами. Это вполне
предсказуемо, потому что мы не ставим перед собой задачу довести модели тре-
бований до совершенства. По мере работы мы обнаруживаем, что нам необходима
дополнительная информация от заинтересованных лиц. Мы также несколько раз
возвращались к рабочему потоку «Управление изменениями и конфигурацией»,
для того чтобы привести нашу работу к базовому уровню.
Как это осуществить? 325
Важной частью рабочего потока «Анализ и проектирование» является опре-
деление и совершенствование рабочей архитектуры системы. Архитектура долж-
на отражать требования к системе и ограничения, обусловленные существующей
инфраструктурой вашей организации. Используйте существующую инфраструк-
туру во время работы по моделированию в этом рабочем потоке, следуя методике
«Используйте имеющиеся ресурсы». Одной из целей рабочего потока «Управление
инфраструктурой», описанного в главе 27, является создание, поддержка и разви-
тие моделей архитектуры, которые впоследствии могут быть использованы дру-
гими группами разработчиков вашей организации.
Г ибкое
управление
инфраструктурой
Рабочий поток «Управление инфраструктурой» направлен на разработку, измене-
ние и поддержку артефактов инфраструктуры организации (к ним относятся, на-
пример, модели организации, процессы разработки ПО, стандарты, руководства
и повторно используемые артефакты). В данном рабочем потоке также осуществля-
ется деятельность по управлению портфелем программных проектов. Короче гово-
ря, управление инфраструктурой — это деятельность, охватывающая весь проект.
Почему этот рабочий поток так важен для гибкого разработчика? Потому что
в больших организациях наверняка есть группы профессионалов, работа которых
состоит в разработке различных вспомогательных функций (администрирование
данных, обеспечение безопасности и поддержка процесса разработки ПО). Такие
группы обеспечивают повторное использование и согласованность разрабатывае-
мых проектов с целью сокращения расходов организации на создание и сопровож-
дение систем. Вашей группе придется сотрудничать с этими группами, причем
в лучшем случае вы извлечете из этого сотрудничества пользу, а в худшем случае
вам придется либо следовать их стандартам, либо находить способы их обойти.
В данной главе мы обсудим следующие моменты:
• Модели инфраструктуры.
• Моделирование инфраструктуры.
• Стандарты и руководства.
• Группы по созданию базовой инфраструктуры.
• Применение АМ группами по созданию базовой архитектуры.
• Как это осуществить?
ВНИМАНИЕ: ОЧЕНЬ ЧАСТО УПРАВЛЕНИЕ АРХИТЕКТУРОЙ НЕ ИМЕЕТ ГИБКОСТИ
Как вы узнаете в данной главе, гибкий подход вполне применим в данном рабочем потоке.
Тем не менее, большинство организаций, занимающихся разработкой ПО, делают ;это очень
не-гибко, предпочитая применять командно-административную систему управления, а -не
направляющий/обучающий подход. Будьте очень осторожны, потому что этот рабочий поток
опасен тем, что может помешать гибкости.
Модели инфраструктуры 327
Модели инфраструктуры
Существует три основные модели, которые вашей организации необходимо разра-
ботать для описания инфраструктуры:
1. Корпоративная модель требований. Эта модель отражает высокоуровне-
вые требования организации (Джекобсон, Грис и Джонсон, 1997) и опи-
сывает услуги, которые организация предоставляет в своей внешней сре-
де. В среде унифицированного процесса в качестве основного артефакта
вы будете разрабатывать высокоуровневую диаграмму Use Case, основан-
ную на высокоуровневых сущностных/бизнес-элементах Use Case (они не
зависят от технологий, и поэтому их «срок годности» практически не огра-
ничен), при этом ссылаясь на другие артефакты требований (например,
основные бизнес-правила и определение ограничений). Однажды я участ-
вовал в разработке модели корпоративных требований, которая описывала
бизнес-среду большой страховой компании. Модель включала в себя менее
20 высокоуровневых элементов Use Case, например «Приобретение финан-
сового инструмента», «Предъявить иск», «Подтвердить иск». Хотя эта мо-
дель и была высокоуровневой, она хорошо описывала требования, поэтому
мы могли представить себе, какие системы следует разработать и привязать
к среде организации. Мы считали данную модель долгосрочной. Она опи-
сывала страховой бизнес в данный момент, 50 лет назад и на 50 лет вперед.
Несмотря на то что страховой бизнес развивался и продолжает развивать-
ся, его основы остаются неизменны. Вы можете использовать диаграмму
потоков данных (DFD) в качестве основного артефакта (особенно в случае,
если подобная диаграмма уже существует) вместо использования элемен-
тов Use Case.
2. Модель архитектуры предметной области. Эта модель отражает высоко-
уровневую бизнес-структуру вашей системы (общие компоненты или услу-
ги, предоставляемые бизнес-системами вашей организации). Эта модель
помогает группам разработчиков понять, какие части предметной облас-
ти можно использовать повторно, а также дает рекомендации по встраива-
нию системы в существующую инфраструктуру, чтобы другие разработчики
могли использовать результаты их работы в дальнейшем. В компонентной/
объектной среде часто используют UML-диаграмму компонентов, отражаю-
щую широкомасштабные компоненты предметной области, которые годят-
ся для повторного использования и изменяются разработчиками с течением
времени. Такие компоненты (например, «Заказ» и «Покупатель» в компа-
нии SWA) могут быть запрошены любым приложением, нуждающимся
в их функциях. До сих пор мы рассматривали всего лишь одно приложе-
ние (SWA Online), но на самом деле бизнес-компоненты, отображенные на
рис. 27.1, могут применяться и в других приложениях. Конечно же, вам при-
дется включить дополнительные функции, необходимые для данных при-
ложений, вам придется произвести, рефакторинг существующих функцио-
нальных возможностей, но именно здесь вам предоставляется возможность
328 Глава Т7 • Гибкое управление инфраструктурой
повторного использования имеющихся ресурсов. В дальнейшем мы еще по-
говорим об этом. Отдельные компоненты будут, в свою очередь, описаны дру-
гой, более подробной, UML-диаграммой компонентов или UML-диаграммой
классов (если вы вообще станете ее создавать). Если вы работаете с данными,
тогда вам больше подойдет корпоративная модель данных. В идеале такая
модель должна показывать только высокоуровневые области данных (экви-
валент компонентов предметной области для данных). Совместно с этой мо-
делью могут создаваться подробные модели данных. Организациям сферы
услуг следует определить категории услуг, представив эти категории в виде
компонентов или просто в виде списка (возможно, вместе со списком услуг,
оказываемых совместно с другими компаниями).
Рис. 27.1. UML-диаграмма компонентов для SWA Online
3. Модель технической архитектуры. Эта модель отражает высокоуровневую
техническую инфраструктуру, которая лежит в основе бизнес-среды. Очень
часто для изображения существующего/наследуемого приложения, тех-
нических средств и сетевого окружения используются сетевые диаграммы,
хотя иногда применяются диаграммы свободной формы. Применяя компо-
нентный/объектный подход, вы можете создать высокоуровневую компо-
нентную диаграмму, которая отражает техническую инфраструктуру компо-
нентов, обеспечивающих безопасность, устойчивость, аудиторский контроль
и многое другое. В некоторых организациях компоненты предметной облас-
Моделирование инфраструктуры 329
ти и компоненты их технической инфраструктуры изображаются на одной
диаграмме (см. рис. 27.1). Для организаций, предоставляющих услуги (на-
пример, веб-сервис или среду абонентской информационно-управляющей
системы), вы опять же будете моделировать категории услуг, возможно,
вместе со списком услуг, оказываемых совместно с другими компаниями.
Модель
корпоративных
требований
Корпоративный
уровень
Уровень
приложения
Подробные модели
Рис. 27.2. Процесс моделирования инфраструктуры
Моделирование инфраструктуры
Теперь давайте рассмотрим процесс моделирования инфраструктуры. На рис. 27.2
изображен высокоуровневый обзор отношений между моделью организации/
корпоративной моделью и моделью проекта. Линии, соединяющие модели, по-
казывают отношения типа «управляет» или «оказывает влияние». Например,
информация, содержащаяся в модели корпоративных требований, может быть ис-
пользована для управления или оказания влияния на информацию в модели тре-
бований, и наоборот (в этом случае линия снабжена стрелками с обеих сторон).
Модель корпоративных требований описывает всю организацию и потому гораз-
до шире, чем модель требований проекта, но содержит меньше деталей. Модель
330 Глава 27 • Гибкое управление инфраструктурой
организации предоставляет общий контекст; модель проекта добавляет в него де-
тали. Что касается модели проектируемой системы, следует принять во внима-
ние функции, описанные в архитектурной модели предметной области и модели
технической архитектуры. Более того, по мере проектирования системы вы може-
те в рамках обратной связи сообщить группе (группам), отвечающим за модели
архитектуры, о тех функциях, которые явно будут использоваться неоднократно.
Давайте рассмотрим процесс, изображенный на рис. 27.2, с разных точек зрения:
нисходящего моделирования и восходящего моделирования.
Нисходящее моделирование
Применяя нисходящий подход к разработке, вы начинаете с разработки моде-
ли корпоративных’ требований, которую затем анализируете для создания ар-
хитектурной модели предметной области и модели технической архитектуры.
Первоначальная работа по моделированию инфраструктуры — процесс длитель-
ный. Эта работа может продолжаться от нескольких дней до нескольких месяцев
в зависимости от степени детальности. Когда эти модели будут готовы, ваша орга-
низация сможет понять поставленные перед ней задачи и архитектурный «ланд-
шафт», поддерживающий данные требования.
Отдельные группы разработчиков приступают к работе и выделяют час-
ти модели корпоративных требований (это является целью рабочего потока
«Требования» на этапе «Начало»), и обычно выбирают небольшие порции функ-
циональных возможностей, основанных на нескольких корпоративных элементах
Use Case. Далее группа продолжает работать над другими рабочими потоками UP
в обычном режиме, но при этом обеспечивая обратную связь с создателями моде-
лей инфраструктуры, для того чтобы они могли совершенствовать модели с тече-
нием времени. Имеющиеся ресурсы следует использовать повторно. Следует рас-
планировать разработку функциональных возможностей, определенных в ваших
моделях, н^> еще не реализованных (эта работа будет выполняться одной или дву-
мя группами разработчиков и/или группой инфраструктуры). Ранее не рассмот-
ренные функциональные возможности можно отнести к одной из трех категорий:
поведение, присущее всей организации и общее для нескольких приложений; по-
ведение, присущее отдельному элементу бизнес-среды и применяемое к несколь-
ким приложениям в данном элементе бизнес-среды; и поведение, присущее отде-
льному элементу бизнес-среды и применяемое к отдельному приложению. Если
вы следуете компонентному подходу, вам необходимо добавить это поведение
либо в компонент предметной области на корпоративном уровне, либо в компо-
нент предметной области, соответствующий отдельному элементу бизнес-среды,
либо в код отдельного приложения соответственно. Категоризация и планирова-
ние этой работы относятся к рабочему потоку «Управление конфигурацией и из-
менениями». Затем последует разработка.
Восходящее моделирование
Если вы применяете восходящий подход к моделированию, ваша группа будет пере-
ходить от одного рабочего потока к другому, а затем на каком-то этапе вы выделите
информацию о структуре организации. Возможно, некоторые компоненты, разра-
Моделирование инфраструктуры 331
батываемые вами, могут быть использованы другими группами для решения сво-
их задач. Еще лучше, если группа разработчиков, отвечающих за повторное исполь-
зование имеющихся ресурсов, переработает результаты вашей работы и поместит
их в общее хранилище, доступ к которому имеют все разработчики вашей организа-
ции. Модели технической архитектуры и модель архитектуры предметной области
могут-быть усовершенствованы с течением времени, чтобы отражать имеющиеся
ресурсы, пригодные для повторного использования, и существующую инфра-
структуру. Модель корпоративных требований также может быть разработана по-
средством обобщения информации, содержащейся в моделях требований.
Сравним два подхода
Выбор подхода зависит от культуры организации, имеющихся ресурсов и вашего
желания создать непротиворечивую модель. В табл. 27.1 представлены эти два под-
хода в сравнении. Оба подхода требуют поддержки со стороны групп по созданию
моделей организации, речь о которых пойдет далее в этой главе. Если ваша органи-
зация не приветствует идею создания таких групп, тогда моделирование архитек-
туры и работа по повторному использованию ресурсов вам не подходят.
Таблица. 27.1 Два подхода к моделированию в сравнении
Подход Преимущества Недостатки Особенности применения в организации
Нисходящее моделирование Обеспечивает согласованное видение организации. Создаются модели, которые гибкие разработчики могут использовать для работы (они используют имеющиеся артефакты) Модели архитектуры организа- ции не могут быть со временем -усовершенствованы. Модели инфраструктуры часто используются в качестве меха- низма управления и контроля групп разработчиков. Подход может утратить гибкость, если группа станет моделировать по принципу BMUF («Сначала- все-смоделируем»). Усложняет управление конфигурацией и сам процесс разработки Допускает наличие иерархической структуры организации. Группы по созданию моделей организации постоянно сопровождают и совершенствуют эти модели
Восходящее моделирование Модели организации отражают насущные нужды разработчиков. Компоненты/ функциональные возможности, отобранные для повторного использования действительно востребованы (они уже используются хотя бы в одном приложении) Модели организации могут легко стать зависимыми от отдельного приложения. Может получиться так, что работающие параллель- но группы разработчиков создадут одну и ту же функциональную возможность В центре внимания организации — группы разработчиков. Группы по созданию моделей организации на самом деле занимаются отбором и рефакторингом артефактов, пригодных для повторного использования
332 Глава 27 • Гибкое управление инфраструктурой
Применение стандартов и руководств
Важным аспектом рабочего потока «Управление инфраструктурой» является
создание, совершенствование и соблюдение корпоративных стандартов и руко-
водств. Это имеет большое значение для гибких разработчиков, потому что они
следуют методике «Используйте имеющиеся ресурсы» и применяют существую-
щие стандарты и руководства, совершенствуя их по мере необходимости (методи-
ка «Применяйте стандарты моделирования»). Вот некоторые стандарты и руко-
водства, которые вы можете применять:
• указания по дизайну пользовательского интерфейса;
• руководства по моделированию;
• стандарты по наименованию данных/компонентов/услуг;
• стандарты и руководства по программированию.
Повторю еще раз: вы можете выбрать либо нисходящий, либо восходящий под-
ход к моделированию в рабочем потоке «Управление инфраструктурой». Каждый
из них имеет свои преимущества и недостатки, перечисленные в табл. 27.1. Когда
мне необходимо определиться со стандартами, я обычно поступаю следующим
образом: сначала выясняю, какие стандарты существуют, и использую их по воз-
можности. Что касается моделирования, UML (Object Management Group, 2001а)
является четким промышленным стандартом для определения нотации и семан-
тики моделирования объектов. На самом деле стандарты существуют для большин-
ства видов деятельности (например, моделирования данных и создания диаграммы
потоков данных). В Интернете вы найдете руководства по дизайну пользователь-
ского интерфейса для большинства платформ (даже для создания веб-страниц).
Если я не могу найти общепринятые руководства, я ищу подходящие документы
в Сети, затем изменяю их и использую для своих целей. И лишь в худшем случае
я пишу их сам.
СОВЕТ: ЕСЛИ ВЫ НАПИШЕТЕ ДЕЛЬНОЕ РУКОВОДСТВО,
ТО РАЗРАБОТЧИКИ ЕГО ПРИМУТ ----------------------------::--------------
Во многих организациях я часто наблюдаю одну и ту же проблему: группы по созданию моделей
организации пишут стандарты и руководства, а группы разработчиков не спешат их применять.
Тогда первые тщетно пытаются внедрить эти стандарты и руководства в приказном порядке
или начинают контролировать их соблюдение. Это приводит к возникновению враждебности по
отношению к этой группе, но не способствует применению созданных ими руководств. Так быть
не должно. Например, на www.ambysoft.com/javaCodingStandards.html я разместил документ
в формате PDF, который описывает соглашение по программированию на Java. Его можно
загрузить бесплатно (на этой же странице имеются ссылки на другие документы, содержащие
стандарты кодирования для Java и других языков). Разработчики могут применять эти стандарты,
если они им подходят. Я знаю, что этот документ пользуется популярностью: зафиксировано
около четверти миллиона запросов этого документа, и множество фирм приобрели права на
его использование. Преимуществом этого документа является наличие свода соглашений,
а самое главное — он дает объяснение этих соглашений. Многие разработчики не принимают
эти соглашения всерьез, но ознакомившись с обоснованием, они, вероятнее всего, станут их
применять. Я считаю, что добиться успеха в использовании корпоративных стандартов можно,
если они просты в применении и четко обоснованы.
Группы по созданию базовой инфраструктуры 333
Группы по созданию базовой инфраструктуры
Термин «Группа по созданию базовой инфраструктуры» (CIT) относится к любой
группе, работающей в масштабе организации и обеспечивающей поддержку групп
разработчиков. К этим группам относятся группы администрирования данных,
группы обеспечения безопасности, группы сопровождения процесса и группы,
отвечающие за повторное использование. В некоторых организациях одна груп-
па отвечает за все аспекты рабочего потока «Управление инфраструктурой», в то
время как в других организациях группы специализируются на определенных ви-
дах деятельности. CIT-группы разрабатывают и поддерживают артефакты инфра-
структуры (корпоративные стандарты и руководства, пригодные для повторного
использования артефакты). CIT-группы могут быть гибкими, хотя, к сожалению,
многие из них таковыми не являются. По этой причине они имеют не самую луч-
шую репутацию среди разработчиков.
Давайте рассмотрим два способа работы CIT-групп. Начнем с подхода, не от-
личающегося гибкостью, а затем рассмотрим гибкий подход. Естественно, ваша
организация выберет золотую середину, внедряя идею CIT-групп. В основе на-
именее гибкого подхода лежит идея о том, что CIT-группы являются своего рода
«госприемкой», которую должны проходить все системы. CIT-группы выберут
модели инфраструктуры, стандарты и руководства, которым должны следовать
группы разработчиков, а затем станут проводить формальный анализ того, что
сделали разработчики. Они также имеют право запретить переход проекта к но-
вому этапу (например, запуску системы в производство) до тех пор, пока систе-
ма не будет соответствовать корпоративным стандартам. Члены CIT-групп часто
воспринимаются как отдельная часть вашей организации и являются вашей един-
ственной возможностью предотвращения хаоса, который может возникнуть, если
группам разработчиков дать волю. Преимуществом данного подхода является то,
что он требует минимального количества людей, потому что CIT-группы только
задают корпоративные стандарты и проверяют, как они соблюдаются. Главным
недостатком является то, что отношения между CIT-группами и группами раз-
работчиков весьма натянуты в силу их противостояния, обусловленного данным
подходом. CIT-группы считают разработчиков менее квалифицированными, чем
они есть на самом деле, и думают, что они не заслуживают доверия (хотя это мож-
но отнести и на их счет). Разработчики, в свою очередь, недоброжелательно отно-
сятся к CIT-группам^ считая их закоренелыми бюрократами, стоящими на пути
прогресса. Подобные мнения, как правило, негативно сказываются на отношени-
ях в целом.
К счастью, CIT-группы могут стать гибкими. CIT-группы могут ввести новый
стандарт на уровне организации или начать работу над моделью, но будут стре-
миться к получению обратной связи для оценки своей работы. Члены С1Т-группы
должны активно сотрудничать с группами разработчиков. С точки зрения разра-
ботчиков, CIT-группы являются заинтересованными в проекте лицами, которые
следуют методике «Активное участие заинтересованных лиц». Члены С1Т-группы
тесно сотрудничают с их непосредственными заказчиками (в первую очередь это
разработчики, хотя CIT-группы имеют дело и с теми заинтересованными лица-
334 Глава 27 • Гибкое управление инфраструктурой
ми, которые не являются разработчиками) для обеспечения необходимой подде-
ржки. Например, СГГ-группа, специализирующаяся на администрировании дан-
ных, при необходимости может «одолжить» администратора баз данных (DBA)
вашей группе. Администратор баз данных не только поможет вам изменить мо-
дели данных, но и проверит соблюдение стандартов по наименованию данных и
стандартов разработки. А CIT-группа, отвечающая за изменение технической ар-
хитектуры, снабдит вашу группу информацией о вычислительных средствах, име-
ющихся в вашей организации, а также поможет вам работать с ними. Данный под-
ход имеет следующие преимущества:
• Ваша корпоративная инфраструктура (стандарты, руководства, модели
и ресурсы для повторного использования) изменяется в ходе проекта, тем
самым обеспечивая соответствие насущным потребностям.
• Улучшаются взаимоотношения между разработчиками и С1Т-группами,
что повышает вероятность использования разработчиками корпоративной
инфраструктуры и способствует применению корпоративных стандартов. •
• Необходимость контроля соответствия стандартам сводится к минимуму
(если не исчезает совсем), потому что за это отвечают сами CIT-члены, ра-
ботающие с вашей группой.
Главный недостаток данного подхода состоит в трудности его применения. Для
достижения успеха вам необходимо преодолеть следующие проблемы:
• Данный подход требует доверительных отношений внутри вашего IT-от-
дела. Члены CIT-группы должны доверять разработчикам, а разработчи-
ки, в свою очередь, должны верить в то, что советы, которые дают члены
CIT-группы, являются ценными для вашей организации и им можно сле-
довать. Более того, заинтересованные лица должны быть уверены в том, что
члены CIT-группы и разработчики могут успешно сотрудничать при реше-
нии проблем, связанных с нуждами проекта и организации.
• Для успешного сотрудничества члены CIT-группы должны обладать отлич-
ными техническими и коммуникативными навыками. К сожалению,, эти-
ми качествами обладают только высокооплачиваемые консультанты,-а по-
скольку члены CIT-группы выступают в качестве штатных консультантов,
вам придется платить им высокую зарплату, если вы хотите, чтобы они ра-
ботали у вас постоянно.
• Члены CIT-группы должны представлять себе полную картину происходя-
щего, чтобы обеспечить определение и выполнение долгосрочных потреб-
ностей вашей организации. Поэтому они должны регулярно проводить соб-
рания, на которых будут делиться своими соображениями. Однако это не
всегда получается, так как разработчики начинают целиком и полностью
полагаться на них, и происходит следующее: член CIT-группы должен по-
свящать работе над проектом X % времени, а' остальное время (100-Х %)
работать над корпоративными проблемами, но в действительности получа-
ется, что он проводит 100 % своего времени в работе над проектом, а свои
обязанности, связанные с работой над корпоративными проблемами, вы-
Применение AM группами по созданию базовой архитектуры 335
полняет сверхурочно.
• Этот подход очень трудно применять в организациях со сложившейся
«не-гибкой» культурой. Часто они даже не верят в то, что этот подход в прин-
ципе возможен. Что ж, иногда это действительно невозможно при текущем
положении дел. Я видел, как гибкий подход к CIT-группам успешно при-
менялся в организации, где работали несколько сотен человек, но в этой
организации со дня основания культивировались доверие и коллективная
работа. Большие организации (скажем, несколько тысяч разработчиков)
со сложившейся «не-гибкой» культурой должны изменять свою культуру
постепенно, стремясь к созданию условий для успешной совместной рабо-
ты CIT-групп и разработчиков.
Применение AM группами
по созданию базовой архитектуры
Идея групп по созданию базовой архитектуры (CAT), которые обеспечивают ра-
боту средних и больших групп (20 разработчиков и более), сродни идее групп по
созданию базовой инфраструктуры (CIT). CAT-группа относится к одному про-
екту. Ее целью является определение, изменение и поддержка архитектуры проек-
та. Группы по созданию базовой архитектуры должны состоять из разработчиков,
имеющих опыт работы с технологиями, которые используются в вашей организа-
ции, а также умеющих работать с пробами архитектуры для изучения новых тех-
нологий. Они также должны понимать предметную область и иметь необходимые
навыки, для того чтобы объяснить архитектуру разработчикам и прочим заинте-
ресованным в проекте лицам.
Для создания успешно работающей CAT-группы в начале большого проекта
вы должны выбрать наиболее опытных разработчиков, обладающих абстрактным
мышлением, а также несколько людей, которым, по вашему мнению, не мешало
бы приобрести опыт по созданию архитектуры, и попросить их войти в состав
САТ-группы. Вам следует сделать это по двум причинам. Во-первых, вы хотите,
чтобы группа состояла из достойных людей. Во-вторых, когда вы разбиваете боль-
шую группу разработчиков на маленькие подгруппы, которые будут занимать-
ся созданием одной или нескольких подсистем, вы должны предусмотреть нали-
чие в них одного или двух членов группы по созданию базовой архитектуры. Это
увеличивает шансы того, что каждая из подгрупп изучает архитектуру системы
и следует ей, а также не позволяет группе по созданию базовой архитектуры игно-
рировать части системы. Кроме того, теперь в каждой подгруппе есть опытный
разработчик.
Группа по созданию базовой архитектуры отвечает за определение перво-
начальной архитектуры и передачу ее группе разработчиков для обратной свя-
зи и последующего развития. Так же как и члены гибкой CIT-группы, члены
САТ-группы будут активно сотрудничать с различными подгруппами проекта,
передавая архитектуру подгруппам и работая совместно с ними для проверки час-
336 Глава 27 • Гибкое управление инфраструктурой
тей архитектуры посредством конкретных экспериментов. CAT-группа будет ра-
ботать по схеме, изображенной на рис. 27.2, учитывая, что модели, изображенные
в верхней части диаграммы, относятся ко всему проекту, а модели, изображенные
в нижней части, предназначены для отдельных подгрупп.
Члены CAT-группы поймут, что им необходимо периодически встречаться,
чтобы изменять архитектуру по мере развития проекта, обсуждать изменения ар-
хитектуры и совершенствовать модели архитектуры в соответствии с изменения-
ми. Эти сеансы моделирования архитектуры будут происходить довольно часто в
начале проекта, но по мере стабилизации архитектуры они будут проводиться все
реже и реже. Члены подгрупп разработчиков, не являющиеся членами группы по
созданию базовой архитектуры, будут иногда присутствовать на сеансах модели-
рования архитектуры, чтобы предоставить информацию. Возможно, они занима-
лись созданием технических прототипов и у них есть информация для разработ-
чиков архитектуры. Как вы знаете из главы 13, лучше всего проводить короткие
сеансы (не более получаса), во время которых участники стоят вокруг белой доски.
На таком сеансе каждый должен быть готов представить и обсудить свои пробле-
мы, а также проблемы группы — это способствует быстрому принятию решения.
Однако в начале проекта вы, возможно, решите провести длительные (одноднев-
ные или двухдневные) сеансы моделирования архитектуры для определения пер-
воначальных вариантов,архитектуры.
Как это осуществить?
В заключение я хочу дать вам несколько советов, которые помогут вам повысить
эффективность применения способов управления инфраструктурой:
1. Имейте в виду, что данный рабочий поток вызывает много сложностей
в применении. Прежде всего ваша организация должна реально оценивать
ситуацию. Если у вас возникают сложности в отдельных проектах по созда-
нию ПО, то не стоит пытаться добиться успеха в работе над несколькими
проектами одновременно. Рабочий поток «Управление инфраструктурой»
подходит организациям, имеющим неплохой опыт в разработке ПО, но же-
лающим повысить продуктивность своей работы.
2. Добивайтесь простоты.
3. Четко распределите обязанности членов групп разработчиков и групп по
созданию базовой инфраструктуры. Несмотря на то что члены С1Т-групп
активно сотрудничают с'группами, занятыми в том или ином проекте, и мо-
гут помогать этим группам, прежде всего они являются членами группы по
созданию базовой инфраструктуры, и их обязанности выходят за рамки од-
ного проекта. ,
4. Добивайтесь простоты.
5. Учиться, учиться и учиться. Разработчики должны понимать, что их рабо-
та должна отражать и поддерживать инфраструктуру и среду организации.
Заинтересованные лица должны понимать, что потребности целой органи-
Как это осуществить? 337
зации имеют большую важность, нежели их личные предпочтения.,Члены
CIT-групп должны понимать, что их задача — поддерживать и направлять
работу групп, занятых в проекте, а не контролировать ее.
6. Добивайтесь простоты.
7. Учтите вероятность изменений. Если существующее управление инфра-
структурой не очень успешно, если CIT-группа и разработчики сотруднича-
ют не очень продуктивно, тогда вам стоит подумать о выборе другого подхо-
да. Новый подход наверняка потребует изменения сложившейся культуры
организации, а на это нужны силы и время.
8. Добивайтесь простоты.
Применение AM
в UP-проекге
В данной главе я рассмотрю проблемы, связанные с применением’ принципов
и методик гибкого моделирования в UP-проекте (Джекобсон, Буч и Рамбо, 1999;
Кратчен, 2000; Амблер, 2001b). Проблемы, описанные в данной главе, характер-
ны для организаций, применяющих UP, в то время как в главе 29 рассказывается
о способах преодоления проблем, общих для всех процессов.
AM/UP-группы должны будут преодолеть различные заблуждения и культур-
ные барьеры, связанные с применением UP. Вот несколько способов, которые мо-
гут в этом помочь:
1. Избегайте термина «управляемый элементами Use Case». Безусловно, это
замечательный маркетинговый термин, но на самом деле только элементов
Use Case, недостаточно для управления чем бы то ни было. Элементы Use
Case хороши для документирования требований, связанных с поведением,
но они представляют собой лишь малую часть картины функциональных
требований и еще меньшую часть общих требований. Они не очень подхо-
дят для документирования бизнес-правил, требований к пользовательско-
му интерфейсу, ограничений и требований, не связанных с функциональ-
ными возможностями, поэтому в унифицированном процессе применяют
так называемую дополнительную спецификацию, в которой содержится
вся эта информация. Система основана на требованиях, а не на элементах
Use Case. Работа по моделированию не будет иметь успеха, если вы не отде-
лите зерна от плевел: UP-разработку ПО от маркетинговых уловок.
2. Примите к сведению, что артефакты моделирования не ограничиваются
только UML-артефактами. Принцип AM «Разнообразие моделей» гово-
рит нам о том, что в нашем распоряжении имеется множество артефактов.
Среди них варианты изменений, истории пользователя, бизнес-правила,
UML-диаграммы деятельности, UML-диаграммы классов, модели дан-
ных, спецификации внешнего интерфейса ит. д. (эти и другие артефак-
ты описаны в приложении А). Смысл этого принципа в том, что вы може-
Применение AM в UP-проекте 339
те использовать не только UML-диаграммы (речь об этом шла в главе 15).
Унифицированный процесс учитывает тот факт, что для изучения слож-
ного современного ПО необходимо множество моделей. В этом и состоит
его преимущество. Последние версии включают моделирование данных и
деятельность, связанную с дизайном пользовательского интерфейса, что
выходит за рамки UML. (На момент написания этого текста последним
стандартом UML являлась версия 1.4.) К сожалению, многие ошибочно по-
лагают, что унифицированный процесс — это процесс, в котором использу-
ется унифицированный язык моделирования UML.
3. Примите к сведению, что UP вовсе не требует создания большого коли-
чества документации. Унифицированный процесс ясно указывает на то, что
вы должны создавать только те артефакты, которые вам необходимы, однако
некоторые разработчики ПО забывают об этом. Поэтому подчеркиваю эту
мысль еще раз. При создании любой модели, предлагаемой UP, вы должны
задавать себе вопрос типа: «Нужна ли она нам?», так как вам вряд ли пона-
добятся ВСЕ артефакты, предлагаемые унифицированным процессом.
Унифицированный процесс предлагает использовать три основных набора
артефактов моделирования: для бизнес-моделирования, для определения
требований и для анализа/проектирования. В свою очередь, каждый набор
артефактов включает в себя несколько детализирующих артефактов. Напри-
мер, к артефактам бизнес-моделирования относятся бизнес-модель Use Case,
бизнес-правила, документ по бизнес-архитектуре и бизнес-спецификация.
Нужны ли вам все эти артефакты? Вряд ли. Если они вам не нужны, то зачем
включать их в официальную документацию? Объясните заинтересованным
лицам смысл принципов AM «Путешествуйте налегке» и «Модель должна
решать конкретную задачу», а также методик «Совершенствуйте только
в случае необходимости» и «Избавляйтесь от временных моделей».
4. Разработчики и заинтересованные лица должны иметь, общее видение
процесса. Руководство часто склоняется к применению предопределенных
процессов, которые кажутся четкими и всеобъемлющими (например, уни-
фицированный процесс, в котором-большое значение придается контролю).
Разработчикам же больше нравятся гибкие методы, цель которых совпада-
ет с целями разработчиков (создание ПО), например экстремальное про-
граммирование (Бек, 2000) или гибкое моделирование. Поскольку выбор
' процесса зависит от руководства, многие разработчики вынуждены приме-
нять UP. К счастью, унифицированный процесс может быть довольно гиб-
ким, но для этого разработчики и заинтересованные лица должны прийти
к некоему соглашению.
5. Применяйте итеративную и инкрементную разработку. Опытным разра-
ботчикам довольно сложно применять методики AM «Моделируйте посте-
пенно», «Переходите от одного артефакта к другому» и «Создавайте не-
сколько моделей параллельно»: Кроме того, вполне вероятно, ваши опытные
разработчики не принимают всерьез идею унифицированного процесса об
итерациях, не говоря уже об итеративном и инкрементном моделировании.
340 Глава 28 • Применение AM в UP-проекте
Сторонники традиционных методик моделирования ратуют за применение
подхода «разработка одного артефакта» (например, моделирование элемен-
тов Use Case или сеансы создания прототипов пользовательского интерфейса).
Также они применяют подход «Сначала-все-спроектируем» (BDUF), или,
точнее, «Сначала-все-смоделируем» (BMUF), при котором сначала все мо-
делируют и только потом приступают к кодированию. В теории все это прос-
то здорово (в процессе работы артефакты моделируются по очереди, позво-
ляя разработчикам быстро привести их в порядок), но на практике все
оказывается иначе. Чтобы облегчить процесс внедрения этих методик, поп-
робуйте вместо сеанса моделирования элементов Use Case провести сеанс
моделирования требований, во время которого вы будете одновременно рабо-
тать с элементами Use Case, карточками CRC, бизнес-правилами и прототйпа-
ми пользовательского интерфейса. Затем вы проводите сеанс анализа, на
котором моделируете элементы Use Case, создаете диаграммы последова-
тельности, прототипы пользовательского, интерфейса и классы. Не забудьте
о сеансах проектирования, на которых вы займетесь моделированием классов,
состояний, данных, компонентов, прототипов пользовательского интерфейса
и, возможно, даже разработкой программного кода. Когда вы освоите эти ме-
тодики, следует перейти к реализации и исполЪзовать множество артефактов
(включая все созданные модели, исходный код и тесты), как того требует истин-
но итеративная разработка. При этом следует сосредоточиться на требовани-
ях, которые вы реализуете в данной итерации, и тогда по завершении каждой
итерации будет реализована некая часть функциональных возможностей.
6. Стремитесь к простоте. «Простота» (основная ценность АМ, положенная
в основу нескольких важных принципов и методик) может сильно повлиять
на эффективность вашей работы. Многие опытные разработчики стремятся
сразу же определить все возможное. Например, они хотят не только смоде-
лировать структуру ПО полностью, используя UML-диаграмму классов, но
еще и определить вспомогательный код для реализации этой структуры. Это
большая работа, но она не приносит ожидаемой пользы. Лучше создать диа-
грамму классов, которая вполне подходит для этой цели. В ней отражается
возможная структура классов, с которой можно начать кодирование. Гибкие
разработчики допускают, что программисты (часто они сами выступают в
этой роли) могут со временем уточнить детали, и вместо этого концентриру-
ются на проблемах, которые не столь очевидны. Данный подход предпола-
гает меньше работы для разработчика и меньше проблем, связанных с моде-
лированием, которые нужно будет преодолеть программисту. Когда гибкий
разработчик создает диаграмму классов, он понимает, что нет никакой не-
обходимости моделировать все классы, нужные для строительства ПО, и
создает лишь основные классы, предполагая, что программист вполне может
справиться со всеми остальными1. Чем проще будут создаваемые вами моде-
1 Если в вашем случае это не так, вам нужно решать проблемы с кадрами. Чрезвычайно сложные
модели не помогут в данной ситуации. Их создание лишь замедлит процесс принятия руководством
сложных решений по поводу качества работы их сотрудников.
Применение AM в UP-проекте 341
ли, тем быстрее вы будете работать. Программистам нужны модели, отража-
ющие основные проблемы и не содержащие ненужных деталей.
7. Наймите на работу побольше опытных универсалов. Во многих органи-
зациях предпочитают разграничивать специализацию разработчиков, что
снижает их способность быть гибкими. Хотя унифицированный процесс
ясно указывает на то, что отдельные разработчики могут и должны высту-
пать в нескольких ролях в проекте, во многих организациях этот совет про-
пускают мимо ушей. Вместо этого в организациях, применяющих UP, по-
являются разработчики, специализирующиеся на определении требований,
анализе системы, разработке дизайна пользовательского интерфейса и со-
здании базы данных, то есть выполняющие отдельные роли, что противоре-
чит и UP и AM. Если ваше участие в проекте ограничиваетсяшишь создани-
ем моделей, то вы склонны «перегружать» модели. Это происходит потому,
что, во-первых, вы хотите сделать свою работу качественно, а во-вторых,
если ваша задача состоит в моделировании, то, значит, есть кто-то, чьей за-
дачей это не является (например, он должен программировать). Возникает
искушение добавить побольше деталей в модель, потому что создатель мо-
дели передает ее программисту. Если вы не только пишете код, но и моде-
лируете, то не станете перегружать лишними деталями модель, с помощью
которой вы определяете, что нужно кодировать в первую очередь. ।
8. Принцип «Открытые и доброжелательные контакты» — в жизнь! Я стал-
кивался с ситуациями, когда группы разработчиков неохотно применя-
ли методику «Демонстрируйте модели открыто» (именно она способству-
ет открытым и доброжелательным контактам с людьми, не входящими
в вашу группу) из-за того, что не знали, как поступит с их информацией
другая политическая «фракция» их организации. Тем не менее, когда они
набрались смелости и начали демонстрировать свои модели открыто, они
быстро поняли, что «политиканам», которых они так боялись, критиковать
было нечего. Здоровая же критика способствовала успеху в дальнейшей ра-
боте.
Важно понять, что для успешного применения AM культура вашей организа-
ции должна приветствовать идеи, ценности и принципы гибкой разработки ПО-
Проблема состоит в том,, что некоторые организации, применяющие UP, прямо
или косвенно отрицают ценности гибкой разработки ПО. Их цель — следовать
процессу и использовать соответствующие инструментальные средства. Продукт
RUP (Rational Corporation, 2001) действительно определяет множество процес-
сов и рассказывает о том, как эффективно применять инструментальные средства
фирмы Rational в проектах по созданию ПО, поэтому унифицированный процесс
интересен для подобных организаций. К сожалению, это противоречит ценнос-
ти AM «Общение», согласно которой предпочтение отдается людям и общению,
а не процессам и инструментальным средствам. Если главное в организации — со-
здание документации, то унифицированный процесс может показаться весьма
привлекательным, потому что, применяя его, можно создать много документа-
ции (но ведь можно применить его так, что документации будет мало). Помните:
342 Глава 28 • Применение AM в UP-проекте
унифицированный процесс довольно гибок. Если в организации придается слиш-
ком большое значение созданию документации, то ее культура противоречит цен-
ности гибкого моделирования, где предпочтение отдается работающему ПО, а не
всеобъемлющей документации. В такой организации унифицированный процесс
можно успешно применять, приспосабливать к своим условиям и реализовывать,
но при этом невозможно следовать принципам и методикам AM, потому что та-
кая организация не обладает «гибкой» культурой (см. главу 1, где говорится о том,
когда имеет смысл применять AM). Я считаю, что успех совместного применения
AM и UP в вашей организации во многом зависит от культуры организации, а не
от унифицированного процесса. Вы легко можете применять методики AM для
повышения эффективности моделирования в унифицированном процессе, но для
этого вам нужно преодолеть некоторые сложности, связанные с культурой вашей
организации.
Как это осуществить?
Прочитав эту часть, вы убедились в том, что унифицированный процесс и мето-
дики гибкого моделирования вполне возможно применять совместно. Чтобы до-
биться успеха, ваша организация должна быть способна принять особенности как
UP, так и AM. Именно в этом заключается сложность их совместного примене-
ния, так как организации, применяющие UP, часто используют его как не-гибкий
и предопределенный процесс, в то время как организации, применяющие AM, хо-
тят работать в гибкой манере. На самом же деле гибкому моделированию нужна
именно такая среда. К счастью, унифицированный процесс довольно Гибок и мо-
жет способствовать применению AM, что подтверждается версией UP, представ-
ленной Робертом Мартином (2001), Гарри Эвансом (2001) и Крейгом Ларманом
(2002). Если вы применяете облегченную версию UP, тогда AM и UP совместимы.
В основе и UP и AM лежит идея о том, что программное обеспечение лучше всего
разрабатывать итеративно и инкрементно. Поскольку унифицированный процесс
включает в себя рабочие потоки, связанные с моделированием, можно легко опре-
делить, где следует применить методики AM, для того чтобы повысить эффектив-
ность UP. Это действительно можно сделать, но только в том случае, если ваша
группа и заинтересованные в проекте лица приложат к этому совместные усилия.
Часть
Глядя в будущее
В этой части описываются важные проблемы организации и управления, касаю-
щиеся гибкого моделирования. Сюда входят следующие главы:
► Глава 29: Внедряем гибкое моделирование: преодоление трудностей В дан-
ной главе приводятся проверенные способы внедрения методологии АМ в
вашу организацию. В ней представлены советы для организаций с гибким об-
разом мышления и способы преодоления трудностей, с которыми вы можете
столкнуться.
► Глава 30: Заключение: стремитесь к успеху. В этой главе гибкое моделиро-
вание рассматривается с точки зрения руководства как средство повышения
продуктивности вашей организации. Я также еще раз делаю беглый обзор всей
методологии.
Внедряем гибкое
моделирование:
преодоление
трудностей
Надо делать или НЕ делать.
Не надо ПЫТАТЬСЯ делать.
Мастер Йода
Если вы дочитали книгу до этого места, то наверняка решили использовать гиб-
кое моделирование в вашей организации. В данной главе мы поговорим о том, как
это сделать. Работая консультантом по совершенствованию процессов разработ-
ки ПО и помогая своим коллегам делать то же самое для их клиентов, мне, к счас-
тью (или к несчастью — зависит от точки зрения), довелось приобрести богатый
опыт в этой сфере. В последнее время я в основном помогал организациям приме-
нять принципы и методики AM, искал способы эффективного применения кор-
поративного унифицированного процесса (Амблер, 2001b), а до этого занимался
сбором паттернов процессов (Амблер, 1998; Атцблер, 1999). Одновременно я ак-
тивно общался в Интернете, давая советы и рассматривая проблемы, с которыми
люди сталкивались при применении таких методологий, как унифицированный
процесс фирмы Rational (Кратчен, 2000; Rational Corporation, 2001) и экстре-
мальное программирование (Бек, 2000). В данной главе я хочу поделиться с вами
накопленным опытом, который поможет вам успешно применять AM, избежать
проблем и непонимания, с которыми люди сталкиваются, работая с другими ме-
тодологиями.
Глава состоит из следующих разделов:
• Оцените степень совместимости.
• Добивайтесь простоты.
• Преодолевайте трудности, связанные с организацией и ее культурой.
• Преодолевайте трудности, связанные с реализацией проекта.
• Подумайте о частичном применении AM.
• Как это осуществить?
Оцените степень совместимости 345
Оцените степень совместимости
В данном разделе предполагается, что сотрудники вашей организации способны
принимать разумные решения и готовы рассмотреть и опробовать новые методи-
ки, если они заслуживают внимания. Подождите, подождите! Не спешите перево-
рачивать страницу! Даже если ваша организация не относится к вышеописанным
и страдает от некоторых распространенных проблем, описанных далее в данной
главе, вы все равно можете найти полезную информацию в этом разделе. По соб-
ственному опыту я знаю, что вам необходимо сделать две важные вещи, если вы
хотите принять и эффективно применять гибкое моделирование. Прежде всего вы
должны решить, уместно ли применение АМ в вашей ситуации, то есть понять, в
каком случае оно сработает, а в каком нет. Потом, внедрять АМ следует осторож-
но. Если вы будете внедрять АМ насильно, то скорее всего вам оно не поможет.
Если вы не можете принять АМ полностью (по крайней мере, сейчас), я советую
вам подумать о его частичном применении.
Когда АМ принесет вам пользу
Гибкое моделирование не является панацеей, его нельзя применять в любой ситу-
ации. Даже в идеальных условиях АМ может не сработать. Вы можете совершить
ошибки, внедряя АМ в вашей организации. По опыту знаю, что применение АМ
очень эффективно при наличии следующих факторов:
Вы применяете гибкий подход к разработке ПО. Прочитав главу 1, вы по-
няли, что гибкое моделирование не является самостоятельной методологией. Его
следует применять в рамках другого процесса (например, ХР или UP (Джекобсон,
Буч и Рамбо, 1999)). Для достижения положительных результатов необходимо
наличие совместимости между АМ и этим процессом, иначе вам придется отбро-
сить некоторые из методик, а это уже не будет гибким моделированием. В треть-
ей части этой книги мы рассмотрели совместное применение АМ и ХР, а в четвер-
той — АМ и гибких вариантов UP.
Вы готовы принять базовые принципы и методики АМ. Чтобы иметь право
утверждать, что вы применяете АМ, вы должны принять хотя бы базовые приг
нципы АМ (см. главу 3) и базовые методики АМ (см. главу 5). Вы можете извлечь
пользу из отдельных принципов и методик АМ, однако не сможете достичь синер-
гизма1, присущего АМ в том случае/если оно применяется целиком (см. главу 7),
а также подвергнете моделирование риску, потому что отдельные методики, при-
нятые вами, должны поддерживаться остальными методиками.
Вы работаете итеративно и инкрементно. Ценность АМ «Общение», а также
принцип «Быстрая обратная связь» обязывают нас подходить к разработке итера-
тивно и инкрементно.
1 Синергизм (от греч. synergeia) здесь трактуется как вариант процесса- с участием нескольких
элементов, характеризующийся тем, что эффект процесса превышает эффект каждого его элемента в
отдельности. — Примеч. науч. ред.
346 Глава 29 • Внедряем гибкое моделирование: преодоление трудностей
Вы сталкиваетесь с нечеткими или изменчивыми требованиями. Мартин
Фаулер (2001а) подчеркивает, что если ваш проект — исследовательский (а таких
большинство), то, вероятнее всего, гибкий подход к разработке — это то, что вам
нужно. Когда требования нечеткие или постоянно изменяются, вам следует при-
менять процесс, который учитывает этот фактор. Ожидая изменений, применяя
инкрементный подход к разработке, поддерживая обратную связь и способствуя
активному участию заинтересованных лиц, гибкое моделирование легко справля-
ется с изменяющимися требованиями, быстро и эффективно их изучая. Обратите
внимание на то, что AM также успешно работает в средах, где требования не изме-
няются, хотя в таких случаях предпочтительнее применение подхода, ориентиро-
ванного на создание документации.
, Ваша главная цель — создание ПО. В этом состоит один из основных принци-
пов AM (см. главу 3), но не для всех проектов эта цель актуальна. Например, иног-
да главная, цель группы — выкачивание денег из заказчиков (посредством при-
влечения внешних ресурсов или субподрядчиков или создания необходимости
проведения консультаций) просто такая спецификация системы, что для ее реа-
лизации можно использовать другую группу. Иногда бывает даже хуже: разработ-
ка просто является политическим трюком для создания видимости выполнения
работы. Целью разработки должно быть создание систем, отвечающих нуждам
пользователей. Эта работа должна быть эффективной. Если перед вами не стоит
подобная цель, тогда гибкое моделирование не для вас.
Вы должны заручиться поддержкой и участием заинтересованных лиц.
Фаулер (2001) также считает, что для успеха гибкой разработки ПО вам необ-
ходимо заручиться поддержкой и участием заинтересованных лиц. Как я уже не
раз говорил в этой книге, заинтересованными лицами являются любые люди, уча-
ствующие в разработке и/или развертывании проекта. К ним относятся прямые
и косвенные пользователи, руководство, высшее руководство, члены группы экс-
плуатации и обслуживания, тестировщики, разработчики, работающие с други-
ми системами, которые интегрируются или взаимодействуют с вашей системой,
и члены группы сопровождения. Чтобы добиться успеха в применении AM, вам
необходимо знать, кто является заинтересованными в вашем проекте лицами. Вам
необходимо ежедневно общаться с теми из них,, кто может сообщить вам необхо-
димую информацию и принять своевременные решения. Вам также нужна под-
держка со стороны руководства. Поддержка со стороны руководства заключается
в наличии достаточных ресурсов, то есть обеспечении всех необходимых условий
для работы (см. главу И), оборудования и специалистов (см. главу 12).
Права и обязанности вашей группы соизмеримы. Гибкая разработка ПО,
а в частности гибкое моделирование, является новшеством для большинства ор-
ганизаций, поэтому применение гибкого подхода часто сопряжено с трудностя-
ми. Я знаю по собственному опыту, что группам необходимо предоставить свобо-
ду действий для того, чтобы они добились успеха или потерпели поражение. Им
нужно позволить попробовать применять новые методы, обеспечить необходимы-
ми ресурсами (включая время), а дальше — все в их руках. В идеале в организации
должно быть поменьше политики (об этом мы поговорим позднее). Это значит,
Оцените степень совместимости 347
что и высшее руководство, и другие группы вашей организации не станут вмеши-
ваться без надобности.
Вам нужны ответственные и желающие работать разработчики. Фаулер
(2001а) подчеркивает, что процесс гибкой разработки ПО требует наличия разра-
ботчиков, обладающих способностью работать совместно для создания качествен-
ного ПО. Это означает, что вам нужна здоровая атмосфера внутри группы, дове-
рие и помощь участников друг другу.-В противоположность тому, что вам .скажут
противники AM, я утверждаю, что вам не нужны люди, творящие чудеса. Вам
просто нужны люди, желающие и умеющие работать вместе. Создавая подобные
группы, вы увеличиваете шансы того, что ваша организация предоставит группе
возможность самостоятельно творить свою судьбу. Мы говорили о группах гибко-
го моделирования в главе 12.
В вашей организации есть сторонники применения AM. Применение чего-
либо нового всегда связано со сложностями. Люди не любят перемен. Они вполне
довольны не-гибкими способами работы, к которым привыкли. Они имеют иные
взгляды на вещи или просто не видят проблем, которые вы пытаетесь решить
с помощью AM. Возможно, они хотят применять собственные любимые подходы
к разработке, которые несовместимы с AM. Возможно, AM угрожает существу-
ющей иерархической структуре организации. Как бы ни складывалась ситуация,
всегда найдутся противники перемен. Для достижения успеха при внедрении нов-
шеств (в данном случае — AM) необходимо наличие сторонников, которые гото-
вы сотрудничать с заинтересованными лицами, отстаивать AM и прививать его
в вашей организации. Для изменений требуется время, а для того чтобы вам пре-
доставили это время, вам нужна поддержка сторонников.
У вас достаточно ресурсов. Вы видите, что гибкое моделирование требует тес-
ного сотрудничества. Это значит, что вам необходимо место для совместной рабо-
ты: специальное помещение для моделйрования, стена, на которой можно разме-
щать модели, и даже общие рабочие станции для работы в парах. Вам также нужны
средства моделирования (белая доска, карточки, маркеры и CASE-средства). Я не
раз сталкивался с ситуациями, когда недостаток ресурсов (отсутствие нормаль-
ных стульев, еды, напитков и хороших рабочих станций) ужасно тормозил процесс
разработки. Если ваша группа едва сводит концы с концами, возникает вопрос:
«Заинтересована ли ваша организация в этом проекте?» Если нет, прекратите ра-
боту над ним и займитесь чем-нибудь более продуктивным. Это касается организа-
ций, где люди вынуждены ждать, пока системный администратор отладит все необ-
ходимое для работы. Однажды системный администратор настраивал мою машину
в течение полутора месяцев — если бы я работал в этой организации постоянно, это
было бы нормально, но у меня был контракт всего лишь на два месяца.
Когда AM вам не поможет
Подозреваю, что вы столкнетесь с проблемами, пытаясь применить AM в следую-
щих ситуациях:
1. В вашей организации отсутствуют один или несколько вышеперечислен-
ных факторов.
348 Глава 29 • Внедряем гибкое моделирование: преодоление трудностей
2. Ваша организация склоняется к предопределённым процессам. Некото-
рые организации просто не заинтересованы в применении гибкого подхо-
да к разработке ПО. Их вполне устраивает существующий порядок вещей,
и им больше ничего не надо. Обычно это правительственные организации,
большие государственные учреждения (некоторые банки, страховые ком-
пании, телекоммуникационные фирмы и т. д.) и консультационные служ-
бы, специализирующиеся на обслуживании этих организаций. Это вовсе не
значит, что в них вообще невозможно применять АМ, но это можно будет
сделать только в том случае, если вы найдете способ избавиться от жесткого
вышестоящего контроля.
3. У вас большая и/или рассредоточенная группа. Лучше всего для гибкого
моделирования подходят группы, сосредоточенные в одном месте, идеаль-
но — в одном помещении. Вы можете попробовать применять АМ в боль-
ших или разрозненных группах, но столкнетесь с трудностями удаленного
• общения. Эта проблема рассматривается далее в этой главе. 1
Я бы также не стал применять АМ для разработки систем, от которых будет
в дальнейшем зависеть жизнь людей (например, систем контроля авиаперевозок
или систем наблюдения за здоровьем пациентов). Я никогда не работал над по-
добными проектами и не имею представления о том, насколько применимо АМ
в таких случаях. Это вовсе не значит, что АМ не сработает в этом случае, но я по-
дозреваю, что необходимость создания документации в подобного рода проектах
потребует от вас применения менее гибкого подхода (и это правильно). Я также
не работал со встроенным ПО и поэтому не имел возможности применять гибкое
моделирование в проектах такого типа. Я подозреваю, что АМ вполне примени-
мо для создания встроенного ПО, но это не более чем предположение. Буду очень
рад, если вы поделитесь своим опытом в этом отношении — оставьте сообщение
на www.agilemodeling.com/feedback.htm.
Добивайтесь простоты
Итак, как же вы поступите, если ваша ситуация не является идеальной? На са-
мом деле идеальных ситуаций не бывает (во всяком случае, я такой никогда не
видел). Я советую во всем добиваться простоты — для этого следуйте принци-
пам и методикам АМ. Для начала займитесь «просветительской работой» среди
разработчиков и заинтересованных лиц — дайте им почитать эту книгу или про-
ведите семинар. Пообщайтесь с ними, поработайте вместе, чтобы выяснить, где
можно полностью (или частично) применять АМ. Вам не нужно создавать офи-
циальную группу, отвечающую за выбор процесса разработки ПО (ее еще назы-
вают группой усовершенствования процесса), — гораздо лучше обсудить это за
кружкой-другой пива.
. Также учтите, что принять решение о применении АМ (как и любого друго-
го процесса) нелегко. Вам нужно набраться смелости, чтобы изменить среду раз-
Преодолевайте трудности, связанные с организацией и ее культурой 349
работки1, а для этого вам необходимо заручиться поддержкой заинтересованных
лиц, и особенно — высшего руководства. Определите самую важную для них цель
(например, быстро разработать высококачественное ПО, отвечающее их нуждам)
и покажите, как AM может помочь достигнуть этой цели. Вы должны убедить их
в том, что существуют лучшие способы работы, и попросить их дать вам шанс это
доказать.
Преодолевайте трудности, связанные
с организацией и ее культурой
Когда вы начинаете внедрять AM в организацию, вы можете столкнуться с неко-
торыми трудностями, связанными со структурой и культурой организации. Вот
некоторые из них:
• скептично настроенные разработчики;
• слишком бдительные «надзиратели»;
• власть имущие — бумажные крысы;
• принцип «поваренной книги»;
• неспособность признать свою вину;
• создание излишней документации как страховка «от кирпича».
Скептично настроенные разработчики
Многие люди весьма скептично относятся к новым методам, и я считаю, что это
хорошо, потому что немного здорового скептицизма не помешает. Однако истин-
но профессиональный разработчик программного обеспечения не должен быть
слишком скептичным. Вот некоторые скептические замечания по поводу AM
и мои ответы на них:
1. Мы с этим уже встречались. Ваша правда. Вы действительно с этим уже
встречались. Как я говорил в главе 1 (да и вообще на протяжении всего по-
вествования — надеюсь, что вы это заметили), отдельные принципы и ме-
тодики известны уже давно. Посредством AM они просто превратились
в упорядоченную синергичную методологию. Пусть этот скептицизм не ос-
тановит вас в вашем решении применять AM. Многие разработчики дол-
гое время игнорировали объектно-ориентрованную разработку по тем же
самым причинам.
2. Это просто новомодная выдумка, которая долго не продержится. Надеюсь,
что это не так. Время покажет. Я считаю, что AM не может быть «одноднев-
кой» по ряду причин. Во-первых, AM основано на существующих принци-
пах и методиках, многие из которых вы наверняка уже применяли, но не хо-
1 Как любит говорить Рои Джефрис: «Измените вашу организацию или... измените вашу орга-
низацию».
350 Глава 29 • Внедряем гибкое моделирование: преодоление трудностей
тите в этом признаваться, потому что AM не похоже на привычный процесс
разработки ПО. Во-вторых, как вы убедились, читая эту книгу, AM не толь-
ко вполне совместимо с ведущими методологиями (например, ХР и UP), но
и повышает их эффективность (проверено на практике). В-третьих, мы уже
некоторое время применяем AM в нашей организации (своего рода «поле-
вые испытания»), а самое главное — AM привлекло внимание разработчи-
ков всего мира, о чем свидетельствуют обсуждения на форуме AM.
3. Это вообще не программная инженерия. Все зависит от вашего определе-
ния программной инженерии (точного определения до сих пор не существу-
ет), но с точки зрения людей, знакомых с традиционными/предписывающи-
ми формами программной инженерии, это замечание вполне справедливо.
Ну и что? Существует масса общепризнанных способов программной ин-
женерии, которые на пбверку оказываются недостаточно эффективными
(Джонс, 2000), так может быть, стоит попробовать AM? Вопрос не в том, яв-
ляется ли гибкое моделирование способом программной инженерии, а в том,
помогает ли оно разработчикам повысить продуктивность работы. Очень
часто чашечка крепкого кофе помогала мне повысить продуктивность. Есть
ли что-то общее между чашкой кофе и программной инженерией?
4. Это не проверено. Тоже верно. Единственным доказательством эффектив-
ности AM является личный опыт, и что теперь? Большинство аспектов те-
ории объектно-ориентированной разработки остаются недоказанными, од-
нако она является доминирующей в мире разработки ПО. Скептицизм по
. этому поводу (как и в случае с определением программной инженерии) яв-
ляется не более чем удобным предлогом для того, чтобы не пробовать ни-
чего нового. Организации, решившие ждать доказательств эффективности
того или иного подхода, рискуют задержать свое развитие на 10-15 лет. Что
является более рискованным с этой точки зрения: применять AM или не
применять?
Слишком бдительные «надзиратели»
Многие организации следуют сложившимся процессам и делают это (по крайней
мере, теоретически) в течение многих лет. Это касается^ организаций, которые
стремятсд получить (или уже получили) аккредитацию в соответствии с про-
мышленными стандартами, такими как ISO 900Х (Международная организация
по стандартизации) и модель зрелости возможностей СММ (Институт разра-
ботки программного обеспечения SEI, 1995). Это, как правило, предопределен-
ные процессы с обилием документации. В таких организациях обычно существует
группа, чьей задачей является поддержка и совершенствование процесса разра-
ботки ПО с течением времени. Отчасти их «поддержка» заключается в провер-
ке того, как группа разработчиков следует процессу. Людей, занимающихся этой
работой, обычно пренебрежительно называют «надзирателями». Эти люди могут
быть недостаточно знакомы с AM или гибкими подходами к разработке ПО в це-
лом. Им трудно понять, что методология, основанная на методиках, может быть
Преодолевайте трудности, связанные с организацией и ее культурой 351
в такой же мере эффективна, как и предопределенная. Вместо того чтобы рассмот-
реть новые способы (возможно, более эффективные), они просто не позволяют
применять методики AM. В таких ситуациях я:
• работаю с «надзирателями», чтобы выяснить причины неприятия методик
AM и развеять заблуждения по этому вопросу (см. главу 30);
• облегчаю процесс внедрения AM (методики принимаются постепенно в
рамках текущего процесса);
• определяю потенциальные проблемы процесса и предлагаю применить ме-
тодики AM, способствующие их решению;
• провожу семинар по AM для «надзирателей» и высшего руководства.
Власть имущие — бумажные крысы
В больших организациях довольно часто встречаются IT-специалисты, которые
годами не участвовали, в непосредственной разработке ПО (программировании,
моделировании, тестировании или управлении). Часто эти люди занимаются уп-
равлением инфраструктурой (управление процессом разработки ПО, управление
ресурсами повторного использования, управление программами). Со временем их
участие в проектах сводится к перекладыванию бумажек с места на место. Эти
люди требуют от отдельных лиц или групп отчеты о текущем положении дел, ко-
торые они анализируют и обеспечивают по ним обратную связь. Они устраивают
отчетные собрания для оценки развития проекта и требуют от группы разработ-
чиков метрик или оценки той области, в которой они специализируются (метрики
повторного использования, оценка безопасности или оценка соответствия стан-
дартам данных). Это вовсе не значит, что все эти люди являются бумажными кры-
сами. Я не раз встречал специалистов по повторному использованию, безопаснос-
ти и данным, готовых в любой момент засучить рукава и помочь нашей группе.
Однако у меня есть и печальный опыт работы с ними. Истинные бумажные крысы
просто требовали ту или иную документацию или назначали собрания по рецен-
зированию проекта. Они не приносили пользы, а только мешали.
К сожалению, иногда очень сложно игнорировать таких людей, потому что они,
как правило, занимают руководящие посты. Отказ заполнить для них какую-
нибудь бумажку может повлечь за собой жалобу вышестоящему начальству, а это
выйдет боком группе разработчиков. Когда я сталкиваюсь с власть имущими бу-
мажными крысами, я поступаю следующим образом:
1. Общаюсь. Сначала я пытаюсь поговорить с этим человеком (или людьми),
выяснить их взгляды и обсудить более эффективные способы выполнения
их требований. Это редко помогает, потому что их нелегко переубедить, но
попробовать-то можно? Г
2. Меняю тактику. Я сообщаю заинтересованным лицам о том, как те или
иные требования бумажных крыс могут повлиять на ход проекта, и прошу
их решить эту проблему.
352 Глава 29 • Внедряем гибкое моделирование: преодоление трудностей
3. Отступаю или борюсь. Я принимаю решение о том, следует ли группе под-
чиниться требованиям бумажных крыс или начать борьбу. Борьба означает
трату сил и политических средств, причем в лице бумажных крыс вы нажи-
вете себе опасных врагов.
Принцип «поваренной книги»
Люди, не принимающие активного участия в разработке ПО (в частности, выше-
стоящее начальство), обычно считают, что процесс разработки подобен приготов-
лению пищи по рецепту. Они считают, что если ваша организация следует вы-
бранному процессу, который в мельчайших подробностях описывает все виды
деятельности, связанные с разработкой, то все проблемы решены. В основе подоб-
ных представлений лежит убеждение, что разработка — это наука, и если найти
точный «рецепт», то кто угодно может создать высококачественное ПО (при этом
в срок и без превышения бюджета), просто выполняя действия, описанные в «ре-
цепте». По опыту знаю, что это не так.
Гибкое моделирование показывает, что разработка ПО — это не наука, а скорее
искусство, творить которое могут.лишь умелые мастера. Гибкое моделирование не
дает указаний насчет того, как создать, к примеру, модель Use Case. Оно даже не
обязывает вас ее создавать. Оно советует вам создавать ту модель, которая больше
всего подходит в вашей ситуации («Применяйте нужный артефакт»), и дает вам
право решать, что выбрать. Гибкое моделирование не имеет ничего общего с пова-
ренной книгой. Поэтому сторонники этого принципа вряд ли станут ратовать за
применение АМ. Если я встречаю человека с подобными взглядами, я указываю
ему, что:
• Разработка ПО требует участия опытных профессионалов.
• Большинство разработчиков вряд ли станут следовать слишком подробно-
му процессу, независимо от того, насколько хорошо'он описан.
• Необходимо следовать какому-либо процессу разработки ПО, но он должен
способствовать работе разработчиков, а не ограничивать и обременять их.
• Разработчики не обязательно должны уметь все, но они должны быть гото-
вы учиться.
• АМ можно использовать совместно с предопределенными процессами (мы
убедились в этом, прочитав четвертую часть книги, где описано совместное
применение АМ и UP, который является наиболее популярным предопре-
деленным процессом).
Неспособность признать свою вину
Как в ХР, так и в UP я неоднократно сталкивался с проблемой, когда в случае про-
вала проекта никто не хотел признать свою вину. Обычно в таких случаях люди
видят причину провала в выбранном процессе, которому они следовали (или, ско-
рее, нарушали его). На самом деле процесс здесь ни при чем — виноваты они сами.
Преодолевайте трудности, связанные с организацией и ее культурой 353
Вот наиболее распространенные ошибки, связанные с применением того или ино-
го процесса:
1. Процесс применен не в той ситуации. Люди пытаются применить процесс
в совершенно не подходящей для этого ситуации. Эта проблема побудила
меня к написанию раздела «Когда AM принесет вам пользу», который вы
уже прочитали. Надеюсь, ваша группа не станет применять AM в неподхо-
дящей ситуации.
2. Процесс искажен. Распространенной проблемой, связанной с ХР, является
то, что некоторые группы не принимают ХР целиком. Они терпят пораже-
ния из-за того, что, опуская некоторые методики, они теряют аспекты раз-
работки, основанные на этих методиках. Поэтому я так категоричен по по-
воду применения основных принципов и методик AM. Только это дает вам
право .утверждать, что вы применяете AM. Это не гарантирует вам полное
отсутствие проблем, но их причиной не станет неверное применение мето-
дологии.
3. Процесс не адаптирован к конкретной ситуации. Распространенной про-
блемой, связанной с применением UP, является то, что организации при-
меняют унифицированный процесс фирмы Rational в чистом виде, не по-
, нимая, что его следует адаптировать к своей среде. Можно совершить
' такую же ошибку, применяя AM (особенно, если не следовать принципу
«Приспосабливаем по месту»).
Многие организации успешно применяют AM, но это не значит, что AM сра-
ботает в любой ситуации. Если у вашей группы возникли проблемы, не вините
в этом AM. Перефразируя известное высказывание — «В провале проектов винов-
ны не процессы, а люди»1.
Создание излишней документации
как страховка «от кирпича»
Во многих организациях боятся того, что с уходом группы разработчиков или ее
большей части будет утрачена важная информация, которая нигде не записана.
Существует несколько причин, по которым вы можете потерять вашу группу:
• Конкурирующая организация переманивает вашу группу, чтобы в срочном
порядке запустить собственный проект.
• Некоторые разработчики постоянно меняют место работы, не задерживаясь
на одном месте.
• Вы сами распускаете группу, когда работа над проектом подошла к концу.
Чтобы решить эту проблему, вышестоящее руководство требует создания огром-
ного количества документации, чтобы в случае ухода группы они могли сформи-
ровать другую и передать им эту документацию. Звучит хорошо, но на деле себя
не оправдывает. Во-первых, документация действительно может помочь в такой
1 «Людей убивает не оружие, а люди» (Национальная стрелковая ассоциация, США).
12 Зак. 926
354 Глава 29 • Внедряем гибкое моделирование: преодоление трудностей
ситуации, но новая группа разработчиков вряд ли примет ее на веру. Они, конечно,
заглянут в нее, чтобы выяснить общую картину, но все подробности они будут вы-
яснять непосредственно в коде. Другими словами, они, вероятнее всего, исполь-
зуют малую ее часть в качестве обзорной документации по системе. Во-вторых,
создание документации на случай потери группы часто именно к этому и приво-
дит. Вы требуете от разработчиков написания огромного количества документа-
ции, потому что боитесь, что они могут покинуть вас в любой момент, а они в свою
очередь решают уйти из-за вашего бюрократического подхода, отсутствия дове-
рия и должного внимания к разработке ПО.
В данной ситуации я бы попытался поговорить с людьми, которые требуют до-
кументацию, и предложить им более гибкий подход. Я знаю по опыту, что при со-
здании качественного описания системы для разработчиков, которые будут со-
провождать и совершенствовать систему в будущем, вполне достаточно четкого
исходного кода и соответствующих моделей соглашения. В главе 14 приведены
способы создания гибкой документации.
Преодолевайте трудности, связанные
с реализацией проекта
Многие группы разработчиков сталкиваются не только с трудностями, связанны-
ми с культурой организации, но и с трудностями реализации конкретного проекта.
Вы можете столкнуться со следующими проблемами:
• группа рассредоточена в разных местах;
• передача работы другим группам;
• контракт с фиксированной ценой.
СОВЕТ: ВАШ ПРОЕКТ НЕ ЯВЛЯЕТСЯ ИСКЛЮЧЕНИЕМ-----------------------;---
Мне часто доводилось слышать: «Мы бы с радостью применяли XYZ, но, к сожалению, это
нам не подходит». Ерунда! С прискорбием извещаю, что ваш проект ничем не отличается
от остальных. Безусловно, вам необходимо будет преодолеть некоторые сложности. Конечно
же, дело это нелегкое. Однако это не является поводом для отказа от способов повышения
эффективности, так что перестаньте искать причины, по которым вы не можете применять AM,
и начните искать способы его применения.
Группа рассредоточена в разных местах
Во время работы над любым проектом может случиться так, что группа будет рас-
средоточена в различных местах: Возможно, в вашей организации введен гибкий
график работы, позволяющий разработчикам частично или полностью работать
на дому. Возможно, работа над вашим проектом ведется в разных направлениях,
и организация делится на подгруппы. Возможно, ваш проект охватывает множе-
ство организаций, и группы рассредоточены по всему миру. В таких ситуациях
вам не удастся собрать разработчиков и заинтересованных лиц в одном месте и со-
Преодолевайте трудности, связанные с реализацией проекта 355
здать условия для общения, которое так необходимо для гибкого моделирования.
В таких ситуациях можно попробовать сделать следующее:
1. Соберите группу в одном месте. Иногда группа рассредоточена в разных
местах по совершенно неразумным причинам. Возможно, работа ведется
в разных местах по политическим причинам (это часто происходит с пра-
вительственными проектами или когда работа ведется в нескольких орга-
низациях одновременно). Вам придется задать себе некоторые вопросы.
Действительно ли необходимо рассредоточить группу разработчиков или
этого можно избежать? Можно ли сосредоточить вашу группу в одном мес-
те для работы над проектом? Можно ли реорганизовать существующие
группы в одну, которая будет совмещать в себе всех людей, обладающих не-
обходимыми навыками?
2. Выберите процесс, поддерживающий удаленное сотрудничество. Вы-
бранный вами процесс должен поддерживать удаленную разработку ПО.
Это касается не только гибкого моделирования. Выбранный вами про-
цесс должен описывать, как преобразовать ваш проект в некое множество
. подпроектов, в которых применение АМ будет возможно. В главе 27 рас-
сматривается моделирование в рабочем потоке корпоративного унифици-
рованного процесса «Управление инфраструктурой». Этот рабочий поток
описывает деятельность групп программистов, рассредоточенных в разных
местах, и управление такими группами.
3. Используйте инструментальные средства для совместной работы. Суще-
ствует множество инструментальных средств, включая средства для мо-
делирования, создания текстовых документов, обсуждения, проведения
конференций и виртуальных собраний, которые можно использовать для
обеспечения работы рассредоточенных групп. Эти средства описаны в
главе 8.
4. Вам нужен «путешественник». «Путешественник» — это человек, который
, способствует общению между удаленными группами. Он постоянно переез-
жает, поочередно работая то с одной, то с другой группой. Путешественники
выступают в роли активных членов группы, когда находятся «на объекте»
и предоставляют информацию о проекте от других групп. Путешественники
зачастую реализуют методику «Формализуйте модели соглашения», ког-
да различные подгруппы определяют интерфейсы, обеспечивающие рабо-
чее взаимодействие с ними. В этой роли обычно выступают люди, имеющие
высокоуровневое представление о проекте. Хотя поначалу роль путеше-
ственника кажется привлекательной (особенно людям, которые редко ез-
дят в командировки), она достаточно сложна. Подобного рода деятельность
отрицательно сказывается на отношениях с другими людьми, а также тре-
бует выносливости к физическим нагрузкам, обусловленных частыми пе-
реездами и сменой часовых поясов. Что бы вам ни говорили, вы никогда не
сможете к этому привыкнуть по той простой причине, что никогда не смог
жете толком выспаться.
356 Глава 29 • Внедряем гибкое моделирование: преодоление трудностей
Передача работы другим группам
Многим группам разработчиков приходится передавать свою работу другим груп-
пам. Возможно, вы работаете в группе внутри организации или в группе, относя-
щейся к организации-субподрядчику, и вам предстоит передать работу по сопро-
вождению и совершенствованию системы другой группе. Или же вы выступаете
в роли консультанта или подрядчика, приглашенного в организацию на опреде-
ленное время для того, чтобы предоставить полный комплект документации. Вы
передаете документацию людям, которым предстоит работать с ней в дальней-
шем. Эти люди являются заинтересованными лицами, поэтому следуйте методике
«Активное участие заинтересованных лиц», чтобы создать то, что им действитель-
но нужно, и помочь им понять, что вы разрабатываете. Это позволит значительно
сократить объем документации. Более того, активно привлекая заинтересованных
лиц к работе, вы создаете ситуацию, способствующую применению AM.
Проблемы также возникают, когда вы работаете над проектом по частям, кон-
центрируясь на отдельных аспектах проекта. Например, Федеральное правитель-
ство Соединенных Штатов практикует следующий подход: некая фирма получает
контракт на определение требований, которые описывают создаваемую систему
(обычно в таких случаях создается официальная спецификация требований SRS).
Эту спецификацию передают фирме, которая получает право на работу на этапе
конструирования (возможно, это будет та же самая фирма, которая разработала
SRS-спецификацию). Таким же образом решается вопрос о работе на других эта-
пах (например, архитектурное или проектное моделирование). Такой подход явно
противоречит основам гибкой разработки ПО. Во-первых, группа применяет по-
следовательный (линейный), а не итеративный подход. Во-вторых, главной целью
становится создание документации, а не создание ПО. Если вам не избежать по-
добной ситуации, следует пойти на частичное принятие принципов и методик AM.
В такой ситуации вряд ли будут применимы следующие методики AM:
• «Изображайте модели просто», потому что несмотря на ваше стремление
создавать максимально простые модели, вы будете вынуждены создавать
всеобъемлющую документацию.
• «Моделируйте постепенно» и «Подтверждайте модель кодом», потому что
у вас не будет, возможности делать это, находясь в рамках этапа последова-
тельного процесса.
• «Совершенствуйте только в случае необходимости», потому что вам надо
создавать согласованную и полную документацию. С другой стороны, дан-
ная методика все-таки применима, хотя это сопряжено с рядом трудностей.
• «Используйте простейшие инструментальные средства», потому что вам не-
обходимо будет создавать «профессиональную» документацию.
Контракт с фиксированной ценой
Несколько лет назад я выступал на конференции в Бразилии. Во время выступ-
ления мне был задан вопрос по поводу оценки контракта с фиксированной ценой,
Подумайте о частичном применении AM 357
в котором не до конца определены требования. Я ответил, что не занимаюсь кон-
трактами с фиксированной ценой, но я бы предоставил оценку на ближайшие 2-
3 месяца работы вместо 18—24 месяцев, о которых просил заказчик. Моя оценка
была бы приблизительной, а не точной. Человек, задавший этот вопрос, ожидал
иного ответа. На протяжении всей конференции он задавал этот же вопрос дру-
гим выступающим и получал аналогичный ответ. Все выступающие были очень
опытными разработчиками, проработавшими в этой сфере более 20 лет. Все они
принадлежали к разным школам разработки и придерживались различных убеж-
дений, но из того, что я слышал, было понятно, что никто из них не считал конт-
ракт с фиксированной ценой хорошей идеей.
Контракты с фиксированной ценой заключаются в том случае, когда заинте-
ресованные в проекте лица хотят установить финансовые ограничения для вашей
группы, чтобы избежать превышёния бюджета. Сторонники экстремального про-
граммирования называют это «играть наверняка» (Бек, 2000). Контракты с фик-
сированной ценой обычно навязываются подрядчикам, которые берут на себя
руководство проектом, оставляя лишь небольшие права по управлению членам
вашей организации (хотя косвенный контроль все равно остается). Внутренние
проекты с фиксированной ценой довольно распространены в организациях с жес-
тким распределением бюджета или в тех организациях, которые сталкивались со
значительным превышением бюджета в прошлом.
На самом деле в контракте с фиксированной ценой нет ничего страшного, если
вы можете контролировать остальные аспекты работы. Руководители проекта
часто говорят о «железном треугольнике» планирования — стоимость, рамки сис-
темы и качество. Вы можете контролировать лишь два аспекта из трех. Поскольку
стоимость оговорена контрактом, а гибкое моделирование обуславливает качест-
во (принцип «Качественная работа»), вам придется проявить гибкость в опреде-
леции рамок системы, то есть функциональных возможностей, которые вы созда-
дите за эту цену. К сожалению, на деле все иначе, потому что люди, заключающие
контракт, хотят определить все три пункта. Они хотят знать, что получат за эти
деньги, и, безусловно, хотят, чтобы работа была выполнена качественно. Лучше
всего будет, если вы объясните им эту идею и попытаетесь убедить их в том, что
ситуацию можно изменить, если учесть следующие моменты:
• примерную оценку стоимости (например, 500 000± 100 000 долларов);
• выполнение работы поэтапно/итеративно (оценивать их тоже постепенно);
• невысокий уровень временных и материальных затрат должен покрыть рас-
ходы и премии, полагающиеся за создание высокоэффективных функцио-
нальных возможностей.
Подумайте о частичном применении AM
Применяя AM в вашем проекте, вы, вероятно, столкнетесь с определенными труд-
ностями. Некоторые вам удастся преодолеть, а с некоторыми придется смириться.
Вы можете обнаружить, что даже изменив все, что только возможно, вы все равно
358 Глава 29 • Внедряем гибкое моделирование: преодоление трудностей
не можете полностью применить АМ. Поэтому выберите один из следующих ва-
риантов:
1. Примите АМ частично. Вы можете применять те принципы и методики,
которые допустимы в вашем случае. Вы не сможете утверждать, что зани-
маетесь гибким моделированием, но это повысит продуктивность вашей
работы. Когда в вашей организации поймут, что существуют более продук-
тивные способы разработки ПО, найдется возможность изменить те факто-
ры, которые мешают применять гибкое моделирование целиком. Другими
словами, внедряйте новые методологии постепенно.
2. Оставьте идею о применении АМ в вашей организации. Лично мне не
очень нравится это предложение, но должен признаться, оно весьма разум-
но. На самом деле АМ подходит не всем, и возможно, это касается именно
вашей организации.
3. Начните искать новое место работы. Существует множество организаций,
в которых стремятся добиться успеха в разработке ПО, и им нужны разра-
ботчики, готовые эффективно работать.
Как это осуществить?
Мой совет: пытайтесь найти способы применения АМ, а не ищите причины не
применять его.
Заключение:
стремитесь
к успеху
Даже небольшие изменения устоявшихся убеж-
дений и ценностей со временем могут сильно
изменять социальное поведение и результаты.
Возможно, это единственный способ что-либо
поменять.
Ди Хок
Многие люди, читая заключение, думают, что на этом все заканчивается. На самом
деле, все только начинается. Все только начинается? Я надеюсь,, что, прочитав эту
, книгу, вы получили некоторое представление о новых эффективных методиках
моделирования и разработки. Все только начинается, потому что теперь вы начне-
те применять полученные знания в своей работе.
Прежде чем вы отложите эту книгу и приступите к работе, давайте рассмот-
рим несколько важных вопросов. Во-первых, я хочу развеять некоторые заблуж-
дения, которые могли возникнуть у вас или у ваших коллег. Во-вторых, я хочу
помочь вам определиться с тем, что является гибким моделированием, а что нет.
В-третьих, я перечислю несколько полезных информационных ресурсов, которые
помогут вам принять AM и применять его в вашей организации. И наконец, я ска-
жу вам пару слов на прощание.
Заблуждения, связанные с AM
Принимая участие в дискуссиях в Интернете (списки рассылки и группы ново-
стей) и работая с клиентами, я понял, что многие люди заблуждаются по поводу
AM. Дело в том, что тогда мое определение гибкого моделирования было не сов-
сем ясным, да и книга еще не появилась в продаже. Давайте рассмотрим эти за-
блуждения еще раз (я кратко изложил их в табл. 30.1), поскольку они продолжают
владеть умами многих разработчиков.
360 Глава 30 • Заключение: стремитесь к успеху
Таблица 30.1. Заблуждения, касающиеся АМ
Заблуждение На самом деле
Специалисты (бизнес- аналитики, специалисты по архитектуре и т. д.) не могут заниматься гибким моделированием На самом деле в гибком моделировании предпочтение отдается универсалам, обладающим несколькими специализациями (см. главу 12), но это не значит, что остальные не могут этим заниматься. Специалисты (например, бизнес-аналитики) могут быть весьма полезны, когда вам нужны люди для работы с заинтересованными лицами, не являющимися членами группы, а специалисты по созданию архитектуры очень помогут в начале проекта при определении варианта архитектуры
Вы не рецензируете/не можете рецензировать гибкие модели Хотя в этой книге не затрагивался вопрос о рецензировании моделей или документации, я не вижу причин, по которым вы не можете этого сделать. Рецензирование следует проводить, - руководствуясь принципом «Содержание важнее формы», а сеансы рецензирования лучше проводить так же, как и сеансы моделирования, описанные в главе 13
АМ высечено в камне Отчасти это так, потому что для того, чтобы утверждать, что вы занимаетесь гибким моделированием, вы должны принять хотя бы основные методики (глава 29). Однако по части применения этих методик вы получаете полную свободу. Например, АМ предлагает вам применять нужный артефакт, но не говорит, какой именно (в приложении А приведены некоторые из них)
Вы не используете CASE- средства Специалисты по гибкому моделированию следуют методике «Используйте простейшие инструментальные средства». Иногда простейшим является CASE-средство (см. главу 10)
Специалисты по гибкому моделированию — супер- разработчики с богатейшим опытом Наличие богатого опыта по части моделирования, безусловно, помогает, но не является обязательным требованием. Даже если вы — новоиспеченный разработчик, вы все равно можете следовать принципам и методикам АМ. Гораздо важнее хотеть работать с другими и приобретать новые навыки. Тогда любой разработчик может стать специалистом по гибкому моделированию
Правда и ложь о гибком моделировании
Самой большой проблемой, связанной с применением любых методологий, явля-
ется утверждение многих разработчиков утверждают, что следуют той или иной
методологии, а на самом деле это не так. Это происходит потому, что, сталкиваясь
с проблемами, они винят методологию, хотя все дело в том, что они неверно ее при-
меняли. Как я уже говорил в главе 29, с подобной проблемой сталкивались и ХР
(Бек, 2000), и UP (Джекобсон, Буч и Рамбо, 1999). Я бы хотел попытаться избежать
этой проблемы с АМ. Хотя сначала вы решаете, принимаете ли все базовые мето-
дики АМ (см. главу 6) или нет, не всегда понятно, применяете ли вы их. Поможет
вам с этим разобраться табл. 30.2, в которой представлены факторы-индикаторы
гибкого моделирования (все из них должны присутствовать). В табл. 30.3 приве-
дены факторы, которые помогут вам понять, что вы не занимаетесь гибким моде-
лированием (на самом деле достаточно одного из них).
Правда и ложь о гибком моделировании 361
Важно отметить, что если в силу внешних причин гибкое моделирование запре-
щено, вы все же можете применять многие принципы и методики AM в текущем
проекте. Однако то, что вы моделируете на белой доске, вовсе не означает, что вы
занимаетесь гибким моделированием. Это просто моделирование на белой доске.
Таблица 30.2. Факторы, свидетельствующие о том, что вы занимаетесь гибким моделированием
Vх Фактор
Ваши клиенты/заказчики активно участвуют в работе по определению требований и/или
анализу
Изменения требований приветствуются и учитываются в дальнейшей работе. Требования
«не замораживаются»
Прежде всего вы работаете над самыми важными требованиями, указанными
заинтересованными лицами, и соответственно — самыми важными проблемами по мере
работы
Вы применяете итеративный и инкрементный подходы к моделированию
Прежде всего вы занимаетесь разработкой ПО, а не созданием документации или моделей
Вы моделируете в группе, где важна работа каждого участника
Вы стараетесь добиваться простоты. Для работы вы используете простейшие
инструментальные средства и создаете простейшие модели
Вы избавляетесь от большинства (если не от всех) моделей по мере разработки
Заказчики принимают бизнес-решения; разработчики — технические
Содержание модели важнее, чем ее форма/представление
Во время моделирования вы постоянно задаете себе вопрос: «Как мы это протестируем?»
Таблица 30.3. Факторы, свидетельствующие о том, что вы не занимаетесь
гибким моделированием
Фактор
Ваша цель — создание документации (например, документирование требований) для
заинтересованных лиц или для предоставления другой группе
Вы используете CASE-средства для определения архитектуры и/или проектирования
системы, НО не используете их для создания части системы или системы полностью
Ваши пользователи/заказчики почти не участвуют в работе. Например, они участвуют
в определении первичных требований или только отвечают на вопросы по.мере их
возникновения, а также принимают участие в приемке системы
Вы не работаете с несколькими моделями одновременно. Типичными примерами
работы являются «моделирование элементов Use Case», «моделирование классов»
или «сеансы моделирования данных». Иначе говоря, вы используете «разработчиков
одного артефакта» (разработчики специализируются на чем-то одном — например,
моделировании данных или моделировании пользовательского интерфейса). В AM работу
выполняют универсалы
Вы склоняетесь к «замораживанию» одной или более моделей. Другими словами, вы
применяете последовательный (линейный) подход
362 Глава 30 • Заключение: стремитесь к успеху
Ресурсы для гибкого моделирования
Эта книга не является единственным источником информации о гибком модели-
ровании. Существует еще несколько сайтов:
Сайт гибкого моделирования. На сайте www.agilemodeling.com я продолжаю
рассказ о методологии AM и привожу ссылки на другие информационные ресур-
сы о гибком моделировании и разработке ПО.
Список рассылки гибкого моделирования. Каждый из вас может подписать-
ся на рассылку информации о гибком моделировании. Подробности на сайте
www.agilemodeling.com/feedback.htm.
Мастер-класс гибкого моделирования. Во время трехдневного мастер-класса
участники работают над созданием реальной системы и применяют принципы
и методики AM для создания разнообразных артефактов. Дальнейшую информа-
цию можно получить на сайте www.ronin-intl.com/services/.
Кроме того, я прошу других авторов поделиться своим опытом применения
AM на практике. Я думаю, что должны появиться книги о применении AM в дру-
гих процессах (не только в ХР или UP), а также о совместном применении прин-
ципов и методик AM и других методологий моделирования, например ICONIX
(Розенберг и Скотт, 1999) или Catalysis (Д’Суза и Уиле, 1999).
Несколько слов на прощание
Я могу лишь показать тебе дверь, но войти в нее
' ты должен сам.
Морфеус. «Матрица»
Я знаю по опыту, что самое сложное — это принять решение стремиться к успеху.
Для успешного применения AM придерживайтесь следующих (возможно, непро-
стых) рекомендаций:
• Тесно сотрудничайте с заинтересованными лицами и добивайтесь того, что-
бы они принимали активное участие в разработке (даже если они сами не
очень хотят участвовать или встречаться с ними сложно).
• Тесно сотрудничайте с другими разработчиками (в идеале вы должны ра-
ботать совместно и на одной территории), даже если в вашей организации
приветствуется индивидуальная работа.
• Научитесь создавать различные модели и стремитесь к освоению новых ме-
тодик, даже если вы предпочитаете специализироваться на чем-то одном.
• Переходите от модели к модели и от артефакта к артефакту (включая ис-
ходный код), даже если от вас требуют создавать каждую модель отдельно,
доводя ее до идеала.
• Направьте свою работу на создание ПО, даже если другие члены вашей ор-
ганизации принуждают вас писать обширную документацию или выпол-
нять больше бумажной работы, чем это необходимо.
Несколько слов на прощание 363
• Ожидайте изменений и действуйте в соответствии с ними, даже когда вам
очень захочется «заморозить» требования. В этом случае вы будете знать
точно, что необходимо разработать. .
• Создавайте просто хорошие модели при помощи простых средств и рабо-
тайте с ними, даже если другие группы, в вашей организации тратят время
на создание «красивых» моделей с помощью электронных инструменталь-
ных средств.
Поначалу AM может сбить с толку. Многие поражены тем количеством арте-
фактов моделирования, которые вам нужно научиться создавать. В приложении А
описано более 30 различных артефактов. Не переживайте. Совершенно не обяза-
тельно знать их все, чтобы начать работать. Скорее всего, вы остановитесь на не-
которых из них. Если вы готовы научиться новым методикам, .вы очень скоро об-
наружите, что ваша копилка знаний и умений растет.
Вы также обнаружите, что AM поначалу требует дисциплины (например, когда
нужно прекратить моделировать после того, как модель выполнила свою задачу,
или перейти к другому артефакту, если вы «застряли» на текущей модели). Эта
дисциплина необходима не потому, что AM — штука сложная, а потому, что вы
приобретаете новые навыки моделирования, а это требует сил и времени. Когда
вы их приобретете, AM станет гораздо проще. Просто наберитесь терпения. Здесь
уместно провести аналогию с детьми, которые учатся ходить: сначала им это труд-
но дается и требует больших усилий, но по мере приобретения опыта они начина-
ют быстро ходить и даже бегать, а потом делают это бессознательно. Если вы стре-
митесь к успеху, то довольно быстро научитесь легко и эффективно применять
гибкое моделирование.
Приложение А
Методики моделирования
Этот раздел содержит справочную информацию о распространенных методиках
моделирования, которые гибкие разработчики могут применять при разработке
проектов. Читая эту информацию, учтите, что:
' 1. Это далеко не все методики, которые вы можете применять. Хотя этот
список включает в себя множество различных методик, он не является пол-
ным (впрочем, я и не ставил перед собой такую цель — создать полный
список). Существуют сотни методик моделирования, которые вы можете
применять для разработки проекта. Здесь я описываю наиболее распро-
страненные из них. Важно понять, что существует гораздо больше методик
моделирования, нежели предлагается многими методологиями моделиро-
вания или стандартами языков моделирования, поэтому не бойтесь приме-
нять новые нестандартные методики, которые вам может предложить ваш
коллега.
2. Методики просто обобщены. Я ставил перед собой задачу просто обоб-
щить информацию о методиках моделирования и указать вам источники
получения более подробной информации о них. Я не намеревался научить
вас применять ту или иную методику. Таблица А.1 поясняет назначение по-
лей, описывающих каждый артефакт моделирования. В табл. А.2 приведе-
ны различные артефакты и методики моделирования.
3. Вам необходимо узнать больше о различных методиках моделирова-
ния. Чем больше артефактов моделирования вы знаете, тем больше веро-
ятность того, что вы будете применять нужный артефакт для выполне-
ния работы.
4, Описание методик основано на опыте. В основу описания методик поло-
жен многолетний опыт работы над различными проектами вашего покорно-
Приложение А • Методики моделирования 365
го слуги и моих коллег из Ronin Internationa], Проекты были различными,
каждый из них был уникален в своем роде, и поэтому мы применяли раз-
личные методики по-разному в зависимости от проекта. Другими словами,
будьте готовы переработать эти методики в соответствии с каждым отдель-
ным проектом.
Таблица А.1. Как организована таблица, обобщающая артефакты
Графа Объяснение
Описание Описание артефакта моделирования
Применение Применение того или иного артефакта при разработке бизнес-приложений
Распространенные ошибки- в применении Распространенные ошибки в применении того или иного артефакта, которые приводят к возникновению сложностей в работе или ее переделыванию; они возникают из-за того, что для решения задачи выбран неверный артефакт. Самая распространенная ошибка (излишняя детализация и сложность) не отмечается, поскольку касается всех артефактов. Даются советы по разрешению проблем, связанных с неправильным использованием
Перейти к Варианты для перехода от данного артефакта к другому, соответствующие методике «Переходите от одного артефакта к другому»
Инструментальные средства для создания Слисок средств для поддержки того или иного артефакта. Вот некоторые из них: • Средство для создания диаграмм (например, Microsoft Visio или CorelDraw) • Набросок (например, на белой доске) • Карточки • Средство моделирования (например, Together фирмы Together Soft или Citerra фирмы Canyon Blue) • Бумага • Стикеры
Когда следует превращать модель в постоянную? Советы о том, когда имеет смысл сохранять эту модель. Но не забывайте о принципе «Путешествуйте налегке» и не поддерживайте модель без необходимости. Здесь же приводятся оценки степени пригодности артефакта для дальнейшей работы (высокая, средняя, низкая)
366 Приложение А • Методики моделирования
Таблица А.2. Методики моделирования
Артефакт Описание Применение
1 2 3
UML-диаграмма деятельности UML-диаграмма деятельности (Рамбо, Джекобсон и Буч, 1999; Фаулер и Скотт, 1999;- Амблер, 2001а) используется для моделирования высокоуровневых процессов или переходов между состояниями класса. Деятельность может быть и бизнес-процессом, и техническим процессом (например, набором операций, реализуемых классами или компонентами) Анализ или проектирование бизнес-процесса или бизнес- правила. Проектирование логического потока сложной операции. Изображение логики элемента Use Case, сценария использования или истории заказчика
Определение Бизнес-правило (Росс, 1997; Уигерс, 1999; Определение требований
бизнес-правила Амблер, 2001а) — это принцип или правила
работы, которым должно соответствовать ваше
ПО. Обычно описывает доступ, управление,
вычисление бизнес-задач или политику
организации
Вариант изменений Вариант изменений (Беннет, 1997; Амблер, Изучение требований, 2001а) используется для описания новых которые могут возникнуть требований к системе мли при внесении в будущем изменений в уже существующие требования
UML-диаграмма UML-диаграмма классов (Рамбо, Джекобсон
классов и Буч, 1999; Фаулер и Скотт, 1999; Амблер,
- 2001а) изображает классы, их статичные
отношения (включая наследование, агрегацию
и ассоциацию) и операции и атрибуты классов
Концептуальное
моделирование.
Моделирование предметной
области. Проектирование
структуры объектно-
ориентированного ПО.
Детальное проектирование
внутренних частей
компонента
Приложение А • Методики моделирования 367
Распространенные Инструмен- ошибки Перейти к тальные средства в применении для создания Когда следует превращать модель в постоянную?
4 5 б 7
Неизвестны • Приемочный тест 1. Набросок (Низкая степень
• Диаграмма классов 2. Инструментальное пригодности.) Нужна
• Сущностный элемент Use Case средство для рисования для высокоуровневого обзора логики бизнес-
• Организационная диаграмма • Исходный код • Системный элемент Use Case • Сценарий использования • Диаграмма Use Case • Истории пользователя 3. CASE-средство процесса
Документирование • Приемочный тест 1. Текстовый (Средняя степень
технических • Диаграмма классов редактор пригодности.)
требований • CRC-модель 2. Карточки Необходимо в случае,
• Сущностный элемент Use Case • Диаграмма потоков данных • Глоссарий • Исходный код • Системный элемент Use 3. CASE-средство если заинтересованные лица хотят получить точные определения бизнес-правил в виде документа
Case,
• Сценарий использования
Обоснование • Ограничение 1. Карточки (Низкая степень
избыточности • CRC-модель 2. Текстовый пригодности.)
системы для учета • Технические редактор Необходим в слу-.
возможных будущих требования чае, если вам нужно
требований • Сценарий обосновать заинте-
использования ресованным лицам
• Элементы Use Case решения архитектуры
t • История пользователя или проектирования
и ТОЛЬКО если они
требуют этот документ
Моделирование физи- •' Диаграмма 1. Набросок (Низкая степень
ческой базы дан- сотрудничества 2. CASE-средство пригодности.)
ных. Создание доку- - • Диаграмма компонентов 3. Карточки, Необходима для того,
ментации по модели • CRC-модель соединенные при чтобы предоставить
предметной области • Модель данных помощи струн объяснение внутренней
(они часто не понима- • Глоссарий структуры ПО
ют нотацию). Только • Диаграмма последова-
диаграммы проекта- тельности
рования для объектно- • Исходный код
ориентированного ПО • Диаграмма состояний
(используются различ- • Сценарий использования
ные модели) • История пользователя
Продолжение &
368 Приложение А • Методики моделирования
Таблица А.2 (продолжение)
1 2 3
Карточки Класс- Обязанность- Сотрудничество (CRC) Модель «Класс-Обязанность-Сотрудничество» Совместное с заинтере- (CRC) (Бек, 2000; Амблер, 2001а) представляет сованными лицами собой набор обычных карточек, каждая моделирование предметной из которых разделена на три части, области и концептуальное указывающие: имя класса, обязанности класса моделирование. Объяснение и сотрудничество с другими классами проектирования структуры объектно-ориентированного ПО
UML-диаграмма сотрудничества UML-диаграмма сотрудничества (Рамбо, Изучение динамичной Джекобсон и Буч, 1999; Фаулер и Скотт, природы сложных объектов 1999; АМблер, 2001а) дает представление о или взаимодействия нескольких сотрудничающих объектах, которые, компонентов работают вместе для достижения одной цели. Диаграммы сотрудничества показывают поток сообщений между объектами в объектно- ориентированном приложении, а также выражают основные ассоциации (отношения) между классами
Компонентная диаграмма UML Компонентная диаграмма UML (Рамбо, Проектирование Джекобсон и Буч, 1999; Фаулер и Скотт, 1999; высокоуровневой Амблер, 2001а) отображает компоненты структуры бизнес-архитек- системы, их интерфейсы и отношения между туры для компонентной компонентами . системы. Проектирование высокоуровневой 'структуры технических компонентнов или подсистем
Приложение А • Методики моделирования 369
4 5 6 7
Неизвестны • Приемочный тест • Бизнес-правило • -Вариант изменений • Ограничение • Диаграмма классов • Сущностный элемент Use Case • Глоссарий • Организационная диаграмма • Исходный код • Системный элемент Use Case • Сценарий использования • Диаграмма Use Case • История пользователя 1. Карточки Обычно выбрасываются, когда работа с ними закончена
Для изучения по- • Диаграмма классов 1. Набросок (Низкая степень
следовательности взаимодействий объектов (для этого лучше использовать диаграмму по- ( следовательности) • Компонентная диаграмма • Диаграмма размещения • Диаграмма устойчивости • Исходный код • Системный элемент Use Case • Сценарий использования • Диаграмма потоков пользовательского интерфейса • Прототип пользо- вательского интерфейса • История пользователя 2. CASE-средство пригодности.) Обычно выбрасывается, когда работа с ней закончена (хотя может быть сохранена для того, чтобы отражать проектную структуру сложной части ПО)
Неизвестны \ '•—С • Диаграмма сотрудничества • Диаграмма классов • Диаграмма размещения • Диаграмма последова- тельности • Исходный код 1. Набросок 2. Карточки, соединенные струнами 3. CASE-средство (Средняя степень пригодности.) Диаграмма для обзора архитектуры ПО
Продолжение #
370 Приложение А • Методики моделирования
Таблица А.2 (продолжение)
1 2 3
Определение ограничения Ограничение (Уигерс, 1999; Амблер, 2001а) Определение бизнес- или определяет степень свободы при принятии технических ограничений решения. Ограничения являются самыми важными требованиями к проекту. Ограничения могут быть экономическими, политическими, техническими или касающимися среды, ресурсов проекта, графика, конечной среды или самой системы
Диаграмма данных Диаграмма/модель данных (Рейнгрубер Проектирование физической иТрегори, 1994; Амблер, 2001а) отражает базы данных. Концептуальное объекты данных и их отношения моделирование или моделирование предметной области для хранилища данных. Изучение отношений между различными объектами
UML-диаграмма размещения UML-диаграмма размещения (Рамбо, Джекобсон Определение физической и Буч, 1999; Фаулер и Скотт, 1999; Амблер, архитектуры системы. 2001а) отображает статическое представление Определение того, как ' работающей конфигурации процессорных узлов компоненты ПО развернуты/ и компонентов, которые запускают эти узлы. будут развернуты в Сюда входит аппаратное обеспечение системы, физической архитектуре ПО, которое устанавливается на аппаратуру и промежуточное ПО, используемое для соединения различных машин друг с другом
Приложение А • Методики моделирования 371
4 5 6 7
Определение • Приемочные тесты 1. Карточки (Средняя степень
бизнес-правила • Варианты изменений 2. Текстовый пригодности.)
и определение • CRC-модель редактор Хранится в качестве
технических • Диаграмма размещения официального
требований • Сущностный элемент Use Case • Глоссарий • Исходный код • Системный элемент Use Case • Технические требования • Сценарий использования определения требований
Концептуальное • Приемочные тесты 1. Набросок (Очень высокая степень
моделирование • Диаграмма классов 2. CASE-средство пригодности.)
объектно- ориентированного ПО • Диаграмма потоков данных Для документирования структуры физической
(лучше использовать • Диаграмма размещения базы данных.
диаграмму классов). • Исходный код (Очень высокая степень
Моделирование предметной • Системный элемент Use Case пригодности.) Служит в качестве
области объектно- ориентированного ПО • Сценарий использования модели соглашения между «хозяевами»
(лучше использовать диаграмму классов). Изучение структуры объектно- ориентированного ПО (лучше использовать диаграмму классов). Основной движитель для диаграммы классов • История пользователя • базы данных и другими системами, имеющими доступ к базе данных
Для отражения • Приемочные тесты 1. Набросок (Средняя степень
зависимостей между компонентами ПО • Диаграмма деятельности / 2. CASE-средство пригодности.) Для документирования
(лучше использовать • Диаграмма технической
диаграмму сотрудничества архитектуры системы
компонентов) • Модель компонентов • Ограничение • Модель данных • Спецификация внешнего интерфейса • Диаграмма последова- тельности • Сценарий использования • История пользователя
Продолжение £
372 Приложение А • Методики моделирования
Таблица А.2 (продолжение)
1 2 3
Диаграмма потоков данных (DFD) Диаграмма потоков данных (DFD) (Йордон, Анализ существующих бизнес- 1989; Гейн и Сарсон, 1978; Амблер, 1997) процессов. Проектирование показывает движение данных в системе между новых или усовершен- процессами, объектами и хранилищами данных ствованных бизнес-процессов
Спецификация внешнего интерфейса Спецификация внешнего интерфейса (EI) Модель соглашения, (Линтикум, 2000) моделирует интерфейс. определяющая интерфейс (интерфейсы) для внешней системы. В силу системы (посредством
, того, что доступ к внешним системам можно программного
получить посредством множества средств интерфейса приложения, (программного интерфейса приложения, информационной обратной доступа к файлу или обращения к общей базе связи и т. д.) данных), содержание и формат спецификации внешнего интерфейса может быть различным
Сущностный прототип поль- зовательского Сущностный прототип пользовательского Изучение требований интерфейса (III) (Константайн и Локвуд, к пользовательскому 1999; Амблер, 2001а) является грубой интерфейсу системы не
/ моделью или прототипом пользовательского зависящим от технологии
'i интерфейса системы. В нем представлена способом общая информация о нем, но не указываются подробности
Сущностный элемент Use Case Элемент Use Case представляет собой Определение требований к последовательность действий, которая использованию для системы, предоставляет достаточную информацию Определение корпоративных для актера. Сущностный элемент Use Case требований организации (Константайн и Локвуд, 1999; Амблер, 2001а) является упрощенным абстрактным обобщенным элементом Use Case, содержащим информацию об идеях пользователя вне зависимости от технологии и реализации
Приложение А • Методики моделирования 373
4 5 6 7
Чрезмерно подробная спецификация системы из-за внедрения в подпроцессы с помощью иерархии диаграмм. Трудности в определении баланса между диаграммой потоков данных и под диаграммами потоков данных • Приемочные тесты 1. Набросок (Низкая степень • Варианты изменений 2. Инструментальное пригодности.) • Ограничения средство для Для обобщения полной • Модель данных рисования проектной структуры • Диаграмма 3. CASE-средство системы, насыщенной развертывания процессами • Организационная диаграмма • Структурная диаграмма • Системный элемент Use £ase • Сценарий использова- ния • История пользователя • Диаграмма Use Case
Неизвестны • Диаграмма потоков 1. Текстовый (Очень высокая степень данных редактор. пригодности.) • Модель данных' 2. CASE-средство Модель соглашения • Диаграмма размещения между вашей и • Глоссарий внешней системами
Неизвестны • Бизнес-правило 1. Бумага и стикеры Обычно выбрасывается • Ограничение 2. Набросок » Сущностный элемент Use Case • Глоссарий • Сценарий использования • Диаграмма потоков пользовательского
интерфейса • Прототип пользователь- ского интерфейса
Неизвестны • Приемочные тесты 1. Текстовый (Средняя степень • Варианты изменений редактор пригодности.) • Ограничения 2. CASE-средство Часть официальной • Сущностный прототип документации потоков пользователь- по системе ского интерфейса • Глоссарий • Системный элемент Use Case • Технические требования
Продолжение &
374 Приложение А • Методики моделирования
Таблица А.2 (продолжение)
1 2 3
Характеристика Характеристика — это «небольшой полезный Исследование требований с точки зрения пользователя результат». Характеристика является крошечным «кирпичиком» планирования, отчетности и отслеживания. Она понятна, невелика и выполнима (вместе с некоторыми другими характеристиками) в течение двухнедельного инкремента разработки (Коад, Левебвр, Де Лука, 1999). Характеристики обычно описывают функциональные требования, хотя могут описывать ограничения, касающиеся работы или операционных параметров приложения
Блок-схема Блок-схема (Гейн и Сарсон, 1979) отражает Определение сложной логики потоки логики бизнес-процесса или программной операции. Блок-схемы очень просто изображают деятельность или процессы, потоки логики от одного процесса к другому и возможные решения
Глоссарий Глоссарий (Джекобсон, Буч и Рамбо, 1999; Определение бизнес- Амблер, 1998) является набором определений и технических терминов, терминов, относящихся к проекту. В глоссарий относящихся к проекту могут входить как бизнес-, так и технические термины
Приложение A • Методики моделирования 375
4 5 6 7
Неизвестны • • • • • • • • • • Приемочные тесты 1. Карточки Определение бизнес- 2. Текстовый правила редактор Диаграмма классов Модель «Класс-Ответ- ственность-Сотрудни- чество» (CRC) Диаграмма сотрудни- чества Определение ограниче- ний Сущностный прототип пользовательского интерфейса Глоссарий Исходный код Прототип пользователь- ского интерфейса (Средняя степень пригодности.) При необходимости списка характеристик, описывающих систему
Излишне точное - • Диаграмма классов 1. Набросок (Средняя степень
определение логики (лучше использовать • Диаграмма сотрудничества 2. Инструментальное средство для пригодности.) Описание логики для бизнес-
исходный код или • Глоссарий рисования правила или бизнес-
спецификацию языка) • • • • • Диаграмма последовательности Исходный код Системный элемент Use Case Сценарий использова- ния История пользователя 3. CASE-средство процесса
Определение бизнес- правил. Определение • Определение бизнес-правила 1. Текстовый редактор (Средняя степень пригодности.)
всех возможных корпоративных терминов • • • • • • • Диаграмма классов CRC-модель Определение ограничений Сущностный элемент Use Case Системный элемент Use Case Технические требования Сценарий использования История пользователя 2. Карточки Для определения важных бизнес- терминов для разработчиков. (Средняя степень пригодности.) Для определения важных технических терминов для заинтересованных лиц
Продолжение &
376 Приложение А • Методики моделирования
Таблица А.2 (продолжение)
1 2 3
Сетевая диаграмма Сетевая диаграмма показывает различные узлы аппаратного обеспечения и взаимосвязь между ними \ Анализ существующей технической инфраструктуры. Проектирование предложенной технической инфрастуктуры
Организационная Организационная диаграмма отражает
диаграмма z структуру организации (люди, должности,
группы)
Отображение существующей
или предложенной структуры
организации. Документация
об участниках проекта
Физический Физический прототип (Гринбаум и Кинг, 1991) Изучение эргономических
прототип моделирует реальную среду, в которой система будет развернута. Физические прототипы могут быть просты до невозможности и имитировать рабочую станцию для одного пользователя или могут быть сложными и моделировать работу всей организации проблем системы. Определяет требования к физическому оборудованию(аппаратное обеспечение, мебель и т. д.)
Диаграмма
устойчивости
Диаграмма устойчивости (Розенберг и Скотт,
1999) отражает основные объекты (граничные/
объекты интерфейса, сущностные объекты
или объекты управления/объекты процесса),
которые участвуют во взаимодействии актеров
с системой (что определено сценарием
использования)
Анализ элементов Use Case
и выбор бизнес-классов
и основных элементов
пользовательского
интерфейса (экраны,
отчеты и т. д.). Проверка
логики поведенческих
требований (элемент Use
Case, история пользователя
и т. д.). Осуществление
предварительного
проектирования
Приложение А • Методики моделирования 377
4 5 6 7
Неизвестны • Диаграмма 1. Набросок (Высокая степень компонентов 2. Инструментальное пригодности.) • Системный элемент Use средство для Официальное Case рисования описание технической 3. CASE-средство инфраструктуры системы или организации
Неизвестны • Диаграмма 1. Карточки и струны (Средняя степень деятельности 2. Набросок пригодности.) • Модель «Класс-Обязан- 3. Человеческие Официальное описание ность-Сотрудничество» ресурсы ПО структуры организации • Диаграмма потоков 4. Инструментальное или ее части данных средство для • Диаграмма Use Case рисования
Неизвестны • Диаграмма Обычно выбрасывается деятельности • Диаграмма размещения • Сетевая диаграмма • Системный элемент Use Case • Сценарий пользова-теля • История пользователя
Проектирование потоков п ол ьзовател ьского интерфейса системы (лучше использовать диаграмму потоков пользовательского интерфейса). Проектирование статичной ’ структуры объектно- ориентированного ПО (лучше использовать диаграмму классов) • Приемочный тест 1. Набросок Обычно выбрасывается • Определение бизнес- 2. CASE-средство правила • Диаграмма сотрудничества • Определение ограничений • Глоссарий • Диаграмма последовательности • Системный элемент Use Case • Сценарий использования • Диаграмма потоков пользовательского интерфейса • Прототип пользователь- ского интерфейса • История пользователя
Продолжение &
378 Приложение А • Методики моделирования
Таблица А.2 (продолжение)
1 2 3
UML-диаграмма последова- тельности UML-диаграмма последовательности (Рамбо, Джекобсон и Буч, 1999; Фаулер и Скотт, 1999; Амблер, 2001а) используется для моделирования логики сценариев использования. Сценарий использования (название говорит само за себя) описывает, как будет использована система Моделирование логики сценария использования или пути в одном или нескольких элементах Use Case, Моделирование историй заказчика или сценария использования (или их частей). Моделирование логики сложной транзакции для изучения ее проектирования
Язык спецификации Язык спецификации (Гейн и Сарсон, 1979) используется для описания логики структурированным, официальным образом. Промышленным стандартом языка спецификации является объектный язык ограничений OCL(Ворнер и Клеппе, 1999) Описывает точную логику процесса, операции, ограничения или бизнес- правила. Определяет ограничения или правила, которые отражаются на
диаграммах. Спецификация
ограничений или инвариантов
классов, компонентов или •
операций
Диаграмма схем
состояний (UML)
Диаграмма схем состояний (Рамбо, Джекобсон
и Буч, 1999; Дуглас, 1999; Фаулер и Скотт,
1999; Амблер,, 2001а) изображает различные
состояния объектов и переходы между этими
состояниями. Состояние представляет этап
паттерна поведения, а переход показывает
изменение состояний
Проектирование поведения
сложного класса или
компонента. Проектирование
функций компонента
аппаратного обеспечения.
Анализ сложного бизнес-
процесса
Диаграмма
структуры
Диаграмма структуры (Гейн и Сарсон, 1979;
Пейдж-Джонс, 1988, Йордон, 1989) показывает
модули процедурно-ориентированного кода и
отношений вызова между этими модулями
Изучение иерархии вызовов
при проектировании
процедурно-
ориентированного ПО.
Изучение вызова служб
(веб-служб)
Приложение А • Методики моделирования 379
4 5 6 7
Моделирование логики для каждого отдельного пути по всем требованиям к системе (следует моделировать только сложные пути) • Диаграмма классов 1. Набросок Обычно выбрасывается • Диаграмма 2. CASE-средство устойчивости • Системный элемент Use Case • Сценарий использования • История заказчика
Создание слишком перегруженных информацией диаграмм (лучше писать документацию или записывать ком- ментарии к исходному коду). Подробная документация для заинтересованных лиц (скорее всего, они не понимают данный язык, поэтому лучше использовать диаграммы, например диаграммы потоков данных) • Приемочные тесты 1. CASE-средства • Бизнес-правила 2. Текстовый • Диаграмма классов редактор • Диаграмма сотрудничества • Диаграмма компонентов • Диаграмма потоков данных
Моделирование потока процесса (лучше использовать диаграмму пото- ков данных). Про- ектирование пове- дения простого класса и/или класса, не имеющего необыч- ного поведения, основанного на состояниях • Тест приемки 1. Набросок (Низкая степень • Бизнес-правило 2. Карточки и струны пригодности.) • Диаграмма классов 3. CASE-средства Часть проектной • Исходный код документации для • Системный элемент Use сложных классов. Case (средняя степень • Сценарий пригодности) использования Часть документации по требованиям для описания сложных бизнес-процессов
Внутреннее проектирование объектно-ориентиро- . ванного ПО (лучше использовать диаграмму последо- вательности или диаграмму сотрудничества) • Диаграмма потоков 1. Набросок (Очень низкая данных 2. Графическая степень пригодности.) • Исходный код утилита Высокоуровневое 3. CASE-средство проектирование структурного ПО
Продолжение &
380 Приложение А • Методики моделирования
Таблица А.2 (продолжение)
1 2 3
Системный Системный элемент Use Case (Кокберн, 2001а; Анализ требований,
элемент Use Case Амблер, 2001а) — это элемент Use Case, Высокоуровневое
в котором отражены высокоуровневые решения проектирование реализации реализаци, обусловленные, например, типом требований пользовательского интерфейса (графический пользовательский интерфейс, HTML и т. д.) и физической средой
Технические требования Технические требования (Вигерс, 1999; Амблер, Определение требований 2001а) касаются не связанных с бизнес-средой аспектов системы (проблемы, связанные с производительностью, надежностью и технической средой)
Сценарий использования Сценарий использования (Гринбаум и Кинг, Изучение использования 1991; Амблер, 2001а) описывает один путь системы логики через один или нескольких элементов Use Case или историй заказчика. Сценарий использования может представлять основной поток поведения (правильный путь) через один элемент Use Case, комбинацию частей правильного пути, замещенную шагами одного или нескольких альтернативных путей через один элемент Use Case, или путь, охватывающий несколько элементов Use Case или историй пользователя
Диаграмма Use Case (UML) Диаграмма Use Case (Кокберн, 2001а; Фаулер Диаграмма обзора системы, и Скотт, 1999; Рамбо, Джекобсон и Буч, 1999;. определяющая основные Амблер, 2001а) показывает набор элементов требования. Контекстная Use Case, актеров, их ассоциации и иногда диаграмма системы, границы системы определяющая рамки проекта. Анализ требований существующей системы. Краткий обзор сущностных или системных элементов Use Case
Приложение А • Методики моделирования 381
4 5 6 7
Определение • Приемочные тесты 1. Текстовый (Средняя степень
требований к системе. Использование в качестве ЕДИНСТВЕННОГО источника для создания системной спецификации (например, вам нужно исследовать нечто, основанное на элементах Use Case) • • • • • • • • • Диаграмма сотрудничества Сущностный элемент Use Case Блок-схема Глоссарий Диаграмма последовательности Диаграммы схем состояний Сценарий использования Диаграмма Use Case Прототип пользователь- ского интерфейса редактор 2. CASE-средство пригодности.) Часть проектной документации по системе
Определение • Приемочные тесты 1. Карточки (Средняя степень
бизнес-требований. • Варианты изменений 2. Текстовый пригодности.)
Выявление ненужных требований, которые технический персонал хочет реализовать • • • • Ограничения Диаграмма размещения Глоссарий Сетевая диаграмма редактор Часть официальных требований
Неизвестны • • • • • • • • • • • • • Приемочные тесты Диаграмма деятельности Бизнес-правило Варианты изменений Ограничения CRC-модель Диаграмма размещения Сущностный элемент Use Case Блок-схема Глоссарий Сетевая диаграмма Системный элемент Use Case Техническое требование 1. Карточки 2. Текстовый редактор Обычно выбрасывается
Создание диаграмм процесса (лучше • Диаграмма деятельности 1. Набросок 2. CASE-средство (Средняя степень пригодности.)
использовать, диаграмму потоков данных или диаграмму деятельности). Создание диаграмм, не основанных на элементах Use Case • • • • Сущностный элемент Use Case Организационная диаграмма Диаграмма устойчивости Системный элемент Use Case 3. Графическая утилита Обзор требований 1
Продолжение &
382 Приложение А • Методики моделирования
Таблица А.2 (продолжение)
1 2 3
Диаграмма потоков поль- зовательского интерфейса Диаграмма потоков пользовательского Изучение требований интерфейса (Константайн и Локвуд, 1999; к пользовательскому Пейдж-Джонс, 2000; Амблер, 2001а) позволяет интерфейсу, вам смоделировать высокоуровневые Высокоуровневый отношения между основными элементами архитектурный обзор интерфейса и представляет собой полный пользовательского обзор пользовательского интерфейса системы интерфейса приложения. Высокоуровневое проектирование пользовательского интерфейса для поддержки элемента Use Case или сценария использования (обычно называется последовательностью кадров)
Прототип поль- зовательского интерфейса Создание прототипа пользовательского Изучение проблемной интерфейса (Константайн и Локвуд, 1999; области. Раскин, 2000; Мейхью, 1992; Амблер 2000а) Детальное проектирование является итеративным методом анализа, где пользовательского пользователи принимают участие в создании интерфейса макета пользовательского интерфейса системы. Создание прототипов пользовательского интерфейса обычно состоит в изучении требований к интерфейсу, создании или усовершенствовании прототипа, реализующего эти требования, и оценки прототипа на предмет соответствия требованиям
История пользователя История пользователя (Ньюкирк и Мартин, 2001; Изучение требований. Бек и Фаулер, 2001) напоминает нам о том, Напоминание что мы должны общаться с заинтересован- о необходимости общения ными в проекте лицами. Истории пользователя с заинтересованными лицами содержат высокоуровневые требования, включая поведение, бизнес-правила, ограничения и технические требования /
Приложение А • Методики моделирования 383
4 5 6 7
Неизвестны • Сущностный элемент 1. Набросок (Средняя степень
Use Case 2. Карточки и струны пригодности.)
• Сущностный прототип 3. Г рафическая Часть официальной ,
пользовательского утилита проектной
интерфейса 4. CASE-средство документации для
• Диаграмма обзора проектирования
устойчивости пользовательского
• Системный элемент Use интерфейса.
Case (Средняя степень
• Прототип пользователь- пригодности.)
ского интерфейса Часть пользовательской
• История пользователя документации для
- обзора системы
Использование • Бизнес-правило 1. Набросок Обычно выбрасывается
в качестве • Ограничение 2. Средство или превращается
ЕДИНСТВЕННОГО источника для создания системной спецификации. Определение требований к пол ьзовател ьскому интерфейсу (лучше использовать сущностный прототип п ол ьзовател ьско го интерфейса) • • • • • • Сущностный элемент Use Case Глоссарий Диаграмма устойчивости Исходный код Системный элемент Use Case Диаграмма потоков п ол ьзовател ьского интерфейса для создания прототипа пользовательского интерфейса 1 3. Среда программирования (например,Java) в рабочую систему
Неизвестны • • • • • • • Приемочные тесты Диаграммы сотрудничества Диаграммы размещения Глоссарий Диаграммы устойчивости Диаграммы последовательности Исходный код 1. Карточки 2. Текстовый редактор
Глоссарий терминов
и сокращений
Данный список терминов и сокращений описывает значения, которые я придаю
терминам и сокращениям в данной книге. В других книгах этим словам могут при;
писываться и другие значения. Это нормально, в конце концов, я и не собирался
писать толковый словарь.
Accessor — операция доступа
Операция, используемая для модификации или возврата отдельного свой-
ства (атрибута) объекта. Также известна под названиями getter (получатель)
и setter (установщик).
Agile developer — гибкий разработчик
Человек, разрабатывающий программы в соответствии с методиками гибкой
разработки программного обеспечения.
Agile model — гибкая модель
Модель, которая всего лишь достаточно хороша. Это означает, что она удовлет-
воряет наши потребности, и ничего более; она понятна предполагаемой ауди-
тории, проста, достаточно точна, непротиворечива и детальна; и затраты на ее
создание и поддержку выгодны для проекта.
Agile modeler — разработчик гибкой модели
Человек, следующий методологии гибкого моделирования.
Agile Modeling (AM) — гибкое моделирование
Упорядочивающая, базирующаяся на практическом опыте методология эф-
фективного моделирования программных систем.
Глоссарий терминов и сокращений 385
Agile modeling session — сеанс гибкого моделирования
Сеанс моделирования, в ходе которого вы следуете принципам и применяете
правила AM.
Analysis modeling session — сеанс моделирования на этапе анализа
Сеанс моделирования, в ходе которого команда старается конкретизировать
требования к системе.
Analysis paralysis — столбняк анализа
Боязнь двигаться дальше, пока модель не станет идеальной.
Analyst — аналитик
Разработчик, отвечающий непосредственно за связь с заказчиками (заинтере-
сованными в проекте лицами) и потенциально отвечающий за «вытягивание»
(сбор) из них информации о требованиях к системе, документирующий и/или
проверяющий эту информацию.
API (Application programming interface) — интерфейс прикладного программи-
рования
Architecture modeling session — сеанс моделирования архитектуры
Сеанс моделирования, в ходе которого команда старается определить высоко-
уровневую стратегию построения вашей системы.
Architecture spike — архитектурный выброс, проба архитектуры
Концепция ХР/под которой понимается разработка такого кода, который не-
обходим для демонстрации факта работоспособности предполагаемой архи-
тектуры.
Artifact — артефакт
Поставляемый или работающий продукт.
Baseline — базовый уровень
Оттестированная и сертифицированная версия поставляемого продукта, ко-
торая представляет собой важнейшую контрольную точку и является, в свою
очередь, основой для дальнейших изменений. Эта версия может быть измене-
на только путем формальных процедур управления изменениями. Конкретная
версия превращается в базовый уровень в тот момент, когда группа, облеченная
соответствующими правами, приходит к решению считать ее базовым уровнем.
BDUF (Big design up front) — «Сначала-все-спроектируем»
Behavioral requirement — требования к поведению
Категория требований, которые описывают порядок взаимодействия пользо-
вателя с системой, то, как система будет использоваться или как система будет
удовлетворять бизнес-функциям.
13 Зак. 926
386 Глоссарий терминов и сокращений
Boundary object — граничный объект
Объект, моделирующий элементы пользовательского интерфейса, такие как
окна, отчеты, HTML-страницы или сообщения электронной почты.
Business rule — бизнес-правило
Принцип или правила работы, которым должна соответствовать ваша про-
грамма.
Cardinality — мощность (кардинальное число)
Соответствует понятию «Сколько?» в ассоциациях.
CASE (Computer-aided system engineering) — автоматизированная разработка
систем
CASE tool — CASE-средства
Программные средства, поддерживающие создание и работу с моделями про-
граммных систем.
Catalysis
Процесс разработки следующего поколения, обеспечивающий последователь-
ную разработку программных систем на основе компонентов и управляемый
бизнес-задачами, которые должны решать эти системы.
С&СМ (Configuration and Change Management) — управление конфигурацией
и внесением изменений
Change case — вариант изменений
Артефакт, используемый для определения перспективных требований к систе-
ме или возможной модификации существующих требований.
Chaordic — упорядочивающий
Свойство саморегулирующихся организмов или систем, в которых гармонично
сочетаются хаос и упорядоченность.
Class diagram — диаграмма классов
Диаграмма UML, описывающая классы, их статические отношения (включая
наследование, агрегацию и ассоциацию) и операции и свойства (атрибуты)
этих классов.
Class Responsibility Collaborator (CRC) card — карточка «Класс-Обязанность-
Сотрудничество», CRC-карточка
Стандартная картотечная карточка, разделенная на три графы. В первой гра-
фе записывается имя класса, который представлен этой карточкой, во второй —
перечень выполняемых этим классом обязанностей (операций) и в третьей —
список имен тех классов, помощь которых потребуется данному классу для
выполнения предполагаемых обязанностей (операций).
Глоссарий терминов и сокращений 387
Class Responsibility Collaborator (CRC) model — CRC-модель
Набор CRC-карточек.
CMM (Capability Maturity Model) — модель зрелости (процесса разработки,
компании)
Cohesion — связность
Степень зависимости .элементов внутри инкапсулированного модуля (такого
как компонент или класс).
, Collaboration diagram — диаграмма сотрудничества
Диаграмма UML, отображающая экземпляры классов, их взаимодействие и по-
токи сообщений между ними. Диаграмма сотрудничества дает возможность
взглянуть на набор взаимодействующих объектов, которые в ходе совместной
работы выполняют определенную задачу, с высоты птичьего полета.
Collaborative modeling tool — средства совместного моделирования
CASE-средства, позволяющие нескольким разработчикам одновременно рабо-
тать с одной или несколькими моделями и дающие им возможность оператив-
но вносить в эти модели необходимые изменения.
Collaborative writing tool — средства совместного редактирования документов
Текстовые редакторы, позволяющие нескольким разработчикам совместно со-
здавать документ, с возможностью оперативно вносить в этот документ необ-
ходимые изменения.
Communication — общение, контакт
Акт передачи информации между людьми.
Component diagram — диаграмма компонентов
Диаграмма UML, описывающая программные компоненты системы, их интер-
фейсы и отношения между этими компонентами.
Connascence — близость, схожесть, родственность
Свойство, определяемое для двух программных элементов, А и В, при котором
для сохранения правильности системы в целом изменения в А вызывают необ-
ходимость изменений в В.
Constraint — ограничение
Ограничения, которыми вы связаны при разработке решения.
Context diagram — контекстная диаграмма, диаграмма окружения
Диаграмма, которая демонстрирует, как система встраивается в окружающую
ее среду. Для этой цели обычно используются высокоуровневые диаграммы
потоков данных или диаграммы размещения.
Contract model — модель соглашения
Модель, которая определяет договоренности между двумя или более сторо-
нами. Модель соглашения — это набор совместных договоренностей сторон,
388 Глоссарий терминов и сокращений
который они при необходимости могут, также совместно, изменять. Модели
соглашений требуются, например, если определенные информационные ресур-
сы — база данных, унаследованное приложение или информационная служба,
которые используются вашей системой, — находятся под контролем третьих
лиц.
Control object — управляющий объект
Объект, выполняющий функцию связки между пограничными объектами /
объектами интерфейса и объектами сущностей. Реализует логику, необходи-
мую для управления различными объектами и их взаимодействиями.
CORBA (Common Object Request Broker Architecture) — обобщенная архитек-
тура брокера объектных запросов
Core infrastructure team — команда поддержки базовой инфраструктуры
Любая группа, обладающая видением проблемы на уровне корпорации, задача
которой — поддержка команды разработчиков.
COTS (Commercial off-the-shelf) — коммерческий «коробочный» программный
продукт
Data definition language (DDL) — язык определения данных (ЯОД)
Набор команд, обеспечивающий устойчивый механизм для создания, удале-
ния или модификации структуры хранимых данных (например, реляционных
таблиц или классов).
Data domain — область данных
Набор связанных между собой элементов данных и связей между ними.
Большинство областей данных базируется на какой-то общей теме или кон-
цепции внутри предметной области,, например, для финансовых учреждений
областями данных будут работа с клиентами, работа с банковскими счетами,
брокерская и страховая деятельность.
Data-flow diagram (DFD) — диаграмма потоков данных
Диаграмма, которая описывает перемещение данных в системе между процес-
сами, хранилищами данных и элементами системы.
Data manipulation language (DML) — язык управления данными (ЯУД)
Набор команд, обеспечивающий устойчивый механизм для доступа к данным,
в том числе для создания, получения из базы, обновления и удаления элемен-
тов данных.
Data model — модель данных
Диаграмма, которая описывает элементы данных и их отношения.
Dead march — смертельный марш
Обреченный проект по разработке программного обеспечения, не имеющий ви-
димых надежд на успех, работа над которым, несмотря на это, не прекращается.
Глоссарий терминов и сокращений 389
Deliverable — поставка
Артефакт, поставляемый как часть общей системы. Примеры поставок — ис-
ходные тексты программ, пользовательская документация по работе с систе-
мой или техническая документация по системе, предназначенная для обслу-
живающего персонала.
Deployment diagram — диаграмма размещения
Диаграмма, которая отображает статическое представление рабочей конфи-
гурации процессорных узлов и программных компонентов, которые работают
в этих узлах.
Design modeling session — сеанс моделирования на этапе проектирования
Сеанс моделирования, в ходе которого команда старается детально определить
стратегию построения части системы.
Developer — разработчик
Любой человек, вовлеченный в процесс создания артефактов, имеющих отно-
шение к программному обеспечению. Примерами разработчиков могут быть
сотрудники, исполняющие роли программистов, проектировщиков и тести-
ровщиков.
Development team — команда разработчиков
Разработчики и заказчики (лица, активно заинтересованные в работе над про-
ектом).
Document — документ
Любой артефакт, являющийся внешним по отношению к тексту программ, за-
дача которого — передача стабильной информации.
Documentation — документация
Стабильная информация, записанная для людей, которые изучают систему,
в том числе документы и комментарии в тексте программ.
Documentation handoff — передача документации
То, что происходит, когда одна группа лиц предоставляет документацию другой.
Domain model — модель предметной области 7
Модель, которая описывает основные бизнес-классы или сущности и их отно-
шения. В этом качестве обычно используется диаграмма классов или диаграм-
ма данных.
Drawing tool — графический пакет
Программное средство, при помощи которого можно рисовать диаграммы.
Графические пакеты представляют собой удобное средство для вывода резуль-
татов работы CASE-средств.
DSDM (Dynamic Systems Development Method) — метод разработки динами-
ческих систем
390 Глоссарий терминов и сокращений
Enterprise architectural modeling — моделирование корпоративной архитектуры
Действия по созданию и разработке моделей, описывающих деловую и техни-
ческую инфраструктуру данной организации.
Enterprise requirements modeling — моделирование корпоративных требований
Действия по созданию и разработке моделей, описывающих требования верх-
него уровня для данной организации.
Entity object — объект-сущность
Объект, обычно извлекаемый из модели предметной области, например «Заказ»
или «Единица хранения» в системе «Склад».
Essential use-case — сущностный (основной) элемент Use Case (вариант ис-
пользования)
Обобщенный, абстрактный, упрощенный элемент Use Case, который воплоща-
ет ожидания пользователей без привязки к реализации.
Essential user interface prototype — прототип основного интерфейса пользова-
теля
Схематичная модель части пользовательского интерфейса системы без при-
вязки к технологии.
EUP (Enterprise Unified Process) — корпоративный унифицированный процесс
Evil wizard — злой волшебник
Генератор кода, в котором невозможно разобраться.
Executable UML — исполняемый UML
Стратегия, в соответствии с которой системы моделируются при помощи арте-
фактов UML и формальных языков, таких как OCL, а рабочие программы ге-
нерируются из созданных моделей автоматически.
Executive overview — служебная записка
Описание концепции системы и резюме по текущим оценкам затрат, предпо-
лагаемой прибыли, элементам риска, необходимым затратам и планируемым
контрольным точкам.
Facilitator — координатор
Лицо, отвечающее за планирование, проведение и руководство сеансами моде-
лирования.
FDD (Feature-Driven Development) — разработка, направляемая ожидаемыми
характеристиками продукта
Flow chart — блок-схема
Диаграмма, отражающая логический поток бизнес-процесса или работы про-
граммного обеспечения. Блок-схемы являются основным артефактом струк-
турного/процедурного моделирования.
Глоссарий терминов и сокращений 391
Formal model — формальная модель
Модель, построенная на основе языка, который имеет хорошо определенные
синтаксис и семантику и, возможно, заранее определенные способы проверки
правильности языковых конструкций — правила анализа, правила вывода од-
них конструкций из других или другие способы.
Getter — получатель
Операция, возвращающая значение свойства (атрибута) данных объекта или
вычисляющая это значение.
Glossary — глоссарий “
Набор определений терминов, имеющих отношение к данному проекту.
Gold owner — золотой телец
Человек или организация, финансирующая проект.
Graphical user interface (GUI) — графический интерфейс пользователя
Тип пользовательского интерфейса, состоящего из графических элементов, та-
ких как окна и кнопки.
Hardware node — аппаратный узел
Компьютер, коммутатор, принтер или другое аппаратное устройство.
IDE (Integrated Development Environment) — интегрированная среда разра-
ботки
Increment — приращение
Разница между двумя версиями системы.
Information radiator — излучатель информации
Предоставление информации в форме заметок, прикрепляемых на стену в таком
месте, где каждый проходящий мимо сотрудник может с ней ознакомиться.
Interface — интерфейс
В языке Java — набор из нескольких (от нуля и более) заголовков операций, ре-
ализуемых внутри класса.
Interface object — объект интерфейса
См. Граничный объект. 1
Iron triangle — железный треугольник
Концепция планирования, согласно которой существует возможность зафик-
сировать только два из трех (затраты, объем и качество) параметров проекта.
IRUF Initial requirements up front — «Сначала базовые требования»
IT (Information Technology) — информационные технологии
392 Глоссарий терминов и сокращений
Iterate — выполнять итерации
Переходить к следующему шагу/задаче, выполняя каждый раз небольшой шаг,
нередко повторяя на новом уровне уже сделанные шаги.
Iteration — итерация
Термин из унифицированного процесса, который обозначает определенную
последовательность действий, соответствующих плану и критериями оценки
и приводящих к получению версии (окончательной или промежуточной).
Ivory tower architecture — архитектура заоблачных замков
Архитектура, разработанная в отрыве от разработчиков или групп разработчи-
ков, которые должны будут заниматься ее реализацией.
Joint application development (JAD) — совместная разработка приложения
Структурированное совещание, в ходе которого группа людей выполняет мо-
делирование. JAD часто помогает определить требования к системе или со-
здать модель пробной архитектуры.
KISS (Keep it simple stupid) — «Делай проще, дурачок!»
Landscape model — пейзажная модель
См. Обзорная модель.
Layering — многослойная организация
Организация классов или компонентов программного обеспечения в виде на-
боров (слоев), ориентированных на общие цели.
Level-0 DFD — базовая диаграмма потоков данных уровня ноль
Модель, построенная на основе диаграммы потоков данных и используемая
в качестве контекстной диаграммы.
Major user interface element — блок пользовательского интерфейса
Крупный элемент пользовательского интерфейса, такой как окно, HTML-стра-
ница или отчет.
Message-invocation box — окно сообщений о вызовах
Узкий вертикальный прямоугольник, используемый в диаграммах последо-
вательности для обозначения выполнения вызванных операций объекта или
класса1.
Minor user interface element — элемент пользовательского интерфейса
Мелкий элемент пользовательского интерфейса, такой как поле ввода, элемент
меню, список или статический текст. >
1 В языке UML носит название фокуса управления. — Примеч. науч, ред,-
Глоссарий терминов и сокращений 393
Model — модель
Абстракция, описывающая одну или несколько характерных черт проблемы
или потенциальных решений этой проблемы. Стало традицией отождествлять
первый вариант модели с некоторым количеством диаграмм и сопровождаю-
щей их документацией. Однако не содержащие диаграмм артефакты, такие как
наборы CRC-карточек, документированное в тексте представление одного или
нескольких бизнес-правил или описание бизнес-процессов на структуриро-
ванном английском языке, также можно считать моделями.
Model Driven Architecture (MDA) — управляемая моделями архитектура
Часть концепций OMG, направленной на поддержку межоперационной сов-
местимости между спецификациями, определяющая связи между стандартами
OMG и их предполагаемое совместное и согласованное использование. '
Modeling session — сеанс моделирования
Совещание, в ходе которого команда старается разработать одну или несколь-
ко моделей.
Multiplicity — кратность
UML объединяет понятия мощности (кардинального числа) и вариантности
в едином понятии — кратности.
Network diagram — сетевая диаграмма
Модель, в которой рассматриваются различные типы аппаратных узлов сети
и связи между дими.
Non-behavioral requirement — требования, не относящиеся к поведению
Категория требований, которые описывают технические параметры системы,
требования, обычно предъявляемые к доступности системы, ее безопасности,
производительности, межоперационной совместимости, надежности и безот-
казности.
Normalization (data) — нормализация (данных)
Способ организации данных, при котором данные упорядочиваются таким об-
разом, чтобы каждый элемент данных хранился в одном и только одном месте.
Normalization (object) — нормализация (объекта)
Способ организации объектов, при котором различные поведения упорядо-
чиваются таким образом, чтобы каждое поведение реализовывалось в одном
и только одном месте.
Note — примечание
Элемент моделирования, предназначенный для добавления произвольного
текста к диаграммам UML.
394 Глоссарий терминов и сокращений
Object Constraint Language (OCL) — объектный язык описания ограничений
Промышленный стандарт на язык описаний, определенный Object Management
Group (www.omg.org).
Object lifeline — линия жизни объекта
На диаграммах последовательности — жизненный цикл объекта в ходе взаи-
модействия.
OOA&D (Object-oriented analysis and design) — объектно-ориентированный
анализ и проектирование
Operations documentation — рабочая документация
Подобная документация обычно включает в себя описание связей системы
с другими программными и аппаратными средствами, суть ее взаимодействия
с другими системами, базами данных и файлами, описания процедур резерв-
ного копирования, список точек входа в систему и методов получения доступа
к ней через эти точки, краткое описание требований по доступности/безотказ-
ности, предполагаемый порядок загрузки системы и рекомендации по устране-
нию неисправностей.
Optionality — вариантность
Соответствует понятию «А нужно ли нам это?» в ассоциациях.
Organization chart — организационная диаграмма
. Модель, описывающая существующую структуру организации — отделы, долж-
ности и сотрудников.
Osmotic communication — осмотические контакты
Косвенная передача информации, получение информации из услышанных
в курилке разговоров или из окружающей вас рабочей атмосферы.
Overview diagram — обзорная диаграмма
Высокоуровневое описание одного из аспектов архитектуры системы. В каче-
стве обзорной диаграммы может быть использована любая диаграмма, которая
поможет лучше понять соответствующий аспект архитектуры, например диа-
грамма классов UML или модель данных.
Phase modeling sessions — сеанс моделирования этапа
Деятельность, в ходе "которой команда старается создавать модели, соответ-
ствующие основным этапам традиционной разработки. Имеются в виду, в том
числе, сеансы моделирования требований, анализа, архитектурного моделиро-
вания и проектирования.
Physical prototype — физический прототип
Физическая модель реальной среды, в которой должна быть размещена
система.
Глоссарий терминов и сокращений 395
Platform Independent Model (PIM) — платформонезависимая модель
Тип модели MDA, в которой система описывается вне связи с какими-либо
техническими деталями.
Platform Specific Model (PSM) — платформозависимая модель
Тип модели MDA, в которой часть платформонезависимой модели, одна или
несколько таких моделей описываются с учетом технических подробностей.
PIG (Process improvement group) — группа улучшения рабочих процессов
Process object — объект процесса
См. Управляющий объект.
Project overview — обзор проекта '
Документ, в котором обобщается основная информация по проекту, такая как
концепция системы, результаты первичных встреч с пользователями, техноло-
гии и средства, которые будут использоваться для построения системы, важ-
ные рабочие процессы (как по отношению к разработке, например методы по-
строения системы, так и по отношению к работе системы, например методы
создания резервной копии) и описания основных артефактов проекта, таких
как исходный код, итоговые модели и другие документы. Этот документ будет
исходной точкой для изучения проекта любым новым членом команды.
Project Stakeholder — заказчик проекта (заинтересованное в проекте лицо)
Непосредственный пользователь, опосредованный пользователь, менеджер,
старший менеджер, обслуживающий персонал, сотрудник «горячей линии»
продукта, тестировщики, разработчики других систем, которые должны быть
интегрированы или работать во взаимодействии с данной, или сотрудники
службы поддержки, потенциально заинтересованные в разработке и/или раз-
мещении проекта по созданию программного обеспечения. Чтобы сохранять
единообразность в терминологии, мы не включаем в число «заинтересованных
лиц» разработчиков, занятых в проекте, хотя они-то как раз наиболее заинте-
ресованы в успехе того проекта, над которым работают.
Referential integrity — ссылочная целостность
Гарантия того, что ссылка из одного элемента на другой будет верна. При на-
личии ссылочной целостности имеется гарантия, что если в объекте А присутс-
твуют ссылки на элемент В, этот элемент В будет существовать. Если элемент
В будет уничтожен, все ссылки на элемент В также будут уничтожены.
Relational database (RDB) — реляционная база данных (РБД)
Механизм долговременного хранения, при котором данные хранятся в виде
строк в таблицах.
Release — версия
Размещение рабочей версии системы. Версии могут быть как внутренними,
предназначенными только для команды разработчиков, так и внешними, кото-
396 Глоссарий терминов и сокращений
рые будут использоваться непосредственными пользователями системы — не-
которыми или всеми.
Requirements — требования
Описание того, что заинтересованные лица ожидают от системы, включая
предполагаемую функциональность и набор ограничений.
Requirements document — описание требований
Этот документ описывает, что должна делать система,.объединяя и собирая во-
едино артефакты требований, такие как бизнес-правила, элементы Use Case,
истории пользователей и важнейшие (но не все!) прототипы пользовательско-
го интерфейса.
Requirements modeling — моделирование требований
Действия по выявлению, определению и исследованию требований к системе.
Requirements modeling session — сеанс моделирования требований
Сеанс моделирования, в ходе которого команда старается определить, чего же
заказчики (заинтересованные в проекте лица) хотят от системы.
Requirements traceability matrix — матрица согласованности требований
' Артефакт, используемый для записи отношений согласованности между арте-
фактами.
Reverse engineering — обратная разработка
Воссоздание модели на основании информации, содержащейся в исходных
текстах программ.
Robustness diagram — диаграмма устойчивости
Модель, которая содержит основные объекты системы — разбитые на гранич-
ные объекты (объекты интерфейса), объекты-сущности и управляющие объ-
екты (объекты процессов), — которые принимают участие во взаимодействии
системы с актером, описанным в сценарии использования.
RUP (Rational Unified Process) — унифицированный процесс фирмы Rational
Scaffolding — леса (вспомогательный код)
Дополнительный'код — операции и свойства (атрибуты), необходимые для
того, чтобы проект заработал. Нередко вспомогательный код пишется про-
граммистами, он может автоматически генерироваться CASE-средствами; он
не моделируется в ходе анализа и часто даже не рассматривается как часть про-
ектного решения.
Scribe — секретарь
Человек, отвечающий за запись информации в ходе сеанса моделирования.
SEI (Software Engineering Institute) — Институт по программной инженерии
Глоссарий терминов и сокращений 397
SEPG (Software engineering process group) — группа процессов разработки про-
граммного обеспечения
Sequence diagram — диаграмма последовательности
Диаграмма UML, используемая для изучения логики сценариев использования.
Setter — установщик
Оператор, который устанавливает значение свойства (атрибута) объекта или
класса. Также известен под названием mutator (мутатор).
Simple tools — простейшие средства
Подручные средства, используемые для моделирования систем, в том числе
перекидные блокноты, наклейки, салфетки, листы бумаги, кнопки, лекцион-
ные доски, каталожные карточки и т. д. ,
Software development artifact — артефакт разработки программного обеспечения
См. Артефакт.
Source code — исходный текст программы
Последовательность инструкций, включая комментарии, поясняющие эти инс-
трукции, для компьютерных систем. Также известен под названиями «код про-
граммы», «исходный код программы» или просто «код».
Specification language — язык описания требований
Манера написания текста, например Объектный язык описания ограничений
(Object Constraint Language, OCL) или Структурированный английский язык
(Structured English), Используемая для описания логики структурированным/
формальным образом.
SPI (Software process improvement) — улучшение процесса разработки про-
граммного обеспечения
Spike — выброс, проба х
См. Архитектурный выброс.
SRS (Software Requirements Specification) — описание требований к программ-
ному обеспечению
State chart diagram — диаграмма состояний
Диаграмма UML, используемая для описания различных состояний, в кото-
рых может находиться объект, и переходов между этими состояниями.
Stereotype — стереотип
Стереотип UML описывает обобщенное использование моделируемого эле-
мента. Стереотипы являются стандартными расширениями UML.
398 Глоссарий терминов и сокращений
Structure diagram — структурная диаграмма
Диаграмма, описывающая модули процедурного кода и отношения вызова
между этими модулями.
Structured English — структурированный английский язык
Традиционный, легкий для чтения тип языка описания требований.
Support documentation — документация по обслуживанию
Эта документация включает в себя учебные материалы для службы поддержки,
всю пользовательскую д'окументацию, используемую для получения справок
при решении проблем, руководство по решению проблем, процедуры передачи
ответственности при решении серьезных проблем и список контактных теле-
фонов и других координат группы поддержки.
System — система
Программное обеспечение, документация, программное обеспечение среднего
уровня, аппаратура, процедуры инсталляции и методики работы.
System documentation — документация по системе
Цель этой документации — предоставить сотрудникам обзор системы и помочь
им понять эту систему. Обычно в этот документ включается обзор технической
архитектуры, бизнес-архитектуры и требования верхнего уровня к описывае-
мой системе.
System Use Case — системный элемент Use Case (вариант использования)
Элемент Use Case, отражающий базовые решения по реализации,- например
особый тип пользовательского интерфейса и физического окружения.
Technical requirement — технические требования
Требования, относящиеся к не связанным с бизнесом аспектам системы, таким,
как вопросы производительности, надежности или выбираемых технологий
реализации.
Traceability — трассируемость
Удобная характеристика, означающая, что свойства одного артефакта — будь
то документ, модель или исходный код — находят отображение/трассируются
в свойства другого артефакта.
Trigger — триггер
। Процедура, которая вызывается автоматически в результате выполнения опе-
раций языка управления данными (ЯДУ) в базе данных.
Truck insurance — страховка от кирпича
Страховка, состоящая в том, что в случае внезапного ухода из команды одного
из ее членов, например в результате того, что на него упадет кирпич, вся важная
для существования проекта информация сохранится в виде документации.
Глоссарий терминов и сокращений 39>9
I
Truck number — число кирпичей
Оценка того, какое минимальное число сотрудников, внезапно покинувших
вашу команду (например, число сотрудников, на которых внезапно упадут
кирпичи), вызовет серьезные затруднения в работе группы.
UML (Unified Modeling Language) — унифицированный язык моделирования
UP (Unified Process) — унифицированный процесс
Usage scenario — сценарий использования
Описание одной логической последовательности действий, включенной в один
или более элементов Use Case или историй пользователей.
Use Case — элемент Use Case (вариант использования)
Последовательность действий, приносящая пользователю значимый для него,
ощутимый и измеримый результат.
Use Case diagram — диаграмма Use Case
Диаграмма UML, используемая для описания набора элементов Use Case, ак-
теров, их взаимодействия и, возможно, границ системы.
Use Case model — модель Use Case
Комбинация из одной или нескольких диаграмм Use Case и соответствующих
им описаний элементов Use Case и актеров.
Use Case realization — реализация элемента Use Case
Артефакт унифицированного процесса фирмы Rational (RUP), представляю-
щий собой подборку из одной или нескольких моделей, описывающих реали-
зации одиночных элементов Use Case.
User documentation — пользовательская документация
Документы, описывающие, как следует работать с системой, включая справоч-
ники, руководства по использованию, дополнительные руководства и учебные
материалы.
User interface (Ul) — пользовательский интерфейс
Та часть программного обеспечения, которая предназначена непосредственно
для взаимодействия с пользователями.
User interface element — часть пользовательского интерфейса
См. Блок пользовательского интерфейса и Элемент пользовательского интер-
фейса.
User interface flow diagram — диаграмма потоков пользовательского интерфейса
Диаграмма, позволяющая промоделировать отношения высокого уровня меж-
ду блоками пользовательского интерфейса и взглянуть на пользовательский
интерфейс системы в целом с высоты птичьего полета.
400 Глоссарий терминов и сокращений
User story — история пользователя
Памятная записка, появляющаяся в результате обсуждения проекта с заказ-
чиками (заинтересованными в нем лицами), в которой содержится единичное
требование к поведению, бизнес-правило, ограничение или техническое требо-
вание к системе.
Version control tool — средства управления версиями
Программные средства, используемые для определения, сверки и управления
созданием новых версий артефактов проекта.
Virtual meeting tool — оборудование для виртуальных конференций
Средства для поддержки общения между людьми, физически находящимися
в различных местах.
Work product — черновик
Тип артефактов, например модель или план проекта, который создаётся в ходе
разработки и может быть в дальнейшем преобразован в рабочий элемент про-
граммы или отброшен за ненадобностью.
Working software — рабочие программы
Программное обеспечение, которое прошло тесты, было принято пользовате-
лями и передано в эксплуатацию.
ХР (extreme Programming) — экстремальное программирование
YAGNI (You Ain’t Gonna Need It Anyway) — «Это вам никогда не пона-
добится»
ZFR (Zero-feature release) — спартанская версия (с нулем характеристик)
Список литературы
Альянс гибких методологий (2001а). Манифест о гибкой разработке программно-
го обеспечения, www.agilealliance.org
Альянс гибких методологий (2001b). Принципы: Альянс гибких методологий, www.
agilealliance.org/principles/html
Ambler, S. W. (1995). The Object Primer: Application Developer’s Guide to Object
Orientation. New York, NY: Cambridge University Press.
Ambler, S. W. (1997). Building Object Application That Work: Your Step-By-Step
Handbook for Developing Robust Systems with Object Technology. New York, NY:
Cambridge University Press. www.ambysoft.com/buildingObjectApplications.html
Ambler, S. W. (1998). Process Patterns: Building Large-Scale Systems Using Object
Technology. New York, NY: Cambridge University Press, www.ambysoft.com/
processPatterns.html
Ambler, S. W. (1999). More process patterns: Delivering Large-Scale Systems Using
Object Technology. New York, NY: Cambridge University Press, www.ambysoft.com/
moreProcessPatterns.html
Ambler, S. W. (2001a). The Object Primer, Second Edition: The Application Developer’s
Guide to Object Orientation. New York, NY: Cambridge University Press, www.
ambysoft.com/theObjectPrimer.html
Ambler, S. W. (2001b). Enterprise Unified Process White Paper. www.roninDintl.com/
publications/unifiedProcess.htm
Ambler, S. W. (2001c). Agile Modeling Home Page, www.agilemodeling.com
Ambler, S. W. (2001d). The Design of a Robust Persistence Layer, www.ambysoft.com/
persistenceLayer.html
Ambler, S. W. (2001e). Mapping Objects to a Relational Database, www.ambysoft.com/
mappingObjects.html
Ambler, S. W. (2001f). Agile Modeling Mailing List Instructions, www.agilemodeling.com/
feedback.htm
402 Список литературы
Ambler, S. W. and Constantine, L. L. (2000a). The Unified Process inception Phase.
Gilroy, CA: CMP Books. www.ambysoft.com/inceptionPhase.html
Ambler, S. W. and Constantine, L. L. (2000b). The Unified Process Elaboration Phase.
Gilroy, CA: CMP Books. www.ambysoft.com/elaborationPhase.html
Ambler, S. W. and Constantine, L. L. (2000c). The Unified Process Construction Phase.
Gilroy, CA: CMP Books. www.ambysoft.com/constructidnPhase.html
Ambler, S. W. and Constantine, L. L. (2002). The Unified Process Transition and
Production Phases. Gilroy, CA: CMP Books. www.ambysoft.com/transitionProduc-
tionPhase.html
Bass, L., Clements, P., and Kazman, R. (1998). Software Architecture in Practice.
Reading, MA: Addison Wesley Longman, Inc.
Beck, K. (2000). Extreme Programming explained: Embrace Change. Reading, MA:
Addison Wesley Longman, Inc. (Русский перевод: Бек, К. Экстремальное про-
граммирование. СПб.: Питер, 2002. 224 с.)
Beck, К. and Cunningham, W. (1989). A Laboratory for Teaching Object-Oriented
Thinking. Proceedings of OOPSLA’89, pp.1-6.
Beck, K. and Fowler, M. (2001). Planning Extreme Programming. Boston, MA:
Addison Wesley. (Русский перевод: Бек К., Фаулер М. Экстремальное програм-
мирование: планирование. СПб.: Питер, 2003. 144 с.)
Beedle, М. and Schwaber, К. (2001). Agile Software Development with SCRUM.
Upper Saddle River, NJ: Prentice Hall, Inc.
Benett, D. (1997). Designing Hard Software: The Essential Tasks. Greenwich, CT:
Manning Publications Co.
Boehm, B. W. (1988). A Spiral Model Of Software Development and Enhancement.
IEEE Computer, pp. 61-72, 21 (5).
Booch, G. (1994). Object-Oriented Analysis and Design with Applications. Reading,
MA: Addison Wesley Publishing Company. (Русский перевод: Буч Г. Объект-
но-ориентированный анализ и проектирование с примерами приложений на
C++, 2-е изд. СПб.: Невский диалект, 1998. 560 с.) ,
Bremer, М. (1999). UnTechnical Writing: How to Write About Technical Subjects and
Products So Anyone Can Understand. Concord, CA: Untechnical Press.
Brooks, F. P. (1995). The Mythical Man Month: Essays on Software Engineering
Anniversary Edition. Reading, MA: Addison Wesley Publishing Company. (Русский
перевод: Брукс Ф. Мифический человеко-месяц, или Как создаются програм-
мные системы. СПб.: Символ-Плюс, 1999. 304 с.)
Brown, W. J., McCormick, Н. W. Ill, and Thomas, S. W. (2000). AntiPattems in Project
Management. New York, NY: John Wiley & Sons, Inc.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M. (1996).
Pattern-Oriented Software Architecture: A System of Patterns. New York, NY: John
Wiley & Sons Ltd.
Christel, M. G. and Kang, К. C. (1992). Issues in Requirements Elicitation. Software
Engineering Institute (SEI) Technical Report CMU / SEI-92-TR-12. www.sei.cmu.
edu
Coad, P., Levebre, E., and DeLuca,J. (1999). Java Modeling in Color with UML:
Enterprise Components and Process. Upper Saddle River, NJ: Prentice Hall, Inc.
Список литературы 403
Cockburn, А. (1998). Surviving Object-Oriented Projects: A Manager’s Guide. Reading,
MA: Addison Wesley Longman, Inc.
Cockburn, A. (2001a). Writing Effective Use Cases. Boston, MA: Addison Wesley.
(Русский перевод: Коберн А. Современные методы описания функциональных
требований к системам. М.: Лори, 2002. 263 с.)
Cockburn, A. (2001b). Crystal Clear: A Human-Powered Software Development
Methodology for Small Teams, http://members.aol.com/humansandt/crystal/clear/
Cockburn, A. (2001c). Characterizing People as Non-Linear, First-Order Component in
Software Development, members.aol.com/humansandt/papers/nonlinear/nonlinear.htm
Cockburn, A. (2002). Agile Software Development. Reading, MA: Addison Wesley
Longman,, Inc. (Русский перевод: Коберн А. Быстрая разработка программного
обеспечения. М.: Лори, 2002. 314 с.)
Constantine, L. L., and Lockwood, L. A. D. (1999) Software For Use: A Practical Guide
to the, Models and Methods of Usage-Centered Design. New York, NY: ACM Press.
(Русский перевод: Константайн. Л., Локвуд Л. Разработка программного обес-
печения. СПб.: Питер, 2004. 592 с.)
Coplien, J. and Harrison, N. (2001). Organizational Pattern Site, www.bell-labs.com/cgi-
user/OrgPatterns/OrgPatterns
Davis, A. M. (1995). 201 Principles of Software Development. New York, NY: McGraw
Hill Inc.
Douglass, В. P. (1999). Doing Hard Time: Developing Real-Time Systems with UML,
Objects, Frameworks, and Patterns. Reading, MA: Addison Wesley Longman, Inc.
D’Souza, D. F., Wills, A. C. (1999). Objects, Components, and Frameworks with UML:
The Catalysis Approach. Reading, MA: Addison Wesley Longman, Inc.
Evans, G. (2001). Palm Sized Process: Point of Sale Gets Agile. Software Development,
September 2001.
Fowler, M. (1997). Analysis Patterns: Reusable ObjectModels. Menlo Park, CA: Addison
Wesley Longman, Inc.
Fowler, M. (1999). Refactoring: Improving the Design of Existing Code. Menlo Park,
CA: Addison Wesley Longman, Inc. (Русский перевод: Фаулер. M. Рефакторинг:
улучшение существующего кода. СПб.: Символ-Плюс, 2003. 432 с.)
Fowler, М. (2'001а). The New Methodology. www.martinfowler.com/articles/newMethodo-
logy.html
Fowler, M. (2001b). Is Design Dead? www.martinfowler.com/articles/designDead.html
Fowler, M., & Scott, K. (1999). UML Distilled, Second Edition: A Brief Guide to the
Standard Object Modeling Language. Reading, MA: Addison Wesley Longman, Inc.
Gane, C., Sarson, T. (1979). Structured Sy stem Analysis: Toolsand Techniques. Englewood
Cliffs, NJ: Prentice Hall, Inc.
Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design Patterns: Elements
of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley Publishing
Company. (Русский перевод: Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж.
Приемы объектно-ориентированного проектирования. Паттерны проектиро-
вания. СПб.: Питер, 2001. 368 с.)
Glib, Т. & Graham, D. (1993). Software Inspection. Harrow, England: Addison Wesley
Longman Limited.
404 Список литературы
Gottesdiener, Е. (2001). Specifying Requirements With a Wall of Wonder. http://www.
therationaledge.com/content/nov_.01/t_wallOfWonder_eg.html
Graham, I., Henderson-Sellers, B.? and Younessi, H. (1997). The OPEN Process
Specification. New York, NY: ACM Press Books.
Greenbaum, J. and Kyng, M., editors (1991). Design At Work: Cooperative Design of
Computer Systems. Hillsdale, NJ: Lawrence Erlbaum Associates, Publishers.
Highsmith, J'. A. Ill (2000). Adaptive Software Development: A Collaborative Approach
to Managing Complex Systems. New York, NY: Dorset House Publishing.
Hock, D. W. (2000). Birth of the Chaordic Age. San Francisco, CA: Berrett-Koehler
Publishers, Inc.
Hohmann, L. (1996). Journey of the Software Professional: The Sociology of Computer
Programming. Upper Saddle River, NJ: Prentice Hall PTR.
Hunt, A. & Thomas, D. (2000). The Pragmatic Programmer: From Journeyman to Master.
Reading, MA: Addison Wesley Longman, Inc.
Jacobson, L, Booch, G., and Rumbaugh, J. (1999). The Unified Software Development
Process. Reading, MA: Addison Wesley Longman, Inc. (Русский перевод: Якоб-
сон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного
обеспечения. СПб.: Питер, 2002. 496 с.)
• Jacobson,!., Christerson, М., Jonsson, Р. and Overgaard, G. (1992). Object-Oriented
Software Engineering: A Use Case Driven Approach. Wokingham, England: ACM
Press.
Jacobson, L, Griss, M., and Jonsson, P. (1997). Software Reuse: Architecture, Process,
and Organization for Business Success. New York, NY: ACM Press.
Jeffries, R. (2001a). EssentialXP: Card, Conversation, Confirmation, www.xprogramming.
com/xpmag/expCardConversationConfirmation.htm
Jeffries, R. (2001b). Essential XP: Documentation, www.xprogramming.com/xpmag/
expDocumentationInXp.htm
Jeffries, R. (2001c). NaturalXP: Documentation, www.xprogramming.com/xpmag/natural.
htm
Jeffries, R. (200Id). Essential XP: Emergent Design, www.xprogramming.com/xpmag/
expEmergentDesign.htm
Jeffries, R. (2001e). Much Ado About Nothing: Documentation, www.xprogramming.com/
xpmag/FussAboutDocumentation.htm
Jeffries, R., Anderson, A., and Hendricsson, C. (2001) Extreme-Programming Installed.
Boston, MA: Addison Wesley.
Jones, C. (2000). Software Assessment, Benchmarks, and Best Practices. Boston, MA:
Addison Wesley Longman, Inc.
• Kerievsky, J. (2001). Patterns and XP. Extreme Programming Examined, pp. 207-220,
Eds. Succi, G. and Marchesi, M. Boston, MA: Addison Wesley.
Kerth, N. (2001). Project Retrospectives: A Handbook for Team Reviews. New York, NY:
Dorset House Publishing.
. Krutchen, P. (1995). The 4+1 View Model Architecture. IEEE Software. 12(6), November
1995. pp. 42-50.
Список литературы 405
Krutchen, Р. (2000). The Rational Unified Process, Second Edition: An Introduction.
Reading, MA: Addison Wesley Longman, Inc. (Русский перевод: Кратчен. Ф.
Введение в Rational Unified Process. М.: Изд. Дом Вильямс, 2002. 240 с.) ~~
Larman, С. (2002). Applying UML and Patterns: An Introduction to. Object-Oriented
Analysis and Design and the Unified Process. Upper Saddle River, NJ: Prentice Hall
PTR.
Leuf, B. and Cunningham, W. (2001). The Wiki Way: Quick Collaboration on the Web.
Reading, MA: Addison Wesley Longman, Inc.
Linthicum, D. S. (2000). Enteiprise Application Integration. Reading, MA: Addison
Wesley Longman, Inc.
Martin, R. (2001). The Process. www.objectmentor.com/publications/RUPvsXP.pdf
Mayhew, D. J. (1992). Principles and Guidelines in Software User Interface Design.
Englewood Cliffs, NJ: Prentice Hall. ’
McConnel, S. (1993). Code Complete: A Practical Handbook of Software Construction..
Redmont, WA: Microsoft Press.
Microsoft Corporation (1995). The Windowsinterface Guidelines for Software Design:
An Application Design Guide. Redmont, WA: Microsoft Press. • _ .
Microsoft Corporation (2001). The Microsoft Solutions Framework (MSF). www.micro-
soft.com/business/services/mcsmsf.asp
Naiburg, E. J. and Maksimchuk, R. A. (2001). UML for Database Design. Boston, MA:
Addison Wesley.
Newkirk, J. and Martin, R. C. (2001). Extreme Programmingin Practice. Boston: Addison
Wesley.
Object Management Group (2001a). The Unified Modeling Language (UML)
Specification, www.omg.org/technology/documents/formal/uml/htm
Object Management Group (2001b). Model Drive Architecture (MDA). ftp.omg.org/
pub/docs/ormsc/01-07-01.pdf
Page-Jones, M. (1988), Practical Guide to Structured Systems Design 2/e. Upper Saddle
River, NJ: Prentice Hall, Inc.
Page-Jones, M. (2000). Fundamentals of Object-Oriented Design in UML. New York,
NY: Dorset-House Publishing.
Raskin, J. (2000). The Human Interface: New Directions for Designing Interactive
Systems. Reading, MA: Addison Wesley.
Rational Corporation (2001). Rational Unified Process Home Page, www.rational.com/
products/rup/index.jsp
Reingruber, M. C. and Gregory, W. W. (1994). The Data Modeling Handbook:
A Best-Practice Approach to Building Quality Data Models. New York, NY: John
Wiley & Sons, Inc.
Roman, E., Ambler, S. W., Jewell, T., and Marinescu, F. (2002). Mastering Enterprise
Java Beans, Second Edition. New York, NY: John Wiley & Sons, Inc.
Rosenberg, D. and Scott, K. (1999). Use Case Driven Object Modeling With UML:
Practical Approach. Reading, MA: Addison Wesley Longman, Inc.
Ross, R. G. (1997) The Business Rule Book, Second Edition. Houston, TX: Business
Rules Solutions, Inc.
406 Список литературы
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. (1991).
Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice Hall, Inc.
Rumbaugh, J., Jacobson, I., and Booch, G. (1999). The Unified Modeling Language
. Reference Manual. Reading, MA: Addison-Wesley Longman, Inc. (Русский пе-
ревод: Рамбо, Дж., Якобсон А., Буч Г. UML: Специальный справочник. СПб.:
Питер, 2002. 656 с.)
Software Engineering Institute. (1995). The Capability Maturity Model: Guidelines
for Improving the Software Process. Reading, MA: Addison-Wesley Publishing
Company, Inc.
Stapleton, J. (1997). DSDM: Dynamic Systems Development Method. Harlow, England:
Addison-Wesley.
Vermeulen, A., Ambler, S. W., Bumgardner, G., Metz, E., Misfeldt, T„ Shur, J., and
Thompson, P. (2000). The Elements of Java Style. New York, NY: Cambridge
University Press. .
Wake, W. C. (2002). Extreme Programming Explored. Boston, MA: Addison Wesley.
Warmer, J. Kleppe, A. (1999). The Object Constraint Language: Precise Modeling with
UML. Reading, MA: Addison-Wesley Longman, Inc.
Weigers, K. (1999). Software Requirements. Redmond, WA: Microsoft Press.
Weiss, E. H. (1991). How to Write Usable User Documentation. Phoenix, AZ: The Oryx
Press.
WellsJ.D. (2001 jExtrezzzePz’ogz'ammmg.-AG'ent/e/ntroc/zzctzon.www.extremeprogramming,
org
Wilkinson, N. M. (1995). Using CRC Cards: An Informal Approach to Object-Oriented
Development. New York, NY: Cambridge University Press.
Williams, L., Kessler, R. R., Cunningham, W., and Jeffries, R. (2000). Strengthening the
Case for Pair Programming. IEEE Software, July/August 2000, pp. 19-25.
Wood, J. and Silver, D. (1995). Joint Application Development Second Edition. New
York, NY: John Wiley & Sons, Inc.
Xerox (2001). Aspect-Oriented Programming, http://www.parc.xerox.com/cls/projects/
aop/
Yourdon, E. (1989). Modem Structured Analysis. Upper Saddle River, NJ: Prentice-Hall,
Inc.
Yourdon, E. (1997). Death March: The Complete Software Developer’s Guide to Surviving
“Mission Impossible” Projects..Upper Saddle River, NJ: Prentice-Hall, Inc.
Алфавитный
указатель
активное участие заинтересованных лиц 77
активные участники сеансов
моделирования 169
альтернативные средства общения 165
Альянс гибкой разработки программного
обеспечения 23
АМ в элементе ХР Разработка 226
АМ на этапе ХР Производство 227
анализ и проектирование
цели 266
цели рабочего потока 300
антипаттерн 72
разработчик одного артефакта 72, 167
сеанс моделирования одного
артефакта 73,166
артефакты моделирования и UML 338
бизнес-моделирование 277
артефакты 266
цели 264
бизнес-модель Use Case 277
бизнес-объектная модель 280
бизнес-спецификация 281
бизнес-среда 284
быстрая обратная связь 49
В
вам нужен набор методик 48
вариант изменения 282
власть имущие бумажные крысы 351
внедрение АМ
культура организации 349
внешняя документация 184
внутренняя документация 184
возможности представления
информации 144
восходящее моделирование 330
временная модель 180
вспомогательные участники сеансов
моделирования 169 •
выброс 240
Г
гибкая документация 187
гибкая модель 31
гибкое моделирование 26
гибкое моделирование в UP
проблемы 338 х
гибкое моделирование
и унифицированный процесс 256
Главная цель — ПО 40
группа рассредоточена в разных
' местах 354
группы по созданию базовой архитектуры
(CAT) 335
Группы по созданию базовой
инфраструктуры (CIT) 333
д
демонстрируйте модели открыто 79, 341
день ХР-разработчика 226
408 Алфавитный указатель
диаграмма
последовательности 249
потоков данных 286
потоков пользовательского
интерфейса 294
диаграмма деятельности UML 69, 202
диаграмма компонентов 306
диаграмма потоков пользовательского
интерфейса 201
диаграмма размещения 306
диаграмма Use Case 213, 287
диаграммы
устойчивости 293
диаграммы обзора 304
добивайтесь простоты 42
доверяйте человеческим инстинктам 67
документ 175
документация в ХР 210
документация как страховка
от кирпича 353
документация по обслуживанию 228
документация по системе 228
документация по эксплуатации 228
документ архитектуры системы (SAD) 303
дополнительные принципы гибкого
моделирования 62
Е
еще одна цель — продолжать проект 40
Ж
жизненный цикл
корпоративного унифицированного
процесса 256
ХР-проекта 221
3
заблуждения в отношении
CASE-средств 141
заблуждения о моделировании 115
заблуждения, связанные с AM 359
заинтересованные лица 77
знай свои модели 65
И
игра «вопрос—ответ» 246
избавляйтесь от временных моделей 89
изменения должны быть небольшими 43
изображайте модели просто 81
исполняемый UML 204
используйте имеющиеся ресурсы 89
используйте простейшие
инструментальные средства 82
истории пользователя 222, 245
истории пользователя в ХР 231
исходный код 175
итерация ХР
подсчет общей суммы заказа 245
поиск товара 239
К
карточки CRC 210
карточки задач 224,239
категория «Документация» 102
категория итеративности
и инкреме'птости 100
категория «Мотивация»' 102
категория подтверждения
правильности 101
категория «Продуктивность» 102
категория «Простота» 101
категория «Работа в группе» 99
качества гибкой модели 31
качества разработчика гибких моделей 153
качественная работа 48
компьютерные средства разработки 128
контракт с фиксированной ценой 357
короткие сеансы моделирования 165
корпоративная модель требований 327
Л
Логическое представление 304
м
Манифест гибкой разработки
программного обеспечения 23
матрица трассируемости 303
матрица трассируемости требований 274
метафора в ХР 234
методика применения UML 205
методика ХР «Парное
программирование» 226
методика ХР «Сначала-тест-потом-
пфограмма» 83,219
методики
базовые 68
дополнительные 85
Алфавитный указатель 409
методики
методики для организации
рабочих мест 151
методы повышения гибкости
документации 195
минимизация документации 182 '
множество моделей 45
моделирование
унифицированный процесс 263
моделирование базовых требований
(IRUF) 232
моделирование в ХР 210
моделируйте в группе 76
моделирование одного артефакта 340
моделируйте постепенно 75
моделируйте, чтобы общаться 94
моделируйте, чтобы понять 94
модель 175
анализа 301
архитектуры предметной
области 327
данных 91, 240
«Класс-обязанность-сотрудничество»
(CRC) 7Г
контекстная 286
корпоративных требований 286
проектирования 301.
соглашения 177,251
технической архитектуры 328
физического представления
данных 69
Use Case 289
модель должна решать конкретную
задачу 44
н
начальный сеанс моделирования 305
недостатки простых средств 131
неспособность признать свою вину 352
не увлекайтесь паттернами 88
нисходящее моделирование 330
нотация UML 203
о
обратная связь 56
общение 53
объект граничный 294
объект-сущность 294
объекты управления/процесса 294
ожидайте изменений 42
оператор SQL 239
описание архитектуры ПО (SAD) 186
определение требований 285
артефакты 265
.осмотическое общение 111
основанная на моделях архитектура
(MDA) 213
отдавайте предпочтение малому 121
открытые и доброжелательные
контакты 66
п
паттерн
применение в ХР-проекте 251
паттерн «Стратегия GoF» 88
передача документации 195
передача работы другим группам 356
переходите от одного артефакта
к другому 74
планирование итерации 225
повышайте отдачу от ресурсов 51
подтверждение модели кодом 83
подход «Сначала-все-спроектируем» 116
пользовательская документация 228
последовательность кадров для элементов
Use Case 265, 293
пост-разработка 183
постоянная модель 180
поток поведения
основной 289
правило KICK 56 '
правило KISS 54
предопределенный процесс
контроль 339
представление архитектуры 4+1 304
представление процессов 304
представление разработки 304
представление сценариев 304
презентация заинтересованным лицам 125
преимущества простых средств 130
приемочные тесты 211
применение методик AM в ХР-проекте 217
применяйте стандарты моделирования 86
принципы гибкого моделирования 39
принципы гибкой разработки
программного обеспечения 25
принцип YAGNI 55
принцип поваренной книги 352
приспосабливаем по месту 65
410 Алфавитный указатель
причины для создания документации 176
причины создания модели 44
проба 239
проба архитектуры 234
проблемы исполняемого UML 204
проблемы применения АМ 347
проблемы сеансов моделирования 173
простота’ 54
простые средства разработки 128
путешествуйте налегке 41
Р
разработчики
побольше универсалов 341
реализация элементов Use Case 308 ,
рефакторинг 96, 216
С
сеанс
- быстрого проектирования 226, 248
гибкого моделирования 164,167
сеансы совместной разработки
приложений (JAD) 171
синдром «изобретено не здесь» (ИНЗ) 89
синхронизация артефактов 250
скептично настроенные разработчики 349
слишком бдительные надзиратели 350
смелость 58
смирение 60
сначала тест, потом программа 96 v
совершенствуйте.только в случае
необходимости 91
советы для создания эффективной
группы 162
совместимость АМ и ХР 215
совместимость рефакторинга и АМ 216
совместное владение 79
совместное применение АМ
и рефакторинга 219
содержание важнее формы 63
создавайте несколько моделей
параллельно 70
создавайте простое содержание 80
создание эффективной рабочей среды 147
соотношение специалистов >
и универсалов 157
специалист по гибкому моделированию 29
спецификация 296
спецификация требований к ПО 285
способы борьбы с документацией 178
стандарты и нормы моделирования 103
стандарты и руководства 332
столбняк анализа 116
стремитесь к простоте разработки 340
сущностный прототип UI 71,91
сценарий использования 309
т
тест приемки 247
типовые усложнения разработки 54
типы групп моделирования 160
трассируемость 274,301
требования к CASE-средствам 142
триггер 242
трудности подтверждения
модели кодом 84
У
унифицированный процесс
рабочие потоки 257, 262, 263
этапы 257
унифицированный язык моделирования
(UML) 200
упорядочивающая методология 105
управление инфраструктурой
артефакты 270
цели 269
уровни устойчивости 101
участники сеансов моделирования 169
координатор 169
наблюдатель 170
секретарь 170
учитесь друг у друга 65
учитывайте тестируемость 83
Ф
факторы, влияющие на общение 110
факторы-индикаторы гибкого
моделирования 360
факторы-индикаторы негибкого
моделирования 360 .
факторы эффективного применения •
АМ 345
физическое представление 304
формализуйте модели соглашения 90
Алфавитный указатель 411
ц
ценности AM 53
ч
частичное применение AM 358
чем является гибкое моделирование 35
четко соблюдайте права и обязанности 123
число кирпичей 79
э
элементы Use Case и требования 338
элемент Use Case 70, 279
этапные сеансы моделирования 167
этапы ХР 221
исследование 222
итерации реализации 225
планирование 223
производство 227
сопровождение 228
ИНОСТРАННЫЕ ТЕРМИНЫ
В
Ьеап-сессия 307
bean-сущности EJB 307
С
CASE-средства 128, 244, 316'
S
SWA Online 37
и
UML-диаграмма классов 91
UML-диаграмма состояний 180
UMLbXP 212
UP и документация 339
Амблер Скотт
Гибкие технологии: экстремальное программирование
и унифицированный процесс разработки
Библиотека программиста
Перевела с английского Л. Калинникова
Главный редактор
Заведующий редакцией
Руководитель проекта
Научный редактор
Литературные редакторы
Художник
Иллюстрации
Корректоры
Верстка
Е. Строганова
А. Кривцов
В. Шрага
С. Орлов
С. Орлов, В. Шрага
Л. Аду веская
Л. Родионова
С. Беляева, Д. Стукалин
К. Кузьминский
Лицензия ИД № 05784 от 07.09.01.
Подписано к печати 20.09.04. Формат 70x100/16. Усл. п. л. 33,54. Тираж 3000. Заказ 926
ООО «Питер Принт», 194044, Санкт-Петербург, пр. Б. Сампсониевский, дом 29а.
Налоговая льгота—- общероссийский классификатор продукции ОК 005-93, том 2; 95 3005 — литература учебная.
Отпечатано с готовых диапозитивов в ОАО «Техническая книга»
190005, Санкт-Петербург, Измайловский пр., 29
КЛУБ ПР(О Х/Е С С И О К А Л
В1997 году по инициативе генерального директора Издательского дома«Питер»
Валерия Степанова й при поддержке деловых кругов города в Санкт-Петербурге
был основан «Книжный клуб Профессионал». Он собрал под флагом клуба про-
фессионалов своего дела, которых объединяет постоянная тяга к знаниям и любовь
к книгам. Членами клуба являются лучшие студенты и известные практики из раз-
. ных сфер деятельности, которые хотят стать или уже стали профессионалами в той
или иной области. ,
Как и все развивающиеся проекты, с течением времени книжный клуб вырос
в «Клуб Профессионал». Идею клуба сегодня формируют три основные «клубные»
функции:
• неформальное общение и совместный досуг интересных людей;
• участие в подготовке специалистов высокого класса
(семинары, пакеты книг по специальной литературе);
• формирование и высказывание мнений современного профессионала
(при встречах и на страницах журнала).
КАК ВСТУПИТЬ В КЛУБ?
Для вступления в «Клуб Профессионал» вам необходимо:
• ознакомиться с правилами вступления в «Клуб Профессионал»
на страницах журнала или на сайте www.piter.com;
• выразить свое желание вступить в «Клуб Профессионал»
по электронной почте postbook@piter.com или потел. (812) 103-73-74;
• заказать книги на сумму не менее 500 рублей в течение любого времени
или приобрести комплект «Библиотека профессионала».
«БИБЛИОТЕКА ПРОФЕССИОНАЛА»
Мы предлагаем вам получить все необходимые знания, подписавшись на «Библио-
теку профессионала». Она для тех, кто экономит не только время, но и деньги.
Покупая комплект - книжную полку «Библиотека профессионала», вы получаете:
• скидку 15% от розничной цены издания, без учета почтовых расходов;
• при покупке двух или более комплектов - дополнительную скидку 3%;
• членство в «Клубе Профессионал»;
• подарок - журнал «Клуо Профессионал».
ИЗДАТЕЛЬСКИЙ НОМ
ЮПИТЕР*
WWW.PITER.COM
Закажите бесплатный журнал
«Клуб Профессионал».
АНТИВИРУС
ИГОРЯ ДАНИЛОВА
Ж Ш1Г НИ'
Скотт Амблер
И УНИФИЦИРОВАННЫЙ НРОЦЕСС
РАЗРАБОТКИ
ISBN 5-94723-545-5
llll.lllllllllllllll II III I III II
___ ______z____ '_______ __
/Библио ГлобфЪ
Москва Мясницкая 6 Тел. 928-35-67
httpi/w’vw.bibllq-globus.ru. , 924-46-80
4 J liWii i I !i!i-
21 1 Mi
. .:>,j. "гзл i5t
мЬ..ер Г чбкие технологии:
Цена: 346j
Разработчики могут и должны работать
вместе и объединять свои усилия.
Но для этого им недостаточно одного
понимания и энтузиазма. Они должны
обладать навыками. Навыками анализа,
моделирования, проектирования,
программирования и тестирования.
При этом команда должна работать
в соответствии с принципами гибкой
разработки. Обо всем этом и говорит
Скотт Амблер в данной книге. Прочитав
ее, разработчик узнает обо всем,
что необходимо для эффективного
проектирования программных систем.
В книге рассматриваются идеи,
принципы и методология гибкого
моделирования, переосмысливаются
некоторые важные вопросы разработки
программного обеспечения: написание
документации, организация сеансов
моделирования, подбор команды,
занимающейся моделированием,
применение UML.
©WILEY С^ППТЕР
wiley.com www.piter.com