Учебники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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