Remkomplekty.ru

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

Архитектура приложения при разработке

Что нужно учесть при проектировании своего приложения

  • Переводы, 24 июня 2018 в 13:23
  • Никита Прияцелюк

Перед тем, как создавать приложение, необходимо продумать его архитектуру. Как это сделать правильно рассмотрим в статье.

Упростите жизнь разработчикам

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

Что упростит разработчику жизнь:

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

Уделите внимание мелочам

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

Помните о юзабилити

Уровень юзабилити жизненно важен по ряду причин. Он повышает доверие и удовлетворённость клиентов и снижает затраты.

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

Обеспечьте безопасность

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

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

Обеспечьте надёжность

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

  • Очевидно, что в системе не должно происходить сбоев, но всё же они происходят. Нужно обеспечить журналирование и анализ таких сбоев;
  • Система должна быть максимально автономной — если произошёл сбой, будет идеально, если она сама с этим справится;

Краткий обзор 10 популярных архитектурных шаблонов приложений

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

Что такое архитектурный шаблон?

По материалам Википедии,

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

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

1. Многоуровневый шаблон

2. Клиент-серверный шаблон

3. Ведущий-ведомый

4. Каналы и фильтры

5. Шаблон посредника

6. Одноранговый шаблон

7. Шина событий

8. Модель-представление-контроллер

9. Доска

10. Интерпретатор

1. Многоуровневый шаблон

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

Чаще всего в общих информационных системах встречаются следующие 4 слоя:

· Слой представления (также известен как слой пользовательского интерфейса)

· Слой приложения (также известен как слой сервиса)

· Слой бизнес-логики (также известен как уровень предметной области)

· Слой доступа к данным (также известен как уровень хранения данных)

Использование

· Общие десктопные приложения.

2. Клиент-серверный шаблон

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

Использование

· Онлайн приложения (электронная почта, совместный доступ к документам, банковские услуги).

3. Ведущий-ведомый

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

Использование

· В репликации баз данных. Там главная БД считается авторитетным источником, а подчиненные базы с ней синхронизируются.

· Периферийные устройства, подключенные к шине в компьютере (ведущие и ведомые устройства).

4. Каналы и фильтры

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

Использование

· Компиляторы. Последовательные фильтры выполняют лексический, синтаксический, семантический анализ и создание кода.

· Рабочие процессы в биоинформатике.

5. Шаблон посредника

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

Сервер размещает свои возможности (службы и характеристики) у посредника (брокера). Клиент запрашивает услугу у брокера. Затем брокер перенаправляет клиента к подходящей службе из своего реестра.

Использование

6. Одноранговый шаблон

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

Использование

· Проприетарные мультимедийные приложения (как тот же Spotify).

7. Шина событий

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

Использование

· Разработки на Android

8. Модель-представление-контроллер

Этот шаблон также известен как MVC-шаблон. Он разделяет интерактивные прикладные программы на 3 части:

1. модель — содержит ключевые данные и функционал;

2. представление — показывает информацию пользователю (можно задавать более одного представления);

3. контроллер — занимается обработкой данных от пользователя.

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

Использование

· Архитектура WWW-приложений, написанных на основных языках программирования.

9. Доска

Такой шаблон подходит для проблем, для которых отсутствуют четкие детерминированные решения. Шаблон «Доска» состоит из 3 главных компонентов:

· доска — это структурированная глобальная память, содержащая объекты из пространства возможных решений;

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

· компоненты управления — выбирает, настраивает и исполняет модули.

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

Использование

· идентификация и отслеживание транспортных средств;

· определение структур белка;

· интерпретация сигналов Sonar.

10. Интерпретатор

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

Использование

· языки запросов к базе данных (SQL);

· языки, которые используются для описания протоколов передачи данных.

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

Ниже приводятся плюсы и минусы каждого из архитектурных шаблонов.

Многоуровневый шаблон

Плюсы:

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

Минусы:

  • Не универсален.
  • В ряде ситуаций возможен пропуск некоторых слоев.

Клиент-серверный шаблон

Плюсы:

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

Минусы:

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

Шаблон «Ведущий-ведомый»

Плюсы:

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

Минусы:

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

Шаблон «Каналы и фильтры»

Плюсы:

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

Минусы:

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

Шаблон «Посредник»

Плюсы:

  • Возможно динамическое изменение, добавление, удаление и перемещение объектов. Этот шаблон делает процесс распределения прозрачным для разработчика.

Минусы:

  • Необходима стандартизация описаний служб.

Одноранговый шаблон

Плюсы:

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

Минусы:

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

Шаблон «Шина событий»

Плюсы:

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

Минусы:

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

Шаблон «Модель-представление-контроллер»

Плюсы:

  • Упрощает создание различных представлений одной и той же модели; их можно включить или отключить на этапе выполнения.

Минусы:

  • Возрастает сложность алгоритма. Может привести ко многим ненужным корректировкам действий пользователей.

Шаблон «Доска»

Плюсы:

  • Легкое добавление новых приложений.
  • Можно без труда расширять структуры пространства данных.

Минусы:

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

Шаблон «Интерпретатор»

Плюсы:

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

Минусы:

  • Проблемы с производительностью, т.к. интерпретированный язык медленнее скомпилированного.

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

Стоимость архитектуры приложения

сроки выполнения : 21 день

От чего зависит цена

По вашему желанию,
цена будет снижена , если:

Заказать годовое сопровождение

Сократить объем работ
(меньше концептов)

Увеличить сроки выполнения

Проектирование архитектуры приложения

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

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

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

  1. Эффективность: приложение выполняет поставленные задачи и выполняет функции в любых условиях. Система производительна, надежна и справляется со всеми нагрузками.
  2. Гибкость: выбранное решение легко менять, и ошибок становится меньше. Можно изменить один элемент, и это не станет фатальным для других составляющих.
  3. Расширяемость: в приложение можно добавлять сколько угодно функций, если потребуется.
  4. Масштабируемость: время на разработку и дополнение уменьшается. Хорошая архитектура позволяет направить разработку в несколько параллельных потоков.
  5. Тестируемость: приложение легко тестируется, а значит, уменьшается число ошибок и увеличивается его надежность.
  6. Повторное использование: элементы и структуру можно использовать в других проектах.
  7. Понятность: код должен быть понятен как можно большему количеству людей. Над приложением работает много людей. Хорошая архитектура позволяет новичкам быстро разобраться в проекте.

Мы знаем, как сделать хорошую архитектуру! Обращайтесь в агентство KOLORO. Проектирование мобильных приложений – наша специализация.

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

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

  • монолитный;
  • модульный;
  • сервис-ориентированный.

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

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

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

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

Мы знаем, как ускорить проектирование интерфейса приложения! Обращайтесь к специалистам агентства KOLORO.

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

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

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

Сколько стоит час работы архитектора приложения?

Проектирование приложения может оцениваться «пакетом» или по часовой ставке. Диапазон расценок варьируется от 10 000 до 200 000 рублей, а в среднем проектирование обычно оценивается в 100 000 рублей.

Часовая ставка меняется в диапазоне от 1 000 до 2 000 рублей. Чаще всего встречается сумма 1 500 – 1 800 рублей за час.

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

В обязанности архитектора приложения входит:

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

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

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

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

Архитектура зависит от выбранного типа приложения.

Мобильное native-приложение – это программа для iOS, Android и других платформ. Native означает, что приложение создано для одной платформы. Плюс – эффективность благодаря соответствию всем требованиям выбранной категории устройств. Минус – приложение плохо работает на других платформах.

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

Гибридное приложение совмещает в себе элементы первых двух типов. Проектирование андроид приложения и программ для iOS в последнее время часто выбирает этот тип.

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

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

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

Визуальное проектирование приложений

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

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

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

Проектирование, разработка мобильных приложений – мы можем все. И это не преувеличение. Обращайтесь к специалистам нашего агентства KOLORO!

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

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

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

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

О критериях

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

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

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

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

А что еще?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В заключение

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

Часть 1. Планирование архитектуры

Серия контента:

Этот контент является частью # из серии # статей: Определение архитектуры приложений с помощью Rational Software Architect

Этот контент является частью серии: Определение архитектуры приложений с помощью Rational Software Architect

Следите за выходом новых статей этой серии.

Существует много различных методологий, обеспечивающих ряд гибких практических приемов, которые помогают предприятиям надежно выпускать высококачественное программное обеспечение. Сегодня гибкая разработка ПО ― общепринятая практика, и один из ее основных принципов заключается в освоении итеративных и поэтапных методов. Эта статья посвящена конкретным действиям архитектора программного обеспечения и предполагает, что вы уже владеете гибкими методами и итеративной разработкой (подробнее см. в разделе Ресурсы об IBM agility@scale, IBM Practices, OpenUP и Rational Unified Process).

Основная цель этой статьи — проиллюстрировать, как Rational Software Architect 8 (далее ― RSA) помогает в проектировании и документировании архитектуры. RSA — это платформа коллективной работы для проектирования высококачественной архитектуры ПО. RSA помогает определить модели на различных уровнях абстракции и может использоваться для поддержки практических приемов проектирования программного обеспечения.

Архитектурный анализ: планирование и развитие архитектуры

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

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

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

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

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

Как правило, во время этапов разработки выполняются следующие мероприятия по уточнению архитектуры.

  1. Уточнение архитектурных механизмов: технические концепции удовлетворения архитектурно значимых требований, определенных на первом шаге.
  2. Уточнение элементов структуры: архитектурно значимые элементы структуры.
  3. Уточнение архитектуры развертывания: единицы и топологии развертывания.

Итерационные мероприятия описаны во второй статье этого цикла.

Рисунок 1. Итеративный и поэтапный архитектурный анализ

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

Описание архитектуры с помощью представлений

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

В 1995 году Филипп Крухтен предложил модель для описания архитектуры сложных программных систем: модель представления архитектуры программного обеспечения «4+1» (см. раздел Ресурсы). Большинство идей модели «4+1» вошли в такие процессы разработки, как IBM Rational Unified Process (RUP) или OpenUP. Недавно IEEE 1471 стандартизировал определение представления для решения проблем различных пользователей архитектуры программного обеспечения (IEEE 1471-2000/ISO 42010, см. раздел Ресурсы).

В оригинальной модели «4+1» используются пять видов представлений, которые дают всеобъемлющее представление о системе, как показано на рисунке 2.

Рисунок 2. Модель представления архитектуры «4+1»

Каждое представление модели «4+1» отражает вопросы определенных участников процесса, позволяя им легко находить в архитектуре программного обеспечения то, что им нужно. Эту модель можно настраивать. В зависимости от сложности проекта можно получить только необходимое подмножество предлагаемых представлений. Модель можно также расширять, добавляя другие представления для описания архитектуры с другой точки зрения. Дополнительные представления обычно вкладываются в существующие как подкатегории.

В таблице 1 каждая строка соответствует представлению для определенной аудитории, области и модели.

Читать еще:  Dsn архитектура драйвера и архитектура приложения
Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×