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

1 См. также таблицы А.2 (приложение А) и В.7 (приложение В).

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

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

4 Для пользовательского прикладного программирования в языках с ограниченной изменчивостью, в частности в языках, используемых в ПЛК (МЭК 61508-6, приложение Е), архитектура определяется поставщиком как стандартная характеристика ПЛК. Однако в рамках настоящего стандарта к поставщику может быть предъявлено требование гарантировать пользователю соответствие поставляемого продукта требованиям 7.4. Пользователь приспосабливает ПЛК, используя стандартные возможности программирования, например многозвенные логические схемы. Требования 7.4.3-7.4.8 сохраняют свою силу. Требование определения и документирования архитектуры может рассматриваться как информация, которую пользователь может использовать при выборе ПЛК (или эквивалентного ему устройства) для приложения.

10 минут, чтобы узнать о профессии архитектор

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

6 Имеются системы, попадающие в промежуток между типами, упомянутыми в примечаниях 4 и 5, в таких случаях ответственность за соответствие разделяется между пользователем и поставщиком.

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

7.4.3.1 В зависимости от характера разработки программного обеспечения ответственность за соответствие 7.4.3 может лежать только на поставщике, только на разработчике или на обеих сторонах (см. примечания, приведенные выше). Распределение ответственности должно быть документировано во время планирования безопасности (см. раздел 6).

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

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

АРХИТЕКТУРНЫЕ ПРОГРАММЫ | Каким софтом пользуются в архитектурных бюро ?

b) основываться на разделении на компоненты/подсистемы, для каждой из которых должна предоставляться следующая информация:

— являются ли они вновь разработанными, уже существующими или находящимися в частной собственности,

— проводилась ли верификация и если проводилась, то при каких условиях,

— связан ли каждый из этих компонентов/подсистем с безопасностью или нет,

— уровень полноты безопасности для компонента/подсистемы;

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

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

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

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

7.4.3.3 Любые изменения, которые может потребоваться внести в специфицированные требования к Е/Е/РЕ системе, связанной с безопасностью, после использования мероприятий 7.4.3.2 должны быть согласованы с разработчиком Е/Е/РЕ систем и документированы.

Примечание — Итерационное взаимодействие между архитектурой аппаратных средств и программного обеспечения является неизбежным (см. рисунок 5), поэтому существует необходимость в обсуждении с разработчиком аппаратуры таких вопросов, как спецификация тестирования интеграции программируемой электронной аппаратуры и программного обеспечения (см. 7.5).

Источник: studfile.net

Архитектура приложения — особенности, описание и требования

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

Вводная информация

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

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

О критериях

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

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

На что делать ставку?

Работая с архитектурой, внимание следует уделить:

1. Эффективности системы. То есть проектирование архитектуры приложения должно создавать такое программное обеспечение, которое сможет решать поставленные задачи и хорошо выполнять возложенные на него функции в разных условиях. В первую очередь здесь следует упомянуть надежность, производительность, безопасность, масштабируемость (способность справляться с увеличением нагрузки).
2. Гибкости системы. Любое, даже самое совершенное приложение приходится со временем менять. Ведь могут измениться существующие требования или добавиться новые. Чем удобнее и быстрее этот процесс можно завершить с меньшим количеством ошибок и проблем, тем конкурентоспособнее и гибче система. Поэтому необходимо следить за тем, чтобы принятый подход не «вырубал в камне» все действия.
3. Расширяемости системы. Возможность добавить новые функции и сущности, не нарушая основную структуру, говорит о продуманности приложения. На начальном этапе имеет смысл закладывать исключительно основной и необходимый функционал. Но при этом должна быть предусмотрена возможность наращивания предоставляемых возможностей по мере возникновения необходимости. Причем таким образом, чтобы на это тратилось минимальное количество сил. Это настолько важно, что даже сформулировано в виде второго принципа SOLID: программные сущности открыты для расширения, закрыты для модификации. То есть архитектура должна быть такой, чтобы можно было написать новый код, но не пришлось менять уже существующий.

А что еще?

Этими тремя критериями архитектура программного приложения не ограничена:

1. Масштабируемость разработки. Архитектура должна предусматривать возможность обеспечить параллельность процесса разработки, чтобы увеличить количество людей, которые работают над проектом.
2. Тестируемость приложения. Код, который легко проверять, содержит в себе меньшее количество ошибок и надежнее работает. К тому же это еще и подталкивает к формированию хорошего дизайна кода, что также облегчает последующую работу с ним.
3. Возможность повторного использования. Систему следует проектировать таким образом, чтобы ее отдельные фрагменты можно было применять в других проектах.
4. Хорошая структурированность, читаемость и понятность кода. Над программами, как правило, работает большое количество людей. Часто встречается ситуация, когда приходят новые или уходят старожилы. Архитектура приложения должна учитывать это. И все наработки должны давать возможность относительно быстро и легко разобраться в создаваемой системе новым людям. В этом помогает хорошая структурированность проекта, отсутствие дублирования, адекватное оформление и документация сопровождения (необязательно, но желательно).

И что же из этого следует?

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

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

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

Рассмотрение примера

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

Превращение спагетти-кода в конструктор

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

1. Масштабируемость – позволяет расширять систему и улучшать ее производительность благодаря добавлению новых модулей.

2. Ремонтопригодность – изменение одной части программы не требует вмешательства в другие.

3. Заменяемость – несколько модулей легко могут выполнять нужные функции.

4. Тестируемость – часто программы можно отделить и отдельно проверить (починить).

5. Переиспользование – отдельный модуль можно использовать в других программах и окружениях.

6. Сопровождаемость – программа легко разбивается на составляющие части, которые несложно понять.

Как выглядит сам процесс?

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

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

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

Иерархическая декомпозиция

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

Часто хватает выделения всего двух уровней (пакеты и классы). Несмотря на свою очевидность, данная мысль не является такой банальной, как кажется на первый взгляд. В качестве примера можно привести такой распространенный архитектурный шаблон, как «Модель-Вид-Контроллер», также известный как MVC. На первом уровне можно разместить самые крупные составные части.

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

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

Функциональная декомпозиция

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

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

Комбинированная декомпозиция

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

1. Высокая сопряженность. Этот параметр говорит о том, что модуль сфокусирован на одной узкой проблеме. Сопряженность достигается только в этом случае. Если же он выполняет разнородные функции и не связанные между собой обязанности, то это говорит о наличии существенных проблем.
2. Слабая связанность. Этот параметр говорит о том, что отдельные модули, из которых строится система, независимы. Как допустимая, но малоприятная альтернатива – слабо связанные между собой. Но при этом они должны иметь возможности для взаимодействия.

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

В заключение

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

Источник: fb.ru

Архитектура ПО: разница между архитектурой и проектированием

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

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

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

Характеристики архитектуры ПО

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

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

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

Архитектурные шаблоны программного обеспечения

Большинство из вас, наверно, уже знакомы с термином «микросервисы». Микросервисы — один из способов моделирования архитектуры ПО, наряду с многоуровневой архитектурой, архитектурой, управляемая событиями, бессерверной архитектурой и многими другими. Некоторые из вышеперечисленных шаблонов будут описаны ниже. Микросервисный стиль архитектуры стал известным после того, как его стали успешно применять в Amazon и Netflix. А теперь, давайте углубимся в детали и более подробно обсудим архитектурные стили.

** Внимание: пожалуйста, не путайте архитектурные стили с шаблонами проектирования, такими как фабричный шаблон проектирования или адаптерами. Я расскажу о них позже.

Бессерверный архитектурный стиль

Этот элемент применим к приложениям, которые в качестве решения используют сервисы третьих лиц для того, чтобы решить проблему загруженности серверов и бэкенда. Бессерверная архитектура делится на две основные категории. Первая это «бэкенд как услуга (BaaS)», вторая — «функция как услуга (FaaS)». Бессерверная архитектура поможет сэкономить время на проверке и исправлении ошибок переноса, а также на работе с регулярными задачами сервера.
Самым известным примером бессерверного API является сервис Amazon AWS «Lambda».

Более подробно прочитать о нем вы можете здесь.

Архитектура, управляемая событиями

Эта архитектура завязана на производителях и потребителях событий. Главная идея состоит в том, чтобы разделить части вашей системы так, чтобы каждая из частей активизировалась, когда интересное событие происходит в другой. Сложно? Давайте упростим. Представьте, что вы создаете систему для онлайн-магазина и она состоит из двух частей: модуль покупок и модуль продаж.

Когда клиент совершает покупку, модуль покупок создает событие «orderPending». Так как модуль продаж заинтересован в этом событии, он будет следить за процессом на случай, если его вызовут. Как только модуль продаж получит это событие, он выполнит определенные задания или запустит ещё одно событие для продолжения покупки товаров у определенного вендора.

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

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

Архитектура микросервисов

За последние несколько лет архитектура микросервисов стала одной из самых популярных. Она создается на основе небольших, независимых модульных сервисов, каждый из которых решает свою проблему или выполняет уникальное задание. Эти модули взаимодействуют через API, запрограммированный на выполнение определённой бизнес цели. А теперь посмотрите на картинку и вы все поймёте.

Проектирование программного обеспечения

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

Если вы разработчик, вам необходимо знать принципы SOLID, и понимать, как шаблон проектирования должен решать повседневные проблемы.

Принципы SOLID ( Single Responsibility, Open Closed, Liskov substitution, Interface Segregation and Dependency Inversion Principles) — это единственная ответственность, открытость/закрытость, принцип подстановки Барбары Лисков, принцип разделения интерфейсов и принцип инверсии зависимостей.

• Принцип единственной ответственности означает, что каждый класс работает только над одной целью, ответственен только за неё и изменяется только по одной причине.
• Принцип открытости/закрытости: класс должен быть открытым для расширения, но закрытым для изменений. Проще говоря, вы можете добавлять новую функциональность в класс, но не можете редактировать существующие функции таким образом, что они будут противоречить используемому коду
• Принцип подстановки Барбары Лисков: согласно этому принципу, разработчик должен соблюдать наследственность таким образом, чтобы нигде не нарушалась логика приложения. Так, если новый класс «XyClass» происходит от родительского класса «AbClass», новый класс должен повторять функции родительского класса таким образом, чтобы они не изменяли поведение родительского класса. Тогда вы легко сможете использовать объект XyClass класса вместо объекта класса AbClass, не нарушая логики приложения.
• Принцип разделения интерфейсов: Всё просто: класс способен реализовывать множество интерфейсов, создавайте свой код таким образом, чтобы классу никогда не приходилось реализовывать функцию, которая не важна для его задач. Вывод — разделяйте свои интерфейсы на категории.
• Принцип инверсии зависимостей: Если вы когда-либо использовали TDD для создания своего приложения, вы знаете насколько важно расщеплять свой код перед тестированием и моделированием. Другими словами, если определенный класс «ex:Purchase» зависит от класса «Users», установка пользовательских объектов должна инициировать снаружи класса «Purchase».

Шаблоны проектирования

• Фабричная модель — самый часто используемый шаблон проектирования в мире OOП, так как он позволяет сэкономить много времени в будущем, когда потребуется изменить один из классов, который вы использовали. Рассмотрим на примере:

Представим, что вы хотите реализовать модель класса пользователей Users(), — вы можете использовать один из двух методов:

1 — $users = new Users();
2 — $users = DataFactory::get(‘Users’);

Я бы выбрал второй, по двум основным причинам, помимо всех остальных. Во-первых, изменение названия класса с «Users» на «UserData» — это всего лишь одно изменение в одном месте, внутри фабричной базы, в остальном ваш код остается тем же. Во-вторых, если в классе «Users» появятся такие параметры как Users($connection), то вам останется только внести изменения в одном месте, а не в каждой функции которая использует объекты класса Users. Поэтому, если вы думаете, что первый вариант лучше, подумайте ещё раз.

• Адаптер (шаблон проектирования) — один из шаблонов структурного проектирования. Посмотрев на название, можно понять, что эта модель делает из неожидаемого использования класса ожидаемое.

Представьте,что ваше приложение работает по API c YouTube и, чтобы получить токен доступа, вам необходимо вызвать функцию getYoutubeToken();

Итак, вы вызвали эту функцию в 20 разных местах в приложении.

А потом, Google публикует новую версию API, переименовав функцию на getAccessToken();

Теперь вам придется найти и переименовать эту функцию во всем приложении или создать адаптер-класс, как показано далее в примере:

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

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

• ТЭГИ
• JavaScript
• Software Development
• Web Development

Источник: nuancesprog.ru