Влияние архитектуры приложений на инфраструктуру реферат

Обновлено: 02.07.2024

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

конструирование веб-приложений на основе графического интерфейса

Общая архитектура приложения ( реферат , курсовая , диплом , контрольная )

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

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

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

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

В разрабатываемом веб_приложении было решено использовать реляционную систему управления базами данных (СУБД) PostgreSQL. К преимуществам данной СУБД можно отнести:

— Данная СУБД распространяется бесплатно и имеет открытый исходный код.
— Поддержка объектно-реляционной модели данных.
— Возможность расширения функционала за счет хранимых процедур.
— Большое сообщество — это позволит легко найти ответы на возникшие вопросы.
— Поддержка большого списка типов данных, включая XML и JSON, а также есть тип для быстрого поиска по JSON — JSONB.
— Возможность написания хранимых процедур на разных языках программирования, например, SQL, PL/PGSQL, JavaScript, Perl и др.
— Возможность создавать индексы не только по полям, но и функциям от них.
— Имеется поддержка транзакций.
— Возможность полнотекстового поиска без надстроек и дополнительных расширений.

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

4. АРХИТЕКТУРА ПРИЛОЖЕНИЙ

4.1. Основные элементы архитектуры приложений
В архитектуре приложений выделяют две основные области (рис. 11) [4]:

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

Рис. 11. Области архитектуры приложений

Портфель прикладных систем предприятия необходим для обеспечения бизнес-процессов набором прикладных систем. Он определяет функциональность каждого приложения, а также то, за счет чего она будет достигаться [10]:
- за счет разработки новой системы;
- за счет покупки готовых систем;
- за счет аренды приложения;
- за счет использования уже имеющихся приложений.
Приложения, задаваемые портфелем прикладных систем предприятия, описывают функции организации, обмен информационных потоков на предприятии, каналы взаимодействия пользователей с приложениями [23]: web-браузеры, графический интерфейс "толстого" клиента, мобильные устройства и т.д.
Портфель прикладных систем обеспечивает целостный взгляд на функциональные компоненты информационных систем, которые обеспечивают потребности бизнес-архитектуры и архитектуры информации и поддерживаются технологической архитектурой.
Область разработки прикладных систем описывает технологии, которые используются для построения систем. Она касается также создания интерфейсов, выбора шаблонов и т.д. Эта область отвечает за организацию процесса разработки, т.е. за выбор технологий для построения приложений и способов их применения [41].
Область разработки прикладных систем ответственна за соблюдение единых подходов к разработке, что влияет на уменьшение стоимости создания прикладных систем [2].
Важно отметить ту часть разработки прикладных систем, которая затрагивает шаблоны проектирования, так как шаблоны находятся на стыке между обеспечением функциональных возможностей и технологиями. Шаблоны по сути являются руководствами по построению систем.
Изучая архитектуру приложений, под ней понимают портфель прикладных систем [31].

4.2. Модели и инструменты управления портфелем приложений
Оценка портфеля является начальным моментом в деле определения проблемных областей и возможностей для улучшения бизнеса и принятия решения об обновлении прикладных систем [2].
В результате оценки прикладных систем их разделяют на 4 группы [25]:

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

Характеристики оценки технического состояния [15]:
– точность данных;
– корректность данных;
– архитектура;
– структура программного кода;
– быстрота отклика;
– время простоя;
– уровень технического сопровождения;
– возможность получения отчетов и т.д.
Информация по имеющимся в организации прикладным системам должна включать [28]:

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

Для оценки портфеля прикладных систем может быть также использована модель, предложенная Gartner [2, 10].
Выделяют 3 класса приложений согласно следующим категориям [11]:

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

На основании этих данных делают финансовую оценку вложений в ИТ на предприятии [28].
Базовые транзакционные (или вспомогательные, или обслуживающие) приложения играют важную роль с точки зрения обеспечения деятельности организации. Они должны иметь низкую стоимость, надежность, стоимость одной транзакции такого приложения должна быть минимальной. Этих приложений в портфеле информационных систем предприятия обычно большинство.
Информационные (дающие преимущества) – это те приложения, которые улучшают деятельность организации. Они обеспечивают информацию для учета, управления, контроля, получения отчетов, анализа, совместной работы.
Инновационные (стратегические или "пограничные") приложения носят принципиально новый характер влияния на функционирование организаций. Эти приложения создают новые конкурентные преимущества на рынке.
В совокупности с тремя типами прикладных систем следует рассматривать еще одну категорию инвестиций в информационные технологии, так называемую технологическую архитектуру, или инфраструктуру [4].
Существует еще одна классификация для приложений, в зависимости от роли, которую оно выполняет в рамках портфеля [41]:

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

Для различных компаний одни и те же "стандартные" приложения, могут относиться к различным уровням в данной классификации [41].

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

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

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

Технологическая архитектура(инфраструктура) рассматривает "традиционные" аспекты построения информационных систем – аппаратные платформы, операционные системы, СУБД, инструментальные средства, сетевую инфраструктуру, системы безопасности, сервисы, определяет набор стандартов и принципов.

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

Два подхода к формированию технологической архитектуры

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

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

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

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

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

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

Классификация технологической архитектуры

META Group выделяет два типа областей (доменов) технологической архитектуры:

базовые (сети, аппаратное обеспечение, ОС, системы хранения, ПО промежуточного слоя (middleware), СУБД, технологии управления ИТ-ресурсами в распределенной среде, архитектура безопасности);

прикладные (системы коллективной работы, электронной почты, workflow, Интернет- приложения, системы электронной коммерции, хранилища данных, специализированное аппаратное обеспечение).

Gartner использует шесть архитектурных компонент(сервисов), в каждом из которых выделяется определенное количество технологических "строительных блоков" (bricks)

Сервисы данных: СУБД, хранилища данных, СППР (Business Intelligence – средства анализа и подготовки отчетов).

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

Программное обеспечениепромежуточного слоя (middleware).

Вычислительная инфраструктура: ОС и аппаратное обеспечение, среда для web-инфраструктуры (браузеры, web-порталы, web-серверы, средства управления и создания контента, серверы каталогов, форматы публикации информации), средства системного управления (средства сетевого управления, администрирование IP), топологии (топология распределенных приложений).

Сетевые сервисы: локальные сети (протоколы, кабельные системы, топология), глобальные сети (транспорт, протоколы), технологии доступа, голосовые технологии (голос/данные поверх IP-протокола, голосовая почта), сетевое аппаратное обеспечение (концентраторы, маршрутизаторы и пр.).

Сервисы безопасности: авторизация, аутентификация, сетевая безопасность (Network Firewall, Internet Firewall), физическая безопасность центров обработки данных, прочие сервисы безопасности (обнаружение вторжений, защита от вирусов).

Техническая справочная модель(TRM - Technical Reference Mode) методики Федеральной архитектуры США FEAF

Содержит четыре области технологических сервисов:

доступ и доставка;

платформы и инфраструктура;

сервис интерфейсов и интеграции.

Каждая область технологических сервисов делится на категории, категории содержат стандарты, а стандарты содержат спецификации.

Оценка состояния и требований к технологической инфраструктуре

Для оценки состояния технологической инфраструктуры можно использовать подход, предложенный Питером Кином (Peter Keen). Он использует два критерия:

функциональные возможности: как простые - пересылка информации так и сложные транзакции, которые могут производиться совместно сотрудниками, а также поставщиками и клиентами;

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

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

Основные характеристики:

самоконфигурирование – организация системы в соответствии с требованиями;

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

самовосстановление – диагностика неисправностей, локализация ошибок и устранение их последствий;

самооптимизация – наиболее рациональное использование имеющихся ресурсов без вмешательства оператора.

Повышение эффективности использования существующих вычислительных ресурсов

сетевая инфраструктура, предполагающая замену дорогих арендованных WAN-линий на более дешевую технологию RAIL2.

система хранения данных, доступная по Ethernet-сети.

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

управляющее ПО, использующее стандарты Web-сервисов, позволяющие быстро интегрировать различные приложения. Такие как SOAP (простой протокол доступа к объектам) и WSDL (язык описания веб-сервисов и доступа к ним, основанный на языке XML).

Основные принципы адаптивной инфраструктуры

все ИТ-ресурсы являются общими и разделяемыми;

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

качество обслуживания является предсказуемым и стабильным, несмотря на непредсказуемый спрос на ресурсы. Для этого компанией Gartner предложена специальная концепция IT Infrastructure Utility и модель зрелости Infrastructure Utility Maturity Model.

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

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

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

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

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

Хорошо построенная архитектура должна соответствовать следующим критериям:

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

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

Как работает архитектура мобильного приложения

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

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

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

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

Модели архитектуры приложений

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

SPA приложение. Его еще называют одностраничным. Принцип работы следующий: вся информация, находящаяся в приложении, загружается на одной странице. Пользователи получают качественный интерфейс без перегруженности и лишних элементов, а также высокую скорость загрузки. По этому принципу устроена архитектура приложений Gmail, Facebook, Twitter.
MPA или многостраничные приложения. Несмотря на уменьшенную скорость загрузки, MPA архитектуру используют крупные компании, такие, как eBay или Amazon. Загрузить всю информацию на одной странице просто не получится, слишком много серверных процессов и компонентов. Для крупных компаний – это хорошее решение.
Архитектура микросервисов. Работает по принципу сервисно-ориентированного подхода. Приложение создается из отдельно взятых модулей и сервисов, каждый компонент нужно отдельно развертывать. Такая разработка обходится гораздо дороже, но зато в случае внесения изменений, обновления функционала нужно работать только с отдельным сервисом, а не переписывать все приложение заново.
PWA приложения. Это решения, которые дают возможность лучше взаимодействовать с пользователем. На устройство ставится приложение, выглядит, как нативное, но при этом оно работает через веб-ресурсы. Пример такого приложения – Pinterest.

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

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

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

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

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

Как происходит проектирование приложения

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

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

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

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

Проектирование имеет несколько способов реализации:

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

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

Оставьте ваши контактные данные. Наш менеджер свяжется и проконсультирует вас.

Читайте также: