Превью

Приветствую Вас, Уважаемые коллеги!

В нашу прошлую встречу мы обсудили тему практик архитектурного проектирование программного обеспечения.

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

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

Вместо введения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Системный администратор:

Заинтересован в интуитивно понятном и логичном функционале, легком управлении и доступных инструментах мониторинга за рабочим «поведением» программного продукта;

• Маркетолог/Специалист по продвижению продукта:

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования, необходимые для создания аналитической архитектуры программного обеспечения

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

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

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

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

• Функциональные требования;
  • Эта группа требований формулирует характеристики программного продукта к процессу взаимодействия между информационной системой и пользователями, в котором достигаются бизнес цели и задачи;
• Не функциональные требования;
  • Это вид требований, который позволяет заложить системный базис информационного продукта, на котором станет возможным «вырастить» оптимальную для конкретных условий архитектуру программного продукта.

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

• Простые в понимании:

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

• Простые в использовании:

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

• Соответствующие реальным ожиданиям пользователей;

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

• Обеспечивающие комфортный процесс разработки;

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

• Команда должна быть согласна с архитектурой

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

• Общие принципы для всех профессиональных активностей, с которыми работаешь в рамках конкретного продукта и конкретной технологии;

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

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

Тем самым мы придем к универсализации рабочих принципов и можем постепенно добьемся создания полноценной организационной системы архитектурного проектирования, но важно помнить, что в любом деле очень важно чувство меры. Система должна быть гибкой и адаптивной, но при этом жесткой. Это позволит выдержать множество проверок, в виде разнообразных поступающих задач по созданию архитектуры программных продуктов. Закон/принцип должен быть. Если он не будет исполняться – Будет плохо всем.

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

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

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

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

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

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

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

• Обработка проектируемых элементов, связей, алгоритмов работы должна представлять собой набор правил (а лучше правило) преобразования и представления данных. Если на последующих стадиях реализации продукта или в процессе управления изменениями поступили требования, которые не вписываются в структуру правил, то необходимо переделать правила, расширив их необходимым образом или перепроектировать систему, с учетом измененных к ней требований;
• Проектируемая архитектура программного продукта должна представлять собой набор относительно небольших модулей, компетенции по работе с которыми должны быть разделены между членами команды проектировщиков. Проектирование каждого модуля и их единое представление должно выполняться в соответствии с стандартами, лучшими практиками, рекомендациями отрасли программной инженерии. Таким образом, можно обеспечить преемственность задач и обеспечить их дальнейшее сопровождение и развитие (не отрицая, а дополняя активность документирования). Важно, чтобы процесс передачи компетенций и наследования знаний постоянно контролировался со стороны менеджмента;
• Обдуманно и очень осторожно относиться к технологии «Copy&Paste». Во многих случаях этот подход к работе (с учетом применения «Copy&Paste» к лучшим и отработанным решениям) лучшее решение, но применять его везде – губительно. Дальнейшее сопровождение/изменение/развитие (сделаем особенное ударение на часть изменение) решений, сделанных по подобной технологии, порождает большое количество ошибок;
• Слишком сложные решения, для того, чтобы разобраться в которых требуется большое количество времени и сил приводит к дальнейшей не реализуемости архитектур. Приведем эмпирическую метрику и скажем о том, что в высокоуровневой схеме архитектуры должен уметь разобраться каждый член команды проектировщиков, самостоятельно, не более чем за 15 минут.

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

Продолжим разговор об требованиях к архитектуре мы в следующий раз

До скорого!

Авторы статьи

Иван Никитин

Михаил Цулая