Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования).
Activity и State диаграммы чуть менее, чем в каждой спецификации.
Sequence и Class Diagram позволяет в целом взглянуть на кучи кода. Руками никогда не делаются, генерятся из кода в Visual Studio. Последнее время заменяется Code Map.
Еще иногда применяются специализированные для конкретной платформы component diagram.
Все остальное — бесполезное фуфло, придуманное чтобы продавать софт.
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования). А>Также опрос
Здравствуйте, Vzhyk, Вы писали:
V>Кратко. Это происходит потому, что кто-то пытается забивать гвозди V>микроскопом, а микробов разглядывать в лупу. V>У каждого инструмента есть границы применения и генерация кода или V>наоборот это уже за рамками границ разумного применения UML.
Да, так и есть. Увы, зачастую проектировщик ПО и программист — это один и тот же человек.
Я например за то что бы надо мной был проектировщик. И хочю хорошую лупу. UML мне не нужен
2/12/2014 5:48 PM, Donim пишет:
> Да, так и есть. Увы, зачастую проектировщик ПО и программист — это один > и тот же человек. > Я например за то что бы надо мной был проектировщик. И хочю хорошую > лупу. UML мне не нужен
Ну если объемы-сложность кода не требуют сопроводиловки (UML здесь
просто удобен), то нафига козе баян.
Нафига тебе проектировщик? Чтобы твою зарплату на двоих разделили?
Проектировщик нужен, когда проект достаточно большой и не тривиальный..
G>Activity и State диаграммы чуть менее, чем в каждой спецификации. G>Sequence и Class Diagram позволяет в целом взглянуть на кучи кода. Руками никогда не делаются, генерятся из кода в Visual Studio. Последнее время заменяется Code Map. G>Еще иногда применяются специализированные для конкретной платформы component diagram.
G>Все остальное — бесполезное фуфло, придуманное чтобы продавать софт.
Приблизительно как с паттернами. Применимых штуки 5-6 (ну ладно 6-7),
а остальные чтобы книжки продавать.
Здравствуйте, Vzhyk, Вы писали:
V>Ну если объемы-сложность кода не требуют сопроводиловки (UML здесь V>просто удобен), то нафига козе баян. V>Нафига тебе проектировщик? Чтобы твою зарплату на двоих разделили? V>Проектировщик нужен, когда проект достаточно большой и не тривиальный..
Да, проект большой, он просто не умещается весь в голове, перескакивание с одного на другое занимает много времени, например было бы лучше если бы один человек занимался гуем, другой — логикой, второе — разные взгляды на вещи способствуют лучшему решению. Мне например было бы лучше если б сказали "нужен черный ящик, на входе имеешь это, на выходе нужно то-то, денег получишь столько то — вперед"
2/12/2014 6:06 PM, Donim пишет:
> Да, проект большой, он просто не умещается весь в голове, перескакивание > с одного на другое занимает много времени, например было бы лучше если > бы один человек занимался гуем, другой — логикой, второе — разные > взгляды на вещи способствуют лучшему решению. Мне например было бы лучше > если б сказали "нужен черный ящик, на входе имеешь это, на выходе нужно > то-то, денег получишь столько то — вперед"
Вот здесь вот и удобен UML, когда нужно описать связи между различными
частями проекта, потоками данных, интерфейсы этих частей. Можно и без
него, но не очень удобно и придумывать свои уникальные обозначения придется.
Здравствуйте, Vzhyk, Вы писали:
V>Вот здесь вот и удобен UML, когда нужно описать связи между различными V>частями проекта, потоками данных, интерфейсы этих частей. Можно и без V>него, но не очень удобно и придумывать свои уникальные обозначения придется.
Ну, думаю обычный человеческий язык, ну и пара схемок, всё таки понятнее и эффективнее будет.
2/12/2014 6:23 PM, Donim пишет:
> Ну, думаю обычный человеческий язык, ну и пара схемок, всё таки понятнее > и эффективнее будет.
Во-во.
Только, человеки не сильно любят читать текст, особенно длинный и не
художественный, а любят картинки.
А в картинках или придумываем свои обозначения или используем
общепринятые. Но так как человеки тебя пошлют с твоими уникальными
обозначениями, ибо лень вникать в то, что ты там нафантазировал, то ты
воспользуешься общепринятыми.
В итоге, все, что нужно по архитектуре продукта будет оформлено в UML.
Здравствуйте, Donim, Вы писали:
_>>нет, нужно не модель приводить в соответствие коду, а код переделывать под изменения модели D>Да, в теории так, на практике выходит по другому. Опять же с точки зрения программера, осознание того что модель не работоспособная приходит часто во время дебагинга,
ШТО
_>>историю изменений тоже на бумаге хранить? D>Нет, для этого ведь есть системы управления версиями
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования).
Ко всем кто пишет, что UML в виде диаграмм классов у них часто нужен и активно используется — пишите свои компании, пожалуйста. Буду знать с кем в будущем НЕ работать.
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования). А>Также опрос
Нужен редко, после маркерной доски и бумаги, и попытки закодировать нечто без UML с последующим переосмыслением. Софт Dia, использую для описания взаимоотношений между классами. Лично для меня UML последний аргумент архитектора, когда для дальнейшего написания кода требуется формализация. Практическая ценность высокая, так как без UML можно зайти в тупик и не выйти.
Использую UML для иллюстрации дизайн-решений. В основном, использую диаграмму классов и диаграмму последовательности. Иногда строю диаграмму последовательности, когда нужно разобраться в коде. Для построения диаграмм использую MS Visio или бумагу и ручку.
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования). А>Также опрос
Волею судьбы почти всю профессиональную жизнь разрабатываю коммерческие средства моделирования на базе UML и все это время готов побить весь OMG в полном состав
Практическое применение UML возможно лишь после выпиливания тонны кусков и вставки domain-specific вещей. Стандарты UML опосля 1.3 к реальности не имеют отношения. Основные претензии:
— отсутствие run-time semantic-и. Каждый крупный кастомер кто юзает UML понимает run-time поведение модели по своему.
— отсутствие нормальной текстовой нотации для написания поведения. Мало-мальски серьезная State/activity модель требует кода в transition/action-ах и т.д. В 99% юзер использует target code в таких случаях. Отсюда вытекает следущая претензия
— отсутствие стандарта на ссылки из target code-а на UML элементы. Каждый следует собственному пути
— отсутствие стандартного формата для графической нотации. Как пример можно взять CIF для SDL. Вот для UML такого нет, что сильно затрудняет обмен диаграммами.
— отсутствие ссылок по имени на уровне мета-модели UML. Все reference-ы обязаны иметь target. Иметь что-то с состояниями "установлено, но не разрезолвлено" нельзя
— не проработан Compare/Merge для моделей вообще (плюс учет еще диаграмм и чтоб было user-friendly). Теоретические работы оторваны от практики, практические воплощения страдают от отсутствия формального базиса. С этой темой на практике вожусь уже года полтора. Проблем тут море.
— генеренный код из модели вообще говоря приходится дебажить. И при дебаге хорошо бы прыгать и по модели. Отсюда вытекает потребность в некоем стандартном UML level API для дебаггинга UML моделей. Над этим тоже не думают.
— еще ворох более мелких претензий..
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[2]: UML в вашей жизни проектировщика ПО
От:
Аноним
Дата:
18.02.14 14:01
Оценка:
_O_>Основные претензии: _O_>- отсутствие run-time semantic-и. _O_>- отсутствие нормальной текстовой нотации для написания поведения.
Здравствуйте, Donim, Вы писали: D>Хм, интересно, посмотрю, спасибо. С первого взгляда не увидел кодогенерации, почему мне нравится модельмейкер — это полная синхронизация с кодом (сужу с позиции программиста) т.е. определил южкейс, Activity, набросал диаграмму классов, кнопка "сделать мне красиво" и опа — готовый код.
"хайп вокруг UML быстро поутих, когда выяснилось, что из неправильных диаграмм генерируется неправильный код"
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Donim, Вы писали: D>>Хм, интересно, посмотрю, спасибо. С первого взгляда не увидел кодогенерации, почему мне нравится модельмейкер — это полная синхронизация с кодом (сужу с позиции программиста) т.е. определил южкейс, Activity, набросал диаграмму классов, кнопка "сделать мне красиво" и опа — готовый код. S>"хайп вокруг UML быстро поутих, когда выяснилось, что из неправильных диаграмм генерируется неправильный код"
А вот, кстати, интересный вопрос поднялся. Что мол UML, теоретически, избавляет нас от написания шаблонного, boilerplate, кода и позволяет генерировать его из высокоуровневых диаграмм.
Но это было давно. Лет 20 назад. У нас появилась куча инструментов, которые решают ту же задачу.
Например с помощью лямбд можно существенно упростить большинство GoF паттернов. Т.е. часть зависимостей между классами на диаграмме классов исчезла. В итоге, если мы не будем злоупотреблять наследованием, диаграмма классов нам может и не понадобиться. Хватит диаграммы пакетов и связей между ними.
Linq, async/await и проч. (монады) избавляют нас еще от кучи лишнего кода и классов. Convention over configuration позволяет не писать еще чуть-чуть куда.
С помощью DSL, кодогенерации и метапрограммирования можно избавиться от кучи boilerplate кода.
Что я предлагаю? Предлагаю я подумать о том, какие типы UML диаграмм можно представить в виде кода без существенной потери выразительности. С помощью функционального подхода, метапрограммирования.
Например, небольшие диаграммы состояний можно описать с помощью DSL или кода без (существенной) потери выразительности.
Что еще вам приходит в голову?
Какие UML диаграммы "выживут" после такого анализа?
Здравствуйте, akava, Вы писали: A>Что еще вам приходит в голову? A>Какие UML диаграммы "выживут" после такого анализа?
Пока существует взаимодействие нескольких систем, диаграммы последовательности будут необходимы.
Диаграммы состояний также крайне полезны безотносительно применяемой внутри технологии. Вот, к примеру, в документацию по API от Office365 входит диаграмма состояний для объекта "подписка". При этом совершенно неважно, на чём там внутри написан этот сервис.
Диаграмма пакетов тоже вполне себе имеет смысл независимо от того, что является частью пакета. Ведь в ФП никто не обязывает сваливать абсолютно все функции в глобальное пространство. К примеру, в том же JS вообще нет никакого понятия пакетов (ну, до недавних версий), что никак не мешает по факту использовать пакетную структуру со всеми её атрибутами — зависимостями, делением по слоям и т.п.
Так и в ФП — вот, функция А является композицией функций X::B и Y::C, полученной при помощи вызова комбинатора Z::D.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования).
Очень часто использую Sequence diagram, сгенерированную упомянутым здесь PlantUML. В основном, для донесения идей до других программистов (редко) или для разъяснения отдельных важных вещей инженерам (часто). Это гораздо проще, чем пытаться объяснять тонкости взаимодействия словами.
Для генерации диаграмм по коду есть doxygen, например. А идея генерировать код из UML... вообще не понимаю, как ее кто-то мог воспринять всерьез.
