Границы применения и область архитектурного проектирования программного обеспечения

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

Сегодня мы взглянем на архитектуру не просто как на результат деятельности, а с точки зрения формирующих её компонентов и их связей.

Введение

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

Если можно было взять ту самую пилюлю истины и переложить всю ответственность за муки принятия решения на неё, тогда нами давно правили существа, производящие эти пилюли и оставляющие "тяжкие" муки выбора на себе.

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

От того, насколько адекватными и обоснованными будут наши (как проектировщиков и разработчиков) решения, зависит то, насколько архитектура будет соответствовать тому представлению, которое вкладывают в неё будущие пользователи и хозяева, а так же способности удовлетворять их потребности и запросы.

Выбор того или иного решения обуславливается множеством разнообразных факторов. Например:

• Понятность и прозрачность требований к архитектуре программного продукта;
• Желаемые характеристики архитектуры;
• Внешнее окружение архитектуры программного продукта:
• Внутренние, используемые архитектурные компоненты и связи между ними;

Все эти отдельные компоненты единого архитектурного "пирога", от гармоничного сочетания и процентной доли которых в общем "деле", будет зависеть конечный успех программного продукта.

Именно об этих составляющих мы и поговорим в сегодняшней лекции.

Характеристики современных архитектур программного обеспечения

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

С одной стороны, многие наши коллеги говорят о том, что если речь идет о разработке небольшого приложения, то не стоит начинать НИОКР, для проектирования архитектуры этого приложения, а разрабатывать "по месту" и "времени". Такой подход, безусловно, имеет право на существование, но есть и альтернативные точки зрения.

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

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

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

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

Архитектура должна однозначно определять структуру разрабатываемого информационного продукта. Одна из основных ассоциаций, приходящих на ум при слове архитектура – структура. Параллели, постоянно проводимые между областью информационных технологий и строительством, имеют право на существование и для направления архитектурного проектирования. Если вы попросите коллегу поверхностно описать архитектуру программного обеспечения, с которым он работает, то, в 8 случаев из 10, он продемонстрирует схему/диаграмму/модель, на которой будут изображены структурные артефакты системы (объекты и связи). Структурные характеристики архитектуры проявляются многими способами в различных ситуациях. Структурный элемент может быть целой подсистемой, процессом, библиотекой, базой данных, вычислительным узлом, системой в традиционном смысле, готовым продуктом и так далее.

Вместе с определением структурных элементов каждая архитектура определяет взаимодействия между ними. Именно характер и тип определенных связей обеспечивает функциональность проектируемой информационной системы.

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

К примеру, можно перечислить следующие элементы:

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

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

Признаком успешной архитектуры, не подвергающейся постоянным переработкам и доработкам, является относительная стабильность. Если архитектура требует постоянного пересмотра, при относительно небольших изменениях "внешнего" или "внутреннего окружения", то это плохой признак.

Архитектура должна гармонизировать все потребности заинтересованных лиц к программному продукту.

Цель создания архитектурного программного продукта – удовлетворение комплекса разноречивых потребностей группы наиболее важных заинтересованных лиц. Очень часто выполнить все пожелания к проектируемой системе довольно затруднительно.

Достижение компромиссных решений, которые будут устраивать большинство заинтересованных лиц, это один из основных аспектов успешного архитектурного проектирования.

Как правило, существуют следующие группы ключевых пользователей программного продукта, с перечисленными пожеланиями к нему:

• Конечный пользователь :

  Заинтересован в интуитивно понятном интерфейсе и предсказуемом и логичном поведении системы, высокой производительности, надежности, удобстве использования, доступности;
• Системный администратор:

  Заинтересован в интуитивно понятном и логичном функционале, легком управлении и доступных инструментах мониторинга за рабочим "поведением" программного продукта;
• Маркетолог/Специалист по продвижению продукта:

  Заинтересован в конкурентоспособных функциях программного продукта, его быстром выводе на рынок, позиционировании и выделении среди других продуктов;
• Специалист по сопровождению:

  Заинтересован в ясном, однозначном и документируемом принципе создания программного продукта, а также в легкости, с которой можно поддерживать текущее состояние и вносить изменения;
• Разработчик

  Заинтересован в понятных и простых требованиях, непротиворечивом принципе проектирования;
• Клиент

  Заинтересован в адекватной цене разрабатываемого продукта, стабильности и т.д.;

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

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

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

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

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

Половинчатым решением (не предусматривающим отказ от документирования) подобной задачи будет использование конкретного архитектурного стиля или набора стилей.

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

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

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

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