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

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

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

Вам будет интересно:Где в Mozilla Firefox хранятся закладки: все о поиске и сохранении закладок

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

Вам будет интересно:Как снять защиту от записи в Total Commander: два способа

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

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

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

Вам будет интересно:Где хранятся закладки в "Опере": поиск сохраненных страниц в браузере и на ПК

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

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

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

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

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

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

Вам будет интересно:Лучшие программы для черчения электрических схем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник