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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Выступать в качестве плана в процессе разработки.

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

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

Выступать в качестве плана в процессе разработки.

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

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

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

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

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

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

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

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

• Обработка как функциональных, так и качественных требований.

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

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

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

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

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

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

Обработка как функциональных, так и качественных требований.

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

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

Повысить внешнюю уверенность в организации или системе.

Ограничения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Специалист по информации, который делится знаниями и имеет огромный опыт.

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

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

Специалист по информации, который делится знаниями и имеет огромный опыт.

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

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

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

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

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

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

• Понятие о сроках, атрибутах оператора, планах внедрения и эксплуатации

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

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

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

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

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

Понятие о сроках, атрибутах оператора, планах внедрения и эксплуатации

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

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

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

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

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

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

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

Динамические атрибуты качества

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

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

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

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

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

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

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

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

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

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

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

Стимул — условие, которое необходимо учитывать при поступлении в систему.

Окружающая среда — стимул возникает в определенных условиях.

Артефакт — целая система или ее часть, такая как процессоры, каналы связи, постоянное хранилище, процессы и т. Д.

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

Мера реагирования — Следует измерить полученные ответы, чтобы можно было проверить требования.

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

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

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

Ключевые принципы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Информационная архитектура — Определяет логические и физические активы данных и ресурсы управления данными.

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

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

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

• Требования, предъявляемые к анализу задач.

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

Требования, предъявляемые к анализу задач.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уменьшить риск и модель для анализа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Минимизация большого дизайна авансом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Архитектурные модели

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

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

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

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

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

• ADL (язык описания архитектуры) — ADL определяет архитектуру программного обеспечения формально и семантически.

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

Модель представления архитектуры (модель представления 4 + 1) — модель представления архитектуры представляет функциональные и нефункциональные требования программного приложения.

ADL (язык описания архитектуры) — ADL определяет архитектуру программного обеспечения формально и семантически.

UML

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

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

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

Структурные диаграммы

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

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

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

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

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

Учебный класс

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

объект

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

Составная часть

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

Композитная структура

Описывает внутреннюю структуру компонента, включая все классы, интерфейсы компонента и т. Д.

пакет

Описывает структуру пакета и организацию. Охватывает классы в пакете и пакеты внутри другого пакета.

развертывание

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

Поведенческие Диаграммы

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

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

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

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

Случай использования

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

Деятельность

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

State Machine / Государственный график

Представляет управляемое событиями изменение состояния системы. Он в основном описывает изменение состояния класса, интерфейса и т. Д. Используется для визуализации реакции системы на внутренние / внешние факторы.

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

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

Обзор взаимодействия

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

связь

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

Время последовательности

Описывает изменения по сообщениям в состоянии, состоянии и событиях.

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

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

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

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

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

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

• Логический или концептуальный вид — описывает объектную модель проекта.

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

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

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

Логический или концептуальный вид — описывает объектную модель проекта.

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

Физическое представление — описывает отображение программного обеспечения на аппаратное обеспечение и отражает его распределенный аспект.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объектно-ориентированная парадигма

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

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

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

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

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

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

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

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

В 1990-х годах Коад включил идеи поведения в объектно-ориентированные методы.

Другими значительными нововведениями стали «Методы объектного моделирования» (OMT) Джеймса Рам Боуг и «Объектно-ориентированная программная инженерия» (OOSE) Ивара Якобсона .

Введение в OO Paradigm

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

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

объект

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

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

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

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

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

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

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

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

Учебный класс

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

Составляющие класса —

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

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

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

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

пример

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

• х – координата, для обозначения х – координаты центра
• у – координата, для обозначения у – координата центра
• а, чтобы обозначить радиус круга

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

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

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

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

Полиморфизм

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

пример

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

Отношения

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

Передача сообщений

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

Состав или Агрегация

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

ассоциация

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

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

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

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

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

пример

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

ОО Анализ

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

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

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

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

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

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

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

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

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

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

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

Функциональное моделирование

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

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

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

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

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

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

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

ОО Дизайн можно разделить на два этапа — Концептуальный дизайн и Детальный дизайн.

Концептуальный дизайн

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

Детальный дизайн

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

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

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

Принцип развязки

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

Обеспечение сплоченности

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

Открыто-закрытый принцип

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

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

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

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

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

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

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

Архитектура потока данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

Внешний контроль требуется для реализации.

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

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

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

Фильтр

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

Активный фильтр

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

Пассивный фильтр

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

труба

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

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

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

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

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

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

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

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

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

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

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

• Уставка — это желаемое значение для контролируемой переменной.

• Алгоритм управления — используется для принятия решения о том, как манипулировать переменными процесса.

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

Переменная ввода — измеряет вход в процесс. Например, температура возвратного воздуха в системе контроля температуры

Управляемая переменная — значение управляемой переменной регулируется или изменяется контроллером.

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

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

Уставка — это желаемое значение для контролируемой переменной.

Алгоритм управления — используется для принятия решения о том, как манипулировать переменными процесса.

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

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

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

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

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

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

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

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

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

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

Архитектура, ориентированная на данные

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

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

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

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

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

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

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

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

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

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

• Репозиторий Архитектурный Стиль
• Архитектурный стиль доски

Репозиторий Архитектурный Стиль

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уменьшает накладные расходы на переходные данные между программными компонентами.

Недостатки

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

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

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

• Эволюция данных сложно и дорого.

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

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

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

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

Эволюция данных сложно и дорого.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источники знаний (KS)

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

Структура данных Blackboard

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

контроль

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

Иерархическая Архитектура

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

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

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

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

• Main-подпрограмма
• Подчиненная
• Виртуальная машина

Main-подпрограмма

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

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

Существует два способа передачи данных в качестве параметров подпрограммам, а именно:

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

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

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

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

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

• Легко разложить систему на основе уточнения иерархии.

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

Легко разложить систему на основе уточнения иерархии.

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

Недостатки

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

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

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

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

Master-Slave

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

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

Реализация шаблона Master-Slave состоит из пяти этапов:

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

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

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

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

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

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

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

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

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

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

Приложения

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

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

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

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

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

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

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

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

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

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

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

Недостатки

• Коммуникации накладные.

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

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

Коммуникации накладные.

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

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

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

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

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

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

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

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

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

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

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

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

Приложения

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

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

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

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

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

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

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

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

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

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

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

• Моделирование для работающей модели бедствия.

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

Переносимость и независимость от платформы.

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

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

Моделирование для работающей модели бедствия.

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

Недостатки

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

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

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

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

Слоистый стиль

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

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

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

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

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

Приложения

Слоистый стиль подходит в следующих областях —

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

Интерактивно-ориентированная архитектура

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

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

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

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

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

Модуль управления — Модуль управления определяет последовательность действий управления и настройки системы.

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

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

Модель-Вид-Контроллер (MVC)

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

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

модель

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

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

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

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

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

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

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

Посмотреть

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

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

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

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

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

контроллер

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

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

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

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

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

MVC — я

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

• Представление контроллера — Представление контроллера действует как интерфейс ввода / вывода, и обработка завершена.

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

Представление контроллера — Представление контроллера действует как интерфейс ввода / вывода, и обработка завершена.

Модель — модель предоставляет все данные и услуги домена.

MVC-I Архитектура

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

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

MVC — II

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

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

MVC-II Архитектура

MVC Приложения

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

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

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

• Существует множество доступных инструментариев MVC для вендоров.

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

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

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

Существует множество доступных инструментариев MVC для вендоров.

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

Легко подключить новый или заменить вид интерфейса.

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

Недостатки

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

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

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

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

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

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

Презентация-Абстракция-Контроль (PAC)

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

Каждый агент имеет три компонента —

• Компонент представления — форматирует визуальное и аудио представление данных.

• Компонент абстракции — Извлекает и обрабатывает данные.

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

Компонент представления — форматирует визуальное и аудио представление данных.

Компонент абстракции — Извлекает и обрабатывает данные.

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложения

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

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

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

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

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

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

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

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

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

• Поддержка многозадачности и мульти-просмотра

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

Распределенная Архитектура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sr.No.	Прозрачность и описание
1	Доступ Скрывает способ доступа к ресурсам и различия в платформе данных.
2	Место нахождения Скрывает, где расположены ресурсы.
3	Технология Скрывает от пользователя различные технологии, такие как язык программирования и ОС.
4	Миграция / Переезд Скрыть ресурсы, которые могут быть перемещены в другое место, которые используются.
5	копирование Скрыть ресурсы, которые могут быть скопированы в нескольких местах.
6	совпадение Скрыть ресурсы, которые могут быть использованы другими пользователями.
7	недостаточность Скрывает сбой и восстановление ресурсов от пользователя.
8	Упорство Скрывает, находится ли ресурс (программное обеспечение) в памяти или на диске.

Доступ

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

Место нахождения

Скрывает, где расположены ресурсы.

Технология

Скрывает от пользователя различные технологии, такие как язык программирования и ОС.

Миграция / Переезд

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

копирование

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

совпадение

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

недостаточность

Скрывает сбой и восстановление ресурсов от пользователя.

Упорство

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

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

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

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

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

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

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

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

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

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

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

Отказоустойчивость — способность продолжать работу после возникновения неисправности.

Недостатки

• Сложность — они более сложны, чем централизованные системы.

• Безопасность — более подвержена внешним атакам.

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

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

Сложность — они более сложны, чем централизованные системы.

Безопасность — более подвержена внешним атакам.

Управляемость — для управления системой требуется больше усилий.

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

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

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

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

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

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

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

Клиент — это первый процесс, который отправляет запрос второму процессу, то есть серверу.

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

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

Клиент-серверная архитектура может быть классифицирована на две модели на основе функциональности клиента —

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

• Осложнения безопасности.

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

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

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

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

Осложнения безопасности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

• Более критичная надежность и доступность сервера.

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

Более критичная надежность и доступность сервера.

Брокер Архитектурный Стиль

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

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

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

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

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

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

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

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

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

Маклер

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

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

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

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

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

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

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

огрызок

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

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

остов

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

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

Мост

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

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

Брокерская реализация в CORBA

CORBA является международным стандартом для Object Request Broker — промежуточного программного обеспечения для управления связью между распределенными объектами, определенными OMG (группа управления объектами).

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

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

Сервис-ориентированная архитектура — это клиент-серверный дизайн, который поддерживает бизнес-ориентированный ИТ-подход, в котором приложение состоит из программных сервисов и потребителей программных сервисов (также известных как клиенты или заказчики сервисов).

Особенности SOA

Сервис-ориентированная архитектура обеспечивает следующие функции —

• Распределенное развертывание. Предоставляйте корпоративные данные и бизнес-логику в виде слабых, связанных, обнаруживаемых, структурированных, основанных на стандартах, грубых компонентов без сохранения состояния, называемых сервисами.

• Возможность компоновки. Соберите новые процессы из существующих сервисов, которые представлены с желаемой степенью детализации через четко определенные, опубликованные и стандартные интерфейсы жалоб.

• Функциональная совместимость — совместное использование возможностей и повторное использование общих служб в сети независимо от базовых протоколов или технологий реализации

• Возможность повторного использования — выберите поставщика услуг и получите доступ к существующим ресурсам, предоставляемым как услуги.

Распределенное развертывание. Предоставляйте корпоративные данные и бизнес-логику в виде слабых, связанных, обнаруживаемых, структурированных, основанных на стандартах, грубых компонентов без сохранения состояния, называемых сервисами.

Возможность компоновки. Соберите новые процессы из существующих сервисов, которые представлены с желаемой степенью детализации через четко определенные, опубликованные и стандартные интерфейсы жалоб.

Функциональная совместимость — совместное использование возможностей и повторное использование общих служб в сети независимо от базовых протоколов или технологий реализации

Возможность повторного использования — выберите поставщика услуг и получите доступ к существующим ресурсам, предоставляемым как услуги.

SOA Operation

На следующем рисунке показано, как работает SOA.

преимущества

• Слабая связь сервис-ориентации обеспечивает большую гибкость для предприятий, чтобы использовать все доступные сервисные ресурсы независимо от платформы и технологических ограничений.

• Каждый компонент службы независим от других служб благодаря функции обслуживания без сохранения состояния.

• Реализация службы не повлияет на применение службы, если открытый интерфейс не изменяется.

• Клиент или любая служба могут получить доступ к другим службам независимо от их платформы, технологии, поставщиков или языковых реализаций.

• Возможность повторного использования активов и сервисов, поскольку клиенты сервиса должны знать только его открытые интерфейсы, состав сервиса.

• Разработка бизнес-приложений на основе SOA намного эффективнее с точки зрения времени и затрат.

• Улучшает масштабируемость и обеспечивает стандартное соединение между системами.

• Эффективное и эффективное использование «Бизнес-услуг».

• Интеграция становится намного проще и улучшается внутренняя совместимость.

• Абстрактная сложность для разработчиков и активизация бизнес-процессов ближе к конечным пользователям.

Слабая связь сервис-ориентации обеспечивает большую гибкость для предприятий, чтобы использовать все доступные сервисные ресурсы независимо от платформы и технологических ограничений.

Каждый компонент службы независим от других служб благодаря функции обслуживания без сохранения состояния.

Реализация службы не повлияет на применение службы, если открытый интерфейс не изменяется.

Клиент или любая служба могут получить доступ к другим службам независимо от их платформы, технологии, поставщиков или языковых реализаций.

Возможность повторного использования активов и сервисов, поскольку клиенты сервиса должны знать только его открытые интерфейсы, состав сервиса.

Разработка бизнес-приложений на основе SOA намного эффективнее с точки зрения времени и затрат.

Улучшает масштабируемость и обеспечивает стандартное соединение между системами.

Эффективное и эффективное использование «Бизнес-услуг».

Интеграция становится намного проще и улучшается внутренняя совместимость.

Абстрактная сложность для разработчиков и активизация бизнес-процессов ближе к конечным пользователям.

Компонентно-ориентированная архитектура

Компонентно-ориентированная архитектура фокусируется на разложении проекта на отдельные функциональные или логические компоненты, которые представляют собой четко определенные интерфейсы связи, содержащие методы, события и свойства. Он обеспечивает более высокий уровень абстракции и делит проблему на подзадачи, каждая из которых связана с компонентными разделами.

Основная задача архитектуры на основе компонентов заключается в обеспечении возможности повторного использования компонентов . Компонент инкапсулирует функциональность и поведение программного элемента в повторно используемую и самораскрывающуюся двоичную единицу. Существует множество стандартных компонентов, таких как COM / DCOM, JavaBean, EJB, CORBA, .NET, веб-сервисы и сеточные сервисы. Эти технологии широко используются в проектировании приложений GUI для локальных компьютеров, таких как графические компоненты JavaBean, компоненты MS ActiveX и компоненты COM, которые можно повторно использовать простым перетаскиванием.

Компонентно-ориентированное проектирование программного обеспечения имеет много преимуществ по сравнению с традиционными объектно-ориентированными подходами, такими как —

• Сокращение времени на рынке и затрат на разработку за счет повторного использования существующих компонентов.

• Повышенная надежность благодаря повторному использованию существующих компонентов.

Сокращение времени на рынке и затрат на разработку за счет повторного использования существующих компонентов.

Повышенная надежность благодаря повторному использованию существующих компонентов.

Что такое компонент?

Компонент представляет собой модульный, переносимый, заменяемый и многократно используемый набор четко определенных функций, которые инкапсулируют его реализацию и экспортируют его в качестве интерфейса более высокого уровня.

Компонент — это программный объект, предназначенный для взаимодействия с другими компонентами, инкапсулирующий определенные функциональные возможности или набор функциональных возможностей. Он имеет явно определенный интерфейс и соответствует рекомендованному поведению, общему для всех компонентов в архитектуре.

Программный компонент может быть определен как единица композиции с указанным в контракте интерфейсом и только с явными контекстными зависимостями. Таким образом, программный компонент может быть развернут независимо и может быть составлен третьими лицами.

Представления компонента

Компонент может иметь три различных представления — объектно-ориентированное представление, обычное представление и представление, связанное с процессом.

Объектно-ориентированный вид

Компонент рассматривается как набор из одного или нескольких взаимодействующих классов. Каждый класс проблемной области (анализ) и класс инфраструктуры (дизайн) объяснены, чтобы идентифицировать все атрибуты и операции, которые применяются к его реализации. Это также включает определение интерфейсов, которые позволяют классам общаться и взаимодействовать.

Обычный вид

Он рассматривается как функциональный элемент или модуль программы, который объединяет логику обработки, внутренние структуры данных, которые необходимы для реализации логики обработки, и интерфейс, который позволяет вызывать компонент и передавать ему данные.

Процессное представление

В этом представлении вместо создания каждого компонента с нуля система строится из существующих компонентов, которые хранятся в библиотеке. По мере формулирования архитектуры программного обеспечения компоненты выбираются из библиотеки и используются для заполнения архитектуры.

• Компонент пользовательского интерфейса (UI) включает в себя сетки, кнопки, называемые элементами управления, а служебные компоненты представляют определенный набор функций, используемых в других компонентах.

• Другие распространенные типы компонентов — это ресурсоемкие, не часто используемые компоненты, которые должны быть активированы с использованием подхода JIT.

• Многие компоненты являются невидимыми, которые распространяются в корпоративных бизнес-приложениях и интернет-веб-приложениях, таких как Enterprise JavaBean (EJB), компоненты .NET и компоненты CORBA.

Компонент пользовательского интерфейса (UI) включает в себя сетки, кнопки, называемые элементами управления, а служебные компоненты представляют определенный набор функций, используемых в других компонентах.

Другие распространенные типы компонентов — это ресурсоемкие, не часто используемые компоненты, которые должны быть активированы с использованием подхода JIT.

Многие компоненты являются невидимыми, которые распространяются в корпоративных бизнес-приложениях и интернет-веб-приложениях, таких как Enterprise JavaBean (EJB), компоненты .NET и компоненты CORBA.

Характеристики компонентов

• Возможность повторного использования — компоненты, как правило, предназначены для повторного использования в различных ситуациях в различных приложениях. Однако некоторые компоненты могут быть предназначены для конкретной задачи.

• Заменяемые — компоненты могут быть свободно заменены другими аналогичными компонентами.

• Не зависит от контекста — Компоненты предназначены для работы в разных средах и контекстах.

• Расширяемый — компонент может быть расширен из существующих компонентов для обеспечения нового поведения.

• Инкапсулированный — компонент AA отображает интерфейсы, которые позволяют вызывающей стороне использовать его функциональные возможности, и не раскрывают детали внутренних процессов или каких-либо внутренних переменных или состояния.

• Независимо — компоненты разработаны так, чтобы иметь минимальные зависимости от других компонентов.

Возможность повторного использования — компоненты, как правило, предназначены для повторного использования в различных ситуациях в различных приложениях. Однако некоторые компоненты могут быть предназначены для конкретной задачи.

Заменяемые — компоненты могут быть свободно заменены другими аналогичными компонентами.

Не зависит от контекста — Компоненты предназначены для работы в разных средах и контекстах.

Расширяемый — компонент может быть расширен из существующих компонентов для обеспечения нового поведения.

Инкапсулированный — компонент AA отображает интерфейсы, которые позволяют вызывающей стороне использовать его функциональные возможности, и не раскрывают детали внутренних процессов или каких-либо внутренних переменных или состояния.

Независимо — компоненты разработаны так, чтобы иметь минимальные зависимости от других компонентов.

Принципы компонентно-ориентированного проектирования

Проект на уровне компонентов может быть представлен с использованием некоторого промежуточного представления (например, графического, табличного или текстового), которое может быть переведено в исходный код. Конструкция структур данных, интерфейсов и алгоритмов должна соответствовать устоявшимся рекомендациям, чтобы избежать ошибок.

• Система программного обеспечения разделена на многократно используемые, связные и инкапсулированные компоненты.

• Каждый компонент имеет свой собственный интерфейс, который определяет необходимые порты и предоставляемые порты; каждый компонент скрывает свою детальную реализацию.

• Компонент должен быть расширен без необходимости внесения внутреннего кода или конструктивных изменений в существующие части компонента.

• Компонент зависимости от абстракций не зависит от других конкретных компонентов, которые увеличивают трудоемкость.

• Соединители соединяют компоненты, определяя и управляя взаимодействием между компонентами. Тип взаимодействия определяется интерфейсами компонентов.

• Взаимодействие компонентов может принимать форму вызовов методов, асинхронных вызовов, широковещания, взаимодействий, управляемых сообщениями, обмена потоком данных и других взаимодействий, специфичных для протокола.

• Для серверного класса должны быть созданы специализированные интерфейсы для обслуживания основных категорий клиентов. В интерфейсе должны быть указаны только те операции, которые относятся к определенной категории клиентов.

• Компонент может распространяться на другие компоненты и по-прежнему предлагать свои собственные точки расширения. Это концепция архитектуры на основе плагинов. Это позволяет плагину предлагать другой плагин API.

Система программного обеспечения разделена на многократно используемые, связные и инкапсулированные компоненты.

Каждый компонент имеет свой собственный интерфейс, который определяет необходимые порты и предоставляемые порты; каждый компонент скрывает свою детальную реализацию.

Компонент должен быть расширен без необходимости внесения внутреннего кода или конструктивных изменений в существующие части компонента.

Компонент зависимости от абстракций не зависит от других конкретных компонентов, которые увеличивают трудоемкость.

Соединители соединяют компоненты, определяя и управляя взаимодействием между компонентами. Тип взаимодействия определяется интерфейсами компонентов.

Взаимодействие компонентов может принимать форму вызовов методов, асинхронных вызовов, широковещания, взаимодействий, управляемых сообщениями, обмена потоком данных и других взаимодействий, специфичных для протокола.

Для серверного класса должны быть созданы специализированные интерфейсы для обслуживания основных категорий клиентов. В интерфейсе должны быть указаны только те операции, которые относятся к определенной категории клиентов.

Компонент может распространяться на другие компоненты и по-прежнему предлагать свои собственные точки расширения. Это концепция архитектуры на основе плагинов. Это позволяет плагину предлагать другой плагин API.

Руководство по проектированию на уровне компонентов

Создает соглашения об именах для компонентов, которые определены как часть архитектурной модели, а затем уточняет или уточняет как часть модели уровня компонента.

• Получает имена архитектурных компонентов из проблемной области и гарантирует, что они имеют значение для всех заинтересованных сторон, которые рассматривают архитектурную модель.

• Извлекает сущности бизнес-процессов, которые могут существовать независимо, без какой-либо связанной зависимости от других сущностей.

• Признает и обнаруживает эти независимые объекты в качестве новых компонентов.

• Используются имена компонентов инфраструктуры, которые отражают их значение для конкретной реализации.

• Моделирует любые зависимости слева направо и наследование сверху (базовый класс) и снизу (производные классы).

• Моделируйте любые зависимости компонентов как интерфейсы, а не представляйте их как прямую зависимость между компонентами.

Получает имена архитектурных компонентов из проблемной области и гарантирует, что они имеют значение для всех заинтересованных сторон, которые рассматривают архитектурную модель.

Извлекает сущности бизнес-процессов, которые могут существовать независимо, без какой-либо связанной зависимости от других сущностей.

Признает и обнаруживает эти независимые объекты в качестве новых компонентов.

Используются имена компонентов инфраструктуры, которые отражают их значение для конкретной реализации.

Моделирует любые зависимости слева направо и наследование сверху (базовый класс) и снизу (производные классы).

Моделируйте любые зависимости компонентов как интерфейсы, а не представляйте их как прямую зависимость между компонентами.

Проведение проектирования на уровне компонентов

Распознает все классы проектирования, которые соответствуют проблемной области, как определено в модели анализа и архитектурной модели.

• Распознает все классы проектирования, которые соответствуют области инфраструктуры.

• Описывает все классы дизайна, которые не получены как повторно используемые компоненты, и указывает детали сообщения.

• Идентифицирует соответствующие интерфейсы для каждого компонента и разрабатывает атрибуты и определяет типы данных и структуры данных, необходимые для их реализации.

• Подробно описывает процесс обработки внутри каждой операции с помощью псевдокода или диаграмм действий UML.

• Описывает постоянные источники данных (базы данных и файлы) и определяет классы, необходимые для управления ими.

• Разрабатывать и разрабатывать поведенческие представления для класса или компонента. Это можно сделать путем разработки диаграмм состояний UML, созданных для модели анализа, и изучения всех вариантов использования, которые относятся к классу проектирования.

• Разрабатывает схемы развертывания для предоставления дополнительных деталей реализации.

• Демонстрирует расположение пакетов ключей или классов компонентов в системе, используя экземпляры классов и обозначая конкретное оборудование и среду операционной системы.

• Окончательное решение может быть принято с использованием установленных принципов проектирования и руководящих принципов. Опытные дизайнеры рассматривают все (или большинство) альтернативных дизайнерских решений, прежде чем остановиться на окончательной модели дизайна.

Распознает все классы проектирования, которые соответствуют области инфраструктуры.

Описывает все классы дизайна, которые не получены как повторно используемые компоненты, и указывает детали сообщения.

Идентифицирует соответствующие интерфейсы для каждого компонента и разрабатывает атрибуты и определяет типы данных и структуры данных, необходимые для их реализации.

Подробно описывает процесс обработки внутри каждой операции с помощью псевдокода или диаграмм действий UML.

Описывает постоянные источники данных (базы данных и файлы) и определяет классы, необходимые для управления ими.

Разрабатывать и разрабатывать поведенческие представления для класса или компонента. Это можно сделать путем разработки диаграмм состояний UML, созданных для модели анализа, и изучения всех вариантов использования, которые относятся к классу проектирования.

Разрабатывает схемы развертывания для предоставления дополнительных деталей реализации.

Демонстрирует расположение пакетов ключей или классов компонентов в системе, используя экземпляры классов и обозначая конкретное оборудование и среду операционной системы.

Окончательное решение может быть принято с использованием установленных принципов проектирования и руководящих принципов. Опытные дизайнеры рассматривают все (или большинство) альтернативных дизайнерских решений, прежде чем остановиться на окончательной модели дизайна.

преимущества

• Простота развертывания. По мере появления новых совместимых версий становится проще заменить существующие версии, не влияя на другие компоненты или систему в целом.

• Снижение затрат — использование сторонних компонентов позволяет распределить затраты на разработку и обслуживание.

• Простота разработки — Компоненты реализуют хорошо известные интерфейсы, чтобы обеспечить определенную функциональность, позволяя разработку, не затрагивая другие части системы.

• Многоразовое использование — использование повторно используемых компонентов означает, что их можно использовать для распределения затрат на разработку и обслуживание по нескольким приложениям или системам.

• Модификация технической сложности — компонент изменяет сложность посредством использования контейнера компонента и его сервисов.

• Надежность. Повышается общая надежность системы, поскольку надежность каждого отдельного компонента повышает надежность всей системы за счет повторного использования.

• Обслуживание и развитие системы — Легко изменить и обновить реализацию, не затрагивая остальную часть системы.

• Независимость — независимость и гибкость подключения компонентов. Самостоятельная разработка компонентов по разным группам параллельно. Производительность для разработки программного обеспечения и будущей разработки программного обеспечения.

Простота развертывания. По мере появления новых совместимых версий становится проще заменить существующие версии, не влияя на другие компоненты или систему в целом.

Снижение затрат — использование сторонних компонентов позволяет распределить затраты на разработку и обслуживание.

Простота разработки — Компоненты реализуют хорошо известные интерфейсы, чтобы обеспечить определенную функциональность, позволяя разработку, не затрагивая другие части системы.

Многоразовое использование — использование повторно используемых компонентов означает, что их можно использовать для распределения затрат на разработку и обслуживание по нескольким приложениям или системам.

Модификация технической сложности — компонент изменяет сложность посредством использования контейнера компонента и его сервисов.

Надежность. Повышается общая надежность системы, поскольку надежность каждого отдельного компонента повышает надежность всей системы за счет повторного использования.

Обслуживание и развитие системы — Легко изменить и обновить реализацию, не затрагивая остальную часть системы.

Независимость — независимость и гибкость подключения компонентов. Самостоятельная разработка компонентов по разным группам параллельно. Производительность для разработки программного обеспечения и будущей разработки программного обеспечения.

Пользовательский интерфейс

Пользовательский интерфейс — это первое впечатление от программной системы с точки зрения пользователя. Поэтому любая программная система должна удовлетворять требованиям пользователя. Пользовательский интерфейс в основном выполняет две функции —

• Принятие ввода пользователя

• Отображение вывода

Принятие ввода пользователя

Отображение вывода

Пользовательский интерфейс играет решающую роль в любой программной системе. Это, возможно, единственный видимый аспект системы программного обеспечения, как —

• Первоначально пользователи увидят архитектуру внешнего пользовательского интерфейса системы программного обеспечения без учета ее внутренней архитектуры.

• Хороший пользовательский интерфейс должен привлекать пользователя к использованию программной системы без ошибок. Это должно помочь пользователю легко понять систему программного обеспечения, не вводя в заблуждение информацию. Плохой пользовательский интерфейс может вызвать сбой рынка на фоне конкуренции программных систем.

• Пользовательский интерфейс имеет свой синтаксис и семантику. Синтаксис включает в себя типы компонентов, такие как текстовый, значок, кнопка и т. Д., А удобство использования суммирует семантику пользовательского интерфейса. Качество пользовательского интерфейса характеризуется его внешним видом (синтаксис) и удобством использования (семантика).

• Существует два основных типа пользовательского интерфейса: а) текстовый; б) графический.

• Программное обеспечение в разных доменах может требовать различного стиля своего пользовательского интерфейса, например, для калькулятора требуется только небольшая область для отображения числовых чисел, но большая область для команд, веб-странице нужны формы, ссылки, вкладки и т. Д.

Первоначально пользователи увидят архитектуру внешнего пользовательского интерфейса системы программного обеспечения без учета ее внутренней архитектуры.

Хороший пользовательский интерфейс должен привлекать пользователя к использованию программной системы без ошибок. Это должно помочь пользователю легко понять систему программного обеспечения, не вводя в заблуждение информацию. Плохой пользовательский интерфейс может вызвать сбой рынка на фоне конкуренции программных систем.

Пользовательский интерфейс имеет свой синтаксис и семантику. Синтаксис включает в себя типы компонентов, такие как текстовый, значок, кнопка и т. Д., А удобство использования суммирует семантику пользовательского интерфейса. Качество пользовательского интерфейса характеризуется его внешним видом (синтаксис) и удобством использования (семантика).

Существует два основных типа пользовательского интерфейса: а) текстовый; б) графический.

Программное обеспечение в разных доменах может требовать различного стиля своего пользовательского интерфейса, например, для калькулятора требуется только небольшая область для отображения числовых чисел, но большая область для команд, веб-странице нужны формы, ссылки, вкладки и т. Д.

Графический пользовательский интерфейс

Графический интерфейс пользователя является наиболее распространенным типом интерфейса пользователя, доступным сегодня. Это очень удобно для пользователя, потому что он использует рисунки, графику и значки — поэтому его называют «графическим».

Он также известен как интерфейс WIMP, потому что он использует —

• W indows — прямоугольная область на экране, где запускаются часто используемые приложения.

• Я минусы — изображение или символ, который используется для представления программного приложения или аппаратного устройства.

• Меню — список опций, из которых пользователь может выбрать то, что ему нужно.

• Указатели — символ, такой как стрелка, который перемещается по экрану, когда пользователь перемещает мышь. Это помогает пользователю выбирать объекты.

W indows — прямоугольная область на экране, где запускаются часто используемые приложения.

Я минусы — изображение или символ, который используется для представления программного приложения или аппаратного устройства.

Меню — список опций, из которых пользователь может выбрать то, что ему нужно.

Указатели — символ, такой как стрелка, который перемещается по экрану, когда пользователь перемещает мышь. Это помогает пользователю выбирать объекты.

Дизайн пользовательского интерфейса

Он начинается с анализа задач, который понимает основные задачи пользователя и проблемную область. Он должен быть разработан с точки зрения терминологии пользователя и начала работы пользователя, а не программиста.

• Чтобы выполнить анализ пользовательского интерфейса, практик должен изучить и понять четыре элемента —

  • Пользователи, которые будут взаимодействовать с системой через интерфейс

  • Задачи, которые должны выполнять конечные пользователи, чтобы выполнять свою работу

  • Контент , представленный как часть интерфейса

  • Рабочая среда, в которой будут выполняться эти задачи

• Правильный или хороший дизайн пользовательского интерфейса работает на основе возможностей и ограничений пользователя, а не машин. При разработке пользовательского интерфейса также важно знать характер работы и среды пользователя.

• Задача, которая должна быть выполнена, затем может быть разделена, которая назначается пользователю или машине, основываясь на знании возможностей и ограничений каждого из них. Дизайн пользовательского интерфейса часто делится на четыре различных уровня —

  • Концептуальный уровень — описывает основные сущности, учитывая взгляд пользователя на систему и возможные действия над ними.

  • Семантический уровень — описывает функции, выполняемые системой, то есть описание функциональных требований системы, но не описывает, как пользователь будет вызывать функции.

  • Синтаксический уровень — описывает последовательность входов и выходов, необходимых для вызова описанных функций.

  • Лексический уровень — он определяет, как входы и выходы фактически формируются из примитивных аппаратных операций.

• Разработка пользовательского интерфейса — это итеративный процесс, где вся итерация объясняет и уточняет информацию, разработанную на предыдущих этапах. Общие шаги для дизайна пользовательского интерфейса

• Определяет объекты пользовательского интерфейса и действия (операции).

• Определяет события (действия пользователя), которые приведут к изменению состояния пользовательского интерфейса.

• Указывает, как пользователь интерпретирует состояние системы из информации, предоставляемой через интерфейс.

• Опишите каждое состояние интерфейса, как оно будет выглядеть для конечного пользователя.

Чтобы выполнить анализ пользовательского интерфейса, практик должен изучить и понять четыре элемента —

Пользователи, которые будут взаимодействовать с системой через интерфейс

Задачи, которые должны выполнять конечные пользователи, чтобы выполнять свою работу

Контент , представленный как часть интерфейса

Рабочая среда, в которой будут выполняться эти задачи

Правильный или хороший дизайн пользовательского интерфейса работает на основе возможностей и ограничений пользователя, а не машин. При разработке пользовательского интерфейса также важно знать характер работы и среды пользователя.

Задача, которая должна быть выполнена, затем может быть разделена, которая назначается пользователю или машине, основываясь на знании возможностей и ограничений каждого из них. Дизайн пользовательского интерфейса часто делится на четыре различных уровня —

Концептуальный уровень — описывает основные сущности, учитывая взгляд пользователя на систему и возможные действия над ними.

Семантический уровень — описывает функции, выполняемые системой, то есть описание функциональных требований системы, но не описывает, как пользователь будет вызывать функции.

Синтаксический уровень — описывает последовательность входов и выходов, необходимых для вызова описанных функций.

Лексический уровень — он определяет, как входы и выходы фактически формируются из примитивных аппаратных операций.

Разработка пользовательского интерфейса — это итеративный процесс, где вся итерация объясняет и уточняет информацию, разработанную на предыдущих этапах. Общие шаги для дизайна пользовательского интерфейса

Определяет объекты пользовательского интерфейса и действия (операции).

Определяет события (действия пользователя), которые приведут к изменению состояния пользовательского интерфейса.

Указывает, как пользователь интерпретирует состояние системы из информации, предоставляемой через интерфейс.

Опишите каждое состояние интерфейса, как оно будет выглядеть для конечного пользователя.

Процесс разработки пользовательского интерфейса

Это следует за спиральным процессом, как показано на следующей диаграмме —

Анализ интерфейса

Он концентрируется или фокусируется на пользователях, задачах, контенте и рабочей среде, которые будут взаимодействовать с системой. Определяет человеческие и компьютерные задачи, которые требуются для достижения функции системы.

Дизайн интерфейса

Он определяет набор интерфейсных объектов, действий и их экранных представлений, которые позволяют пользователю выполнять все определенные задачи таким образом, который соответствует всем целям удобства использования, определенным для системы.

Построение интерфейса

Он начинается с прототипа, который позволяет оценивать сценарии использования, и продолжается инструментами разработки для завершения построения.

Проверка интерфейса

Основное внимание уделяется способности интерфейса правильно выполнять каждую пользовательскую задачу, учитывать все варианты задач, выполнять все общие пользовательские требования и степень, в которой интерфейс прост в использовании и легок в изучении.

Модели пользовательского интерфейса

Когда пользовательский интерфейс проанализирован и спроектирован, используются следующие четыре модели:

Модель профиля пользователя

• Создан пользователем или инженером-программистом, который устанавливает профиль конечных пользователей системы на основе возраста, пола, физических способностей, образования, мотивации, целей и личности.

• Рассматривает синтаксические и семантические знания пользователя и классифицирует пользователей как новичков, знающих прерывистых и знающих частых пользователей.

Создан пользователем или инженером-программистом, который устанавливает профиль конечных пользователей системы на основе возраста, пола, физических способностей, образования, мотивации, целей и личности.

Рассматривает синтаксические и семантические знания пользователя и классифицирует пользователей как новичков, знающих прерывистых и знающих частых пользователей.

Модель дизайна

• Создано инженером-программистом, которое включает в себя данные, архитектуру, интерфейс и процедурные представления программного обеспечения.

• Происходит из модели анализа требований и контролируется информацией в спецификации требований, которая помогает определить пользователя системы.

Создано инженером-программистом, которое включает в себя данные, архитектуру, интерфейс и процедурные представления программного обеспечения.

Происходит из модели анализа требований и контролируется информацией в спецификации требований, которая помогает определить пользователя системы.

Модель реализации

• Создано разработчиками программного обеспечения, которые работают над внешним видом интерфейса в сочетании со всей вспомогательной информацией (книгами, видео, файлами справки), которая описывает системный синтаксис и семантику.

• Служит переводом модели проектирования и пытается согласиться с ментальной моделью пользователя, чтобы пользователи чувствовали себя комфортно с программным обеспечением и эффективно использовали его.

Создано разработчиками программного обеспечения, которые работают над внешним видом интерфейса в сочетании со всей вспомогательной информацией (книгами, видео, файлами справки), которая описывает системный синтаксис и семантику.

Служит переводом модели проектирования и пытается согласиться с ментальной моделью пользователя, чтобы пользователи чувствовали себя комфортно с программным обеспечением и эффективно использовали его.

Ментальная модель пользователя

• Создается пользователем при взаимодействии с приложением. Он содержит образ системы, которую пользователи несут в своих головах.

• Часто называемое пользователем восприятие системы и правильность описания зависят от профиля пользователя и общего знакомства с программным обеспечением в предметной области.

Создается пользователем при взаимодействии с приложением. Он содержит образ системы, которую пользователи несут в своих головах.

Часто называемое пользователем восприятие системы и правильность описания зависят от профиля пользователя и общего знакомства с программным обеспечением в предметной области.

Особенности дизайна пользовательского интерфейса

Ориентированный на пользователя

Пользовательский интерфейс должен быть продуктом, ориентированным на пользователя, который вовлекает пользователей на протяжении всего жизненного цикла продукта. Прототип пользовательского интерфейса должен быть доступен пользователям и отзывы пользователей должны быть включены в конечный продукт.

Простой и интуитивно понятный

Пользовательский интерфейс обеспечивает простоту и интуитивность, что позволяет быстро и эффективно использовать его без инструкций. GUI лучше текстового, поскольку GUI состоит из меню, окон и кнопок и управляется простым использованием мыши.

Контролировать пользователей

Не заставляйте пользователей выполнять предопределенные последовательности. Дайте им варианты — отменить или сохранить и вернуться туда, где они остановились. Используйте термины в интерфейсе, понятные пользователям, а не термины системы или разработчика.

Предоставьте пользователям некоторое указание на то, что действие было выполнено, либо показав им результаты действия, либо подтвердив, что это действие было успешно выполнено.

прозрачность

Пользовательский интерфейс должен быть прозрачным, чтобы пользователи чувствовали, что они достигают через компьютер и напрямую манипулируют объектами, с которыми работают. Интерфейс можно сделать прозрачным, предоставляя пользователям рабочие объекты, а не системные объекты. Например, пользователи должны понимать, что их системный пароль должен содержать не менее 6 символов, а не количество байтов, в котором должен быть пароль.

Используйте прогрессивное раскрытие

Всегда обеспечивайте легкий доступ к общим функциям и часто используемым действиям. Скрыть менее распространенные функции и действия и позволить пользователям перемещаться по ним. Не пытайтесь поместить каждую часть информации в одно главное окно. Используйте вторичное окно для информации, которая не является ключевой информацией.

консистенция

Пользовательский интерфейс поддерживает согласованность внутри и внутри продукта, сохраняя одинаковые результаты взаимодействия, команды и меню пользовательского интерфейса должны иметь одинаковый формат, пунктуация команд должна быть одинаковой, а параметры должны передаваться всем командам одинаковым образом. Пользовательский интерфейс не должен иметь поведения, которое может удивить пользователей, и должен включать механизмы, позволяющие пользователям восстанавливаться после своих ошибок.

интеграция

Программная система должна плавно интегрироваться с другими приложениями, такими как MS notepad и MS-Office. Он может напрямую использовать команды буфера обмена для обмена данными.

Компонентно-ориентированный

Дизайн пользовательского интерфейса должен быть модульным и включать в себя компонентно-ориентированную архитектуру, чтобы дизайн пользовательского интерфейса имел те же требования, что и дизайн основной части программной системы. Модули могут быть легко изменены и заменены, не затрагивая другие части системы.

Настраиваемый

Архитектура всей системы программного обеспечения включает в себя подключаемые модули, которые позволяют множеству разных людей независимо расширять программное обеспечение. Это позволяет отдельным пользователям выбирать из различных доступных форм в соответствии с личными предпочтениями и потребностями.

Уменьшить нагрузку на память пользователей

Не заставляйте пользователей вспоминать и повторять, что компьютер должен делать для них. Например, при заполнении онлайн-форм имена пользователей, адреса и номера телефонов должны запоминаться системой после их ввода пользователем или после открытия записи о клиенте.

Пользовательские интерфейсы поддерживают долговременное извлечение памяти, предоставляя пользователям элементы для распознавания, а не для вызова информации.

разделение

Пользовательский интерфейс должен быть отделен от логики системы посредством ее реализации для повышения возможности повторного использования и обслуживания.

Архитектурные Методы

Итеративный и инкрементальный подход

Это итеративный и поэтапный подход, состоящий из пяти основных этапов, который помогает генерировать подходящие решения. Это возможное решение может быть дополнительно улучшено путем повторения этих шагов и, наконец, создания архитектуры, которая лучше всего подходит для нашего приложения. В конце процесса мы можем проверить и сообщить нашу архитектуру всем заинтересованным сторонам.

Это только один из возможных подходов. Есть много других более формальных подходов, которые определяют, анализируют и передают вашу архитектуру.

Определить архитектурную цель

Определите цель архитектуры, которая формирует архитектуру и процесс проектирования. Безупречные и определенные цели подчеркивают архитектуру, решают правильные проблемы в дизайне и помогают определить, когда текущая фаза завершена, и готова перейти к следующей фазе.

Этот шаг включает в себя следующие действия —

• Определите ваши архитектурные цели с самого начала.
• Определите потребителя нашей архитектуры.
• Определите ограничения.

Примеры действий архитектуры включают в себя создание прототипа для получения обратной связи по пользовательскому интерфейсу обработки заказов для веб-приложения, создание приложения для отслеживания заказов клиентов, а также разработку архитектуры аутентификации и авторизации для приложения для выполнения проверки безопасности.

Ключевые сценарии

Этот шаг делает упор на дизайн, который имеет наибольшее значение. Сценарий — это обширное и охватывающее описание взаимодействия пользователя с системой.

Ключевые сценарии — это те сценарии, которые считаются наиболее важными для успеха вашего приложения. Это помогает принимать решения об архитектуре. Цель состоит в том, чтобы достичь баланса между потребностями пользователя, бизнеса и системы. Например, аутентификация пользователя является ключевым сценарием, потому что они представляют собой пересечение атрибута качества (безопасности) с важной функциональностью (как пользователь входит в вашу систему).

Обзор приложения

Создайте обзор приложения, что делает архитектуру более удобной, связывая ее с реальными ограничениями и решениями. Он состоит из следующих действий —

Определить тип приложения

Определите тип приложения, будь то мобильное приложение, многофункциональный клиент, многофункциональное интернет-приложение, служба, веб-приложение или некоторая комбинация этих типов.

Определить ограничения развертывания

Выберите подходящую топологию развертывания и разрешите конфликты между приложением и целевой инфраструктурой.

Определите важные стили дизайна архитектуры

Определите важные стили архитектуры, такие как клиент / сервер, многоуровневая структура, шина сообщений, проектирование на основе домена и т. Д., Чтобы улучшить разбиение и способствовать повторному использованию проекта, предоставляя решения для часто повторяющихся проблем. Приложения часто используют комбинацию стилей.

Определите соответствующие технологии

Определите соответствующие технологии, учитывая тип разрабатываемого нами приложения, наши предпочтительные варианты топологии развертывания приложений и архитектурные стили. Выбор технологий также будет зависеть от политики организации, ограничений инфраструктуры, навыков работы с ресурсами и так далее.

Ключевые проблемы или ключевые точки

При разработке приложения горячие точки — это зоны, где чаще всего допускаются ошибки. Определите ключевые проблемы на основе качественных признаков и сквозных проблем. Потенциальные проблемы включают появление новых технологий и критических требований бизнеса.

Атрибуты качества — это общие характеристики вашей архитектуры, которые влияют на поведение во время выполнения, проектирование системы и взаимодействие с пользователем. Пересекающиеся проблемы — это особенности нашего дизайна, которые могут применяться ко всем слоям, компонентам и уровням.

Это также области, в которых наиболее часто допускаются ошибки проектирования. Примерами сквозных проблем являются аутентификация и авторизация, связь, управление конфигурацией, управление и проверка исключений и т. Д.

Решения для кандидатов

После определения ключевых горячих точек создайте исходную базовую архитектуру или сначала высокоуровневый дизайн, а затем начните заполнять детали, чтобы сгенерировать подходящую архитектуру.

Кандидатская архитектура включает в себя тип приложения, архитектуру развертывания, архитектурный стиль, выбор технологий, атрибуты качества и общие проблемы. Если архитектура-кандидат является улучшением, она может стать основой, на которой можно создавать и тестировать новые архитектуры-кандидаты.

Прежде чем итеративно следовать циклу и улучшать проект, проверяйте возможный дизайн решения на соответствие ключевым сценариям и требованиям, которые уже определены.

Мы можем использовать архитектурные пики, чтобы обнаружить определенные области дизайна или подтвердить новые концепции. Архитектурные пики являются прототипом проекта, который определяет выполнимость конкретного пути проектирования, снижает риск и быстро определяет жизнеспособность различных подходов. Протестируйте архитектурные всплески по ключевым сценариям и горячим точкам.

Обзор архитектуры

Обзор архитектуры является наиболее важной задачей, чтобы снизить стоимость ошибок и как можно раньше найти и исправить архитектурные проблемы. Это хорошо зарекомендовавший себя экономически эффективный способ снижения стоимости проекта и шансов на провал проекта.

• Часто пересматривайте архитектуру на основных этапах проекта и в ответ на другие значительные архитектурные изменения.

• Основная цель обзора архитектуры состоит в том, чтобы определить выполнимость базовых и возможных архитектур, которые правильно проверяют архитектуру.

• Связывает функциональные требования и атрибуты качества с предлагаемым техническим решением. Это также помогает выявить проблемы и выявить области для улучшения

Часто пересматривайте архитектуру на основных этапах проекта и в ответ на другие значительные архитектурные изменения.

Основная цель обзора архитектуры состоит в том, чтобы определить выполнимость базовых и возможных архитектур, которые правильно проверяют архитектуру.

Связывает функциональные требования и атрибуты качества с предлагаемым техническим решением. Это также помогает выявить проблемы и выявить области для улучшения

Оценки на основе сценариев являются доминирующим методом для анализа проекта архитектуры, который фокусируется на сценариях, наиболее важных с точки зрения бизнеса и оказывающих наибольшее влияние на архитектуру. Далее следуют распространенные методологии анализа —

Метод анализа архитектуры программного обеспечения (SAAM)

Первоначально он был разработан для оценки модифицируемости, но позже был расширен для анализа архитектуры в отношении атрибутов качества.

Метод анализа компромиссов в архитектуре (ATAM)

Это отточенная и улучшенная версия SAAM, в которой рассматриваются архитектурные решения с точки зрения требований к качественным атрибутам и того, насколько они соответствуют конкретным целям качества.

Активный дизайн обзора (ADR)

Он лучше всего подходит для незавершенных или незавершенных архитектур, в которых больше внимания уделяется набору проблем или отдельным частям архитектуры за раз, чем выполнению общего обзора.

Активные обзоры Intermediate Designs (ARID)

Он сочетает в себе аспект ADR при анализе текущей архитектуры с акцентом на ряд проблем, а подход ATAM и SAAM к анализу на основе сценариев фокусируется на атрибутах качества.

Метод анализа затрат и выгод (CBAM)

Основное внимание уделяется анализу затрат, выгод и сроков выполнения архитектурных решений.

Анализ модифицируемости на уровне архитектуры (ALMA)

Оценивает модифицируемость архитектуры для бизнес-информационных систем (BIS).

Метод оценки семейной архитектуры (FAAM)

Он оценивает архитектуры семейства информационных систем на предмет взаимодействия и расширяемости.

Общение архитектурного дизайна

После завершения проектирования архитектуры мы должны сообщить о проекте другим заинтересованным сторонам, в том числе команде разработчиков, системным администраторам, операторам, владельцам бизнеса и другим заинтересованным сторонам.

Существует несколько следующих известных методов описания архитектуры для других:

Модель 4 + 1

Этот подход использует пять представлений о полной архитектуре. Среди них четыре представления ( логическое представление, представление процесса, физическое представление и представление разработки ) описывают архитектуру с разных подходов. В пятом представлении показаны сценарии и варианты использования программного обеспечения. Это позволяет заинтересованным сторонам увидеть особенности архитектуры, которые их особенно интересуют.

Язык описания архитектуры (ADL)

Этот подход используется для описания архитектуры программного обеспечения до внедрения системы. В нем рассматриваются следующие проблемы — поведение, протокол и соединитель.

Основным преимуществом ADL является то, что мы можем проанализировать архитектуру на предмет полноты, согласованности, неоднозначности и производительности, прежде чем формально начать использовать проект.

Agile Modeling

Этот подход следует концепции «контент важнее представления». Он гарантирует, что созданные модели просты и понятны, достаточно точны, детализированы и последовательны.

Гибкие типовые документы нацелены на конкретного клиента (ов) и выполняют рабочие усилия этого клиента. Простота документа обеспечивает активное участие заинтересованных сторон в моделировании артефакта.

IEEE 1471

IEEE 1471 — это краткое название стандарта, официально известного как ANSI / IEEE 1471-2000, «Рекомендуемая практика для описания архитектуры программно-интенсивных систем». IEEE 1471 расширяет содержание описания архитектуры, в частности, придавая конкретное значение контексту , взгляды и точки зрения.

Унифицированный язык моделирования (UML)

Этот подход представляет три представления модели системы. Представление функциональных требований (функциональные требования системы с точки зрения пользователя, включая варианты использования); статическое структурное представление (объекты, атрибуты, отношения и операции, включая диаграммы классов); и динамическое представление поведения (взаимодействие между объектами и изменения внутреннего состояния объектов, включая диаграммы последовательности, активности и состояния).