Подходы к документированию архитектуры программного обеспечения
Выбор нотаций для визуализации архитектуры программного обеспечения
В предыдущем абзаце мы рассмотрели набор архитектурных методик, каждая из которых предоставляет собственный инструментарий, необходимый для визуализации разрабатываемой архитектуры программного продукта. Но когда речь заходит о выборе оптимальной архитектурной нотации, как правило, большинство департаментов информационных технологий (или ответственные за создание архитектуры подразделения) современных компаний склоняется к созданию собственной нотации, скомпилированной из хорошо себя зарекомендовавших, для данного предприятия, нотаций и способов моделирования бизнес процессов и структур данных архитектуры и функциональности разрабатываемого программного продукта.
Несмотря на наличие большого числа соответствующих стандартов в области описания архитектуры (ISO, IEEE, The Open Group и пр.), ни одна из них не доминирует на рынке соответствующего направления области информационных технологий.
Опрос, проведенный не так давно институтом разработки корпоративной архитектуры (США) продемонстрировал, что:
- 52% предпочитали собственные наработки;
- 30% применяли модель Захмана;
- 18% использовали прочие методики.
Можно сделать выводы о том, что "best practice" в проектировании и разработке соответствующей документации для обеспечения полного жизненного цикла программного продукта заключается в применении всего лучшего, что накоплено в базе знаний отрасли. В связи с этим системному архитектору или специалисту, задействованному в проектировании и реализации архитектуры программного продукта, важно детально представлять и понимать преимущества и недостатки существующих методик и нотаций, соотнесенные с ясной целью и четкими задачами, которые должны быть определены перед стартом разработки архитектуры информационной системы определенной организации.
Для проектирования и последующей реализации архитектуры программного продукта следует:
- Компилировать "собственную" методику создания архитектуры, применяя доступные эталонные образцы общепринятых моделей и методик
В сфере проектирования и разработки архитектуры на текущий момент развития области информационных технологий отсутствует единый источник стандартов. Следовательно, вполне корректно использовать всю доступную информацию по имеющимся методологиям для создания на их основе собственной, наиболее подходящей под конкретные нужды, адаптированной под реалии процессов проектирования и разработки архитектуры и функциональности программных продуктов.
Достоинствами этого подхода являются:
- Концепции, структуры описания архитектуры и прочие значимые шаблоны будут разработаны с учетом конкретных факторов и условий, определяющих программный продукт и его архитектуру. В случае использования репозитория "best practice" архитектурного направления, можно с высокой долей вероятности гарантировать, что разработанные артефакты будут определяться процессами и понятиями, гармонизированными с наиболее успешными и качественными образцами отрасли;
- После соответствующей адаптации разработанные методики будут отражать именно те детали, которые характерны для конкретной компании:
- Квалификация персонала;
- Уровень корпоративной культуры компании;
- Степень ресурсных затрат различных иерархических уровней предприятия для поддержки работ над архитектурой программных продуктов;
- Размер финансирования;
- Пр.
Из недостатков подобного подхода к созданию документационного обеспечения конкретной организации можно выделить то, что документация будет уникальна для конкретной компании и ее масштабирование и последующее использование в других предприятиях потребует ресурсов.
При выборе необходимых нотаций из существующих или разработке собственных методик документирования архитектуры, критично детально изучить примеры реализованных артефактов, которые достаточно эффективно описывают архитектуру программных продуктов в заданных условиях функционирования компании. При этом важно понимать, что нет догм о составе и объеме необходимых нотаций и документов. Каждый раз, сталкиваясь с специфичными особенностями определенной ситуации, необходимо по возможности адаптировать имеющиеся шаблоны и расставлять приоритеты в соответствии с практическими потребностями в тех или иных элементах описания архитектуры. Основным требованием к выбранным артефактам является их согласованность между собой, с архитектурной методикой в целом, с процессами управления и поддержки программной архитектуры.
Попытка включить в описание дополнительные нотации или документы, необходимость которых не обоснована реальными условиями или требованиями к последующему развитию архитектуры приведет к "холостому" перерасходу ресурсов.
Важно определить те области архитектуры, практическое использование которых будет определять успех конкретного программного продукта и сфокусироваться на их детальном моделировании и последующем документировании.
Рамки архитектурных документов
В процессе создания архитектурных артефактов, как обеспечивающих (документирование, проектирование и т.д.), так и основных (разработка, тестирование и т.д.) процессов реализации программных продуктов, задействованные исполнители (системный архитектор, аналитики и т.д.) выполняют проработку базиса информационной системы. Исчерпывающий набор действий, определяющий рамки создания архитектурного фундамента информационной системы, взаимосвязан с использованием выбранных нотаций или языков моделирования бизнес процессов, структур данных и т.д. Наиболее встречающимся языком архитектурного моделирования является UML, который мы рассмотрели выше. UML, как было показано, не является "панацеей" домена архитектурного проектирования программных продуктов. При этом данный язык включает в себя средства, которые поддерживают многие характеристики, составляющие большинство применяемых архитектурных моделей.
Для создания полноценного и самодостаточного программного продукта потребуется выполнить активности моделирования. Создаваемые архитектурные модели позволяют демонстрировать ожидаемую структуру и поведение функционала программного продукта в виде, доступном для понимания адресату создаваемых архитектурных артефактов. Реализованные модели архитектуры следует использовать для:
- Визуализации разрабатываемой архитектуры;
- Управления и сопровождения структуры и функционала информационной системы;
- Повышения прозрачности и последующего совершенствования процессов проектирования и разработки программного продукта;
- Оптимизации автоматизируемых бизнес процессов и их последующего рефакторинга/реинжиниринга;
- Выработки эффективных шаблонов, способствующих реализации результативной информационной системы;
- Синхронизации видения на рамки и объемы работ по созданию программного продукта между заказчиками и исполнителями.
- Моделирование, как многие активности архитектурного домена, были почерпнуты из научно-технической области, в которой этот вид деятельности является инженерной методикой.
К примеру, в области строительства сооружений применяется множество видов моделирования, каждое из которых преследует определенные цели:
- Архитектурное моделирование зданий – детальная визуализация создаваемых сооружений с учетом внешних факторов;
- Математическое моделирование зданий - подробное исследование вероятных нагрузок различного характера и оптимизация проекта инженерной конструкции;
Мы привели пример из сферы архитектурного строительства, как "предтечи" архитектурного проектирования программных продуктов, но во множестве современных практических направлений деятельности, имеющих различную природу, к моделированию прибегают постоянно. В таких гуманитарных предметах, как социология, экономика, или не совсем гуманитарном менеджменте, моделирование используют для проверки теоретических положений и предвидения новых идей с минимально возможными рисками и затратами.
Создание эффективных моделей функциональных процессов и архитектур программных систем способствует выработке объективного обоснования рамок, которые должны охватить бизнес-процессы необходимые для автоматизации в конкретном информационном продукте. Критичным требованием к достижению результата разработки оптимального программного продукта является требование к точному соблюдению рамок внедрения и последующего функционирования системы. Если позволить рамкам "расползтись" под давлением влиятельных стэйкхолдеров, стремящихся получить более "объемный" и качественный продукт за счет ранее согласованного количества ресурсов, то результат реализации архитектуры, с высокой долей вероятности подтвержденной соответствующей статистикой, будет не достигнут и от этого, прежде всего, пострадает организация-заказчик.
Рекомендации по соблюдению рамок функциональности программных продуктов и соответствующих архитектур, а так же поддерживающей и обеспечивающей их документации состоят в необходимости соблюдения первоначальных объемов автоматизириуемых бизнес-процессов.
Выводы по изученной лекции
В ходе сегодняшней лекции мы выполнили подробное рассмотрение уровней, формирующих оптимальную архитектуру программных продуктов, изучили существующие подходы к документированию информационных архитектур, детально взглянули на современные методики документирования программных продуктов.
Обзор архитектурных моделей, пожалуй, является ядром данной лекции и должен стать отправной точкой в изучении архитектур для тех коллег, которые видят свое профессиональное развитие в сфере реализации эффективных и результативных информационных архитектур современного программного обеспечения различной степени сложности и надежности.
На сегодняшний день накоплен внушительный массив различных реализаций архитектурных моделей, каждая из которых зарекомендовала себя на практике в определенных внутренних и внешних условиях. Несмотря на это, еще рано говорить о сложившемся самодостаточно предмете архитектурного моделирования в силу недостаточной теоретической обоснованности многих практических моделей и неспособности их массового тиражирования в различных условиях.
Именно в силу необходимости подробного документирования, аналитического рассмотрения и последующей синтетической реализации, необходимо использовать эффективные модели документирования результативных архитектур программных продуктов.