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

Сейчас мало найдется людей, которые будут спорить с утверждением, что наш мир все более зависим от программного обеспечения (ПО). И это неудивительно. Ведь ПО используется в сотовых телефонах, комплексных системах управления воздушным движением, на персональных компьютерах, электронике автомобилей и много где еще. Множество новшеств, которые нами воспринимаются как данность, а также большое количество различных организаций вроде "Яндекс", Amazon или Google просто невозможны без программного обеспечения. Да даже в традиционных торговом, общественном и финансовом секторах обойтись без ПО очень сложно.

Общая информация

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

В первую очередь необходимо вспомнить Лэнса Басса. «Архитектура программного обеспечения на практике» - довольно старый труд данного автора (русский перевод был выпущен в 2006 году), но тем не менее позволяет получить качественное представление о процессе создания ПО.

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

Немного терминологии

Рассмотрим несколько понятий, которые помогут нам разобраться в теме:

1. Система – определенный набор компонентов, что были объединены с целью выполнения определенной функции или их набора.
2. Миссия – применение (действие), которое одно или несколько заинтересованных лиц собираются совершить в соответствии с требуемым набором условий.
3. Компонент – это логическая, физическая, технологически связанная (независимая), мелко- или крупногранулированная модульная часть системы, что инкапсулирует ее содержимое.

И еще несколько толкований по основной теме:

1. Архитектура – набор значимых решений, что влияют на организацию системы ПО. Набор структурных элементов, а также их интерфейсов, с помощью которых осуществляется компоновка.
2. Архитектура программы (компьютерной системы) – структура, что включает в себя определенные элементы, видимые извне их свойства, а также связи между ними. Она состоит из всех важных принимаемых проектных решений. Это обеспечивает желаемый набор свойств, которые необходимы для успешной деятельности.
3. Архитектура – это структура организации, а также связанное с ней поведение системы. Ее можно рекурсивно разбирать на части, связи и условия сборки.

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

Влияние архитектуры на структуру

Здесь есть один интересный момент. Стоит попросить описать слово «архитектура», как большинство людей при этом упомянут о структуре. И это неудивительно. Ведь архитектура программного обеспечения на практике часто строится по схеме, на которой изображаются структурные аспекты системы. Причем не важно, о чем ведется речь – об уровнях, компонентах или распределенных узлах. Структура является важнейшей характеристикой архитектуры. Ее аспекты и особенности проявляются множеством способов. Структурный элемент может быть базой данных, библиотекой, процессом, подсистемой, вычислительным узлом и так далее. Причем внимание необходимо уделять им не только по отдельности, но и композициям из них, установленным связям, интерфейсам и разбиениям. Нужно учитывать, что каждый из этих элементов может быть представлен разными способами. Как пример можно привести соединительное звено. Оно может быть а/синхронным, сокетом, быть связанным с определенным протоколом и так далее.

Влияние архитектуры на поведение

Его просто невозможно недооценить. Проектирование архитектуры программного обеспечения оказывает большое влияние на ее реализацию и последующую работоспособность. Поведение ПО, возможные зависания, проблемы и тому подобное очень сильно зависят от того, как все развивалось с самого начала. Архитектура влияет на взаимодействие между структурными элементами, должна обеспечивать передачу данных именно туда, куда необходимо, чтобы в конечном итоге получить желаемый результат. Как это происходит с нашими стандартами? Можно рассмотреть небольшую схему деятельности. Допустим, у нас есть предприятие. Необходимо сделать, чтобы служащий принимал заказ с помощью экземпляра класса «Бланк». В него заносятся все необходимые сведения о клиенте. Если заказ оформляется впервые, то сведения заносятся в «Бланк» с помощью системы управления. Затем используется экземпляр класса «Начало обработки заказа», который запускает все нужные процессы на предприятии. Всего используется пять элементов. При этом наблюдается определенная зависимость. Например, оформление заказа невозможно без служащего. А если не будет заполнен «Бланк», то он не будет принят к исполнению.

Концентрация архитектуры на значимых элементах

Итак, мы уже рассмотрели влияние на структуру и поведение. Но здесь необходимо отметить один важный момент. А именно, что архитектура определяет не всю структуру и не все поведение. Она влияет на те элементы, что считаются значимыми. Что под ними понимается? Значимыми считаются те элементы, что обладают продолжительным и устойчивым действием. Например, главные структурные. Или те, от которых зависит надежность и масштабируемость программного обеспечения. При этом архитектура, как правило, не имеет никакого отношения к гранулярным деталям всех этих элементов. Главный признак, по которому некоторые оцениваются больше других, – это стоимость создания и изменения. Архитектура фокусируется на значимые элементы. Поэтому она должна предлагать конкретную перспективу, то, что наиболее значимо. Можно сказать, что архитектура является некоторым обобщением всей системы программного обеспечения, которое позволяет разработчику управлять имеющейся сложностью. Здесь необходимо отметить один важный момент. А именно то, что набор значимых элементов – это не статичный список чего-то, и он может меняться с течением времени. В каких случаях это происходит? Как пример можно привести ситуации, когда приходит уточнение результата требований, идентификация рисков и прочие подобные моменты. При этом следует отметить, что относительная стабильность архитектуры, несмотря на вносимые изменения, является признаком хорошо выполненной работы и правильно поставленного процесса разработки, а также опытности и квалифицированности персонала.

Уравновешивание потребностей заинтересованных лиц

На практике архитектура программного обеспечения должна быть удобной как для пользователей, так и административного персонала. Следует отметить, что часто выполнить все высказанные пожелание не представляется возможным. Как пример можно навести ситуацию, когда заинтересованное лицо просит, чтобы определенная функциональность выполнялась за конкретный временной промежуток. Но эти две потребности взаимоисключающие. То есть можно или уменьшить границы выполняемой функции, чтобы она соответствовала запрашиваемому расписанию, или же оставить все в полном объеме, но тогда будет использоваться слишком много времени. Аналогично описываемому примеру заинтересованные лица могут иметь потребности разной степени противоречия. В таких случаях необходимо достигать определенного равновесия. Компромиссное решение – это практически неотъемлемый аспект процесса разработки архитектуры. И здесь, увы, ничего не поделаешь – приходится преодолевать трудности. Чтобы получить представление о реальной ситуации, давайте смоделируем ситуацию, когда необходимо удовлетворить потребности со стороны нескольких заинтересованных лиц:

1. Конечный пользователь. Он заинтересован в том, чтобы программное обеспечение было интуитивно понятным, производительным, надежным, удобным в использовании, безопасным и доступным, а также обладало корректным поведением.
2. Системный администратор. Он заинтересован в наличии интуитивно понятного управления, инструментах мониторинга и поведения всего комплекса.
3. Специалист по рекламе и продвижению. Он заинтересован в наличии уникальных функций, что делают программное обеспечение конкурентоспособным, ориентировочном времени до выхода разработки на рынок, стоимости продукта и его позиций среди аналогов.
4. Разработчик. Он заинтересован, чтобы были понятные требования и непротиворечивые принципы внутреннего устройства.
5. Руководитель проекта. Он заинтересован в том, чтобы ход проектирования, планирования и выполнения был предсказуем. Также необходимо позаботиться о рациональном использовании доступного бюджета и средств.

Архитектура базируется на логическом обосновании

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

Об архитектурном стиле

Что и как в данном случае? Если посмотреть описание архитектуры программного обеспечения для многих продуктов, то можно заметить, что они строятся на основе систем, которые используют сходные наборы интересов. Ряд сходств может быть оформлен в определенный стиль. Он, в свою очередь, может рассматривать как особенный вид шаблона, весьма сложный и составной. Это – кодификатор опыта, и для разработчиков весьма неплохо использовать его повторно. Ведь это позволит сделать сходную работу более быстро и оперативно. Какие основные архитектуры программного обеспечения по стилям выделяют? В качестве примеров можно привести:

1. Распределенный.
2. Каналы и фильтры.
3. С централизованной обработкой данных.
4. Построенный на правилах.

Следует отметить, что отдельные системы могут демонстрировать наличие более одного стиля. Что является подтверждением этих слова? В первую очередь можно вспомнить про архитектурный стиль Шоу и Гарлана. Как он проявляется? Архитектурный стиль – это, по сути, номенклатура компонентов, а также типов соединительных звеньев и наборов условий, в соответствии с которыми они могут быть соединены. Повторное использование опыта в виде применения архитектурного стиля позволяет облегчить жизнь благодаря тому, что он уже неплохо документирован и обосновано рациональное зерно использования чего-то.

Про влияние окружения. И наоборот

Или иными словами, об архитектуре в рамках смыслового содержимого.

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

Что же говорят об этом стандарты? Если говорить о преимущественно-программных системах, то необходимо учитывать определенные аспекты окружения. Так, чтобы программа была полезной, она должна работать. Для этого ее необходимо запустить на определенном аппаратном обеспечении. Здесь большое значение имеет архитектура компьютера. Программное обеспечение компьютера, созданное для Windows, не будет работать на технике, на которой установлен MacOS. Хотя, конечно, можно сделать эмулятор, запустить через виртуальную машину или воспользоваться другим посредником и запустить программное обеспечение. Но эффективность его работы будет значительно меньше, нежели в случаях работы с целевыми системами. Поэтому архитектура ПК и программное обеспечение должны совпадать, дабы нормально работать. Ведь тот же MacOS может работать только под определенной конфигурацией. Да и Windows имеет определенные ограничения, хотя он и меньше привязан к железу.

О видовом разнообразии

По каким моделям можно создавать ПО? Кратко перечислим виды архитектуры программного обеспечения, которые довольно широко используются:

1. Клиент-серверная модель.
2. Монолитное приложение.
3. Событийная архитектура.
4. Структурированная.
5. Трехуровневая.
6. Сервис-ориентированная архитектура.
7. Неявные вызовы.
8. Поиск-ориентированная архитектура.

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