Предисловие
О конспекте. По большей части это не конспект, а цитатник. Мест, где что-то переформулировано или изменено, крайне мало. Для каждой цитаты указан контекст, в котором она была обнаружена.
О возможной пользе для читающего. Этот конспект можно рассматривать в качестве источника для определений; источника для проверки своей «картины мира», поиска потенциально туманных мест в ней и возможности их точечного фикса; в качестве материала для проведения семинаров в рамках своей компании/команды с целью синхронизации профессиональных взлядов на разработку ПО в целом.
Благодарности. Большое спасибо Павлу Аргентову за внимательное ревью и советы в процессе работы над статьей. Спасибо моей команде парней, с которыми я имею честь трудиться и задумываться о высоких и низких материях. Спасибо моей компании Evrone за комфортную среду обитания. И конечно, отдельное спасибо читающему статью.
Источник
Объектно-ориентированнй анализ и проектирование с примерами приложений (3-е издание)
Гради Буч
ISBN 978-5-8459-1401-9
ISBN 0-201-89551-X
О книге
Иногда в руки попадается не просто книга. Читая ее, ловишь себя на мысли о том, что недоумеваешь, как автору удалось осознать столь много и в таких деталях, удивляешься стройностью его мысли, логичностью его высказываний. Преисполняешься восхищением и глубочайшим уважением. Конечно, тут же слегка расстраиваешся от осознания подлинного «величия» собственого ума и опыта. Однако, прийдя в себя, начинаешь понимать, что это просто труд… великий труд, представляющий концентрат, возможно, всей его профессиональной жизни.
Конспект
Сэр Исаак Ньютон по секрету признался друзьям, что он знает, как гравитация ведет себя, но не знает, почему.
(Lily Tomlin, The Search for Signs of Intelligent Life in the Universe)
Глава 1. Сложность
Чем сложнее система, тем она уязвимее. [5]
Трудно себе представить строителя, размышляющего, а не вырыть ли еще один подвальный этаж под уже построенным стоэтажным зданием. Такое мероприятие было бы слишком дорогим и опасным. Как ни странно, пользователи программного обеспечения, не задумываясь, просят делать аналогичные именения в программах. Более того, они считают. что для программиста эта задача не представляет никаких трудностей.
Структура сложных систем
… (emergent behaviour): поведение целого сложнее, чем поведение суммы его составляющих.[6]
Сложность присущая программному обеспечению
Эйнштейн полагал, что должно существовать простое описание природы, так как Бог не действует случайным образом. У программиста нет такого утешения: сложность, которую он должен преодолевать, носит произвольный характер. [1]
Брукс утверждает: Сложность программного обеспечения является существенным, а не случайным свойством [3]. Это объясняется четырьмя причинами: сложностью предметной области, трудностью управления разработкой программного обеспечения, необходимостью обеспечить гибкость программ, а также сложностью описания функционирования дискретных систем.
… сопровождением (maintenance) называется исправление выявленных ошибок, эволюцией (evolution) — реакция на изменение технических требований, а сохранением (preservation) — попытка всеми возможными средствами продлить функционирование устаревших и распадающихся частей программного обеспечения.
Задача группы проектировщиков — создать иллюзию простоты.
При коллективной разработке программного обеспечения главной задачей руководства является обеспечение единства и целостности проекта.
Сложность описания дискретных систем
Бросая мяч в воздух, мы можем точно предсказать его траекторию, потому что в нормальных условиях действуют определенные физические законы. Мы бы очень удивились, если бы, бросив мяч чуть сильнее, обнаружили, что на середине пути он неожиданно остановился и полетел вертикально вверх.
Парнас (Parnas) утверждает: «Когда мы говорим, что система описывается непрерывной функцией, мы имеем ввиду, что в ней нет скрытых сюрпризов. Небольшие изменения входных параметров всегда вызывают небольшие изменения результатов» [4]
Пять признаков сложной системы
1. Иерархическая структура (Hierarchic Structure)
Часто сложность проявляется в виде иерархии, при этом сложные системы состоят из взаимозависимых подсистем, имеющих, в свою очередь, собственные подсистемы, и т.д., вплоть до самого низкого уровня, образованного элементарными компонентами. [7]
Все системы имеют подсистемы, и все системы являются частями более крупных систем… Сущность системы определяется отношениями между ее частями, а не частями как таковыми [9].
2. Относительность выбора элементарных компонентов (Relative Primitives)
Как правило, наблюдатель произвольно решает, какие компоненты в данной системе считать элементарными
3. Разделение обязанностей (Separation of Concerns)
Связи внутри компонентов обычно сильнее, чем связи между компонентами (связность и увязка). Это разделение между внутри- и межкомпонентными взаимодействиями позволяет провести разделение обязанностей (separation of concerns) между частями системы и изучать их по отдельности.
4. Общие шабоны (Common Patterns)
Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных
5. Стабильные промежуточные формы (Stable Intermediate Forms)
Любую работоспособную сложную систему можно разложить на устойчивые промежуточный формы начинающиеся с некоторой более простой работоспособной системы и т.д. до последней формы
Любая работоспособная сложная система является итогом эволюции более простой работоспособной системы… Сложная система, разработанная «с нуля», никогда не работает так как надо, и никакие «заплатки» не заставят ее работать правильно. Проектирование следует начинать с простой работоспособной системы [13].
Организованная и неорганизованная сложность
Ни одну архитектуру нельзя назвать единственно правильной. Это обстоятельство порождает основную проблему, связанную с архитектурой системы, — поиск баланса между множеством разных способов организации компонентов, пятью атрибутами сложных систем и потребностями пользователей.
Эксперименты психологов, например Миллера, показывают, что максимальное количество порций информации, которыми человек может оперировать одновременно, приблизительно равно семи (плюс-минус две) [14]
Упорядочение хаоса
Способ управления сложными системами известен с античных времен — divide et impera (разделяй и властвуй) [16]. При проектировании сложной системы программного обеспечения необходимо разделять ее на все меньшие и меньшие части, каждую из которых можно уточнять независимо друг от друга. В этом случае мы не выйдем за пределы реальных возможностей человеческого мозга.
Какой способ декомпозиции правильнее: по алгоритмам или по объектнам?… Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое значение агентам, которые являются либо объектами, либо субъектами действия.
В 60-70-е годы было разработано много методов, помогающих справиться с растущей сложностью программ.… Тогда же стали появляться компьютеры еще больших, поистине гигантских возможностей. Значение структурного подхода осталось прежним, но как замечает Стейн, «оказалось, что структурный подход не работает, если объем программы превышает приблизительно 100000 строк» [19].
«Люди развили чрезвычайно эффективную технологию преодоления сложности. Мы абстрагируемся от нее. Будучи не в состоянии полностью воссоздать сложный объект, мы просто игнорируем не слишком важные детали и, таким образом, имеем дело с обобщенной, идеализированной моделью объекта» [36].
О проектировании сложных систем
«Разработка новых структур предполагает и полет фантазии, и синтез опыта и знаний: все то, что необходимо художнику для реализации своего замысла на холсте или бумаге. После того, как этот замысел созрел в голове инженера-художника, он обязательно должен быть проанализирован с точки зрения применимости данного научного метода инженером-ученым со всей тщательностью, присущей настоящему ученому» [38].
«Программная постановка задачи является упражнением в применении абстракции и требует способностей как формального математика, так и компетентного инженера» [39]
«Цель проектирования — выявление ясной и относительно простой внутренней структуры, иногда называемой архитектурой… Проект есть окончательный продукт процесса проектирования» [41]
Примечание
[1] Brooks, F. April 1987. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer vol. 20(4), p. 12.
[3] Brooks. No Silver Bullet, p. 11.
[4] Parnas, D. July 1985. Software Aspects of Strategic Defense Systems. Victoria, Canada: University of Victoria, Report DCS-47-IR.
[5] Peter, L. 1986. The Peter Pyramid. New York, NY: William Morrow, p. 153.
[6] Waldrop, M. 1992. Complexity: The Emerging Science at the Edge of Order and Chaos. New York, NY: Simon and Schuster.
[7] Courtois, P. June 1985. On Time and Space Decomposition of Complex Structures. Communications of the ACM vol. 28(6), p. 596.
[9] Rechtin, E. October 1992. The Art of Systems Architecting. IEEE Spectrum vol. 29(10), p. 66.
[13] Gall, J. 1986. Systemantics: How Systems Really Work and How They Fail. Second Edition. Ann Arbor, MI: The General Systemantics Press, p. 65.
[14] Miller, G. March 1956. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Review vol. 63(2), p. 86.
[16] Dijkstra, E. 1979. Programming Considered as a Human Activity. In Classics in Software Engineering. New York, NY: Yourdon Press, p. 5.
[19] Stein, J. March 1988. Object-Oriented Programming and Database Design. Dr. Dobb's Journal of Software Tools for the Professional Programmer no. 137, p. 18.
[36] Shaw, M. (ed.). 1981. ALPHARD: Form and Content. New York, NY: Springer-Verlag, p. 6.
[38] Petroski, H. 1985. To Engineer Is Human. New York, NY: St. Martin's Press, p. 40.
[39] Dijkstra, E. January 1993. American Programmer vol. 6(1).
[41] Stroustrup, B. 1991. The C+ Programming Language. Second Edition. Reading, MA: Addison-Wesley, p. 366.