Человеческий фактор в программировании
Добавить в закладки К обложке
- Предисловие - Страница 1
- Предисловие к первому изданию - Страница 3
- IГрупповая разработка - Страница 5
- 2Консенсус и компромисс - Страница 7
- 4Скромный и высокопоставленный писарь - Страница 11
- 5Официальное пространство - Страница 14
- 6Раздражающие прерывания - Страница 17
- IIКовбои и ковгерлы - Страница 19
- 8Возвращение блудного ковбоя - Страница 22
- 9Единство в разнообразии - Страница 25
- 10Кодеры-ковбои и программисты-мудрецы - Страница 28
- IIIОрганизация работы - Страница 33
- 12Методы хаоса - Страница 36
- 13Открытая архитектура - Страница 39
- 14Синхронное плавание - Страница 42
- 15Командная политика - Страница 45
- 16Все сразу - Страница 47
- 17Заговор упрямцев - Страница 49
- IVИнструменты, модели и методы - Страница 51
- 19Вопросы моделирования - Страница 54
- 20Свет мой, зеркальце - Страница 56
- 21Методичное сумасшествие - Страница 58
- 22Говоря по существу - Страница 60
- 23Будущие формы - Страница 63
- 24Цели программного обеспечения - Страница 66
- 25Шито белыми нитками - Страница 69
- VСовершенствование процесса - Страница 73
- 27Повторение и вознаграждение - Страница 76
- 28Суперобучение - Страница 79
- 29Вверх по водопаду - Страница 81
- 30Своевременная поставка - Страница 83
- 31Под давлением - Страница 85
- 32Re: Архитектура - Страница 87
- 33Пошаговое улучшение качества - Страница 89
- VIЮзабилити программного обеспечения - Страница 95
- 35Сложность и прогрессирующий функционизм - Страница 98
- 36Назад к истокам - Страница 101
- 37Цветной язык - Страница 104
- 38Совершенствующиеся середнячки - Страница 107
- 39Пригодны ли вы - Страница 110
- 40Редактирование интерфейсов - Страница 113
- 41Сервис - Страница 115
- VIIУдобные объекты - Страница 117
- 43Глубокое понимание - Страница 121
- 44Абстрактные объекты - Страница 125
- 45Новая среда - Страница 128
- 46Полезные ситуации - Страница 132
- 47Эффективные объекты - Страница 136
- 48Связанные объекты - Страница 140
- VIIIЭто превосходное новое программное обеспечение - Страница 143
- 50Интерфейсы разнообразные - Страница 146
- 51Мастеры - Страница 148
- 52Образы будущего - Страница 150
- IXКультура и качество - Страница 152
- 54Агенты изменения - Страница 154
- 55Встроено самое лучшее - Страница 156
- 56Заметки из итальянского ресторана - Страница 159
- 57Наставничество - Страница 162
- 58На обучение - Страница 164
- 59Одаренные программисты - Страница 166
- 60Иконы отрасли - Страница 168
- 61Импресарио - Страница 170
- Приложение - Страница 172
- Библиография - Страница 174
22Говоря по существу
Если для того чтобы добраться до работы или дома, нужно преодолеть 11 ООО миль, то поневоле задумаешься о том, что является предметами первой необходимости. Когда вы упаковываете вещи в чемоданы и коробки, рассчитывая прожить год за границей, это делает еще более отчетливой разницу между тем, что «нужно», и тем, что «хочется», поскольку тарифы на лишнюю кладь составляют более 90 долларов за сумку. В разработке программ и приложений также важно прежде всего рассмотреть самое главное, то есть отделить основную часть того, что вам нужно программировать, от несущественных требований и ненужных предположений.
Сущностное моделирование — это концептуальный инструмент, предназначенный для акцентирования внимания разработчика на главном. Сущностная модель описывает ядро приложения, извлекая из задачи самое необходимое и отделяя все ненужные или ограничивающие предположения.
Понятие сущностного моделирования в разработке программ происходит, по крайней мере, от идей структурного проектирования. Схемы потоков данных были придуманы в качестве непроцедурной модели вычислений, которая отделяла суть того, что должен был выполнить компьютер, от того, как это должно быть исполнено посредством алгоритма или процедуры. Модульная конструкция, соответствующая сути задачи, позволяет создавать более надежное программное обеспечение, основа которого сохраняется при изменениях в деталях процесса. По крайней мере, такова была идея. На практике схемы потоков данных зачастую превращались чуть ли не в обыкновенные блок-схемы с забавными символами. Последующие дополнения, такие как сохранение данных и управляю-щая логика, неявным образом способствовали процедурному мышлению. В конце концов сущностные модели получили признание с появлением книги «Essential Systems Analysis» (Основы системного анализа) (МсМе-namin и Palmer, 1984). Эта книга, признанная сегодня классической, сделала сущностные модели краеугольным камнем перестроенного и обновленного метода структурного анализа.
В более широком смысле сущностные модели отображают суть системы. Они представляют собой идеализированные и абстрактные описания, свободные от технологий и соответствующие намерениям пользователей и фундаментальному назначению системы. Лучшими сущностными моделями становятся те, которые подвергаются упрощению и обобщению в процессе многократных уточнений. Они отражают дух приложения, а не его физическое воплощение в виде реального кода, работающего на реальной технике.
Сущностная модель основывается на идеальной технологии: бесконечно быстрые компьютеры, сколь угодно большие мониторы, бесклавиатурные системы ввода данных. Есть все, что может понадобиться для наиболее быстрой реализации необходимых функций. Такой полет технической фантазии — это не дань воображению, а обеспечение максимальной независимости модели от современного уровня технологии. Технология меняется намного быстрее, чем практика деловых отношений или люди; решения, которые слишком тесно привязаны к какой-либо технологии, безусловно, менее живучи и гибки.
Сущностные интерфейсыРазработка пользовательских интерфейсов — это одна из областей, где сущностные модели могут найти хорошее применение. Моделирование сущностных пользовательских ситуаций при проектировании интерфейсов является подходом, расширяющим разработанный Джекобсоном (Jacobson и др., 1992 [44]) метод объектно-ориентированных пользовательских ситуаций. Сущностная пользовательская ситуация — это абстрактный сценарий одного законченного и полезного взаимодействия с системой, рассматриваемого с точки зрения намерений или цели пользователя. Это обобщенное описание вида или категории использования системы, которое передает действия пользователя и ответы системы[28] в упрощенной и обобщенной форме. Суть идеи состоит в том, что разрабатываемые интерфей-сы должны соответствовать намерениям пользователей — тому, что пользователи хотят достичь. Исходные условия, связанные с технологией, — форма визуальных компонентов или даже вид устройств, применяемых для взаимодействия, — должны быть минимальны.
Для примера возьмем задачу по извлечению наличных денег из банкомата. Физическая модель может быть следующей: клиент вставляет карту; система читает информацию с магнитной полоски и запрашивает PIN-код;[29] пользователь вводит PIN-код; система подтверждает PIN-код и предлагает меню возможных операций; пользователь выбирает нужную операцию; система предлагает меню счетов; пользователь выбирает счет; система запрашивает сумму; пользователь вводит сумму и нажимает на кнопку подтверждения; система выдает наличность; пользователь берет деньги и убегает. Что может быть проще?
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176