Краткое руководство

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

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

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

Архитектура служит blueprint for a system. Он предоставляет абстракцию для управления сложностью системы и создания механизма связи и координации между компонентами.

• Он определяет structured solution чтобы соответствовать всем техническим и эксплуатационным требованиям, оптимизируя при этом общие атрибуты качества, такие как производительность и безопасность.

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

  • Выбор структурных элементов и их интерфейсов, из которых состоит система.

  • Поведение, указанное в сотрудничестве между этими элементами.

  • Составление этих структурных и поведенческих элементов в большую подсистему.

  • Архитектурные решения соответствуют бизнес-целям.

  • Архитектурные стили руководят организацией.

Разработка программного обеспечения

Дизайн программного обеспечения обеспечивает design planкоторый описывает элементы системы, как они подходят и работают вместе, чтобы выполнить требования системы. Цели разработки плана заключаются в следующем:

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

• Действуйте как образец в процессе разработки.

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

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

Цели архитектуры

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

Некоторые из других целей заключаются в следующем -

• Раскройте структуру системы, но скройте детали ее реализации.

• Реализуйте все варианты использования и сценарии.

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

• Соблюдайте как функциональные требования, так и требования к качеству.

• Уменьшите цель владения и улучшите положение организации на рынке.

• Улучшение качества и функциональности, предлагаемых системой.

• Повысьте внешнее доверие к организации или системе.

Ограничения

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

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

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

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

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

• Отсутствие понимания процесса проектирования, опыта проектирования и оценки дизайна.

Роль архитектора программного обеспечения

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

Экспертиза дизайна

• Эксперт в разработке программного обеспечения, включая различные методы и подходы, такие как объектно-ориентированный дизайн, дизайн, управляемый событиями и т. Д.

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

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

Доменная экспертиза

• Эксперт по разрабатываемой системе и плану развития программного обеспечения.

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

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

Технологическая экспертиза

• Эксперт по имеющимся технологиям, помогающий во внедрении системы.

• Координируйте выбор языка программирования, фреймворка, платформ, баз данных и т. Д.

Методологическая экспертиза

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

• Выбирайте подходящие подходы к развитию, которые помогают всей команде.

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

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

• Информационный специалист, который делится знаниями и имеет большой опыт.

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

Результаты работы архитектора

• Четкий, полный, последовательный и достижимый набор функциональных целей

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

• Концепция системы

• Дизайн в виде системы, по крайней мере, с двумя уровнями декомпозиции

• Понятие сроков, атрибутов оператора, а также планов внедрения и работы

• Документ или процесс, обеспечивающий соблюдение функциональной декомпозиции и контролируемую форму интерфейсов.

Атрибуты качества

Качество - это мера совершенства или состояние отсутствия недостатков или дефектов. Атрибуты качества - это системные свойства, которые не связаны с функциональными возможностями системы.

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

Их можно классифицировать как -

Статические атрибуты качества

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

Атрибуты динамического качества

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

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

Сценарии качества

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

• Source - Внутренний или внешний объект, такой как люди, оборудование, программное обеспечение или физическая инфраструктура, которые генерируют стимул.

• Stimulus - Условие, которое необходимо учитывать при поступлении в систему.

• Environment - Стимул возникает в определенных условиях.

• Artifact - Целая система или ее часть, такая как процессоры, каналы связи, постоянное хранилище, процессы и т. Д.

• Response - Действия, предпринимаемые после поступления стимула, такие как обнаружение сбоев, восстановление после сбоя, отключение источника событий и т. Д.

• Response measure - Следует измерять полученные ответы, чтобы можно было проверить требования.

Общие атрибуты качества

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

Категория	Атрибут качества	Описание
Качество дизайна	Концептуальная целостность	Определяет согласованность и согласованность общего дизайна. Это включает способ проектирования компонентов или модулей.
	Ремонтопригодность	Способность системы легко претерпевать изменения.
	Возможность повторного использования	Определяет возможность использования компонентов и подсистем в других приложениях.
Качества времени выполнения	Совместимость	Способность системы или других систем успешно работать, обмениваясь информацией с другими внешними системами, написанными и управляемыми внешними сторонами.
	Управляемость	Определяет, насколько легко системным администраторам управлять приложением.
	Надежность	Способность системы оставаться в рабочем состоянии с течением времени.
	Масштабируемость	Способность системы либо справляться с увеличением нагрузки, не влияя на производительность системы, либо возможность быстрого увеличения.
	Безопасность	Способность системы предотвращать злонамеренные или случайные действия за пределами запланированного использования.
	Спектакль	Индикация реакции системы на выполнение любого действия в течение заданного интервала времени.
	Доступность	Определяет время, в течение которого система функционирует и работает. Его можно измерить как процент от общего времени простоя системы за заранее определенный период.
Системные качества	Возможность поддержки	Способность системы предоставлять информацию, полезную для выявления и решения проблем, когда она не работает правильно.
	Тестируемость	Мера того, насколько легко создать критерии тестирования для системы и ее компонентов.
Качества пользователя	Удобство использования	Определяет, насколько хорошо приложение соответствует требованиям пользователя и потребителя, будучи интуитивно понятным.
Качество архитектуры	Правильность	Ответственность за выполнение всех требований системы.
Качество не во время выполнения	Портативность	Способность системы работать в различной вычислительной среде.
	Целостность	Возможность заставить отдельно разработанные компоненты системы корректно работать вместе.
	Возможность модификации	Легкость, с которой каждая программная система может вносить изменения в свое программное обеспечение.
Атрибуты качества бизнеса	Стоимость и график	Стоимость системы с учетом времени вывода на рынок, ожидаемого срока службы проекта и использования наследия.
	Товарность	Использование системы применительно к рыночной конкуренции.

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

Архитектурный стиль

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

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

• Составьте словарь компонентов и соединителей с правилами их комбинирования.

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

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

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

• Набор типов компонентов, которые выполняют в системе необходимые функции.

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

• Семантические ограничения, которые определяют, как компоненты могут быть интегрированы для формирования системы.

• Топологическая схема компонентов, указывающая их взаимосвязь во время выполнения.

Общий архитектурный дизайн

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

Категория	Архитектурный дизайн	Описание
Общение	Шина сообщений	Описывает использование программной системы, которая может получать и отправлять сообщения, используя один или несколько каналов связи.
	Сервис-ориентированная архитектура (SOA)	Определяет приложения, которые предоставляют и используют функциональность как службу с помощью контрактов и сообщений.
Развертывание	Клиент / сервер	Разделите систему на два приложения, где клиент делает запросы к серверу.
	3 уровня или N уровня	Разделяет функциональность на отдельные сегменты, каждый из которых представляет собой уровень, расположенный на физически отдельном компьютере.
Домен	Доменный дизайн	Сосредоточен на моделировании бизнес-домена и определении бизнес-объектов на основе сущностей в бизнес-области.
Структура	На основе компонентов	Разбейте проект приложения на функциональные или логические компоненты многократного использования, которые предоставляют четко определенные интерфейсы связи.
	Слоистый	Разделите проблемы приложения на группы (слои).
	Объектно-ориентированный	На основе разделения ответственности приложения или системы на объекты, каждый из которых содержит данные и поведение, относящиеся к объекту.

Типы архитектуры

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

• Business architecture - Определяет стратегию бизнеса, управления, организации и ключевых бизнес-процессов внутри предприятия и фокусируется на анализе и разработке бизнес-процессов.

• Application (software) architecture - Служит планом для отдельных прикладных систем, их взаимодействия и их отношений с бизнес-процессами организации.

• Information architecture - Определяет логические и физические активы данных и ресурсы управления данными.

• Information technology (IT) architecture - Определяет строительные блоки аппаратного и программного обеспечения, составляющие общую информационную систему организации.

Процесс проектирования архитектуры

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

• Требования, создаваемые задачами анализа.

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

Результатом процесса проектирования архитектуры является architectural description. Базовый процесс проектирования архитектуры состоит из следующих этапов:

Понять проблему

• Это наиболее важный шаг, поскольку он влияет на качество последующего дизайна.

• Без четкого понимания проблемы невозможно создать эффективное решение.

• Многие программные проекты и продукты считаются провальными, потому что они на самом деле не решают действительную бизнес-проблему или не имеют ощутимой рентабельности инвестиций (ROI).

Определите элементы дизайна и их отношения

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

• Разбиение системы на основные компоненты по функциональным требованиям. Декомпозицию можно смоделировать с помощью матрицы структуры проекта (DSM), которая показывает зависимости между элементами дизайна без указания степени детализации элементов.

• На этом этапе выполняется первая проверка архитектуры путем описания ряда экземпляров системы, и этот этап называется архитектурным проектированием на основе функциональности.

Оцените архитектурный дизайн

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

• Он включает в себя оценку архитектуры на соответствие требованиям атрибутов качества архитектуры.

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

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

Преобразуйте архитектурный дизайн

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

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

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

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

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

Ключевые принципы архитектуры

Ниже приведены ключевые принципы, которые следует учитывать при проектировании архитектуры.

Строить, чтобы меняться, а не строить на долгие годы

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

Снижение риска и модель для анализа

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

Используйте модели и визуализации как инструмент коммуникации и совместной работы

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

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

Используйте инкрементный и итерационный подход

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

Ключевые принципы дизайна

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

Разделение проблем

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

Принцип единой ответственности

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

Принцип наименьшего знания

Ни один компонент или объект не должен знать внутренних деталей других компонентов. Такой подход позволяет избежать взаимозависимости и способствует удобству обслуживания.

Сведите к минимуму большой дизайн заранее

Сведите к минимуму объемный дизайн заранее, если требования приложения неясны. Если есть возможность изменить требования, избегайте создания большого проекта для всей системы.

Не повторяйте функциональность

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

Предпочитайте композицию наследованию при повторном использовании функциональности

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

Определите компоненты и сгруппируйте их в логические слои

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

Определите протокол связи между уровнями

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

Определить формат данных для слоя

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

Компоненты системных служб должны быть абстрактными

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

Исключения проектирования и механизм обработки исключений

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

Соглашения об именах

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

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

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

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

• UML (Unified Modeling Language) - UML - одно из объектно-ориентированных решений, используемых при моделировании и проектировании программного обеспечения.

• Architecture View Model (4+1 view model) - Модель представления архитектуры представляет функциональные и нефункциональные требования программного приложения.

• ADL (Architecture Description Language) - ADL определяет архитектуру программного обеспечения формально и семантически.

UML

UML расшифровывается как Unified Modeling Language. Это графический язык, используемый для создания чертежей программного обеспечения. UML был создан Object Management Group (OMG). Проект спецификации UML 1.0 был предложен OMG в январе 1997 года. Он служит стандартом для анализа требований к программному обеспечению и проектной документации, которая является основой для разработки программного обеспечения.

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

Эти элементы подобны компонентам, которые можно связывать различными способами для создания полной картины UML, известной как diagram. Таким образом, очень важно понимать различные диаграммы для реализации знаний в реальных системах. У нас есть две широкие категории диаграмм, и они делятся на подкатегории, т.е.Structural Diagrams и Behavioral Diagrams.

Структурные схемы

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

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

• Диаграмма классов
• Схема объекта
• Схема компонентов
• Схема развертывания
• Схема упаковки
• Композитная структура

В следующей таблице представлено краткое описание этих диаграмм -

Sr.No.	Схема и описание
1	Class Представляет объектную ориентацию системы. Показывает, как классы статически связаны.
2	Object Представляет набор объектов и их взаимосвязей во время выполнения, а также представляет статическое представление системы.
3	Component Описывает все компоненты, их взаимосвязь, взаимодействия и интерфейс системы.
4	Composite structure Описывает внутреннюю структуру компонента, включая все классы, интерфейсы компонента и т. Д.
5	Package Описывает структуру и организацию пакета. Охватывает классы в пакете и пакеты в другом пакете.
6	Deployment Диаграммы развертывания - это набор узлов и их взаимосвязей. Эти узлы являются физическими объектами, на которых развернуты компоненты.

Диаграммы поведения

Диаграммы поведения в основном отражают динамический аспект системы. Динамические аспекты - это в основном изменяющиеся / движущиеся части системы. UML имеет следующие типы диаграмм поведения:

• Диаграмма вариантов использования
• Диаграмма последовательности
• Схема связи
• Диаграмма диаграммы состояний
• Диаграмма деятельности
• Обзор взаимодействия
• Диаграмма временной последовательности

В следующей таблице представлено краткое описание этой диаграммы -

Sr.No.	Схема и описание
1	Use case Описывает отношения между функциями и их внутренними / внешними контроллерами. Эти контроллеры известны как акторы.
2	Activity Описывает поток управления в системе. Он состоит из мероприятий и ссылок. Поток может быть последовательным, параллельным или разветвленным.
3	State Machine/state chart Представляет изменение состояния системы, управляемое событиями. Он в основном описывает изменение состояния класса, интерфейса и т. Д. Используется для визуализации реакции системы на внутренние / внешние факторы.
4	Sequence Визуализирует последовательность вызовов в системе для выполнения определенных функций.
5	Interaction Overview Сочетает в себе диаграммы действий и последовательностей, чтобы обеспечить обзор потока управления системой и бизнес-процессом.
6	Communication То же, что и диаграмма последовательности, за исключением того, что она фокусируется на роли объекта. Каждое сообщение связано с порядком следования, номером плюс прошлые сообщения.
7	Time Sequenced Описывает изменения по сообщениям в состоянии, состоянии и событиях.

Модель представления архитектуры

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

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

4 + 1 Просмотр модели

Модель представления 4 + 1 была разработана Филиппом Крухтеном для описания архитектуры программно-интенсивной системы, основанной на использовании нескольких одновременных представлений. Этоmultiple viewмодель, которая учитывает различные функции и проблемы системы. Он стандартизирует проектную документацию программного обеспечения и упрощает понимание проекта всеми заинтересованными сторонами.

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

• The logical view or conceptual view - Описывает объектную модель дизайна.

• The process view - Он описывает деятельность системы, фиксирует аспекты параллелизма и синхронизации проекта.

• The physical view - Он описывает отображение программного обеспечения на аппаратное обеспечение и отражает его распределенный аспект.

• The development view - Он описывает статическую организацию или структуру программного обеспечения в среде разработки.

Эту модель представления можно расширить, добавив еще одно представление под названием scenario view или же use case viewдля конечных пользователей или заказчиков программных систем. Он согласован с другими четырьмя представлениями и используется для иллюстрации архитектуры, служащей представлением «плюс один», (4 + 1) моделью представления. На следующем рисунке описана архитектура программного обеспечения с использованием модели пяти параллельных представлений (4 + 1).

Почему он называется 4 + 1 вместо 5?

В use case viewимеет особое значение, поскольку подробно описывает требования высокого уровня к системе, в то время как другие рассматривают детали - как эти требования реализованы. Когда все остальные четыре представления завершены, это фактически избыточно. Однако все другие виды без него были бы невозможны. На следующем изображении и в таблице подробно показан вид 4 + 1 -

	Логический	Процесс	Развитие	Физический	Сценарий
Описание	Показывает компонент (объект) системы, а также их взаимодействие	Показывает процессы / правила рабочего процесса системы и то, как эти процессы взаимодействуют, фокусируется на динамическом представлении системы	Предоставляет структурные блоки системы и описывает статическую организацию системных модулей.	Показывает установку, настройку и развертывание программного приложения.	Показывает, что дизайн завершен путем проверки и иллюстрации.
Наблюдатель / держатель ставки	Конечный пользователь, аналитики и дизайнер	Интеграторы и разработчики	Программист и менеджеры программных проектов	Системный инженер, операторы, системные администраторы и установщики систем	Все мнения их взглядов и оценщиков
Рассматривать	Функциональные требования	Нефункциональные требования	Организация программных модулей (повторное использование управления программным обеспечением, ограничение инструментов)	Нефункциональные требования к базовому оборудованию	Системная согласованность и достоверность
UML - Диаграмма	Класс, Состояние, Объект, последовательность, Схема связи	Диаграмма деятельности	Компонент, Диаграмма пакета	Схема развертывания	Диаграмма вариантов использования

Языки описания архитектуры (ADL)

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

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

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

Трудно классифицировать или различать ADL и язык программирования или язык моделирования. Однако существуют следующие требования для того, чтобы язык был классифицирован как ADL:

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

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

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

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

• Он должен поддерживать аналитические возможности или обеспечивать быстрое создание прототипов.

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

• Первый объектно-ориентированный язык был Simula (Моделирование реальных систем), который был разработан в 1960 году исследователями Норвежского вычислительного центра.

• В 1970 г. Alan Kay и его исследовательская группа в Xerox PARC создали персональный компьютер под названием Dynabook и первый чистый объектно-ориентированный язык программирования (OOPL) - Smalltalk для программирования Dynabook.

• В 1980-х годах Grady Boochопубликовал статью под названием «Объектно-ориентированный дизайн», в которой в основном был представлен дизайн для языка программирования Ada. В следующих изданиях он расширил свои идеи до полного объектно-ориентированного метода проектирования.

• В 1990-е годы Coad включил поведенческие идеи в объектно-ориентированные методы.

Другими значительными нововведениями стали методы объектного моделирования (OMT) от James Rum Baugh и объектно-ориентированное программное обеспечение (OOSE) Ivar Jacobson.

Введение в объектно-ориентированную парадигму

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

Основные понятия и терминология объектно-ориентированных систем -

Объект

Объект - это элемент реального мира в объектно-ориентированной среде, который может иметь физическое или концептуальное существование. У каждого объекта есть -

• Идентичность, которая отличает его от других объектов в системе.

• Состояние, определяющее характерные свойства объекта, а также значения свойств, которыми обладает объект.

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

Объекты можно моделировать в соответствии с потребностями приложения. Объект может иметь физическое существование, например клиент, автомобиль и т. Д .; или нематериальное концептуальное существование, такое как проект, процесс и т. д.

Класс

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

Составляющими класса являются -

• Набор атрибутов для объектов, которые должны быть созданы из класса. Как правило, разные объекты класса имеют некоторые различия в значениях атрибутов. Атрибуты часто называют данными класса.

• Набор операций, отображающих поведение объектов класса. Операции также называются функциями или методами.

Example

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

• x – координата, чтобы обозначить x – координату центра.
• y – координата, чтобы обозначить y – координату центра.
• a, чтобы обозначить радиус круга

Некоторые из его операций можно определить следующим образом:

• findArea (), метод вычисления площади
• findCircumference (), метод вычисления окружности
• scale (), метод увеличения или уменьшения радиуса

Инкапсуляция

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

Полиморфизм

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

Example

Давайте рассмотрим два класса, Circle и Square, каждый из которых имеет метод findArea (). Хотя название и назначение методов в классах одинаковы, внутренняя реализация, то есть процедура вычисления площади, различна для каждого класса. Когда объект класса Circle вызывает свой метод findArea (), операция находит область круга без какого-либо конфликта с методом findArea () класса Square.

Relationships

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

Сообщение передается

Любое приложение требует гармоничного взаимодействия нескольких объектов. Объекты в системе могут связываться друг с другом с помощью передачи сообщений. Предположим, в системе есть два объекта - obj1 и obj2. Объект obj1 отправляет сообщение объекту obj2, если obj1 хочет, чтобы obj2 выполнил один из своих методов.

Состав или агрегирование

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

Ассоциация

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

• Унарное отношение связывает объекты одного класса.
• Бинарная связь связывает объекты двух классов.
• Тернарное отношение связывает объекты трех или более классов.

Наследование

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

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

Example

От класса Mammal может быть получен ряд классов, таких как Человек, Кошка, Собака, Корова и т. Д. Люди, кошки, собаки и коровы имеют отличительные характеристики млекопитающих. Кроме того, у каждого есть свои особенности. Можно сказать, что корова - это млекопитающее.

ОО анализ

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

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

Объектное моделирование

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

Процесс моделирования объекта можно визуализировать в следующих шагах -

• Определять объекты и группировать в классы
• Определите отношения между классами
• Создать схему пользовательской объектной модели
• Определите атрибуты объекта пользователя
• Определите операции, которые должны выполняться над классами

Динамическое моделирование

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

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

Процесс динамического моделирования можно визуализировать в следующих шагах -

• Определить состояния каждого объекта
• Выявление событий и анализ применимости действий
• Постройте диаграмму динамической модели, состоящую из диаграмм переходов состояний.
• Express each state in terms of object attributes
• Validate the state–transition diagrams drawn

Functional Modeling

Functional Modeling is the final component of object-oriented analysis. The functional model shows the processes that are performed within an object and how the data changes, as it moves between methods. It specifies the meaning of the operations of an object modeling and the actions of a dynamic modeling. The functional model corresponds to the data flow diagram of traditional structured analysis.

Процесс функционального моделирования можно визуализировать в следующих шагах -

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

Объектно-ориентированный дизайн

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

Этапы объектно-ориентированного проектирования могут быть определены как:

• Определение контекста системы
• Проектирование системной архитектуры
• Идентификация объектов в системе
• Построение дизайнерских макетов
• Спецификация объектных интерфейсов

OO Design можно разделить на два этапа - Концептуальное проектирование и Детальное проектирование.

Conceptual design

На этом этапе определяются все классы, необходимые для построения системы. Кроме того, на каждый класс возлагаются определенные обязанности. Диаграмма классов используется для пояснения отношений между классами, а диаграмма взаимодействия используется для отображения потока событий. Он также известен какhigh-level design.

Detailed design

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

Принципы дизайна

Ниже приведены основные принципы дизайна -

Principle of Decoupling

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

Ensuring Cohesion

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

Open-closed Principle

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

• Для каждого конкретного класса необходимо поддерживать отдельный интерфейс и реализации.

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

• Сведите к минимуму использование глобальных переменных и переменных класса.

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

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

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

• Пакетная последовательная
• Труба и фильтр или непоследовательный конвейерный режим
• Контроль над процессом

Пакетный последовательный

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

• Поток данных переносит пакет данных в целом от одной подсистемы к другой.

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

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

• Типичное применение этой архитектуры включает обработку бизнес-данных, такую ​​как банковское дело и выставление счетов за коммунальные услуги.

Преимущества

• Обеспечивает более простое разделение на подсистемы.

• Каждая подсистема может быть независимой программой, работающей с входными данными и производящей выходные данные.

Недостатки

• Обеспечивает высокую задержку и низкую пропускную способность.

• Не обеспечивает параллелизма и интерактивного интерфейса.

• Для реализации требуется внешний контроль.

Архитектура труб и фильтров

Этот подход делает упор на постепенное преобразование данных последовательными компонентами. В этом подходе поток данных управляется данными, и вся система разбивается на компоненты: источник данных, фильтры, каналы и приемники данных.

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

Фильтр

Фильтр - это независимый преобразователь потока данных или преобразователи потока. Он преобразует данные входящего потока данных, обрабатывает их и записывает преобразованный поток данных по конвейеру для обработки следующим фильтром. Он работает в инкрементном режиме, в котором он начинает работать, как только данные поступают через подключенный канал. Есть два типа фильтров -active filter и passive filter.

Active filter

Активный фильтр позволяет подключенным каналам извлекать данные и выталкивать преобразованные данные. Он работает с пассивным конвейером, который предоставляет механизмы чтения / записи для извлечения и толкания. Этот режим используется в конвейере UNIX и механизме фильтрации.

Passive filter

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

Преимущества

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

• Обеспечивает возможность повторного использования и упрощает обслуживание системы.

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

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

• Обеспечивает гибкость, поддерживая как последовательное, так и параллельное выполнение.

Недостатки

• Не подходит для динамического взаимодействия.

• Для передачи данных в форматах ASCII необходим низкий общий знаменатель.

• Накладные расходы на преобразование данных между фильтрами.

• Не позволяет фильтрам совместно взаимодействовать для решения проблемы.

• Сложно настроить эту архитектуру динамически.

Труба

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

Архитектура управления процессами

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

Типы подсистем

Архитектура управления процессом будет иметь processing unit для изменения переменных управления процессом и controller unit для расчета суммы изменений.

Блок контроллера должен иметь следующие элементы -

• Controlled Variable- Управляемая переменная предоставляет значения для базовой системы и должна измеряться датчиками. Например, скорость в системе круиз-контроля.

• Input Variable- Измеряет вход в процесс. Например, температура возвратного воздуха в системе контроля температуры.

• Manipulated Variable - Значение управляемой переменной регулируется или изменяется контроллером.

• Process Definition - Он включает механизмы для управления некоторыми переменными процесса.

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

• Set Point - Это желаемое значение контролируемой переменной.

• Control Algorithm - Он используется для принятия решения о том, как управлять переменными процесса.

Области применения

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

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

• Приложения, целью которых является поддержание заданных свойств выходов процесса при заданных эталонных значениях.

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

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

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

Наиболее известные примеры архитектуры, ориентированной на данные, - это архитектура базы данных, в которой общая схема базы данных создается с помощью протокола определения данных - например, набор связанных таблиц с полями и типами данных в СУБД.

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

Типы компонентов

Есть два типа компонентов -

• А central dataструктура или хранилище данных или репозиторий данных, которое отвечает за обеспечение постоянного хранения данных. Он представляет текущее состояние.

• А data accessor или набор независимых компонентов, которые работают с центральным хранилищем данных, выполняют вычисления и могут возвращать результаты.

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

• Стиль архитектуры репозитория
• Классная Архитектура Стиль

Стиль архитектуры репозитория

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

• Клиент отправляет в систему запрос на выполнение действий (например, вставку данных).

• Вычислительные процессы независимы и запускаются входящими запросами.

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

• Этот подход широко используется в СУБД, библиотечной информационной системе, репозитории интерфейсов в CORBA, компиляторах и средах CASE (автоматизированная разработка программного обеспечения).

Преимущества

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

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

• Снижает накладные расходы на переходные данные между программными компонентами.

Недостатки

• Он более уязвим к сбоям, и возможна репликация или дублирование данных.

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

• Изменения в структуре данных сильно влияют на клиентов.

• Развитие данных сложно и дорого.

• Стоимость перемещения данных по сети для распределенных данных.

Классная Архитектура Стиль

В архитектурном стиле Blackboard хранилище данных активно, а его клиенты пассивны. Следовательно, логический поток определяется текущим статусом данных в хранилище данных. У него есть компонент «классная доска», действующий как центральное хранилище данных, а внутреннее представление создается и используется различными вычислительными элементами.

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

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

• Текущее состояние решения сохраняется на доске, и обработка запускается в зависимости от состояния доски.

• Система отправляет уведомления, известные как trigger и данные для клиентов, когда в данных происходят изменения.

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

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

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

Части модели Blackboard

Модель доски обычно представлена ​​тремя основными частями:

Knowledge Sources (KS)

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

Blackboard Data Structure

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

Control

Control управляет задачами и проверяет состояние работы.

Преимущества

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

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

• Поддерживает экспериментирование с гипотезами.

• Поддерживает возможность повторного использования агентов источников знаний.

Недостатки

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

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

• Проблемы с синхронизацией нескольких агентов.

• Основные проблемы при проектировании и тестировании системы.

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

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

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

Иерархические архитектурные стили делятся на -

• Main-subroutine
• Master-slave
• Виртуальная машина

Главная подпрограмма

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

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

Есть два способа, которыми данные передаются в качестве параметров подпрограмм, а именно:

• Pass by Value - Подпрограммы используют только прошлые данные, но не могут их изменять.

• Pass by Reference - Подпрограммы используют, а также изменяют значение данных, на которые ссылается параметр.

Преимущества

• Простая декомпозиция системы на основе уточнения иерархии.

• Может использоваться в подсистеме объектно-ориентированного проектирования.

Недостатки

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

• Плотное соединение может вызвать более волнообразный эффект изменений.

Мастер-Раб

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

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

Реализация шаблона Master-Slave включает пять шагов:

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

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

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

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

• Реализуйте мастер в соответствии со спецификациями, разработанными на шагах с 1 по 3.

Приложения

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

• Широко применяется в области параллельных и распределенных вычислений.

Преимущества

• Более быстрые вычисления и простая масштабируемость.

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

• Slave может быть реализован иначе, чтобы минимизировать семантические ошибки.

Недостатки

• Накладные расходы на связь.

• Не все проблемы можно разделить.

• Трудно реализовать и проблема переносимости.

Архитектура виртуальной машины

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

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

В большинстве случаев виртуальная машина отделяет язык программирования или среду приложения от платформы выполнения. Основная цель - предоставитьportability. Интерпретация конкретного модуля через виртуальную машину может восприниматься как -

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

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

На следующем рисунке показана архитектура стандартной инфраструктуры виртуальной машины на одной физической машине.

В hypervisor, также называется virtual machine monitor, работает в ОС хоста и выделяет соответствующие ресурсы каждой гостевой ОС. Когда гость выполняет системный вызов, гипервизор перехватывает и преобразует его в соответствующий системный вызов, поддерживаемый ОС хоста. Гипервизор контролирует доступ каждой виртуальной машины к ЦП, памяти, постоянному хранилищу, устройствам ввода-вывода и сети.

Приложения

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

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

• Примеры приложений включают интерпретаторы микропрограммирования, обработку XML, выполнение командного языка сценариев, выполнение системы на основе правил, язык программирования Smalltalk и интерпретатор Java.

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

Преимущества

• Мобильность и независимость от платформы машины.

• Простота разработки программного обеспечения.

• Обеспечивает гибкость за счет возможности прерывания и запроса программы.

• Моделирование аварийной рабочей модели.

• Вносите изменения во время выполнения.

Недостатки

• Медленное выполнение интерпретатора из-за его характера.

• Существует снижение производительности из-за дополнительных вычислений, связанных с выполнением.

Многослойный стиль

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

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

• Каждый уровень предоставляет услуги более высокому уровню и служит клиентом для уровня ниже, т.е. запрос к уровню i + 1 вызывает услуги, предоставляемые уровнем i через интерфейс уровня i. Ответ может вернуться на уровень i +1, если задача завершена; в противном случае уровень i постоянно вызывает службы уровня i -1 ниже.

Приложения

Многослойный стиль подходит в следующих областях -

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

• Любое приложение, которое можно разделить на части для конкретных приложений и платформ.

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

Преимущества

• Дизайн, основанный на возрастающих уровнях абстракции.

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

• Разделение стандартного интерфейса и его реализации.

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

• Каждый уровень может быть абстрактной машиной, развернутой независимо и поддерживающей переносимость.

• Простая декомпозиция системы на основе определения задач в порядке уточнения сверху вниз

• Различные реализации (с идентичными интерфейсами) одного и того же уровня могут использоваться взаимозаменяемо.

Недостатки

• Многие приложения или системы нелегко структурировать в многоуровневую структуру.

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

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

• Открытие межуровневой связи может вызвать тупиковые ситуации, а «мостик» может вызвать сильную связь.

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

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

• Data module - Модуль данных обеспечивает абстракцию данных и всю бизнес-логику.

• Control module - Модуль управления определяет последовательность действий по управлению и настройке системы.

• View presentation module - Модуль представления представления отвечает за визуальное или звуковое представление вывода данных, а также предоставляет интерфейс для ввода данных пользователем.

Архитектура, ориентированная на взаимодействие, имеет два основных стиля: Model-View-Controller (MVC) и Presentation-Abstraction-Control(PAC). И MVC, и PAC предлагают трехкомпонентную декомпозицию и используются для интерактивных приложений, таких как веб-приложения с несколькими разговорами и взаимодействиями с пользователем. Они разные по своему контролю и организации. PAC - это иерархическая архитектура на основе агентов, но MVC не имеет четкой иерархической структуры.

Модель-представление-контроллер (MVC)

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

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

Модель

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

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

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

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

Посмотреть

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

• Представления запрашивают информацию из своей модели и генерируют выходное представление для пользователя.

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

Контроллер

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

• Он действует как интерфейс между связанными моделями и представлениями и устройствами ввода.

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

MVC - I

Это простая версия архитектуры MVC, в которой система разделена на две подсистемы:

• The Controller-View - Представление контроллера действует как интерфейс ввода / вывода, и обработка выполняется.

• The Model - Модель предоставляет все данные и сервисы домена.

MVC-I Architecture

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

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

MVC - II

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

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

MVC-II Architecture

Приложения MVC

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

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

Advantages

• Доступно множество наборов инструментов для платформы MVC.

• Несколько представлений синхронизированы с одной и той же моделью данных.

• Легко добавлять новые или заменять виды интерфейса.

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

Disadvantages

• Не подходит для агентно-ориентированных приложений, таких как интерактивные мобильные и робототехнические приложения.

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

• Разделение между представлением и контроллером в некоторых случаях неясно.

Презентация-Абстракция-Управление (PAC)

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

Каждый агент состоит из трех компонентов -

• The presentation component - Форматирует визуальное и звуковое представление данных.

• The abstraction component - Извлекает и обрабатывает данные.

• The control component - Обрабатывает такую ​​задачу, как поток управления и связь между двумя другими компонентами.

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

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

На следующем рисунке показана блок-схема для одного агента в проекте PAC.

PAC с несколькими агентами

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

• У каждого агента есть своя конкретная назначенная работа.

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

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

На следующем рисунке показано несколько агентов, участвующих в PAC.

Applications

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

• Эффективен, когда ожидается, что связь между агентами будет слабой, так что изменения в агенте не влияют на другие.

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

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

Преимущества

• Поддержка многозадачности и множественного просмотра

• Поддержка повторного использования и расширяемости агента

• Легко подключить новый агент или изменить существующий

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

Недостатки

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

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

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

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

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

• Распределенная система может быть продемонстрирована архитектурой клиент-сервер, которая составляет основу для многоуровневых архитектур; альтернативы - архитектура брокера, такая как CORBA, и сервис-ориентированная архитектура (SOA).

• Существует несколько технологических платформ для поддержки распределенных архитектур, включая .NET, J2EE, CORBA, веб-службы .NET, веб-службы AXIS Java и службы Globus Grid.

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

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

Промежуточное ПО как инфраструктура распределенной системы

Основа распределенной архитектуры - ее прозрачность, надежность и доступность.

В следующей таблице перечислены различные формы прозрачности в распределенной системе.

Sr.No.	Прозрачность и описание
1	Access Скрывает способ доступа к ресурсам и различия в платформе данных.
2	Location Скрывает, где находятся ресурсы.
3	Technology Скрывает от пользователя различные технологии, такие как язык программирования и ОС.
4	Migration / Relocation Скрыть используемые ресурсы, которые могут быть перемещены в другое место.
5	Replication Скрыть ресурсы, которые могут быть скопированы в нескольких местах.
6	Concurrency Скрыть ресурсы, которыми могут поделиться с другими пользователями.
7	Failure Скрывает сбой и восстановление ресурсов от пользователя.
8	Persistence Скрывает, находится ли ресурс (программное обеспечение) в памяти или на диске.

Преимущества

• Resource sharing - Совместное использование аппаратных и программных ресурсов.

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

• Concurrency - Параллельная обработка для повышения производительности.

• Scalability - Увеличена пропускная способность за счет добавления новых ресурсов.

• Fault tolerance - Возможность продолжить работу после возникновения неисправности.

Недостатки

• Complexity - Они сложнее централизованных систем.

• Security - Более восприимчивы к внешним атакам.

• Manageability - Требуется больше усилий для управления системой.

• Unpredictability - Непредсказуемые реакции в зависимости от организации системы и загрузки сети.

Централизованная система против распределенной системы

Критерии	Централизованная система	Распределенная система
Экономика	Низкий	Высоко
Доступность	Низкий	Высоко
Сложность	Низкий	Высоко
Последовательность	просто	Высоко
Масштабируемость	Бедных	Хорошо
Технологии	Однородный	Неоднородный
Безопасность	Высоко	Низкий

Клиент-серверная архитектура

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

• Client - Это первый процесс, который отправляет запрос второму процессу, то есть серверу.

• Server - Это второй процесс, который получает запрос, выполняет его и отправляет ответ клиенту.

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

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

Модель тонкого клиента

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

• Используется, когда устаревшие системы переносятся на клиент-серверные архитектуры, в которых устаревшая система действует как самостоятельный сервер с графическим интерфейсом, реализованным на клиенте.

• Основным недостатком является то, что он создает большую вычислительную нагрузку как на сервер, так и на сеть.

Модель толстого / толстого клиента

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

• Наиболее подходит для новых систем C / S, где возможности клиентской системы известны заранее

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

Преимущества

• Разделение обязанностей, таких как представление пользовательского интерфейса и обработка бизнес-логики.

• Возможность повторного использования серверных компонентов и возможность параллелизма

• Упрощает проектирование и разработку распределенных приложений

• Это упрощает миграцию или интеграцию существующих приложений в распределенную среду.

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

Недостатки

• Отсутствие разнородной инфраструктуры для работы с изменениями требований.

• Проблемы безопасности.

• Ограниченная доступность и надежность сервера.

• Ограниченная тестируемость и масштабируемость.

• Толстые клиенты с презентацией и бизнес-логикой вместе.

Многоуровневая архитектура (многоуровневая архитектура)

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

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

Уровень презентации

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

Уровень приложения (бизнес-логика, уровень логики или средний уровень)

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

Уровень данных

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

Advantages

• Лучшая производительность, чем у тонкого клиента, и проще в управлении, чем у толстого клиента.

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

• Обеспечивает поддержку многопоточности, а также снижает сетевой трафик.

• Обеспечивает ремонтопригодность и гибкость

Disadvantages

• Неудовлетворительная возможность тестирования из-за отсутствия инструментов тестирования.

• Повышенная надежность и доступность серверов.

Архитектурный стиль брокера

Broker Architectural Style - это архитектура промежуточного программного обеспечения, используемая в распределенных вычислениях для координации и обеспечения связи между зарегистрированными серверами и клиентами. Здесь обмен объектами осуществляется через промежуточное программное обеспечение, называемое брокером объектных запросов (программная шина).

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

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

• CORBA (Common Object Request Broker Architecture) - хороший пример реализации архитектуры брокера.

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

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

Broker

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

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

• Он сохраняет регистрационную информацию серверов, включая их функции и услуги, а также информацию о местоположении.

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

Stub

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

Прокси-сервер скрывает IPC (межпроцессное взаимодействие) на уровне протокола и выполняет маршалинг значений параметров и де-маршалинг результатов с сервера.

Skeleton

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

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

Bridge

Мост может соединять две разные сети на основе разных протоколов связи. Он является посредником между различными брокерами, включая брокеров DCOM, .NET remote и Java CORBA.

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

Broker implementation in CORBA

CORBA - это международный стандарт для брокера объектных запросов - промежуточного программного обеспечения для управления коммуникациями между распределенными объектами, определенными OMG (группой управления объектами).

Сервис-ориентированная архитектура (SOA)

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

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

Особенности SOA

Сервис-ориентированная архитектура предоставляет следующие функции:

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

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

• Interoperability - Совместное использование возможностей и повторное использование общих служб в сети независимо от базовых протоколов или технологии реализации.

• Reusability - Выберите поставщика услуг и получите доступ к существующим ресурсам, представленным как услуги.

SOA Operation

На следующем рисунке показано, как работает SOA.

Advantages

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

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

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

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

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

• Разработка бизнес-приложений на основе SOA намного эффективнее с точки зрения времени и затрат.

• Повышает масштабируемость и обеспечивает стандартное соединение между системами.

• Эффективное и действенное использование «Деловых услуг».

• Интеграция становится намного проще и улучшается внутренняя совместимость.

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

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

Основная цель компонентной архитектуры - обеспечить component reusability. Компонент инкапсулирует функциональность и поведение программного элемента в многоразовый и саморазвертывающийся двоичный модуль. Существует множество стандартных компонентных сред, таких как COM / DCOM, JavaBean, EJB, CORBA, .NET, веб-службы и сетевые службы. Эти технологии широко используются в разработке графических приложений для локального рабочего стола, таких как графические компоненты JavaBean, компоненты MS ActiveX и компоненты COM, которые можно повторно использовать простым перетаскиванием.

Компонентно-ориентированный дизайн программного обеспечения имеет много преимуществ по сравнению с традиционными объектно-ориентированными подходами, такими как:

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

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

Что такое компонент?

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

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

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

Виды компонента

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

Object-oriented view

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

Conventional view

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

Process-related view

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

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

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

• Многие компоненты являются невидимыми, которые распространяются в корпоративных бизнес-приложениях и Интернет-приложениях, таких как Enterprise JavaBean (EJB), компоненты .NET и компоненты CORBA.

Характеристики компонентов

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

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

• Not context specific - Компоненты предназначены для работы в различных средах и контекстах.

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

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

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

Принципы компонентно-ориентированного проектирования

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

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

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

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

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

• Соединители соединяют компоненты, определяя и управляя взаимодействием между компонентами. Тип взаимодействия определяется интерфейсами компонентов.

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

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

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

Рекомендации по проектированию на уровне компонентов

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

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

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

• Распознает и обнаруживает эти независимые сущности как новые компоненты.

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

• Моделирует любые зависимости слева направо и наследование сверху (базовый класс) вниз (производные классы).

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

Проведение проектирования на уровне компонентов

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

• Распознает все классы проектирования, соответствующие предметной области инфраструктуры.

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

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

• Подробно описывает поток обработки внутри каждой операции с помощью псевдокода или диаграмм активности UML.

• Описывает постоянные источники данных (базы данных и файлы) и определяет классы, необходимые для управления ими.

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

• Разрабатывает схемы развертывания, чтобы предоставить дополнительные сведения о реализации.

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

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

Преимущества

• Ease of deployment - По мере появления новых совместимых версий становится легче заменить существующие версии, не влияя на другие компоненты или систему в целом.

• Reduced cost - Использование сторонних компонентов позволяет распределить расходы на разработку и сопровождение.

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

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

• Modification of technical complexity - Компонент изменяет сложность за счет использования контейнера компонентов и его сервисов.

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

• System maintenance and evolution - Легко изменить и обновить реализацию, не затрагивая остальную систему.

• Independent- Независимость и гибкость подключения компонентов. Независимая разработка компонентов разными группами параллельно. Производительность для разработки программного обеспечения и будущего развития программного обеспечения.

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

• Принятие ввода пользователя

• Отображение вывода

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

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

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

• UI имеет свой синтаксис и семантику. Синтаксис включает типы компонентов, такие как текст, значок, кнопка и т. Д., А удобство использования обобщает семантику пользовательского интерфейса. Качество пользовательского интерфейса характеризуется его внешним видом (синтаксисом) и удобством использования (семантикой).

• Существует два основных типа пользовательского интерфейса: а) текстовый б) графический.

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

Графический интерфейс пользователя

Графический пользовательский интерфейс - это наиболее распространенный тип пользовательского интерфейса, доступный сегодня. Он очень удобен для пользователя, потому что в нем используются изображения, графика и значки - поэтому он называется «графическим».

Он также известен как WIMP interface потому что он использует -

• Windows - Прямоугольная область на экране, в которой запускаются часто используемые приложения.

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

• Menus - Список параметров, из которых пользователь может выбрать то, что ему нужно.

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

Дизайн пользовательского интерфейса

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

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

  • В users кто будет взаимодействовать с системой через интерфейс

  • В tasks что конечные пользователи должны выполнять свою работу

  • В content который представлен как часть интерфейса

  • В work environment в котором эти задачи будут выполняться

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

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

  • The conceptual level - Он описывает основные сущности, учитывая взгляд пользователя на систему и возможные действия над ними.

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

  • The syntactic level - Он описывает последовательность входов и выходов, необходимых для вызова описанных функций.

  • The lexical level - Он определяет, как фактически формируются входы и выходы из примитивных аппаратных операций.

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

• Определяет объекты пользовательского интерфейса и действия (операции).

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

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

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

Процесс разработки пользовательского интерфейса

Это следует по спирали, как показано на следующей диаграмме -



Interface analysis

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

Interface design

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

Interface construction

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

Interface validation

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

User Interface Models

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

User profile model

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

• Учитывает синтаксические и семантические знания пользователя и классифицирует пользователей как новичков, знающих с перерывами и знающих частых пользователей.

Design model

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

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

Implementation model

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

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

User's mental model

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

• Часто называемое восприятием системы пользователем и правильность описания зависит от профиля пользователя и общего знакомства с программным обеспечением в области приложения.

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

Ориентировано на пользователя

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

Просто и интуитивно понятно

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

Предоставьте пользователям контроль

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

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

Прозрачность

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

Используйте прогрессивное раскрытие информации

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

Последовательность

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

Интеграция

Программная система должна легко интегрироваться с другими приложениями, такими как блокнот MS и MS-Office. Он может использовать команды буфера обмена напрямую для обмена данными.

Компонентная ориентация

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

Настраиваемый

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

Уменьшите нагрузку на память пользователей

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

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

Разделение

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

Итеративный и инкрементный подход

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

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

Определить цель архитектуры

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

Этот шаг включает в себя следующие действия -

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

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

Ключевые сценарии

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

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

Обзор приложения

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

Определить тип приложения

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

Определить ограничения развертывания

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

Определите важные стили архитектурного дизайна

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

Определите соответствующие технологии

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

Ключевые проблемы или ключевые горячие точки

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

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

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

Возможные решения

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

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

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

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

Обзор архитектуры

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

• Часто пересматривайте архитектуру на основных этапах проекта и в ответ на другие значительные архитектурные изменения.

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

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

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

Метод анализа архитектуры программного обеспечения (SAAM)

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

Метод анализа компромиссов в архитектуре (ATAM)

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

Обзор активного дизайна (ADR)

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

Активные обзоры промежуточных дизайнов (ARID)

Он сочетает в себе аспект ADR проверки незавершенной архитектуры с акцентом на наборе вопросов, а также подходы ATAM и SAAM к проверке на основе сценариев, ориентированные на атрибуты качества.

Метод анализа затрат и выгод (CBAM)

Он фокусируется на анализе затрат, выгод и последствий архитектурных решений для графика.

Анализ изменяемости уровня архитектуры (ALMA)

Он оценивает модифицируемость архитектуры бизнес-информационных систем (BIS).

Метод оценки семейной архитектуры (FAAM)

Он оценивает архитектуры семейства информационных систем на предмет взаимодействия и расширяемости.

Сообщение архитектурного дизайна

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

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

Модель 4 + 1

Этот подход использует пять представлений полной архитектуры. Среди них четыре вида (logical view, в process view, в physical view, и development view) описывают архитектуру с разных подходов. Пятый вид показывает сценарии и варианты использования программного обеспечения. Это позволяет заинтересованным сторонам видеть особенности архитектуры, которые их конкретно интересуют.

Язык описания архитектуры (ADL)

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

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

Гибкое моделирование

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

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

IEEE 1471

IEEE 1471 - это краткое название стандарта, официально известного как ANSI / IEEE 1471-2000, «Рекомендуемая практика для описания архитектуры программно-интенсивных систем». IEEE 1471 расширяет содержание описания архитектуры, в частности, придавая конкретное значение контексту, представлениям и точкам зрения.

Единый язык моделирования (UML)

Этот подход представляет собой три представления модели системы. Вfunctional requirements view (функциональные требования системы с точки зрения пользователя, включая варианты использования); the static structural view(объекты, атрибуты, отношения и операции, включая диаграммы классов); иdynamic behavior view (взаимодействие между объектами и изменение внутреннего состояния объектов, включая диаграммы последовательности, активности и состояний).