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

Question

Я часто рисую поток данных на листе бумаги.Даже планирование моих маленьких инструментов сделано на бумаге.

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

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

**** Полезные ссылки, опубликованные в комментариях: ** SO Link # 1 SO Link # 2

Прямо сейчас мне интересно узнать о 2 вещах, и одна из них была у меня в голове довольно давно:

1) Mindmap - Я пробовал некоторое время назад, довольно понравилось, но забросил.Hoever даст ему еще одну попытку

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

У кого-нибудь есть другие интересные идеи?Мне бы очень хотелось услышать, что другие используют для разработки своего программного обеспечения и как оно продвигается.

Большое спасибо!

Answer 1

Почему вы вообще хотите рисовать UML, будь то на бумаге или на компьютере?

Я согласен, что вам нужна модель для представления дизайна. Но даже в крупных проектах продолжительностью около 500 человеко-месяцев я заметил, что только 3-4 диаграммы последовательности действительно имеют значение и имеют шанс пережить весь жизненный цикл приложения. Эти 3-4 диаграммы последовательности (и диаграммы классов, которые представляют их статические временные отношения), как правило, представляют собой высокоуровневый дизайн приложения.

Или посмотрите на это так:

Любое достойное корпоративное приложение не будет иметь 20 различных потоков вызовов. Будет один или два общих (или абстрактных) потока вызовов, которые реализуют все конкретные варианты использования. Давайте возьмем простое приложение Struts / EJB. Общий поток будет что-то вроде: класс действий, вызывающий валидатор, а затем вызывающий сессионный компонент без сохранения состояния, который, в свою очередь, вызывает класс домена, который будет вызывать DAO. Все варианты использования приложения просто реализуют этот поток с конкретными классами, специфичными для этого варианта использования.

Согласны ли вы?

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

Если вы согласны со мной, мы сводим до 3-4 диаграмм классов и последовательностей даже для крупных корпоративных приложений, состоящих из нескольких тысяч классов. Почему это важно, как вы рисуете и поддерживаете эти 3-4 диаграммы?

Вы можете сказать, что хотите документировать все варианты использования в целях обучения или документирования. За последние 14 лет работы в реальном мире корпоративного программного обеспечения я не помню, чтобы я видел хорошо «поддерживаемую» документацию UML. Прежде всего, хорошие документы трудно произвести, и их не так часто можно найти. Во-вторых, большую часть времени они не синхронизированы с кодом. Большая часть моего опыта связана с крупными банками, страховыми компаниями, автомобильными компаниями и т. Д. Эта среда слишком беспокойна, и их ресурсы ограничены (правда? Мы говорим о банках? Да, в это трудно поверить, но это правда) для «поддержания» хорошего документация.

Так я предлагаю избавиться от UML?

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

Итак, что является разумным решением для простого производства и поддержки моделей UML?

1. Вероятно, нам лучше использовать текущий набор инструментов UML для рисования этих 3-4 высокоуровневых UML-диаграмм. Если вы не любите их использовать, отметьте вариант 3 ниже.
2. Для диаграмм на следующем уровне абстракции (любые полезные модели должны иметь разные уровни абстракции), сгенерируйте UML из исходного кода. Вы можете создавать диаграммы классов и последовательностей.
3. В этот век гибких методологий, почему бы просто не написать классы оболочки и сгенерировать эти 3-4 высокоуровневых диаграммы классов и последовательностей UML? Таким образом, UML вообще не будет поддерживаться.

Исходный код - это правда.

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

Однако есть две основные проблемы с сгенерированным UML.

1. Когда мы вручную рисуем диаграмму классов, мы показываем отношения между классами, участвующими в сценарии. Большинство существующих инструментов генерации диаграмм классов позволяют пользователю добавлять классы Java (исходный код) в инструмент, и инструмент автоматически показывает отношения между классами. Проблема здесь в том, как можно узнать о классах, включенных в сценарий для начала?
2. Вторая проблема - подробность сгенерированных диаграмм. Доступны инструменты для генерации последовательности выполнения и диаграмм классов для сценария. Но диаграммы часто очень многословны и опровергают назначение моделей, цель которых - выделить важные аспекты и отфильтровать несущественные детали.

Хорошие инструменты генерации UML должны решать обе вышеуказанные проблемы. В домене Java есть несколько инструментов, которые пытаются решить эти проблемы. Проверьте обсуждения ниже:

Какие инструменты я должен использовать для визуализации структуры моего кода

Существуют ли какие-либо инструменты для определения архитектурных и дизайнерских шаблонов в коде?

Надеюсь, я ответил на оригинальный вопрос:

У кого-нибудь есть другие интересные идеи? Мне бы очень хотелось услышать, что другие используют для разрабатывать свое программное обеспечение и прогресс его.

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

Answer 2

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

Я использую диаграммы ER (на доске) для моделирования моих данных и диаграммы последовательности сообщений (на доске) для моделирования потока данных. Я также сделаю быстрые макеты страниц пользовательского интерфейса на доске.

Кроме того, я использую Ruby / Rails для кодирования на стороне сервера и HTML / CSS / jQuery / JS на клиенте.

Answer 3

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

Число растет, вот некоторые из них, которые вы можете посмотреть:

• UMLet : настольное приложение, поддерживает большинство UML, а также различные другие диаграммы.Можно также создавать свои собственные формы и коннекторы.FOSS.
• WebSequenceDiagrams.com : онлайновые диаграммы последовательности.
• TextUML : настольное приложение.Фокус исполняемых моделей, автоматически генерирует диаграммы классов.FOSS.У него также есть онлайн коммерческий брат .

чч.

Answer 4

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

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

Answer 5

Нет. Есть различные другие способы. UML это просто вариант. Перо и Бумага Прототипирование также отличный вариант, он не должен следовать UML. Mind Map - еще один замечательный способ.

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

Answer 6

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

Почему бы не определить свой собственный язык, который точно соответствует вашим потребностям и вашей конкретной проблеме? Такие языки называются Специфичные для домена языки (DSL). Вместо того, чтобы вкладывать средства в изучение сложного языка, вы вкладываете средства в определение языков, которые точно соответствуют вашим потребностям.

Существует множество подходов, которые поддерживают определение DSL. Наиболее распространенной является Универсальная система моделирования затмения (GEMS) . Лично я получил большой опыт работы с GrGen благодаря его универсальности и возможности автоматизации рабочих шагов с помощью преобразования графиков.

Answer 7

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

Я думаю, что UML должен больше ориентироваться на код, но несосредоточиться на текстовом вводе.