Автор: Sergey Teplyakov

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

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

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

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

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

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

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

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

Помогла статья? Оцените её!
0 из 5. Общее количество голосов - 0
 

You have no rights to post comments

Дмитрий Крикунов

Публикую статьи, обучающие курсы и новости по программированию: алгоритмам, языкам (С++, Java), параллельному программированию, паттернам и библиотекам (Qt, boost).