Vvmebel.com

Новости с мира ПК
5 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Архитектура проекта программирование

Архитектура проекта программирование

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

В книге An Introduction to Software Architecture Дейвид Гарлан (David Garlan) и Мэри Шоу (Mary Shaw) пишут, что архитектура — это особый уровень проекта: «Помимо создания алгоритмов и структур данных, необходимо решить еще одну принципиальную задачу — разработать общую структуру системы. Процесс разработки структуры включает в себя создание общей инфраструктуры организации системы и управления ею, выбор протоколов и методов синхронизации и доступа к данным, распределение функций системы между компонентами, физическое распределение, объединение элементов проекта, масштабирование, оптимизацию производительности и выбор оптимальных вариантов среди доступных альтернатив». [GAR93]

Однако архитектура не ограничивается рамками структуры программного продукта. Сотрудники группы разработчиков архитектур IEEE называют архитектуру «концепцией системы высочайшего уровня в своей среде» [IEP1471]. В этом определении архитектура охватывает такие аспекты, как целостность системы, экономическую целесообразность ее реализацию, эстетику программирования и стиль. В рамках архитектуры рассматриваются не только внутренние элементы системы, но и взаимодействие системы с внешней средой, включая пользовательскую среду и среду разработки.

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

Описание архитектуры

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

Архитектурные представления

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

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

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

Архитектуру можно представить в виде совокупности архитектурных представлений, каждое из которых описывает «значимый для архитектуры» элемент модели. В RUP отправной точкой при разработке архитектуры служит типичный набор архитектурных представлений, который называется «моделью 4+1» [KRU95]. Модель содержит следующие компоненты:

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

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

Фокус архитектуры

Хотя перечисленные выше представления могут полностью охватывать проект системы, в состав архитектуры входят только вполне определенные аспекты:

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

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

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

Шаблоны архитектуры

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

Примеры шаблонов архитектуры

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

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

Определение архитектуры ПО приведено мной ранее: «Что такое архитектура программного обеспечения?»
Нужна ли архитектура ПО? Можно ли реализовать программную систему без проектирования архитектуры? Какова цель проектирования архитектуры ПО?

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

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

Тут я вижу, как минимум, четыре проблемы:

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

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

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

Техническое решение требуется готовить задолго до начала реализации продукта

Получение готового кода в конце процесса разработки влечёт за собой серию рисков:

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

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

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

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

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

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

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

Читать еще:  Учебник программирования c с нуля

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

Восстановление описания системы на основе кода требует специальных навыков и больших трудозатрат

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

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

Код не может описать причины принятых технических решений и их альтернативы

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

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

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

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

Проблемы незаконченного продукта

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

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

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

Именно таким описанием и является архитектура программного обеспечения.

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

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

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

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

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

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

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

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

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

Большинство из вас, наверно, уже знакомы с термином «микросервисы». Микросервисы — один из способов моделирования архитектуры ПО, наряду с многоуровневой архитектурой, архитектурой, управляемая событиями, бессерверной архитектурой и многими другими. Некоторые из вышеперечисленных шаблонов будут описаны ниже. Микросервисный стиль архитектуры стал известным после того, как его стали успешно применять в 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();

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

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

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

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

Анализ области решений

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

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

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

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

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

Под архитектурой ПО понимают набор внутренних структур ПО, которые видны с различных точек зрения и состоят из компонентов, их связей и возможных взаимодействий между компонентами, а также доступных извне свойств этих компонентов [1].

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

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

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

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

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

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

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

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

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

увеличить изображение
Рис. 6.1. Примерная архитектура авиасимулятора

Рис. 6.1 показывает набросок архитектуры такого авиасимулятора. Каждый из указанных компонентов решает свои задачи, которые необходимы для работы всей системы. В совокупности они решают все задачи системы в целом. Стрелками показаны потоки данных и управления между компонентами. Пунктирные стрелки изображают потоки данных, передаваемых для протоколирования.

Читать еще:  Локальная политика безопасности команда

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

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

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

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

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

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

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

Основные конструкции языков Java и C#

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

Архитектура программного обеспечения (англ. software architecture ) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними. Этот термин также относится к документированию архитектуры программного обеспечения. Документирование архитектуры ПО упрощает процесс коммуникации между заинтересованными лицами (англ. stakeholders ), позволяет зафиксировать принятые на ранних этапах проектирования решения о высокоуровневом дизайне системы и позволяет использовать компоненты этого дизайна и шаблоны повторно в других проектах.

Содержание

Обзор

Область компьютерных наук с момента своего образования столкнулась с проблемами, связанными со сложностью программных систем. Ранее проблемы сложности решались разработчиками путем правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин «архитектура программного обеспечения» является относительно новым для индустрии разработки ПО, фундаментальные принципы этой области неупорядоченно применялись пионерами разработки ПО начиная с середины 1980-х. Первые попытки осознать и объяснить программную архитектуру системы были полны неточностей и страдали от недостатка организованности, часто это была просто диаграмма из блоков, соединенных линиями. В 1990-е годы наблюдается попытка определить и систематизировать основные аспекты данной дисциплины. Первоначальный набор шаблонов проектирования, стилей дизайна, передового опыта (best-practices), языков описания и формальная логика были разработаны в течение этого времени. ЕПИ-3-11 супер Основополагающей идеей дисциплины программной архитектуры является идея снижения сложности системы путем абстракции и разграничения полномочий. На сегодняшний день до сих пор нет согласия в отношении четкого определения термина «архитектура программного обеспечения».

Являясь в настоящий момент своего развития дисциплиной без четких правил о «правильном» пути создания системы, проектирование архитектуры ПО все еще является смесью науки и искусства. Аспект «искусства» заключается в том, что любая коммерческая система подразумевает наличие применения или миссии. То, какие ключевые цели имеет система, описывается с помощью сценариев как нефункциональные требования к системе, также известные как атрибуты качества, определяющих, как будет вести себя система. Атрибуты качества системы включают в себя отказоустойчивость, сохранение обратной совместимости, расширяемость, надежность, пригодность к сервисному обслуживанию (maintainability), доступность, безопасность, удобство использования, а также другие качества. С точки зрения пользователя программной архитектуры, программная архитектура дает направление для движения и решения задач, связанных со специальностью каждого такого пользователя, например, заинтересованного лица, разработчика ПО, группы поддержки ПО, специалиста по сопровождению ПО, специалиста по развертыванию ПО, тестера, а также конечных пользователей. В этом смысле архитектура программного обеспечения на самом деле объединяет различные точки зрения на систему. Тот факт, что эти несколько различных точек зрения могут быть объединены в архитектуре программного обеспечения является аргументом в защиту необходимости и целесообразности создания архитектуры ПО еще до этапа разработки ПО.

История

Начало архитектуре программного обеспечения как концепции было положено в научно-исследовательской работе Эдсгера Дейкстры в 1968 году и Дэвида Парнаса в начале 1970-х. Эти ученые подчеркнули, что структура системы ПО имеет важное значение, и что построение правильной структуры — критически важно. Популярность изучения этой области возросла с начала 1990-х годов вместе с научно-исследовательской работой по исследованию архитектурных стилей (шаблонов), языков описания архитектуры, документирования архитектуры, и формальных методов.

В развитии архитектуры программного обеспечения как дисциплины играют важную роль научно-исследовательские учреждения. Мэри Шоу и Дэвид Гэрлан из университета Carnegie Mellon написали книгу под названием «Архитектура программного обеспечения: перспективы новой дисциплины в 1996 году», в которой выдвинули концепции архитектуры программного обеспечения, такие как компоненты, соединители (connectors), стили и так далее. В калифорнийском университете институт Ирвайна по исследованию ПО в первую очередь исследует архитектурные стили, языки описания архитектуры и динамические архитектуры.

Первым стандартом программной архитектуры является стандарт IEEE 1471: ANSI / IEEE 1471—2000: Рекомендации по описанию преимущественно программных систем. Он был принят в 2007 году, под названием ISO ISO / IEC 42010:2007.

Темы по программной архитектуре

Языки описания архитектуры

Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также ByADL (Университет L’Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации.

Виды (views)

Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.

  • Функциональный/логический вид
  • Вид код/модуль
  • Вид разработки (development)/структурный
  • Вид параллельности выполнения/процесс/поток
  • Физический вид/вид развертывания
  • Вид с точки зрения действий пользователя
  • Вид с точки зрения данных

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

Базовые фреймворки для архитектуры ПО (software architecture frameworks)

Существуют следующие фреймворки, относящихся к области архитектуры ПО:

  • 4+1
  • RM-ODP (Reference Model of Open Distributed Processing)
  • Service-Oriented Modeling Framework (SOMF)

Такие примеры архитектур как фреймворк Захмана (Zachman Framework), DODAF и TOGAF относятся к области архитектуры предприятия (enterprise architectures).

Отличие архитектуры ПО от детального проектирования ПО

Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией функциональных требований.

Архитектура ПО, которую также можно представить себе в виде разработки стратегии — это деятельность, связанная с определением глобальных ограничений, накладываемых на проектирование системы, такие как выбор парадигмы программирования, архитектурных стилей, стандарты разработки ПО, основанные на использовании компонентов, принципы проектирования и ограничения, накладываемые государственным законодательством. Детальное проектирование, то есть разработка тактики — это деятельность, связанная с определением локальных ограничений проекта, такие как шаблоны проектирования, архитектурные модели, идиомы программирования и рефакторинга. Согласно «гипотезе напряжения/окрестности» (Intension/Locality Hyphotysis), различие между архитектурным и детальным проектированием определяется критерием окрестности (Locality Criteria), согласно которому утверждение, что дизайн ПО не является локальным (а является архитектурным) истинно тогда и только тогда, когда программа, которая удовлетворяет этому критерию может быть расширена в программу, которая не удовлетворяет ему. Например, стиль приложения клиент-сервер является архитектурным стилем (стратегическим дизайном), потому что программа, которая построена на этом принципе, может быть расширена в программу, которая не является клиент-сервером, например, путем добавления peer-to-peer узлов.

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

Примеры архитектурных стилей и моделей

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

  • Blackboard
  • Клиент-серверная модель (client-server)
  • Архитектуры, построенные вокруг базы данных (database-centric architecture)
  • Распределенные вычисления (distributed computing)
  • Событийная архитектура (event-driven architecture)
  • Front end and back end
  • Неявные вызовы (implicit invocations)
  • Монолитное приложение (monolithic application)
  • Peer-to-peer
  • Пайпы и фильтры (pipes and filters)
  • Plugin
  • Representational State Transfer
  • Rule evaluation
  • Поиск-ориентированная архитектура
  • Сервис-ориентированная архитектура
  • Shared nothing architecture
  • Software componentry
  • Space based architecture
  • Структурированная
  • Трех-уровневая
Ссылка на основную публикацию
Adblock
detector