Моделирование архитектуры приложения
Чтобы обеспечить соответствие вашей программной системы или приложению потребностям пользователей, вы можете создавать модели в Visual Studio в рамках описания общей структуры и поведения программной системы или приложения. С помощью моделей также можно описывать шаблоны, используемые при разработке. Такие модели помогают понять существующую архитектуру, обсуждать изменения и четко формулировать свои намерения.
Чтобы узнать, какие выпуски Visual Studio поддерживают эту функцию, см. раздел Поддержка инструментов моделирования и архитектуры в различных выпусках.
Модель предназначена для уменьшения числа неоднозначностей, возникающих в описаниях на естественном языке, а также для того, чтобы помочь вам и вашим коллегам визуализировать проект и обсудить другие возможные варианты. Модель следует использовать совместно с другими документами или обсуждениями. Сама по себе модель не представляет полную спецификацию архитектуры.
Примечание.
В этом разделе понятие "система" означает разрабатываемое вами программное обеспечение. Это может быть крупная коллекция компонентов программного и аппаратного обеспечения, одно приложение или часть приложения.
Архитектуру системы можно разделить на две области:
Высокоуровневый дизайн. Описывает основные компоненты и их взаимодействие друг с другом для выполнения каждого требования. Если система имеет большой размер, каждый компонент может иметь собственную высокоуровневую структуру, показывающую, что он состоит из более мелких компонентов.
Шаблоны проектирования и соглашения, используемые во всех конструкциях компонентов. Шаблон описывает конкретный подход к решению задачи при программировании. Используя одинаковые шаблоны в рамках всего процесса проектирования, команда может сократить затраты на внесение изменений и разработку нового программного обеспечения.
Высокоуровневый дизайн
Высокоуровневая структура описывает основные компоненты системы и их взаимодействие друг с другом, направленное на достижение целей разработки. Действия в следующем списке связаны с разработкой высокоуровневой структуры, однако их последовательность может быть иной.
При обновлении существующего кода можно начать с описания основных компонентов. Убедитесь, что понимаете все изменения требований пользователей, а затем добавьте или измените взаимодействия между компонентами. При разработке новой системы сначала разберитесь с основными функциями в потребностях пользователей. После этого можно изучить последовательности взаимодействий для основных вариантов использования и объединить эти последовательности в структуру компонентов.
В любом случае полезно разрабатывать различные действия параллельно. а также разрабатывать код и тесты на раннем этапе. Не старайтесь закончить одну из этих задач, прежде чем приступить к другой. Как правило, требования и представление о наилучшем способе разработки системы изменяются по мере написания и тестирования кода. Таким образом, следует начать с понимания основных возможностей структуры и особенностей требований и написания кода под них. Заполните подробности в последующих итерациях проекта.
Общие сведения о требованиях. Начальной точкой любой разработки является четкое понимание потребностей пользователей.
Архитектурные шаблоны. Выбранные базовые технологии и архитектурные элементы системы.
Модель данных компонентов и интерфейсов. Можно рисовать схемы классов для описания сведений, передаваемых между компонентами и хранящихся внутри компонентов.
Общие сведения о требованиях
Высокоуровневую структуру всего приложения наиболее эффективно разрабатывать вместе с моделью требований или другим описанием потребностей пользователей. Дополнительные сведения о моделях требований см. в разделе "Требования для пользователей модели".
Если разрабатываемая система является компонентом более крупной системы, часть требований или все они могут быть заключены в программные интерфейсы.
Модель требований предоставляет следующие важные сведения:
Предоставленные интерфейсы. Предоставленный интерфейс перечисляет службы или операции, которые система или компонент должны предоставить своим пользователям, являются ли они людьми или другими программными компонентами.
Необходимые интерфейсы. Необходимый интерфейс перечисляет службы или операции, которые может использовать система или компонент. В некоторых случаях можно разработать все эти службы в рамках собственной системы. В других случаях, особенно при разработке компонента, который можно объединить с другими компонентами в различных конфигурациях, требуемый интерфейс будет задан внешними ограничениями.
Требование к качеству обслуживания. Производительность, безопасность, надежность и другие цели и ограничения, которым система должна соответствовать.
Требования к модели записываются с точки зрения пользователей системы, являются ли они людьми или другими программными компонентами. Они ничего не знают о внутренних механизмах работы системы. Напротив, в модели архитектуры задача заключается в том, чтобы описать внутренние механизмы работы и показать, как они согласуются с требованиями пользователей.
Сохранение требований и моделей архитектуры полезно, поскольку это упрощает обсуждение требований с пользователями. Это также помогает выполнить рефакторинг модели и учитывать альтернативные варианты архитектуры без изменения требований.
Объем сведений, которые следует помещать в требования или модель архитектуры, зависит от масштаба проекта, а также от размера и распределения команды. Небольшая группа с коротким проектом может ограничиться набросками схемы классов для бизнес-концепций и несколькими конструктивными шаблонами; крупный проект, распределенный по нескольким регионам, потребует значительно большего числа подробностей.
Шаблоны архитектуры
В начале разработки необходимо выбрать базовые технологии и элементы, от которых зависит структура. Ниже перечислены области, в которых необходимо сделать выбор:
Базовые технологии, такие как выбор между базой данных и файловой системой, а также выбор между сетевым приложением и веб-клиентом и т. д.
Выбор платформы, например выбор между Windows Workflow Foundation и ADO.NET Entity Framework.
Выбор метода интеграции, например выбор между служебной шиной предприятия или каналом "точка-точка".
Эти варианты часто определяются требованиями к качеству обслуживания, такими как масштаб и гибкость, и соответствующий выбор может быть сделан до определения подробных требований. В большой системе конфигурации оборудования и программного обеспечения жестко взаимосвязаны.
Сделанный выбор влияет на использование и интерпретацию модели архитектуры. Например, в системе, которая использует базу данных, ассоциации на схеме классов могут представлять отношения или внешние ключи в базе данных, тогда как в системе, основанный на XML-файлах, ассоциации могут означать перекрестные ссылки, использующие XPath. В распределенной системе сообщения на схеме последовательностей могут представлять передаваемые сообщения; в автономном приложении они могут представлять вызовы функций.
Конструктивные шаблоны
Конструктивный шаблон представляет собой структуру, описывающую проектирование определенных аспектов программного обеспечения, особенно такого, которое повторяется в различных частях системы. Придерживаясь единого подхода в рамках всего проекта, можно снизить стоимость разработки, обеспечить согласованность в пользовательском интерфейсе и сократить затраты на изучение и изменение кода.
Некоторые общие конструктивные шаблоны, например Observer, хорошо известны и широко применяются. Кроме того, существуют шаблоны, которые применимы только к вашему проекту. Например, в системе веб-продаж в коде будет несколько операций, в которых изменения вносятся в заказ клиента. Чтобы обеспечить точность отображения состояния заказа на каждом этапе, все эти операции должны следовать определенному протоколу по обновлению базы данных.
Часть задач архитектуры программного обеспечения заключается в том, чтобы определить, какие именно шаблоны следует внедрить в рамках всей структуры. Обычно это задача выполняется постоянно, в ходе выполнения проекта будут предложены новые шаблоны и улучшения для существующих шаблонов. Полезно упорядочить план разработки таким образом, чтобы использовать каждый из основных конструктивных шаблонов на раннем этапе.
Большинство конструктивных шаблонов может быть частично встроено в код платформы. Часть шаблона можно свести к тому, чтобы вынудить разработчика использовать определенные классы или компоненты, такие как слой доступа к базе данных, который гарантирует правильную обработку базы данных.
Конструктивный шаблон описывается в документе и обычно состоит из следующих частей:
Имя.
Описание контекста, в котором он применяется. В каких условиях разработчику рассмотреть возможность применения этого шаблона?
Краткое описание решаемой им проблемы.
Модель основных частей и их отношений. Это могут быть классы или компоненты и интерфейсы, имеющие ассоциации и зависимости между ними. Элементы обычно делятся на две категории.
Соглашения об именовании.
Описание того, как шаблон решает проблему.
Описание вариантов, которые разработчики могут быть в состоянии внедрить.