Руководство по инструментам архитектуры Visual Studio. Сценарий – Мне необходимо начать разработку новой системы РЕКОМЕНДАЦИИ Мы рекомендуем, чтобы вы рассмотрели сценарий «Сценарий – мне необходима повторно используемая (повторяемая) архитектура» перед переходом к сценарию с новой системой. Visual Studio Ultimate поможет вам по пути успешного построения новой системы. Сочетание инструментов Unified Model Language (UML) и итеративный подход может помочь вам постепенно: Определить требования Создать многоуровневую архитектуру с подходящей абстракцией для объектно-ориентированного подхода Разработать потоки команд управления между компонентами и классами Требования для новой системы определяют, что должно быть разработано. Набор требований поможет нам определить архитектуру для системы. Форма следует за функцией. Как только мы имеем форму или архитектуру системы, мы можем удовлетворить каждое из требований путем выстраивания потоков между различными компонентами и классами. Прозрачная архитектура является критичной для расширяемой и простой в поддержке системы. Visual Studio Ultimate позволит осветить архитектуру, так что все в команде смогут увидеть ее элегантность. Это критично для крупных систем, но столь же важно для проектов с одним или двумя людьми. Рабочий процесс сценария создания новой системы Разрабатывает ли ваш проект три человека или триста поток информации через подсистемы, компоненты или классы важен для интеграции системы. Потоки могут использоваться с целью связывания моделей протоколов между системами, контрактов между интерфейсами или последовательности сообщений. Рекомендуется использовать итеративный подход и избегать попыток моделировать всю систему за один раз («Абсолютный большой дизайн»). Создайте наброски модели в первых итерациях и затем в каждой последующей итерации, детализируйте функциональные возможности, которые будут рассмотрены в этой итерации. Разрабатывайте тесты, которые отражают модель максимально близко и проверяйте код на основе этих тестов. Извлекайте уроки во время кодирования и отображайте их обратно в модели. Таким образом, процесс моделирования и процесс разработки синхронизируются с помощью итеративного подхода. Рабочий процесс Существует пять основных рабочих потоков для сценария новой системы, которые отражены на рисунке: Определение архитектуры – этот рабочий поток содержит мероприятия для синергизма форм системы: слои, компоненты и классы Выявление субъектов/вариантов использования – этот рабочий поток содержит мероприятия, посредством которых мы определим пользователей и их цели использования системы Определить поведение – этот рабочий поток содержит мероприятия для определения динамического поведения системы и связанной с ним архитектурой Рецензирование модели – этот рабочий поток позволяет другим членам команды обеспечить понимание и дать комментарии для модели архитектуры Разработка системы – этот рабочий поток содержит необходимые процесс для разработки куска модели и обеспечения обратной связи, так чтоб будущие активности моделирования оставались в синхронизации с кодом Эти пять рабочих потоков обеспечивают полный процесс для моделирования новой системы. Поскольку каждый из них опирается на другие и обеспечивает обратную связь, ошибки могут быть легко обнаружены по потоку и исправлены. Связывание рабочих элементов позволяет создать задачи разработки и тестовые сценарии из модели и связать для обеспечения отслеживания происхождения. Обратите внимание, что рабочие потоки могут работать одновременно – вам не нужно завершать один прежде чем начать другие. Определение архитектуры Многие типы приложений следуют установленным архитектурным шаблонам. Эти шаблоны предоставляют вам стандартные решения, которые имеют хорошие инженерные характеристики, такие как прозрачное разделение проблем. Использование знакомых шаблонов упрощает разработчикам понимание приложений и позволяет найти различные части функциональности. Например, диаграмма слоев на рисунке ниже может применяться для любого веб-приложения. Однако применяя этот шаблон к Pet Shop sample application держит нашу архитектуру прозрачной, по крайней мере на самом высоком уровне. Архитектура слоев высокого уровня для Online Pet Shop Когда применяется этот шаблон, можно разбить вашу систему на подсистемы. Для более крупных систем подсистемы может назначить группы или отдел. В небольших системах подсистема может иметь один или двух владельцев. Конечно, при использовании процесса разработки программного обеспечения с общим владением кода, подсистемы могут быть созданы для целей идентификации и сохранения базы кода в порядке. Подсистемы часто используются для формирования нашего решения Visual Studio. Детализированная диаграмма архитектуры слоев Можно добавить более подробную диаграмму слоев в виде развернутых слоев и применения шаблонов нижнего уровня. На низком уровне можно назначить классы для каждой подсистемы, которые будут реализовать необходимые функции. Вы можете даже пойти до уровня методов – так что это будет самый низкий уровень, например, действительно сложный класс обработки заказа с 30 методами может потребовать свою собственную схему слоя, при попытке отделить различные варианты поведения. Вы должны уважать зависимости: стрелки между подсистемами указывают шаблон одностороннего использования между слоями. Несколько слоев позволяют изучить архитектурные точки зрения и могут использоваться для назначения рабочих элементов (задач и ошибок) или связать другие документы со слоями, чтобы конкретная проблемная область была полностью представлена слоем. Например, ошибки, обычно классифицируются их компонентами или архитектурными зонами и назначаются необходимому разработчику. Ключевой аспект некоторых из этих диаграмм держать их максимально простыми, чтобы не «загрузить» пользователя. Диаграмма, которая используется для связывания элементов, для других членов команды может быть более абстрактной, а для одного, который использует ее для создания или проверки кода, может быть более подробной. Определение субъектов, вариантов использования и бизнес концепции Субъект — тип внешней сущности, такая как пользователь или другая система, которая взаимодействует с вашей системой. Некоторые примеры субъектов для приложения веб-зоомагазин являются «Online Customer» и «PayPal». Поскольку приложение Pet Shop ориентировано на Интернет-коммерцию, «Online Customer» является лучшим наименованием субъекта, чем просто «Customer». Частичная диаграмма вариантов использования для приложения Online Pet Shop Определите цели каждого субъекта. Представьте каждую цель как вариант использования. Например, многие клиенты хотят просто посмотреть на фотографии собак и кошек прежде чем получить одного из них. Их цель – Просмотр тавара (или может быть «Обзор домашних животных» звучит лучше) до тех пор, пока они не находят нужного. Как только они находят, что они хотели, они, возможно, пожелают добавить в корзину и купить этого питомца. Варианты использования обычно принимают форму глагола с последующим существительным. Схема вариантов использования на рисунке выше показывает несколько субъектов и вариантов использования для Интернет-зоомагазина. Вариант использования «Purchase Pet(s)» расширяет вариант использования «Browse Inventory» потому что он содержит все функции просмотра, а также некоторые дополнительную функциональность покупки. Хороший ресурс, который вы можете рассмотреть “Agile Modeling”, Scott Ambler. Смотрите Modeling User Requirements для более подробной информации. Определение бизнес концепции Диаграмма классов бизнес-концепции описывает сущности и отношения, которые представляют интерес в разработке. Ключевой задачей является обеспечение понимания командой бизнес-требований, согласованности и использования общей терминологии (глоссария терминов) и что команда фактически строит правильную систему. Эти классы представляют условия и отношения, которые определены и применимы пользователями. Диаграмма бизнес концепции отвечает на вопросы о требованиях заказчика, например «Товары это список видов животных или список отдельных животных?» или «Каждое животное оценивается индивидуально или оцениваются по виду?» Диаграмма бизнес концепции не является (обязательно) диаграммой классов программного обеспечения, так что вам не нужно связывать операций с этими классами. Вместо этого цель схемы заключается в том, чтобы помочь избежать недоразумения в ключевых терминах, которые часто мешают дискуссии между командами разработчиков, клиентами и тестировщиками. Диаграмма классов для бизнес-концепции Схема вариантов использования и бизнес-концепции вместе описывают «обще употребляемый язык» вашего проекта: термины, используемые при обсуждении требований с пользователями, наименования важных классов и компонентов в вашем дизайне и термины, используемые для определения системных тестов. Полезно описать результаты каждого варианта использования в терминах сущностей и связей в схеме бизнес-концепции. Например: «Обзор домашних животных позволяет онлайн клиенту увидеть всех животных в списке товаров; Онлайн клиент может просмотреть виды животных и цены». «Покупка животных добавляет один или несколько домашних животных в корзину заказчика». Убедитесь, что вы можете описать важные результаты каждого варианта использования с точки зрения связей и атрибутов бизнес-концепции, предположений, общего высокого уровня потока требований, критериев успеха и часто встречающихся вариаций. Например, чтобы описать Обзор, требуются только классы Pet и Inventory. Чтобы описать покупку, вам нужно добавить Shopping Cart. Необходим также атрибут Price, который порождает вопрос о том положить его на Pet или Pet Type. Это вопрос, который может потребоваться обсудить с заказчиком, владельцем зоомагазина. Убедитесь, что вы понимаете то, что вариант использования создает и удаляет все связи. Например, какой вариант использования удаляет связь между Pet и Inventory? Pet удаляется из Inventory как только он добавляется в Shopping Cart? Мы должны добавить к описанию Purchase Pet(s) «… и эти животные удаляются из списка товаров»? Как другой пример, какие варианты использования добавляют или удалять Pet Type из Catalog? Смотрите UML Use Case Diagrams: Guidelines для получения дополнительной информации и примеров. Эти вопросы являются очень полезными для обсуждения с вашими заказчиками. Они возникают из ваших попыток сделать описание вариантов использования и бизнес-концепции в соответствии друг с другом; это делает модель UML гораздо больше, чем пассивный набор диаграмм. Вместо этого они являются мощным инструментом, который помогает вам сформировать четкое понимание потребностей ваших заказчиков на раннем этапе в проекте. Прочную основу для функциональных тестов системы обеспечивает «обще употребляемый язык» диаграмм бизнес концепции и вариантов использования и на описания целей вариантов использования. Несмотря на то, что модель на этом уровне является гораздо проще, чем в дальнейшем будет реализация, и ничего не говорит о том, как будут реализовываться классы, связи и варианты использования, описания, тем не менее, однозначны с точки зрения итогов каждого варианта использования. Кроме того диаграммы бизнес-концепций обеспечивают основу, на которой выражают инвариантные бизнес-правила, как отношения между полной стоимостью корзины и цены его вложенных элементов. Определение поведения Для моделирования динамического поведения бизнеса или системы, можно использовать различные типы поведенческих диаграмм. Диаграммы активности используются для описания потока событий на бизнес-уровне в варианте использования и особенно полезны, чтобы помочь вам описать параллельные активности. Варианты использования часто «конкретизируются» с помощью диаграмм активности. UML диаграммы последовательностей особенно хороши для демонстрации, как работа распределяется между различными субъектами и компонентами системы. Для каждого варианта использования вы можете нарисовать диаграмму последовательностей, в котором линии жизни являются субъектом и системой или ее основными компонентами, и которая показывает, как они взаимодействуют для достижения цели варианта использования. При разработке компонента как композиции из нескольких частей, можно создать диаграммы последовательностей, в которых каждая часть является линей жизни. Для каждого вызова внешних интерфейсов компонента вы можете показать, как части взаимодействуют для достижения результата, требуемого для вызова. По ходу того как ваш проект развивается через разработку различных частей системы вы постепенно вводите новые диаграммы для описания новых компонентов. Вы часто должны обновлять эти диаграммы во время разработки. Во время кодирования, диаграммы помогают команде обсудить и открывать новые пути и оптимизировать методы и классы. В Visual Studio Ultimate поддерживаются два типа диаграмм последовательностей. UML-диаграммы последовательностей являются частью UML-модели. Диаграммы последовательности .NET генерируются из кода программы, используют общие нотации UML и не являются частью UML-модели. Пока вы разрабатываете некоторый код, можно создать диаграмму последовательностей, чтобы пересмотреть его структуру, сравнить его с дизайном, который первоначально создавался, и обсудить альтернативные распределения ответственности. Диаграмма последовательностей .Net сгенерированная из ProcessOrder приложения Pet Shop Рецензирование моделей Каждая модель обеспечивает представление системы с другой стороны. Полная картина системы получается, когда все модели собраны и рассмотрены. Постоянное рецензирование моделей является прекрасным методом для принятия предположений и понимания точки зрений друг друга. В рецензировании работа для реализации модели в коде может быть назначена с помощью рабочих элементов. TFS может использоваться для сотрудничества по расширению модели и модели могут быть связаны с рабочими элементами. Visual Studio 2012 включает в себя новую функцию, когда рабочие элементы можно связать с моделью, и это жизненно важно для такого процесса. Соглашение и использование цветов, комментариев и ссылок для рабочих элементов является еще одной полезной стратегией в поддержку рецензирования моделей и диаграмм. РЕКОМЕНДАЦИИ Смотрите Visual Studio 2012 Architecture Guidance – New System HOL для пошаговой инструкции по этому сценарию. Автор статьи: Александр Шамрай.