вторник, 15 сентября 2009 г.

Книга Гради Буча и др. "Объектно-ориентированный анализ и проектирование с примерами приложений"

Booch_OOA_And_OOD_2007 «Звезда в преддверии коллапса; ребенок, который учится читать; клетки крови, атакующие вирус, - это только некоторые из потрясающе сложных объектов физического мира. Компьютерные программы тоже бывают сложными, однако их сложность совершенно другого рода. … Эйнштейн утверждал, что должны существовать простые объяснения природных процессов, так как Бог не действует из каприза или по произволу. У программиста нет такого утешения: сложность, с которой он должен справиться, лежит в самой природе системы».

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

Авторы пишут: «Эксперименты психологов, например, Миллера, показывают, что максимальное количество порций информации, которыми человек может оперировать одновременно, приблизительно равно семи (плюс-минус две). Вероятно, это ограничение пропускной способности информационного канала связано с объемом краткосрочной памяти человека». И именно это ограничение является своего рода лакмусовой бумажкой при объектно-ориентированной декомпозиции сложной системы.

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

Во второй части книги, авторы описывают метод построения сложных систем, основанный на объектной модели. Сначала вводится система графических обозначений (теперь в книге используется язык UML, вместо «нотации Буча»), а затем рассматриваются основы обобщенного процесса разработки. Вот, что они говорят: «Дилетанты постоянно ищут некий волшебный метод или инструмент, который мог бы сделать процесс разработки программ тривиальным. В отличие от них, профессионалы знают, что такой панацеи не существует. Дилетанты хотят иметь готовые рецепты; профессионалы знают, что такой подход ведет к негодным проектным решениям и нагромождению лжи, за которой разработчики скрываются от ответственности за ранее принятые неверные решения. Дилетанты либо игнорируют документацию вообще, либо делают из нее фетиш, заботясь больше о том, как их бумажный продукт выглядит в глазах заказчика, чем о его сути. Профессионал признает важность документации, но всегда отдает предпочтение разумным архитектурным новшествам. Процесс объектно-ориентированного анализа и проектирования невозможно описать с помощью рецептов, однако он определен достаточно хорошо, чтобы стать основой прогнозируемого и воспроизводимого процесса разработки программного обеспечения».

Авторы подчеркивают важность архитектурной целостности, итеративного и поступательного жизненного цикла разработки. Интересной особенностью изложения является то, что авторы не считают рациональный унифицированный процесс разработки единственно верным во всех случаях, а ускоренные методы (agile process) неверными в корне. «Выбирая между ускоренным и планомерным проектированием, следует оценивать риск. С какими рисками сталкивается проект? Выберите стиль и соответствующие методы, минимизирующие эти риски…. Выбор процесса проектирования не означает, что работа сделана. Этот процесс следует уточнять на протяжении всего жизненного цикла проекта. Инструменты, работающие хорошо, следует оставить, а инструменты, работающие плохо, - исключить. Целью должен быть непрерывный процесс усовершенствования, основанный на практическом опыте».

Третья часть книги состоит из примеров приложений, охватывающих разные предметные области. Основная проблема примеров в области объектно-ориентированного анализа и проектирования является то, что очень сложно в них показать итеративность процесса разработки. Нельзя на страницах книги рассказать, как думает «выдающийся проектировщик», принимая те или иные решения. Как он анализирует требования, как он чувствует, где кроется подвох и нужно эти требования уточнить у пользователя, а в каком случае связаться с экспертом предметной области. Как правильно выявить абстракции, с какой стороны на них лучше смотреть, как выявить существенные характеристики некоторого объекта именно для вашей задачи. Все это, к сожалению, очень сложно описать на примерах. Но при всем при этом примеры полезны и могут помочь вам сделать определенные выводы в тех или иных обстоятельствах вашей профессиональной деятельности.

Так сможет ли эта книга сделать из вас превосходного архитектора? Честно говоря, не знаю… Ведь процесс познания, точно также, как и процесс разработки программного обеспечения, является итеративным и поступательным. Одно только наличие этой книги на полке не является гарантией успеха ваших проектов. Прочитав эту книгу, вы не сможете в первом своем проекте с легкостью анализировать противоречивые требования пользователя, вам не откроются тайны объектно-ориентированной декомпозиции и ваши абстракции будут далеки от идеала. Ведь книга – это всего лишь направление, это не автострада, по которой вы сможете пронестись на бешеной скорости, это всего лишь еле заметная дорожка через тернистый путь, имя которому – объектно-ориентированный анализ и проектирование.

1 комментарий:

  1. Стоит ли читать русский перевод? Или лучше осилить в оригинале, что значительно сложнее? А то видел огромное количество плохих отзывов на эту книгу именно из-за качества перевода...

    ОтветитьУдалить