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

Статья
02/20/2013

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

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

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

Архитектуру системы можно разделить на две следующие части.

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

Структура высокого уровня

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

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

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

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

Понимание требований

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

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

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

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

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

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

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

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

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

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

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

Выбор основных технологий, например выбор между базой данных и файловой системой, выбор между сетевым приложением и веб-клиентом и так далее.
Выбор платформы, например выбор между Windows Workflow Foundation и ADO.NET Entity Framework.
Выбор метода интеграции, например выбор между шиной служб предприятия и каналом "точка-точка".

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

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

Компоненты и их интерфейсы

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

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

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

Компоненты

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

Схема компонентов UML с частями

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

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

Зависимости между компонентами

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

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

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

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

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

Интерфейсы

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

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

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

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

При необходимости определить список операций в интерфейсе, можно создать другое представление интерфейса на UML-схеме классов.Для этого найдите интерфейс в обозревателе моделей UML и перетащите его на схему классов.Затем можно добавлять к интерфейсу операции.

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

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

Разделение компонента на части

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

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

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

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

Используйте части в следующих случаях.

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

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

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

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

Взаимодействия между компонентами

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

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

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

Определение событий, запускающих реакцию

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

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

Опишите процедуры вычисления

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

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

Дополнительные сведения см. в разделе UML-схемы последовательностей: правила работы.

В некоторых случаях также полезны схемы активности.Например, если компоненты связаны с непрерывным потоком данных, можно описать это как поток объектов.Если компонент содержит сложный алгоритм, можно описать это как поток управления.Убедитесь, что на схеме понятно, какой компонент выполняет каждое из действий. Это можно сделать, например, с помощью примечаний.Дополнительные сведения см. в разделе UML-схемы деятельности: рекомендации.

Укажите операции

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

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

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

Модель данных компонентов и интерфейсов

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

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

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

Шаблоны разработки

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

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

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

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

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

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