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

Введение

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

1.Сущность и задачи архитектуры программного обеспечения

Под архитектурой программного обеспечения понимается набор внутренних структур программного обеспечения, которые видны под разными углами и состоят из компонентов, их взаимосвязей и возможных взаимодействий между компонентами, а также свойств, доступных извне этих компонентов.
По компоненту в данном определении это довольно произвольный программный структурный элемент, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает. В общем, при разработке программного обеспечения термин "компонент" (см. ниже обсуждение компонентных технологий) имеет немного другое и более узкое значение: это единица развертывания, наименьшая часть системы, которая может быть включена или не включена в система.
Такой компонент также имеет определенный интерфейс и удовлетворяет набору правил, называемому шаблоном компонента. Там, где возможны недоразумения, будет указано, в каком смысле используется этот термин. В этой лекции, прежде чем обсуждать UML, мы будем использовать в основном широкое понимание этого термина, а затем, наоборот, узкое.
В определении архитектуры упоминается набор структур, а не одна структура. Это означает, что разные аспекты архитектуры, разные взгляды на нее отличаются разными структурами, соответствующими различным аспектам взаимодействия компонентов. [3]
Примерами этих аспектов являются описание типов компонентов и типов статических отношений между ними с использованием диаграмм классов, описание состава компонентов с использованием объектных структур, ссылающихся друг на друга, описание поведения компонентов с использованием их моделирования как чем набор конечных автоматов.

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

2. Разработчики архитектуры программного обеспечения

Архитектура программного обеспечения начинается с набора требований. Они могут быть выражены в виде диаграмм, блок-схем процессов, шаблонов или задокументированных списков операционных задач, которые должно выполнять программное обеспечение. Обычно клиент или партнер также выдвигают менее точные требования, такие как внешний вид или способ работы определенных пользовательских интерфейсов для общих задач.
Требования также должны включать информацию о существующем программном обеспечении, системах, оборудовании и сетях, с которыми будет взаимодействовать новое программное обеспечение; и другие факторы, такие как план развертывания и обслуживания и, конечно же, доступный бюджет проекта.
Разработчик архитектуры программного обеспечения должен учитывать потребности клиента. Однако общий термин "клиент" обычно включает три противоречащих друг другу сферы ответственности: бизнес-требования, требования пользователя и системные требования.
Бизнес-требования обычно определяют ряд факторов, таких как бизнес-процессы, факторы производительности (такие как безопасность, надежность и пропускная способность), а также бюджетные ограничения и ограничения затрат.
Требования пользователя включают дизайн интерфейса, производственные возможности и простоту использования программного обеспечения. Системные требования включают возможности и ограничения оборудования, сети и среды выполнения.
У каждого разработчика программного обеспечения есть свой собственный подход к сбору и анализу требований, а также к определению архитектуры.
Однако им часто приходится отвечать на следующие вопросы « " как пользователи будут работать с приложением?"; " как приложение будет развертываться и управляться в производственной среде?"; " каковы требования к атрибутам качества для приложения, таким как безопасность, производительность, конкуренция, интернационализация и конфигурация?»; «Какой должна быть архитектура приложения, чтобы обеспечить гибкость и простоту обслуживания с течением времени? " и " какие архитектурные тенденции могут повлиять на приложение сейчас и после его развертывания?".

Заключение

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