Главная - Литература

0 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 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294


Рис. 3-7. Не имея хорошей архитектуры, вы можете решать правильную проблему, но прийти к неправильному решению. Успешное конструирование может оказаться невозможным

Внесение изменений в архитектуру при конструировании и на последующих этапах обходится недешево. Время, необходимое для исправления ошибки в архитектуре ПО, сопоставимо со временем, нужным для исправления ошибки в требованиях, т. е. превышает временные затраты на исправление ошибки в коде (Basili and Perricone, 1984; Willis, 1998). Изменения архитектуры похожи на изменения требований еще и тем, что кажущиеся небольшими изменения могут иметь далеко идущие последствия Чем бы ни были обусловлены изменения архитектуры - исправлением ошибок или внесением улучшений, - чем раньше вы осознаете их необходимость, тем лучше.

Типичные компоненты архитектуры

Удачные архитектуры имеют много общего. Если всю систе-Перекрестная ссылка О низко- Jt-

УРО8Н0ВОМ проектирована про- создаете самостоятельно, работа над архитектурой

rpaMMfet см. главы 5-9. будет перекрываться с более детальным проектированием

В этом случае вам следует по крайней мере обдумать каждый компонент архитектуры. Если вы работаете над системой, архитектура которой была разработана кем-то другим, вы должны уметь определять ее важные компоненты без охотничьей собаки и увеличительного стекла Как бы то ни было, далее приведен список компонентов архитектуры, на которые следует обратить внимание.

Организация программы

Если вы не можете объяснить "РУ очередь архитектура должна включать общее опи-

нто-то шестилетнему ребешу, значит, вы сами этого не понимаете,

Альберт Эйнштейн

сание системы. Без такого описания вам будет трудно составить согласованную картину из тысячи деталей или хотя бы десятка отдельных классов. Если бы система была мозаикой из 12 фрагментов, ее мог бы с легкостью собрать и годовалый ребенок Головоломку из 12 подсистем собрать труднее, но, если вы не сможете сделать этого, вы не поймете, какой вклад вносит в систему разрабатываемый вами класс

Архитектура должна включать подтверждения того, что при ее разработке были рассмотрены альтернативные варианты, и обосновывать выбор окончательной организации системы. Никому не хочется разрабатывать класс, если его роль в системе не кажется хорошо обдуманной. Описывая альтернативные варианты,



архитектура обосновывает организацию системы и показывает, что роль каждого класса была тщательно рассмотрена. В одном обзоре методик проектирования было обнаружено, что обоснование проекта программы не менее важно для ее сопровождения, чем сам проект (Rombach, 1990).

Архитектура должна определять основные компоненты

lieiteitiiectKdii СгСыдкд Об ис-

программы. В зависимости от размера программы ее ком- j, проектировав понентами могут быть отдельные классы или подсистемы, компонентах разных уров-состоящие из нескольких классов. Каждый компонент яв- ней ом. яощшцея «Урош йро-ляется классом или набором классов/методов, которые в шщоътт» раздела 5.2. совокупности реализуют высокоуровневые функции программы, такие как взаимодействие с пользователем, отображение Web-страниц, интерпретация команд, инкапсуляция бизнес-правил или доступ к данным. За каждую функцию приложения, указанную в требованиях, должен отвечать хотя бы один компонент. Если функцию реализуют несколько компонентов, они должны сотрудничать, а не конфликтовать.

Архитектура должна четко определять ответственность каж-

дого компонента. Компонент должен иметь одну область (йьет сведений, швее-ответственности и как можно меньше знать об областях ных компонентам друг о дру-ответственности других компонентов. Сведя к минимуму ге, - главнуй аспект сокрытйя объем сведений, известных компонентам о других компо- информации. Подробности ом. нентах, вы сможете локализовать информацию о проекте подразделе «Скрывайте сек-

реты {к вопросу о сокрытии

приложения в отдельных компонентах. информации), раздела 5.3.

Архитектура должна ясно определять правила коммуникации для каждого компонента. Она должна описывать, какие другие компоненты данный компонент может использовать непосредственно, какие косвенно, а какие вообще не должен использовать.

Основные классы

Архитектура должна определять основные классы приложе-

/ . 11щ1е«рвстнай ссылиа О проек-

ния, их области ответственности и механизмы взаимодеи- жировании классов см главу 6 ствия с другими классами. Она должна описывать иерархии классов, а также изменения состояний и время существования объектов. Если система достаточно велика, архитектура должна описывать организацию классов в подсистемы.

Архитектура должна описывать другие рассматривавшиеся варианты организации классов и обосновывать итоговый вариант. Не все классы системы нужно описывать в спецификации архитектуры. Ориентируйтесь на правило 80/20: описывайте 20% классов, которыми на 80% определяется поведение системы (Jacobsen, Booch, and Rumbaugh, 1999; Kruchten, 2000).

Организация данных

Архитектура должна описывать основные виды формата

фаилов и таблиц. Она должна описывать рассмотренные аль- JJ,,,, переменных см. тернативы и обосновывать итоговые варианты. Если при- jggy 1М1 ложение использует список идентификаторов клиентов и

разработчики архитектуры решили реализовать его при помощи списка с после-

3-403



довательным доступом, в документации должно быть сказано, почему этот вид списка лучше, чем список с произвольным доступом, стек или хэш-таблица. Эта информация окажет вам неоценимую помощь во время конструирования и сопровождения программы, подсказав, чем руководствовались разработчики архитектуры. Без нее вы будете чувствовать себя зрителем, который смотрит иностранный фильм без субтитров.

Прямой доступ к данным обычно следует предоставлять только одной подсистеме или классу; исключения возможны при использовании классов или методов доступа, обеспечивающих доступ к данным, контролируемым абстрактным образом. Подробнее об этом см. подраздел «Скрывайте секреты (к вопросу о сокрытии информации)» раздела 5.3.

Архитектура должна определять высокоуровневую организацию и содержание всех используемых БД. Архитектура должна объяснять, почему одна БД предпочтительнее, чем несколько (или наоборот), почему БД предпочтительнее, чем однородные файлы, определять возможные типы взаимодействия приложения с другими программами, использующими те же данные, объяснять, как будут отображаться данные, и т. д.

Бизнес-правила

Архитектура, зависимая от специфических бизнес-правил, должна определять их и описывать их влияние на проект системы. Возьмем для примера бизнес-правило, согласно которому информация о клиентах должна устаревать не более чем на 30 секунд. В данном случае в спецификации архитектуры должно быть указано, как это правило повлияло на выбор метода обеспечения актуальности данных и их синхронизации.

Пользовательский интерфейс

Пользовательский интерфейс (GUI) часто проектируется на этапе выработки требований. Если это не так, его следует определить на этапе разработки архитектуры. Архитектура должна описывать главные элементы формата Web-страниц, GUI, интерфейс командной строки и т. д. Удобство GUI может в итоге определить популярность или провал программы.

Архитектура должна быть модульной, чтобы GUI можно было изменить, не затронув бизнес-правил и модулей программы, отвечающих за вывод данных. Например, архитектура должна обеспечивать возможность сравнительно легкой замены группы классов интерактивного интерфейса на группу классов интерфейса командной строки. Такая возможность весьма полезна; во многом это объясняется тем, что интерфейс командной строки удобен для тестирования ПО на уровне блоков или подсистем.

Проектирование GUI заслуживает отдельной книги, и мы его Шр: ос2ехот/039$ рассматривать не будем.

Управление ресурсами

Архитектура должна включать план управления ограниченными ресурсами, такими как соединения с БД, потоки и дескрипторы. При разработке драйверов, встроенных систем и других приложений, которые будут работать в условиях ограни-



0 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 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



0.0022