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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основные объекты аналитической архитектуры программного обеспечения

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

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

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

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

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

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

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

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

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