Общее использование UML

Question

По моему опыту, большая часть архитектурной документации была в лучшем случае ad-hoc, и, кроме более структурированных видов написания мертвым деревом, мне еще предстоит увидеть формальный UML в реальном использовании, и я работал с немногими, если Любые разработчики, которые смогут четко или правильно строить UML-диаграммы - похоже, они больше используются как своего рода «графический псевдокод».

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

Answer 1

UML (унифицированный язык моделирования) является гибким. Нет необходимости использовать «полный» UML все время.

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

Некоторые из этих целей выходили за рамки «очевидного» использования диаграммы. Например, я использовал диаграммы развертывания для документирования наборов виртуальных машин. Поскольку элемент Node является «классификатором» UML, его можно использовать с наследованием. Я использовал это, чтобы показать, насколько специализирована базовая виртуальная машина. Например, база - это просто Windows Server 2008, но специализация, в которой установлен SQL Server, и специализация, которая используется в качестве сервера базы данных.

Answer 2

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

Из темы: Использование моделей в процессе разработки в http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

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

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

Как научиться «хорошему дизайну / архитектуре программного обеспечения»? на https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Answer 3

Я видел использование диаграмм классов UML для автоматической генерации кода. Поток был примерно таким: Enterprise Architect использовался для генерации XML-схемы из диаграммы классов. Затем эта схема использовалась в качестве входных данных для JAXB для генерации классов Java, которые обеспечивают программный доступ к данным, представленным в модели UML.

Answer 4

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

Answer 5

Я обнаружил, что диаграмма классов UML гораздо более полезна для создания логической модели данных или модели предметной области, чем диаграмма отношений сущностей. Он более выразителен, имеет обобщение (т.е. наследование) и специфические отношения n-to-n. Попробуйте смоделировать это на диаграмме ER:)

Answer 6

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

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