Как часто вы используете формальный UML?

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

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

Никогда.

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

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

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

По иронии судьбы, UML должен быть гибким.

В реальном мире, он не должен быть педантичным упражнение делать это один правильный путь. Речь идет об эффективной коммуникации и документировании системы / процесса / идеи.

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

В течение четырех лет я очень регулярно использовал UML для продукта, который сгенерировал все (большую часть) его скелетов кода из Rational Rose.

За последние пять лет появилось больше «коробок и стрелок», в основном, изобретенных на месте, и обычно их было достаточно, чтобы донести общую идею. Формально исправьте UML только несколько раз за это время.

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

Спросите своего профессора, когда в последний раз он использовал этот подход в реальной системе. Шутки в сторону.

Я стараюсь быть настолько формальным, насколько это возможно, когда дело доходит до UML, но только если / когда это имеет смысл. Зилоты по обе стороны спектра (от ковбоев до настойчивых формалистов) не понимают этого.

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

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

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

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

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

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

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

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

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

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

Обычные предостережения академического исследования применяются, конечно :)

Ссылка на реферат и сам документ (если у вас нет доступа к ACM) .

Кроме того, я настоятельно рекомендую Ambler «Agile Modeling».

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

Это зависит от отрасли, в которой вы работаете. Если вы работаете с клиентами, которым требуются частые технические проверки (например, PDR, CDR и т. Д.), То они предпочитают какую-то стандартизацию, а не специальные системы обозначений. В частности государственная работа. Это предотвращает недопонимание и первоначальное 15-минутное объяснение обозначения, которое вы изобрели.

Кроме того, только то, что вы используете UML, не означает, что вы должны расставлять точки каждый i и пересекать каждый t в соответствии со стандартом. Это только в том случае, если вы хотите сделать какую-то автоматическую генерацию / выполнение кода. Я не знаю никого, кто делал это для более чем 1 проекта.

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

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

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

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

Когда я читал об UML, я пробовал это на всех проблемах, которые я должен был решить в моем курсе C ++. К счастью, одним из первых примеров, которые я попробовал, было описание связанного списка.
Не сработало
Тем не менее, в сочетании с хорошим процессом моделирования UML является полезным. Просто потому что это к лучшему или худшему стандарту.
Я хотел бы видеть язык описания шаблонного метапрограммирования. Я думаю, что это очень помогло бы в понимании того, что происходит в <<<>>> земле

UML будет болезненным, если вы также попробуете разработку на основе моделей. Я имею в виду, что UML - очень полезная только графическая запись, а все остальное бесполезно. Я не трачу на моделирование, но использую UML каждый день, чтобы создать структуру своих проектов. Что я делаю, так это быстро рисую базовую диаграмму вариантов использования на уровнях требований, а затем сразу переключаюсь на диаграммы классов. Я добавляю трассируемость требований между диаграммами сценариев использования и классов. Моя диаграмма классов также создает код, потому что он синхронизирован в реальном времени. Нет тега в коде, вся модель сохраняется в модели UML, которая сопоставлена ​​с проектом Java.

Я создаю скелет своего приложения с помощью нескольких диаграмм классов, а затем переключаюсь на код. Закончив код, я объединяю его с моделью. Это своего рода итерация между кодом и моделью, где код запускает модель. Таким образом, мои диаграммы классов дают мне более высокий уровень абстракции и мой код, в то время как мой код дает мне мою реализацию бизнес-логики (например, методы).

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

UML великолепен, фантастичен и действительно полезен, но разработка на основе моделей бесполезна !!

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

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

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

На мой взгляд, Унифицированный процесс имеет много достоинств, но вся практика создания визуальных артефактов, какой бы ни был язык моделирования, немного нелепа. Итеративно уточненный документ, содержащий последовательный список, например, который может быть создан с помощью Word, Workflowy, Evernote, OpenOffice или именованного текстового процессора, вполне способен документировать то, что требуется Unified Process. Нечто такое, на что можно без труда работать несколькими пользователями, с управлением версиями, и если кто-то выберет правильный инструмент для этого, команда может работать над ним одновременно. Это гораздо легче сделать, чем когда UML казался необходимым способом объединения полчищ.