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

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

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

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

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

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

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

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

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

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

Повышение эффективности 1Т-подразделений. Этот результат достигается за счет автоматизации различных процессов.

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

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

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

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

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

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

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

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

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

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

< >

1. Определение целей архитектуры

\_____/

Процесс создания архитектуры ПО

Рис. 5.1. Процесс создания архитектуры ПО

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

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

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

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

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

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

Пример 5.2. Рассмотрим процесс определения целей архитектуры при разработке интернет-магазина по продаже сотовых телефонов:

  • задачей архитектуры будет являться разработка архитектуры нового приложения по продаже сотовых телефонов через Интернет;
  • потребителями будут разработчики, тестировщики и другие 1Т-специалисты; архитектура будет представлена заказчику на одобрение, но ему может быть достаточно общей сметы затрат, чтобы утвердить или предложить переработать архитектуру, если предлагаемое решение получится слишком дорогим для него;
  • • основные ограничения, накладываемые на архитектуру: наличие только УеЬ-интерфейса; лимитирование бюджета на приобретение сервера для магазина, а также на покупку лицензий для сервера баз данных; определенные требования по пропускной способности сервера (число одновременных запросов, обрабатываемых в минуту, и др.).

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

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

Диаграмма вариантов использования (рис. 5.2) состоит из следующих элементов: «актеров», для которых система производит действие (актер обозначается значком человечка); «действий», которые актеры хотят получить от системы (действие обозначается овалом); «комментариев» (отображаются в виде прямоугольников и соединяются с комментируемым элементом линией); «использования действий» (обозначается в виде стрелок, которые направлены от актера к действию, над стрелкой указывается ключевое слово «uses»); «расширения действий» или дополнительных действий (показывается в виде стрелки от действия-расширения к действию, которое оно расширяет, над стрелкой указывается ключевое слово «extends»; если одно действие включается в другое, то используется ключевое слово

Интернет-магазин по продаже сотовых телефонов

Диаграмма вариантов использования для интернет-магазина

Рис. 5.2. Диаграмма вариантов использования для интернет-магазина

по продаже сотовых телефонов

Любой

пользователь сети

Заре ги сгр ирован н ы й пользователь

Только менеджер может изменять статус заказа

«include»). Диаграмма используется при проектировании архитектуры приложения.

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

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

Консольные приложения. Консоль подразумевает отображение только текстовых данных. Одним из представителей подобного приложения можно назвать файловый менеджер FAR, который является «наследником» аналогичных программ, используемых в операционной системе DOS.

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

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

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

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

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

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

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

Ограничения по программным требованиям. Например, использование конкретной операционной системы.

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

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

Пример 5.5. Для рассмотренного ранее интернет-магазина следует ввести следующие ограничения развертывания, заданные заказчиком: Web-сервер должен находиться на одном физическом сервере с базой данных, где будет храниться информация по заказам; необходимо использовать сервер на базе операционной системы Linux или Unix.

 
< Пред   СОДЕРЖАНИЕ     След >