Сертификация архитекторов J2EE-приложений

Сертификация как способ повышения рыночной стоимости услуг специалиста или компании стала сегодня весьма популярной темой. В этой связи полезно узнать мнение специалиста, прошедшего горнило сертификационного экзамена, который предусмотрен компанией Sun Microsystems для разработчиков приложений на платформе J2EE.

Экзамен Sun Certified Architect for Java Platform, Enterprise Edition (SCEA), пожалуй, оптимален для систематизации и обновления знаний в области проектирования программного обеспечения для платформы J2EE. Однако и стоит он недешево: при удачном прохождении всех этапов общая стоимость экзамена может достигать 550 у.е.

Процесс сертификации состоит из трех этапов. На первом кандидату предлагается традиционный автоматизированный тест, состоящий из 48 вопросов с несколькими возможными ответами на каждый. Язык экзамена — английский. Для успешного прохождения первого этапа необходимо за 75 минут набрать не менее 68% правильных ответов. Фиксированного списка вопросов для подготовки нет — на сайте Sun можно получить только список общих тем экзамена.

За исключением небольшого количества специфичных для платформы J2EE вопросов, первая часть не оставляет впечатления привязки к сугубо Java-ориентированным технологиям; большинство вопросов рассчитано на проверку общей подготовки проектировщика распределенных приложений, а также навыков объектно-ориентированного проектирования, в числе которых:

• концепции объектно-ориентированного проектирования приложений, использование UML;
• свойства и условия применимости различных сетевых протоколов (JRMP, IIOP, HTTP, HTTPS);
• интернационализация распределенных приложений;
• использование программного обеспечения промежуточного слоя, ориентированного на обмен сообщениями (message oriented middleware - MOM);
• образцы проектирования;
• общие аспекты разработки архитектуры; для заданного описания архитектуры необходимо указать сильные и слабые стороны с позиции нефункциональных требований (масштабируемость, надежность, доступность и т.д.);
• обеспечение безопасности (межсетевые экраны, безопасность апплетов, общие методы защиты приложений).

К темам, непосредственно связанным с J2EE, относятся: Enterprise Java Beans, модель контейнера EJB, применимость технологий J2EE, способы интеграции J2EE-приложений с унаследованными системами.

Большое количество вопросов находится на пересечении нескольких тем. Например, требуется указать, какой из нескольких предложенных образцов проектирования GoF используется в реализации конкретного механизма EJB-компонентов. Многие вопросы снабжены UML-диаграммами, не разобравшись в которых сложно дать правильный ответ. Вопросы по безопасности могут опираться на свойства протоколов, а для ответа на вопрос о применимости технологий J2EE необходимо выбрать один из нескольких сценариев, в которых проблема может решаться как с помощью EJB, так и с помощью MOM.

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

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

Вторая, наиболее интересная часть экзамена предусматривает построение архитектурной спецификации для системы резервирования и продажи авиабилетов, которую предстоит разработать на основе описания бизнес-процессов вымышленной авиакомпании Flight-By-Night. Архитектура системы должна предусматривать возможность интеграции с одним унаследованным и одним параллельно разрабатываемым приложением.

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

В качестве результата соискатель сертификата должен сформировать и отправить в центр обработки Sun набор UML-диаграм, описывающих систему, а также подробное описание основных проектных решений. Этот этап не имеет ограничений по времени; получение материалов и отправка результатов происходит через Internet — работа над задачей проводится вне центра тестирования. Единственное ограничение в описании задачи гласит, что архитектура проекта должна базироваться на платформе J2EE.

Пакет диаграмм должен включать в себя диаграммы классов, диаграммы компонентов и диаграммы последовательности (по желанию, вместо диаграмм последовательности можно предоставить диаграммы кооперации). Выбор средства разработки диаграмм остается за претендентом: диаграммы должны соответствовать стандарту UML, а итоговый документ, в который включаются диаграммы, должен быть представлен в формате HTML. Степень детализации диаграмм, количество классов и компонентов, формирующих систему, определяется самим претендентом. По итогам анализа представленных результатов экзаменаторы из Sun начисляют процент полноты решения: за диаграммы классов и диаграммы компонентов претендент может получить по 44%, за диаграммы последовательности или кооперации — 12%. (Каждая оценка включает в себя 5% за «чистоту» UML.) Необходимо набрать не менее 70%.

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

Работая над диаграммами, следует сосредоточиться на построении действительно работоспособного архитектурного каркаса приложения. Индикатором качества диаграммы компонентов и диаграмм классов должны служить простые и подробные диаграммы последовательности, однозначно описывающие каждый сценарий использования системы. В противном случае существенно возрастает опасность, что проектирование затянется. Перед началом работы полезно изучить образцы проектирования, разработанные специально для платформы J2EE. Описывая систему, не следует забывать об экзаменаторах: оформление результатов должно быть по возможности полным, а любые сделанные в процессе работы предположения необходимо представить в сопроводительной записке. Диаграмму классов целесообразно разбить на несколько диаграмм, отражающих только классы и интерфейсы, задействованные в одном-двух сценариях использования системы; в противном случае диаграмма может разрастись и станет сложной для восприятия.

Сразу после отправки материалов в центр обработки Sun можно переходить к последнему, третьему этапу. В его рамках претендент сдает экзамен, аналогичный пройденному на первом этапе, с той разницей, что в нем отсутствуют варианты ответов — ответы принимаются в виде эссе и проверяются вместе с результатами работы по второму этапу. Вопросы посвящены конкретным аспектам реализации проектного задания; по сути, этот этап представляет собой «защиту» второго этапа с одновременной проверкой авторства решения. Важно дать четкие и подробные ответы, уложившись при этом в полтора часа.

Для того чтобы сдать экзамен на сертификат SCEA, по моему мнению, не обязательно предварительно обучаться на курсах Sun. Гораздо важнее опыт реального проектирования J2EE-систем и объектно-ориентированных приложений. Полезно иметь опыт разработки архитектуры конкретных систем с выделенным слоем бизнес-логики на основе EJB и использованием всех видов EJB-компонентов.

Хотелось бы отметить и ряд общих впечатлений.

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

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