Поделиться через

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

  • Статья

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

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

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

Примечание.

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

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

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

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

Высокоуровневый дизайн

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

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

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

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

  • Архитектурные шаблоны. Выбранные базовые технологии и архитектурные элементы системы.

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

Общие сведения о требованиях

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

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

Модель требований предоставляет следующие важные сведения:

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

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

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

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

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

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

Шаблоны архитектуры

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

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

  • Выбор платформы, например выбор между Windows Workflow Foundation и ADO.NET Entity Framework.

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

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

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

Конструктивные шаблоны

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

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

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

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

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

  • Имя.

  • Описание контекста, в котором он применяется. В каких условиях разработчику рассмотреть возможность применения этого шаблона?

  • Краткое описание решаемой им проблемы.

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

  • Соглашения об именовании.

  • Описание того, как шаблон решает проблему.

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

Связанный контент