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

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

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

Meyer, Bertrand. Object-Oriented Software Construction, 2d ed. - New York, NY: Prentice Hall PTR, 1997. Мейер приводит убедительные доводы в защиту чистого объектно-ориентированного программирования.

Raymond, Eric S. The Art of UNIX Programming. - Boston, MA: Addison-Wesley 2004. Эта книга - хорошо обоснованный взгляд на проектирование ПО сквозь призму UNIX. В разделе 1.6 приведено лаконичное объяснение 17 ключевых принципов проектирования ПО для UNIX.

Larman, Craig. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2d ed. - Englewood Cliffs, NJ: Prentice Hall, 2001. Это популярное введение в объектно-ориентированное проектирование в контексте метода Unified Process. Кроме того, здесь обсуждается объектно-ориентированный анализ.

Теория проектирования ПО

Parnas, David L, and Paul С. Clements. «А Rational Design Process: How and Why to Fake It». - IEEE Transactions on Software Engineering SE-12, no. 2 (February 1986): 251-57. В этой классической статье описывается разрыв между реальным и желательным процессами проектирования программ. Суть статьи в том, что в действительности никто никогда не следует рациональному упорядоченному процессу проектирования, но стремление к этому приводит в итоге к созданию лучших проектов.

Работы, в которых было бы приведено исчерпывающее обсуждение сокрытия информации, мне неизвестны. В большинстве учебников по разработке ПО оно обсуждается кратко, часто в контексте объектно-ориентированных подходов. Наверное, до сих пор лучшими материалами по сокрытию информации являются три статьи, принадлежащие перу Парнаса.

Parnas, David L. «Оп the Criteria to Be Used in Decomposing Systems into Modules». -

Communications of the ACM 5, no. 12 (December 1972): 1053-58.

Parnas, David L. «Designing Software for Ease of Extension and Contraction». - IEEE

Transactions on Software Engineering SE-5, no. 2 (March 1979): 128-38.

Parnas, David L, Paul С Clements, and D. M. Weiss. «The Modular Structure of Complex Systems».

- IEEE Transactions on Software Engineering SE-11, no. 3 (March 1985); 259-66.

Шаблоны проектирования

Gamma, Erich, et al. Design Patterns. - Reading, MA: Addison-Wesley, 1995. Очень полезная книга о шаблонах проектирования, написанная «Бандой четырех».

Shalloway, Alan, and James R. Trott. Design Patterns Explained. - Boston, MA: Addison-Wesley, 2002. Данная книга представляет собой несложное введение в шаблоны проектирования.

«Бандой четырех (Gang of Four)» называют группу авторов, в которую входят Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон Влиссидес. ~ Пргш. перев.



Проектирование в общем

Adams, James L Conceptual Blockbusting: A Guide to Better Ideas, 4th ed. - Cambridge, MA: Perseus Publishing, 2001. Нельзя сказать, что эта книга посвящена непосредственно проектированию ПО, но это не умаляет ее достоинств: она была написана как учебник по проектированию для студентов инженерного факультета Стэн-фордского университета. Даже если вы никогда ничего не проектировали и не проектируете, в ней вы найдете увлекательное обсуждение творческого мышления и много упражнений, позволяющих развить мышление, для эффективного проектирования. Кроме того, данная книга включает список литературы, посвященной проектированию и творческому мышлению, с подробными аннотациями. Если вам нравится решать проблемы, вам понравится эта книга.

Polya, G. How to Solve It: A New Aspect of Mathematical Method, 2d ed. - Princeton, NJ: Princeton University Press, 1957. Это обсуждение эвристики и решения проблем концентрируется на математике, но актуально и для разработки ПО. Книга Полья стала первым трудом, посвященным применению эвристики для решения математических проблем. В ней проводится четкое различие между небрежной эвристикой, используемой для обнаружения решений, и более аккуратными методами, которые применяются для представления найденных решений. Читать ее нелегко, но если вы интересуетесь эвристикой, то в итоге все равно прочитаете ее, хотите вы того или нет. Полья ясно показывает, что решение проблем не является детерминированным процессом и что приверженность единственной методологии аналогично ходьбе в кандалах. Когда-то в Microsoft эту книгу выдавали всем новым программистам.

Michalewicz, Zbigniew, and David В. Fogel. How to Solve It: Modem Heuristics. - Berlin: Springer-Verlag, 2000. Это обновленный вариант книги Полья, который содержит некоторые нематематические примеры и менее требователен к читателю.

Simon, Herbert. The Sciences of the Artificial, 3d ed. - Cambridge, MA: MIT Press, 1996. В этой интересной книге проводится различие между науками, имеющими дело с естественным миром (биология, геология и т. д.), и науками, изучающими искусственный мир, созданный людьми (бизнес, архитектура и информатика). Затем в ней обсуждаются характеристики наук об искусстбенном, при этом особое внимание уделяется проектированию. Книга написана в академическом стиле, и ее следует прочитать всем, кто решил сделать карьеру в области разработки ПО или любой другой «искусственной» области.

Glass, Robert L. Software Creativity. - Englewood Cliffs, NJ: Prentice Hall PTR, 1995. Что в большей степени управляет процессом разработки ПО: теория или практика? Является ли он преимущественно творческим или преимущественно детерминированным? Какие интеллектуальные качества нужны разработчику ПО? В этой книге приведено интересное обсуждение природы разработки ПО со специфическим акцентом на проектировании.

Petroski, Henry. Design Paradigms: Case Histories of Error and judgment in Engineering. - Cambridge: Cambridge University Press, 1994. Главная идея этой книги в том, что анализ прошлых неудач способствует успешному проектированию не в меньшей, а то и в большей степени, чем исследование прошлых успехов. В подтверждение своей позиции автор приводит многие факты из области гражданского строительства (особенно проектирования мостов).



Стандарты

ШЕЕ Std 1016-1998, Recommended Practice for Software Design Descriptions. Данный документ содержит стандарт IEEE-ANSI описания проектов ПО, определяющий, что следует включать в проектную документацию.

IEEE Std 1471-2000. Recommended Practice for Architectural Description of Software Intensive Systems. Los Alamitos, CA: IEEE Computer Society Press. Этот документ представляет собой руководство IEEE-ANSI по созданию спецификаций архитектуры ПО.

Контрольный список: проектирование при конструировании Методики проектирования

□ Выполнили ли вы несколько итераций проектирования, Шр: сс2в.сош/0527 выбрав самую лучшую попытку, а не просто первую?

□ Попробовали ли вы выполнить декомпозицию системы несколькими способами с целью нахождения наилучшего варианта?

□ Использовали ли вы для решения проблемы и нисходящий, и восходящий способы проектирования?

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

□ Был ли выполнен формальный или неформальный обзор вашего проекта другими разработчиками?

□ Довели ли вы проектирование до той точки, в которой реализация проекта кажется очевидной?

□ Выполнили ли вы регистрацию проекта уместными способами, такими как Wiki, электронная почта, плакаты, цифровые фотографии, UML, карточки CRC или комментарии в самом коде?

Цели проектирования

□ Адекватно ли проект решает проблемы, которые были определены и отложены на этапе разработки архитектуры?

□ Разделен ли проект на уровни?

□ Удовлетворены ли вы тем, как выполнена декомпозиция программы на подсистемы, пакеты и классы?

□ Удовлетворены ли вы тем, как выполнена декомпозиция классов на методы?

□ Достигнуто ли минимальное взаимодействие классов между собой?

□ Спроектированы ли классы и подсистемы так, чтобы их можно было использовать в других системах?

□ Будет ли программа легкой в сопровождении?

□ Является ли проект полным, но минимальным? Все ли его части действительно необходимы?

□ Подразумевает ли проект использование только стандартных методик? Смогли ли вы избежать применения экзотических, трудных для понимания элементов?

□ Помогает ли проект в целом минимизировать и несущественную, и существенную сложность?



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