Какие UML-диаграммы вы создаете для приложений ASP.NET?

Я работаю в компании среднего размера в качестве старшего разработчика и занимаюсь разработкой проектов с довольно большими размерами ( > 1 год как минимум). Большинство архитекторов здесь считают, что создание диаграмм UML не оправдывает время (хотя у нас всегда есть ERD и некоторая неофициальная диаграмма последовательности действий для всех проектов)

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

  • Для создания логической модели - модель роли объекта (ORM
  • Для создания физической модели - компонент, класс, последовательность, активность
  • Для модели базы данных - ERD

Вопросы:

  • Какие UML-диаграммы вы создаете в своей компании?
  • Имеет ли MS Visio возможность создавать все диаграммы выше?
  • Являются ли UML-диаграммы выбранными в зависимости от типа приложения, являющегося разработаны?

ОТВЕТЫ

Ответ 1

# 1 Какие UML-диаграммы вы создаете в своей компании?

Мы используем весь набор диаграмм, определенных UML. Мы особенно сильно используем диаграммы использования, диаграммы классов, диаграммы последовательностей и диаграммы состояний машины.

# 2 Имеет ли MS Visio возможность создавать все диаграммы выше?

Это так, но мы обычно не используем Visio для этого, поскольку есть много инструментов, намного более подходящих для работы. Лично я предпочитаю инструменты, которые позволяют мне создавать диаграммы очень быстро, без особых проблем и суеты. Меня раздражают инструменты, обеспечивающие рабское соблюдение спецификации UML (или, что еще хуже, интерпретация спецификации поставщика инструмента). Одним из инструментов, которые я нашел особенно полезными, является Pacestar UML Diagrammer.

# 3 Являются ли UML-диаграммы выбранными в зависимости от типа разрабатываемого приложения?

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

Большинство архитекторов считают, что создание диаграмм UML не оправдывает время, затрачиваемое на

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

Ответ 2

Я использовал UML, так как он был изобретен в 90-х годах и использовал его в крупных и малых компаниях для самых разных целей. Я использую UML для двух основных целей: как блокнот для мышления (иногда я не знаю, что я думаю, пока не увижу, что я рисую;) и как способ документировать и сообщать проекты. Вот как я это использую и некоторые из моих правил.

Я использую UML , когда другие инструменты неадекватны для визуализации/моделирования. Итак, если вы используете базу данных SQLServer, вы можете использовать встроенные графические схемы и печатать и вставлять их в свои документы. UML здесь не нужен.

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

Разработка JavaScript и Ajax. Слабая поддержка инструментов и визуализации. Я использую UML, чтобы продумать и показать высокоуровневый дизайн сложных приложений JavaScript. (Если вы работаете над Java-приложением, вы можете использовать инструменты, встроенные в большинство Java-IDE, чтобы визуализировать ваш код. С другой стороны, если вы работаете над приложением JavaScript или имеете плохие инструменты, это труднее сделать, поэтому UML может заполните пробелы.)

Информационные архитектуры и навигация для веб-приложений. Я использую UML для отображения веб-страниц, их отношений и информационных компонентов на веб-страницах. То же самое относится и к экранам в любом графическом интерфейсе (его раньше называли моделью пользовательского опыта). Я использую URL-адреса REST в своих веб-приложениях. Поэтому я комментирую объекты своей страницы, чтобы показать фактические URL-адреса REST. Таким образом, я одновременно размышляю над частью REST, когда я выкладываю страницы. По моему опыту, это один из самых полезных и недостаточно используемых типов диаграмм, возможно, потому, что он не является стандартным. Он отображает как информационную архитектуру (модель вашего домена, представленная в виде коллекции страниц/экранов), так и концепцию приложения в виде набора навигационных представлений. Часто существует несоответствие между этой моделью, которая наиболее близка к пользователю и модели домена приложения или модели базы данных. Возможность иметь эту модель устраняет проблему. Ive работал над проектами, в которых каждая из них создавала свою модель приложения: юзабилити, разработчики, люди базы данных, архитекторы предприятия. Но ни у кого не было правильной модели, а модель пользовательского опыта скрывала то, чего они не видят.

Кодовые модели. Я работаю с Java и реконструирую кодовую базу и создаю диаграммы для документирования дизайна. Однако, поскольку Java-инструменты настолько зрелы, мне редко приходится перерабатывать только для понимания кода. Я использую Enterprise Architect, который является недорогим и позволяет вам перепроектировать новый код и синхронизировать его с диаграммами UML на основе старого кода.

Я помещаю все эти разные диаграммы в один проект, и он отображает общий дизайн системы как набор представлений. Я также экспортирую проекты UML в XML и сохраняю их в своей системе управления версиями. Диаграммы публикуются в Интранете и вставляются в документы.

Диаграммы компонентов никогда. Если я хочу отображать компоненты, я просто использую диаграмму классов и аннотирую ее со стереотипом: page, view, table - для представления типа объекта Im, изображающего, Это облегчает мне жизнь. Я сильно использую стереотипы. Они позволяют мне по существу создавать собственные типы диаграмм и при этом придерживаться использования диаграмм классов классов.

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

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

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

Ответ 3

ПРЕДИСЛОВИЕ

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

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

1. Какие диаграммы UML вы создаете в своей компании?

Отсутствует. UML - это не то, что BAs, команда разработчиков и т.д. Понимают, где я сейчас работаю. Тем не менее, значение действительно не соответствует типу dev, который мы делаем: быстрые и умеренные тактические решения.

2. У MS Visio есть возможность создать все диаграммы выше?

Да. http://softwarestencils.com/uml/index.html

Я предлагаю вам рассмотреть инструмент, который позволяет UML → Code Gen http://www.visual-paradigm.com/

3. Диаграммы UML, выбранные в зависимости от типа разрабатываемого приложения?

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