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

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

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

Высокий коэффициент объединения по входу При высоком коэффициенте объединения по входу (fan-in) к конкретному классу обращается большое число других классов. Это значит, что система предусматривает интенсивное использование вспомогательных низкоуровневых классов.

Низкий или средний коэффициент разветвления по выходу Это означает, что конкретный класс обращается к малому или среднему числу других классов. Высокий коэффициент разветвления по выходу (fan-out) (более семи) говорит о том, что класс использует большое число других классов и, возможно, слишком сложен. Ученые обнаружили, что низкий коэффициент разветвления по выходу выгоден как в случае вызова методов из метода, так и в случае вызова методов из класса (Card and Glass, 1990; Basili, Briand, and Melo, 1996).

Портируемость Проектируйте систему так, чтобы ее можно было легко адаптировать к другой среде.

Минимальная, но полная функциональность Этот аспект подразумевает отсутствие в системе лишних частей (Wirth, 1995; McConnell, 1997). Вольтер говорил, что книга закончена не тогда, когда в нее больше нечего добавить, а когда из нее ничего нельзя выбросить. При разработке ПО это верно вдвойне, потому что дополнительный код необходимо разработать, проанализировать, протестировать, а также пересматривать при изменении других фрагментов программы. Кроме того, в будущих версиях приложения придется поддерживать обратную совместимость с дополнительным кодом. Опасайтесь вопроса: «Эту функцию реализовать легко - почему бы этого не сделать?»

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

Яш як О Т0 Например, если вы создаете современную систему, которая

IbZ шшйШйсГр должна использовать большой объем старого, плохо спро-дел 24.6, ектированного кода, напишите уровень, отвечающий за взаи-

модействие со старым кодом. Спроектируйте этот уровень так, чтобы он скрывал плохое качество старого кода, предоставляя более новым уровням согласованный набор сервисов. Пусть остальные части системы работают с этими классами вместо старого кода. Такой подход сулит два преимущества: 1) он изолирует плохой код и 2) если вы когда-нибудь решите выбросить старый код или выполнить его рефакторинг, вам не придется изменять новый код за исключением промежуточного уровня.

Соответствие стандартным методикам Чем экзо-ееыш Об осо-

бвн«опа0шомтипест>атифи- ™чнее система, тем сложнее будет другим программистам кацшпришнешй шаблонов понять ее. Попытайтесь придать всей системе привычный проешвашя см, лодраз- для разработчиков облик, применяя стандартные популяр-дел «Старайтесь использовать ные подходы, популярные шаблоны лроекти-роеания» раздела 5.3.



Уровни проектирования

Проектирование программной системы требует нескольких уровней детальности. Некоторые методы проектирования используются на всех уровнях, а другие только на одном-двух (рис. 5-2).

(D Программная система

I Разделение системы на подсистемы/пакеты

(D Разделение пакетов на классы


® Разделение классов на данные и методы

(D Проектирование методов

Рис. 5-2. Уровни проектирования программы. Систему (1) следует разделить

на подсистемы (2), подсистемы - на классы (3), а классы - на методы и данные (4);

методы также необходимо спроектировать (5)

Уровень 1: программная система

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

Уровень 2: разделение системы на подсистемы или пакеты

Главный результат проектирования на этом уровне - определение основных подсистем. Подсистемы могут быть

Иными словами - и зто неизменный принцип, на котором основан всегалактический успех всей корпорации, - фундаментальные изъяны конструкции ее товаров камуфлируктся их внешними изъянами.

Лтс Адат (Douglas Adams)



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

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

Допустим, вы определили систему из шести подсистем (рис. 5-3). При отсутствии каких-либо ограничений в силу второго закона термодинамики энтропия системы должна увеличиться. Один из способов увеличения энтропии является абсолютно свободное взаимодействие между подсистемами (рис. 5-4).



Рис. 5-3. Пример системы, включающей шесть подсистем


Рис. 5-4. Возможный результат отсутствия правил, ограничивающих взаимодействие подсистем

Как видите, в итоге все подсистемы начинают напрямую взаимодействовать, что поднимает несколько важных вопросов:

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



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.0112