Архитектура программы что это

Как устроена архитектура веб-приложений: мануал для начинающих

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

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

#Архитектура приложения и кода

Когда вы создаете приложение, вы должны помнить три принципа:

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

Мы обсудим вышеупомянутые моменты в архитектуре веб-приложений, и подробно рассмотрим основную концепцию, как работает архитектура, ее компоненты и типы.

Что такое архитектура веб-приложений?

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

• Решает конкретную проблему, даже если это просто поиск информации.
• Такая же интерактивная, как настольное приложение.
• Работает с системой управления контентом.

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

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

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

Архитектура ПО. Введение

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

Как работает веб-запрос?

Возьмем в пример ситуацию, который вы хотите посетить progler.ru:

• Вы вводите progler.ru в своем браузере: когда вы вводите URL-адрес в своем веб-браузере и нажимаете Enter, веб-браузеру необходимо знать адрес сервера, на котором расположена страница. Таким образом, он отправляет запрос в DNS (сервер доменных имен, который является хранилищем доменных имен и их IP-адресов). После этого браузер отправляет запрос на найденный IP-адрес по протоколу HTTPS. Если вы уже заходили на progler.ru ранее из того же браузера, он извлечет адрес из кеша.
• Веб-сервер обрабатывает запрос: на следующем шаге веб-сервер отправляет запрос в область хранения, чтобы найти страницу и все данные, которые следуют за ней. Здесь появляется бизнес-логика (также называемая логикой домена и логикой приложения). Бизнес логика берет на себя ответственность за маршрутизацию, что означает доступ к каждой части данных. Она регулирует этот рабочий процесс специально для каждого приложения. По мере того как БЛ обрабатывает запрос, она отправляет его в хранилище, чтобы найти искомые данные.
• Вы получаете ответ: когда ответ возвращается, он отображается на вашем экране. Веб-страница (графический интерфейс) любого веб-сайта, отображаемого на вашем экране, называется внешним интерфейсом приложения. Здесь вы видите все компоненты UI и UX для доступа к информации.

Как работает архитектура веб-приложений?

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

• Код, который запускается в браузере и работает в соответствии с вводом пользователя.
• Код на сервере, который отвечает на HTTP-запросы.

Работая над веб-приложением, веб-разработчик определяет функции кода на сервере и функции кода в браузере. Они также определяют, как эти функции будут работать по отношению друг к другу. Серверный код может быть написан с использованием языков Python, JavaScript, C#, PHP, Ruby on Rails и т. д. Любой код может иметь возможность запускаться на сервере, если он может отвечать на HTTP-запросы. Серверный код в основном отвечает за создание страницы, запрошенной пользователем. Он также хранит различные типы данных, такие как профили пользователей, твиты, страницы и т. д. Серверный код не может быть виден конечным пользователем (за исключением редкой неисправности).

Клиентская часть включает комбинацию языков HTML, CSS и JavaScript. Этот код анализируется браузером, и пользователь может его видеть и редактировать. Только через HTTP-запросы клиентский код может связываться с сервером. Кроме того, он не может напрямую читать файлы с сервера.

Компоненты архитектуры веб-приложений

Архитектура веб-приложения работает на различных компонентах. Эти компоненты можно разделить на две части.

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

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

• Веб-браузер или клиент.
• Сервер веб-приложений.
• Сервер базы данных.

Трехуровневая архитектура веб-приложений

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

Уровень представления: этот уровень доступен клиенту через браузер и включает компоненты пользовательского интерфейса и компоненты процесса пользовательского интерфейса. Как мы уже обсуждали, эти компоненты пользовательского интерфейса созданы с помощью HTML, CSS и JavaScript (и его фреймворков или библиотеки), где каждый из них играет свою роль в создании пользовательского интерфейса.

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

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

Некоторые другие части веб-приложения, которые отделены от основных слоев, существующих в архитектуре:

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

Типы архитектуры веб-приложений

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

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

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

Это повышает продуктивность разработчиков и ускоряет процесс разработки.

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

Заключение

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

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

1. Определение понятия архитектуры ПО

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

2. Клиент-серверная модель

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

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

4. Сервер не инициирует запросов. 5. Обычно для выполнения запросов клиенты проходят аутентификацию на сервере.

Главными преимуществами клиент-серверной модели являются: – Высокая безопасность . Все данные хранятся на сервере, обеспечивающем больший уровень безопасности, нежели отдельный клиент. – Централизованный доступ к данным . Так как данные хранятся только на сервере, ими легко управлять (например, обеспечить обновление). – Устойчивость и лёгкость сопровождения . Роль сервера могут выпол- нять несколько физических компьютеров, объединённых в сеть. Благодаря этому клиент не замечает сбоев или замены отдельного серверного компьютера.

Рассмотрим некоторые варианты клиент-серверной модели. В системах кли- ент-очередь-клиент (client-queue-client или passive queue) сервер исполняет роль очереди для данных клиентов. То есть, клиенты использую сервер только для обмена данными между собой. Пиринговые приложения (peer-to-peer application) – это вариация системы клиент-очередь-клиент, в которой любой клиент может играть роль сервера. Сервера приложений (application server) служат для размещения и выполнения программ, которыми управляет клиент.

3. Компонентная архитектура

Ключевым понятием компонентной архитектуры является компонент (component). Это программный объект, спроектированный так, чтобы удовлетворять следующим требованиям: 1. Компонент допускает повторное использование в различных системах. 2. Компонент не хранит информации, специфичной для конкретного ПО, в котором он используется.

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

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

4. Многоуровневая архитектура

Многоуровневая архитектура (multilayered architecture) сосредоточена на иерархическом распределении отдельных частей системы при помощи эффективного разделения отношений. Каждая часть соотносится с определённым уровнем (layer), для каждого уровня заданы выполняемые им функции, уровни выстроены в стековую структуру (то есть находятся один поверх другого).

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

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

Многоуровневая архитектура активно применяется при создании бизнес — приложений и сайтов, особенно приложений масштаба предприятия. При этом обычно используется следующий набор уровней (рис. 1): Уровень представления (presentation layer) ответственен за взаимодействие с пользователем, ввод и вывод информации. Бизнес-уровень или уровень бизнес-логики (business logic layer) обрабатывает информацию, реализуя конкретные бизнес-правила. Уровень доступа к данным (data access layer) обеспечивает загрузку и сохранение информации, используя источник данных (файл, база данных) или внешний сервис.

Пользователи	Внешние
	вызывающие
сервисы
Уровень
представления
Бизнес-уровень

Уровень доступа

к данным

Источники данных

Сервисы

Рис. 1. Типичные уровни бизнес-приложения. Для каждого уровня дополнительно можно выделить типичный набор компонентов (рис. 2). Заметим, что не все из перечисленных компонентов (и даже уровней) должны присутствовать в любом бизнес-приложении 1 . 1 См. также статью http://msdn.microsoft.com/en-us/library/ff648105.aspx .
Пользователи

Компоненты пользовательского интерфейса
Компоненты сценариев
Интерфейсы сервисов
Рабочие	Бизнес-	Бизнес-
потоки	компоненты		сущности
Компоненты,
отвечающие за доступ		Агенты сервисов
к данным
Источники данных		Сервисы

Безопасность

Управление транзакциями

Связь

Рис. 2. Компоненты отдельных уровней. 1. Компоненты пользовательского интерфейса (UI Components). Они пред- назначены для вывода информации и для ввода данных пользователями. Эти компоненты являются элементами оконного или веб-интерфейса. 2. Компоненты сценариев (UI Process Components).

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

Для того чтобы упорядочить такие сценарии и повторно их использовать, они объединяются в специальные объекты. Кроме этого, создаётся специальный механизм, который позволяет пользователю работать с системой только по определённым сценариям. 3. Рабочие потоки (Business Workflows).

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

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

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

Сейчас мало найдется людей, которые будут спорить с утверждением, что наш мир все более зависим от программного обеспечения (ПО). И это неудивительно. Ведь ПО используется в сотовых телефонах, комплексных системах управления воздушным движением, на персональных компьютерах, электронике автомобилей и много где еще. Множество новшеств, которые нами воспринимаются как данность, а также большое количество различных организаций вроде «Яндекс», 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. Поиск-ориентированная архитектура.

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

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

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

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

Архитектура программного обеспечения (software architecture) представляет собой совокупность важнейших решений об организации программной системы. Она включает в себя:

· структурные элементы и их интерфейсы;

· соединения элементов во всё более крупные системы;

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

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

Архитектурный вид состоит из двух компонентов:

· Отношения между элементами.

Архитектурные виды можно разделить на три основных типа:

1. Модульные (module views), которые представляют систему как структуру из различных программных блоков.

2. Компоненты-и-коннекторы (component-and-connector views) — показывают систему как структуру из параллельно запущенных элементов (компонентов) и способов их взаимодействия (коннекторов).

3. Размещение (allocation views), отображающий размещение элементов системы во внешних средах.

Примеры модульных видов:

· Декомпозиция (decomposition view) — состоит из модулей в контексте отношения «является подмодулем»;

· Использование (uses view) — состоит из модулей в контексте отношения «использует» (т.е. один модуль использует сервисы другого);

· Уровней (layered view) — показывает структуру, в которой связанные по функциональности модули объединены в группы (уровни);

· Классов/обобщений (class/generalization view) — состоит из классов, связанных через отношения «наследуется от» и «является экземпляром».

Примеры видов компонентов-и-коннекторов:

· Процессный (process view) — состоит из процессов, соединённых операциями коммуникации, синхронизации и/или исключения;

· Параллельный (concurrency view) — состоит из компонентов и коннекторов, где коннекторы представляют собой «логические потоки»;

· Обмена данными (shared-data (repository) view) — состоит из компонентов и коннекторов, которые создают, сохраняют и получают постоянные данные;

· Клиент-серверный (client-server view) — состоит из взаимодействующих клиентов и серверов с коннектором между ними (например, протоколов и общих сообщений).

Примеры видов размещения:

· Развертывание (deployment view) — состоит из программных элементов, их размещения на физических носителях и коммуникационных элементов;

· Внедрение (implementation view) — состоит из программных элементов и их соответствия файловым структурам в различных средах (разработческой, интеграционной и т.д.);

· Распределение работы (work assignment view) — состоит из модулей и описания того, кто ответственен за внедрение каждого из них.

Несмотря на то, что было разработано несколько языков для описания архитектуры программного обеспечения, в настоящий момент нет согласия по поводу того, какой набор видов должен быть принят в качестве эталона. В качестве стандарта для моделирования программных систем в 90-е годы 20 века был создан язык UML.

Для упорядочения описания архитектур применяются архитектурные шаблоны (паттерны). Каждый шаблон решает свои задачи и имеет свои недостатки.

Наиболее распространенные типы архитектурных шаблонов:

1) Многоуровневый шаблон (Layered pattern). Система разбивается на уровни, которые на диаграмме изображаются один над другим. Каждый уровень может вызывать только уровень на 1 ниже него. Таким образом, разработку каждого уровня можно вести относительно независимо, что повышает модифицируемость системы. Недостатками данного подхода являются усложнение системы и снижение производительности.

2) Шаблон посредника (Broker pattern). Если в системе присутствует большое количество модулей, их прямое взаимодействие друг с другом становится слишком сложным. Для решения этой проблемы вводится посредник (например, шина данных), по которой модули общаются друг с другом. Таким образом, повышается функциональная совместимость модулей системы. Все недостатки вытекают из наличия посредника: он понижает производительность, его недоступность может сделать недоступной всю систему, он может стать объектом атак и узким местом системы.

3) Шаблон «Модель-Вид-Контроллер» (Model-View-Controller pattern). Т.к. требования к интерфейсу меняются чаще всего, то возникает потребность часто его модифицировать, при этом сохраняя корректное взаимодействие с данными (чтение, сохранение). Для этого в шаблоне Model-View-Controller (MVC) интерфейс отделён от данных. Такой подход позволяет менять интерфейсы, равно как и создавать их разные варианты. В MVC система разделена на следующие составляющие:

a) Модель, хранящую и обрабатывающую данные;

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

c) Контроллер, являющийся посредником между видами и моделью.

Концепция MVC имеет и свои недостатки. В частности, из-за усложнения взаимодействия падает скорость работы системы.

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

В курсовом проекте необходимо использовать одну из следующих типов архитектур:

1) Монолитную, которая реализуется в виде единой программы (файла), без вспомогательных файлов и модулей;

2)
Клиент-серверную или двухзвенную, состоящую из двух частей (приложений) – клиентской и серверной. В ней сервер отвечает на клиентские запросы напрямую и в полном объеме, используя только собственные ресурсы. Общий вид такой архитектуры представлен нар рис. 5.1. Запросы к серверу (базе данных) могут быть реализованы, например, на языке MySQL.

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

4) Сервис-ориентированную (на основе веб-cервиса), обеспечивающую распределенное взаимодействие в среде Интернет (см. рис. 5.3). Взаимодействие осуществляется посредством HTTP протокола (Hyper Text Transfer Protocol). Веб-сервис – это программа, которая реализуется на веб-сервере. В сервис-ориентированной системе выполняются следующие операции.

a) Владелец веб-сервиса размещает его на сервере, а также определяет формат запросов к сервису и его ответов.

b) Программа-потребитель веб-сервиса делает запрос на выполнение функции, предоставляемой сервисом.

c) Веб-сервис отрабатывает запрос и возвращает ответ в заявленной ранее форме.

5) Распределенную, которая использует не менее четырех уровней (см. рис.5.4).

1) представления данных (пользовательский уровень);

2) обработки данных;

3) управления данными;

4)
хранения данных.

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

— представление данных для просмотра пользователем;

— проверка корректности введенных данных;

— сохранение выполненных изменений;

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

Функциями уровня обработки данных являются следующие:

— обработка потоков данных в соответствии с некоторыми правилами;

— взаимодействие с уровнем представления данных для получения запросов и возвращения ответов;

— взаимодействие с уровнем хранения данных для передачи запросов и получения ответов.

К функциям уровня управления данными относятся:

— управление частями распределенного приложения;

— управление соединениями и каналами связи между частями приложения;

— управление потоками данных между клиентами и серверами и между серверами;

— реализация системных служб приложения.

Необходимо отметить, что часто уровень управления данными создается на основе готовых решений, поставляемых на рынок программного обеспечения различными производителями. Так, для платформы Windows, — используются разнообразные инструменты: технология COM+ (развитие технологии Microsoft Transaction Server, MTS), технология обработки очередей сообщений MSMQ, технология Microsoft BizTalk и др.

Уровень хранения данных объединяет серверы SQL и базы данных, используемые приложением. Он обеспечивает решение следующих задач:

— хранение данных в базе и поддержание их в работоспособном состоянии;

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

— реализация части логики распределенного приложения;

— управление распределенными базами данных при помощи административного инструментария серверов базы данных.

UML-ДИАГРАММЫ

UML (Unified Modeling Language- унифицированный язык моделирования) – это язык графического описания для объектного моделирования в области разработки программного обеспечения. Он является языком широкого профиля. Это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. Язык был создан для определения, визуализации, проектирования и документирования программных систем.

Существует 13 официальных диаграмм UML 2.0, каждая из которых представляет собой различное представление разных аспектов системы. Наиболее распространенные из них представлены на рисунке 6.1, как средства моделирования сложной системы.

Взаимосвязь между основными диаграммами UML иллюстрирует рисунок 6.2.

В курсовом проекте предлагается использовать следующие диаграммы:

1) модель хранения данных;

2) вариантов использования;

4) деятельности (для одного из вариантов использования);

5) последовательности действий (для одного из вариантов использования);

6) состояний основного класса программы;

7) компонентов системы;

8) размещения программных компонентов системы.

Рассмотрим, как строится каждая из этих диаграмм.

Дата добавления: 2017-02-13 ; просмотров: 7427 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Источник: poznayka.org

Архитектура программы что это

Узбекское Агентство
Связи и Информатизации

Ташкентский Университет Информационных Технологий

Кафедра
«Программное обеспечение информационных технологий»

Преподаватель дисциплины

Выдержки из лекций

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

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

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

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

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

Традиционный метод борьбы со сложностью — принцип «Разделяй и властвуй» — часто называют «Модуляризацией».

Во время разработки архитектуры программного обеспечения выполняется его модульно-иерархическое построение.

Модуль — это замкнутая программа, которую можно вызвать из любого другого модуля в программе и можно отдельно ком­пилировать.

Стремление к созданию модульных программ объясняется следующими факторами:

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

— модульные программы легко читать, сопровождать и мо­дифицировать. Исправление отдельного модуля вызывает мини­мальные изменения в других модулях, связанных с ним по управлению и информации;

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

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

— процедура загрузки всей программы в оперативную память упрощается при использовании метода оверлейности;

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

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

Минимальными компонентами, из которых строятся модули, являются операторы языка программирования. Разнообразие операторов сравнительно невелико (50 — 100 типов), и каждый оператор реализуется алгоритмом на базе в среднем 1 — 10 машинных команд ЭВМ. С повышением уровня языка программи­рования возрастает функциональная сложность операторов.

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

Программные модули решают небольшую функциональную задачу и реализуются 10 — 100 операторами языка программирования высокого уровня или 100 — 1000 операторами ассемб­лера. В результате программа модуля имеет 100 — 1000 машинных команд. Каждый модуль может использовать на входе около десятка типов переменных. Количество выходных данных несколько меньше. Если для решения небольшой функциональной задачи требуется 500 операторов или более, то целесообразно провести декомпозицию задачи на несколько более простых, для реализации каждой из которых потребуется модуль, реализуемый 50 — 500 операторами.

Модули (10 — 100 шт.) объединяются в группы программ определенного функционального назначения с автономной це­левой задачей.

Несколько (5 — 20) групп программ образуют комплекс программ. В особо сложных случаях возможно создание системы программ из нескольких взаимодействующих комплексов.

Функциональные группы программ и комплексы программ формируются на базе десятков модулей и решают сложные автономные функциональные задачи. На их реализацию в ЭВМ используется примерно 10 тысяч команд. Соответственно воз­растает количество используемых типов переменных и разнооб­разие выходных данных. При этом значительно быстрее растет количество типов переменных, обрабатываемых модулем и лока­лизующихся в пределах одного или нескольких модулей.

В итоге все комплексы программ объединяются в одно целое большое программное обеспечение.

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

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

Типовая архитектура программного обеспечения может иметь вид:

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

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

— компоненты одного уровня обеспечивают реализацию функций компонент следующего уровня;

— каждый уровень иерархии реализуется через функции ком­понент более нижних уровней;

— каждый компонент знает о компонентах более низких уровней и ничего не знает о компонентах более высоких уровней;

— право вмешательства и приоритетного воздействия на компоненты любых уровней со стороны компонент более высоких иерархических уровней;

— взаимозависимость действий компонент верхних уровней от реакций на воздействия и от функционирования компонент нижних уровней, информация о которых передается верхним уровням.

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

— сверху вниз— координирующие и управляющие воздействия верхних уровней иерархии на нижние.

— снизу вверх — передача информации о состоянии и реали­зации предписанных функций компонентами нижних уровней иерархии верхнему уровню.

Взаимодействие компонент системы предполагает выбор c пособа координации и реализации координирующих алгоритмов с выработкой соответствующих воздействий на них.

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

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

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

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

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

Уровневые архитектуры бывают двух видов: замкнутые и открытые.

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

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

Материал сайта является электронным пособием
по дисциплине «Технология Программирования»
в помощь студентам ТУИТ.

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