Здравствуйте, Donim, Вы писали: D>Хм, интересно, посмотрю, спасибо. С первого взгляда не увидел кодогенерации, почему мне нравится модельмейкер — это полная синхронизация с кодом (сужу с позиции программиста) т.е. определил южкейс, Activity, набросал диаграмму классов, кнопка "сделать мне красиво" и опа — готовый код.
"хайп вокруг UML быстро поутих, когда выяснилось, что из неправильных диаграмм генерируется неправильный код"
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
G>Activity и State диаграммы чуть менее, чем в каждой спецификации. G>Sequence и Class Diagram позволяет в целом взглянуть на кучи кода. Руками никогда не делаются, генерятся из кода в Visual Studio. Последнее время заменяется Code Map. G>Еще иногда применяются специализированные для конкретной платформы component diagram.
G>Все остальное — бесполезное фуфло, придуманное чтобы продавать софт.
Приблизительно как с паттернами. Применимых штуки 5-6 (ну ладно 6-7),
а остальные чтобы книжки продавать.
Здравствуйте, Аноним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 моделей. Над этим тоже не думают.
— еще ворох более мелких претензий..
Здравствуйте, Donim, Вы писали:
D>Да и софта нормального нет, наиболее эффективным для меня был Modelmaker но он для паскаля и с#, Enterprise Architect вообще какой то монстр, работая с ним надо переключатся только на него, опять же сильно отвлекает от собственно задачи
попробуйте plantuml. на входе исходник в довольно простой форме, на выходе изображение. может работать из командной строки, может быть подключен плагином к разным редакторам (eclipse, sublime, ещё какие-то), есть и отдельные редакторы.
оценить можно по онлайн версии, там и устанавливать ничего не надо: http://codeuml.com/
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования).
Полезен при составлении иллюстраций к ТЗ (иногда одна схема с успехом заменяет пару листов текста) или при рисовании на доске в ходе обсуждения.
На мой взгляд, схема предназначенная для использования внутри команды не должна требовать для своего понимания детального знания uml. На диаграммах не должно быть разных типов блоков, толстых-пунктирных стрелок с двойным ромбом и прочей магии. Если до такого дошло — диаграмма годится только для сопроводительной документации, и то в ней в обязательном порядке нужно подписывать разные типы стрелок (блоков), или размещать легенду c объяснениями в самом видном месте.
На практике большая часть диаграмм — это схемы данных (зависимостей), actor model и flow model. При обсуждении изредка всплывает sequence diagram, но это уже экзотика.
Здравствуйте, diez_p, Вы писали:
C>>Ко всем кто пишет, что UML в виде диаграмм классов у них часто нужен и активно используется — пишите свои компании, пожалуйста. Буду знать с кем в будущем НЕ работать. _>Простите, а как вы шарите знание о структуре проекта? Если вы так рьяно отрицаете UML, то вам в такие компании даже и не надо
Ага. Мы предпочитаем что-нибудь удобное.
_>Вот пример приходит новый сотрудник или кто-то другой хочет разобраться поверхностно в том, как работает 200к локов. Откуда ему черпать знания?
Из текстового описания. С содержанием, кратким обзором и описанием модулей.
Диаграмма классов из UML — совершенно не нужна. Она слишком низкоуровневая, чтобы понять крупную структуру проекта и слишком высокоуровневая, чтобы понять детали реализации.
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования).
Ко всем кто пишет, что UML в виде диаграмм классов у них часто нужен и активно используется — пишите свои компании, пожалуйста. Буду знать с кем в будущем НЕ работать.
Здравствуйте, akava, Вы писали:
A>А можно, плиз, конкретнее? Вопрос не в невозможности такого (в это я охотно верю), а в вопросе почему UML для этих областей подходит лучше чем что-то еще. Например XML, DSL.
Исторические причины. Ряд крупных компаний в духе Ericsson-а в свое время подсел на UML Room. Другие использовали SDL и UML был вариантом миграции с него.
Кто-то поддался рекламе.
A>Примером может служить SOAP + WSDL. Идея та же, но без UML.
UML используется телкомом, военными, производителями периферии (например они http://global.oce.com/ ). Компании выстраивают целые процессы разработки вокруг UML и средств моделирования.
UML это не только бизнесс-приложения (WSDL и т.п.) , это и моделирование систем(смотреть SysML), real-time, embedded и прочее. Просто на просторах СНГ про это мало кто знает и еще меньше тех, кто с этим на практике сталкивается.
Когда процессы разработки в компании построены вкруг какого-то языка и набора средств моделирования, то мигрировать на что-то другое КРАЙНЕ сложно а подчас невозможно. Можно начать новый проект на чем-то новом, но существующее надо продолжать поддерживать.
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования).
Activity и State диаграммы чуть менее, чем в каждой спецификации.
Sequence и Class Diagram позволяет в целом взглянуть на кучи кода. Руками никогда не делаются, генерятся из кода в Visual Studio. Последнее время заменяется Code Map.
Еще иногда применяются специализированные для конкретной платформы component diagram.
Все остальное — бесполезное фуфло, придуманное чтобы продавать софт.
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования). А>Также опрос
Здравствуйте, Аноним931, Вы писали:
А>Здравствуйте, Donim, Вы писали:
D>>Не нужен, пытался использовать несколько раз. Намного эффективнее лист бумаги и карандаш. А>Это ведь не взаимоисключающие вещи.
Да, но UML требует изучения его, соблюдения определеных правил, изучение софта для работы с ним, это сильно отвлекает от собственно задачи. Да и софта нормального нет, наиболее эффективным для меня был Modelmaker но он для паскаля и с#, Enterprise Architect вообще какой то монстр, работая с ним надо переключатся только на него, опять же сильно отвлекает от собственно задачи. Так что для программиста пока что лучший способ держать всё в голове, документ Word с описанием важных весчей, и бумага с карандашом под клавиатурой
Здравствуйте, akava, Вы писали: A>Что еще вам приходит в голову? A>Какие UML диаграммы "выживут" после такого анализа?
Пока существует взаимодействие нескольких систем, диаграммы последовательности будут необходимы.
Диаграммы состояний также крайне полезны безотносительно применяемой внутри технологии. Вот, к примеру, в документацию по API от Office365 входит диаграмма состояний для объекта "подписка". При этом совершенно неважно, на чём там внутри написан этот сервис.
Диаграмма пакетов тоже вполне себе имеет смысл независимо от того, что является частью пакета. Ведь в ФП никто не обязывает сваливать абсолютно все функции в глобальное пространство. К примеру, в том же JS вообще нет никакого понятия пакетов (ну, до недавних версий), что никак не мешает по факту использовать пакетную структуру со всеми её атрибутами — зависимостями, делением по слоям и т.п.
Так и в ФП — вот, функция А является композицией функций X::B и Y::C, полученной при помощи вызова комбинатора Z::D.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, hrensgory, Вы писали:
>> Ага. Мы предпочитаем что-нибудь удобное. H>Поделитесь — что именно пользуете. Я сам особо UML не увлекаюсь, но H>иногда надо что-то задокументировать (как правило — E/R подобное), не H>изобретать же для этого свои обозначения )
Для ER обычно достаточно стандартных средств реверса БД, потому мы их не документируем. Какой смысл, если разработчик может нажать пару кнопок в IDE и получить ту же диаграмму.
Для тех случаев, где надо показать взаимные отношения модулей или зависимости разных объектов — используем банальные "квадратики со стрелочками". Это нужно нам, кстати, достаточно часто, но никогда именно для диаграмм классов.
Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования).
Также опрос
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования). А>Также опрос
Использовал один единственный раз в жизни, когда нужно было отрефакторить очень сложную иерархическую структуру (классов 30, объекты не считал) — один сильно умник засериализовал её в BLOB-поле базы, а надо было нормально замапить на таблицы. А там уже поверх кода наваляли выше крыши. Проголосовал за "не нужен".
2/12/2014 1:14 PM, Аноним931 пишет:
> Расскажите, пожалуйста, используете ли вы UML (Unified Modeling > Language) при проектировке ПО, насколько интенсивно, какой применяете > софт, и как вы оцениваете практическую ценность UML (исходя из опыта > использования).
Да. Очень удобно на определенном уровне описания.
Софт пофиг какой. Предпочитаю фришный.
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования).
Зависит от масштабов приложения. Нужен, вероятно, только архитекторам. А программистам в фирмах, где
используется UML соотв. нужно уметь его читать.
Не нужен, пытался использовать несколько раз. Намного эффективнее лист бумаги и карандаш.
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования). А>Также опрос
Здравствуйте, Donim, Вы писали:
D>Не нужен, пытался использовать несколько раз. Намного эффективнее лист бумаги и карандаш.
Это ведь не взаимоисключающие вещи.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, den_po, Вы писали:
_>попробуйте plantuml. на входе исходник в довольно простой форме, на выходе изображение. может работать из командной строки, может быть подключен плагином к разным редакторам (eclipse, sublime, ещё какие-то), есть и отдельные редакторы. _>оценить можно по онлайн версии, там и устанавливать ничего не надо: http://codeuml.com/
Хм, интересно, посмотрю, спасибо. С первого взгляда не увидел кодогенерации, почему мне нравится модельмейкер — это полная синхронизация с кодом (сужу с позиции программиста) т.е. определил южкейс, Activity, набросал диаграмму классов, кнопка "сделать мне красиво" и опа — готовый код. Если они поддерживали плюсы — цены бы не было
Re[6]: UML в вашей жизни проектировщика ПО
От:
Аноним
Дата:
12.02.14 13:22
Оценка:
Здравствуйте, Donim, Вы писали:
D>Хм, интересно, посмотрю, спасибо. С первого взгляда не увидел кодогенерации, почему мне нравится модельмейкер — это полная синхронизация с кодом (сужу с позиции программиста) т.е. определил южкейс, Activity, набросал диаграмму классов, кнопка "сделать мне красиво" и опа — готовый код. Если они поддерживали плюсы — цены бы не было
не, кодогенерации там нет.
без кодогенерации я обхожусь, а вот без наглядного отображения внутренностей проектов уже невмоготу. старею.
2/12/2014 4:15 PM, Donim пишет:
> С первого взгляда не увидел > кодогенерации, почему мне нравится модельмейкер — это полная > синхронизация с кодом (сужу с позиции программиста) т.е. определил > южкейс, Activity, набросал диаграмму классов, кнопка "сделать мне > красиво" и опа — готовый код. Если они поддерживали плюсы — цены бы не было
Вот этим пользоваться не советую ни в одном, ни в другом направлении. У
инструмента, как UML есть свои рамки применения, и когда им пытаются
забивать гвозди, то получается чаще всего плохо.
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования). А>Также опрос
Да и постоянно. Я вообще не понимаю как можно ревьювить дизайн без UML. В легаси коде при изменении дизайна UML тоже необходим, если меняются интерфейсы и зависимости. При дизайне и ревью дизайна UML диаграммы помогают концептуально уложить разные функциональные аспекты приложения, без промежуточной абстракции у меня это не получается сделать.
В рисовании диаграмм есть очень важное НО! диаграмма не должна быть перегружена детализацией и количеством эелементов. UML это абстракция представления некоторой функциональности приложения и ключевых абстракциях и их связей. Детально расписывать все и вся не имеет смысла.
Пользовал Enterprise architect, если для рисования UML, то UI сильно перегружен, reverse engineering делает весьма не плохо (C# code base), сейчас рисуюу в yEd (бесплатный, набор элементов минимален, но позволяет делать ), вроде тоже все ок.
Так же много рисуем на доске в квадратах, последовательностях и т.д.
Мне кажется, что UML создатели: Буч, Румбах и Якобсон изначальное хотели ввести более высокую абстракцию разработки в ПО, нежели чем кодинг. Чтобы на основе этой абстракции можно было генерить код, но на практике это не получилось. При имплементации пока не на пишешь — не узнаешь взлетит дизайн или нет, можно ли его упростить и т.д.
Опять таки наверное из этого появился DSL, что на основе некоторого абстрактного описания, можно получить работающую программу. Наверное под такое описание подойдет WF от Microsoft.
Здравствуйте, Donim, Вы писали:
D>Да, но UML требует изучения его, соблюдения определеных правил, изучение софта для работы с ним, это сильно отвлекает от собственно задачи. Да и софта нормального нет, наиболее эффективным для меня был Modelmaker но он для паскаля и с#, Enterprise Architect вообще какой то монстр, работая с ним надо переключатся только на него, опять же сильно отвлекает от собственно задачи. Так что для программиста пока что лучший способ держать всё в голове, документ Word с описанием важных весчей, и бумага с карандашом под клавиатурой
Голова имеет свойство забывать, выучить UML, я вас умоляю. Вот отвлечение от решения задачи — чисто кодерский подход. Я вообще не знаю как можно писать, не зная общих практик и подоходов в конкретном приложении. Вот из-за такого подходы и получается что залепили, вместо того чтобы изучить и написать. На счет программ, а не все ли равно в чем квадраты рисовать? Бумага и карандаш не более чем для 3-4 пометок.
А вот как описать 4-6 сущностей с 7-10 связями словами — не представляю.
Ну как бы ещё один плюс за кодогенерацю: рефакторинг, вы изменяете что то на лету, изменения существенные, меняется Activity, классы, возможно не один раз, после работы с кодом вам придется затратить столько же времени на приведение модели в соответствие с кодом, а в софте с кодогенерацией рефакторинг можно делать на уровне модели или паралельно.
А внутренности проектов все же думаю эффективнее отображать просто на бумаге, хотя бы потому что здесь вы не будете ограничены ничем.
А>не, кодогенерации там нет. А>без кодогенерации я обхожусь, а вот без наглядного отображения внутренностей проектов уже невмоготу. старею.
Здравствуйте, Donim, Вы писали:
D>Здравствуйте, Аноним, Вы писали:
D>Ну как бы ещё один плюс за кодогенерацю: рефакторинг, вы изменяете что то на лету, изменения существенные, меняется Activity, классы, возможно не один раз, после работы с кодом вам придется затратить столько же времени на приведение модели в соответствие с кодом, а в софте с кодогенерацией рефакторинг можно делать на уровне модели или паралельно.
нет, нужно не модель приводить в соответствие коду, а код переделывать под изменения модели
D>А внутренности проектов все же думаю эффективнее отображать просто на бумаге, хотя бы потому что здесь вы не будете ограничены ничем.
Здравствуйте, den_po, Вы писали:
_>нет, нужно не модель приводить в соответствие коду, а код переделывать под изменения модели
Да, в теории так, на практике выходит по другому. Опять же с точки зрения программера, осознание того что модель не работоспособная приходит часто во время дебагинга, и тут же по горячему начинаешь исправлять код, что то сочинять, что то удалять. Если бросить в этот момент всё и переключится в тот же Enterprise Architect и опа, он не соответствует коду, ой а что это за кнопочка, ой а это что ...
_>историю изменений тоже на бумаге хранить?
Нет, для этого ведь есть системы управления версиями
2/12/2014 5:21 PM, Donim пишет:
> Да, в теории так, на практике выходит по другому. Опять же с точки > зрения программера, осознание того что модель не работоспособная > приходит часто во время дебагинга, и тут же по горячему начинаешь > исправлять код, что то сочинять, что то удалять. Если бросить в этот > момент всё и переключится в тот же Enterprise Architect и опа, он не > соответствует коду, ой а что это за кнопочка, ой а это что ...
Кратко. Это происходит потому, что кто-то пытается забивать гвозди
микроскопом, а микробов разглядывать в лупу.
У каждого инструмента есть границы применения и генерация кода или
наоборот это уже за рамками границ разумного применения UML.
Здравствуйте, Vzhyk, Вы писали:
V>Кратко. Это происходит потому, что кто-то пытается забивать гвозди V>микроскопом, а микробов разглядывать в лупу. V>У каждого инструмента есть границы применения и генерация кода или V>наоборот это уже за рамками границ разумного применения UML.
Да, так и есть. Увы, зачастую проектировщик ПО и программист — это один и тот же человек.
Я например за то что бы надо мной был проектировщик. И хочю хорошую лупу. UML мне не нужен
2/12/2014 5:48 PM, Donim пишет:
> Да, так и есть. Увы, зачастую проектировщик ПО и программист — это один > и тот же человек. > Я например за то что бы надо мной был проектировщик. И хочю хорошую > лупу. UML мне не нужен
Ну если объемы-сложность кода не требуют сопроводиловки (UML здесь
просто удобен), то нафига козе баян.
Нафига тебе проектировщик? Чтобы твою зарплату на двоих разделили?
Проектировщик нужен, когда проект достаточно большой и не тривиальный..
Здравствуйте, 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 с последующим переосмыслением. Софт Dia, использую для описания взаимоотношений между классами. Лично для меня UML последний аргумент архитектора, когда для дальнейшего написания кода требуется формализация. Практическая ценность высокая, так как без UML можно зайти в тупик и не выйти.
Использую UML для иллюстрации дизайн-решений. В основном, использую диаграмму классов и диаграмму последовательности. Иногда строю диаграмму последовательности, когда нужно разобраться в коде. Для построения диаграмм использую MS Visio или бумагу и ручку.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Donim, Вы писали: D>>Хм, интересно, посмотрю, спасибо. С первого взгляда не увидел кодогенерации, почему мне нравится модельмейкер — это полная синхронизация с кодом (сужу с позиции программиста) т.е. определил южкейс, Activity, набросал диаграмму классов, кнопка "сделать мне красиво" и опа — готовый код. S>"хайп вокруг UML быстро поутих, когда выяснилось, что из неправильных диаграмм генерируется неправильный код"
А вот, кстати, интересный вопрос поднялся. Что мол UML, теоретически, избавляет нас от написания шаблонного, boilerplate, кода и позволяет генерировать его из высокоуровневых диаграмм.
Но это было давно. Лет 20 назад. У нас появилась куча инструментов, которые решают ту же задачу.
Например с помощью лямбд можно существенно упростить большинство GoF паттернов. Т.е. часть зависимостей между классами на диаграмме классов исчезла. В итоге, если мы не будем злоупотреблять наследованием, диаграмма классов нам может и не понадобиться. Хватит диаграммы пакетов и связей между ними.
Linq, async/await и проч. (монады) избавляют нас еще от кучи лишнего кода и классов. Convention over configuration позволяет не писать еще чуть-чуть куда.
С помощью DSL, кодогенерации и метапрограммирования можно избавиться от кучи boilerplate кода.
Что я предлагаю? Предлагаю я подумать о том, какие типы UML диаграмм можно представить в виде кода без существенной потери выразительности. С помощью функционального подхода, метапрограммирования.
Например, небольшие диаграммы состояний можно описать с помощью DSL или кода без (существенной) потери выразительности.
Что еще вам приходит в голову?
Какие UML диаграммы "выживут" после такого анализа?
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования).
Очень часто использую Sequence diagram, сгенерированную упомянутым здесь PlantUML. В основном, для донесения идей до других программистов (редко) или для разъяснения отдельных важных вещей инженерам (часто). Это гораздо проще, чем пытаться объяснять тонкости взаимодействия словами.
Для генерации диаграмм по коду есть doxygen, например. А идея генерировать код из UML... вообще не понимаю, как ее кто-то мог воспринять всерьез.
Здравствуйте, landerhigh, Вы писали:
L>Для генерации диаграмм по коду есть doxygen, например. А идея генерировать код из UML... вообще не понимаю, как ее кто-то мог воспринять всерьез.
Есть области где генерится дофига кода. Сотни мегабайт кода. И из UML. Правда допиленного и со своей семантикой но тем не менее из UML. Причем делают это уже лет 15 а то и побольше.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Аноним931, Вы писали:
А>>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования). C>Ко всем кто пишет, что UML в виде диаграмм классов у них часто нужен и активно используется — пишите свои компании, пожалуйста. Буду знать с кем в будущем НЕ работать.
Простите, а как вы шарите знание о структуре проекта? Если вы так рьяно отрицаете UML, то вам в такие компании даже и не надо
Вот пример приходит новый сотрудник или кто-то другой хочет разобраться поверхностно в том, как работает 200к локов. Откуда ему черпать знания?
On 21.02.2014 14:13, Cyberax wrote:
> C>>Ко всем кто пишет, что UML в виде диаграмм классов у них часто нужен > и активно используется — пишите свои компании, пожалуйста. Буду знать с > кем в будущем НЕ работать. > _>Простите, а как вы шарите знание о структуре проекта? Если вы так > рьяно отрицаете UML, то вам в такие компании даже и не надо > Ага. Мы предпочитаем что-нибудь удобное.
Поделитесь — что именно пользуете. Я сам особо UML не увлекаюсь, но
иногда надо что-то задокументировать (как правило — E/R подобное), не
изобретать же для этого свои обозначения )
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, akava, Вы писали: A>>Что еще вам приходит в голову? A>>Какие UML диаграммы "выживут" после такого анализа? S>Пока существует взаимодействие нескольких систем, диаграммы последовательности будут необходимы. S>Диаграммы состояний также крайне полезны безотносительно применяемой внутри технологии. Вот, к примеру, в документацию по API от Office365 входит диаграмма состояний для объекта "подписка". При этом совершенно неважно, на чём там внутри написан этот сервис. S>Диаграмма пакетов тоже вполне себе имеет смысл независимо от того, что является частью пакета. Ведь в ФП никто не обязывает сваливать абсолютно все функции в глобальное пространство. К примеру, в том же JS вообще нет никакого понятия пакетов (ну, до недавних версий), что никак не мешает по факту использовать пакетную структуру со всеми её атрибутами — зависимостями, делением по слоям и т.п. S>Так и в ФП — вот, функция А является композицией функций X::B и Y::C, полученной при помощи вызова комбинатора Z::D.
Это UML с точки зрения документирования. На эту сторону UML никто не нападет. Другое дело, что с такой точки зрения UML стал слишком формальным.
Ведь "квадратики/кружочки со стрелочками" неплохо заменяют UML во всех случаях, что ты указал. Эффект тот же, но я бы побоялся назвать это UML.
Мне кажется, что формальный UML важен именно для кодогенерации. И именно этот аспект я хотел обсудить. По этому вопросы есть мысли? У меня кроме идеи ничего в голову не пришло. Не так часто "UML"-диаграммы использую.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, landerhigh, Вы писали:
L>>Для генерации диаграмм по коду есть doxygen, например. А идея генерировать код из UML... вообще не понимаю, как ее кто-то мог воспринять всерьез. _O_>Есть области где генерится дофига кода. Сотни мегабайт кода. И из UML. Правда допиленного и со своей семантикой но тем не менее из UML. Причем делают это уже лет 15 а то и побольше.
А можно, плиз, конкретнее? Вопрос не в невозможности такого (в это я охотно верю), а в вопросе почему UML для этих областей подходит лучше чем что-то еще. Например XML, DSL.
Примером может служить SOAP + WSDL. Идея та же, но без UML.
On 21.02.2014 15:23, Cyberax wrote:
> Для ER обычно достаточно стандартных средств реверса БД, потому мы их не > документируем. Какой смысл, если разработчик может нажать пару кнопок в > IDE и получить ту же диаграмму.
Я не случайно написал "подобное" — это именно что не чистый E/R, надо
допустим заодно показать наследование и т.п.
> Для тех случаев, где надо показать взаимные отношения модулей или > зависимости разных объектов — используем банальные "квадратики со > стрелочками". Это нужно нам, кстати, достаточно часто, но никогда именно > для диаграмм классов. > > Ещё очень часто нужны диаграммы состояний.
А обозначения свои какие-то используете? Если да, то почему не УМЛ?
Здравствуйте, hrensgory, Вы писали:
H>Я не случайно написал "подобное" — это именно что не чистый E/R, надо H>допустим заодно показать наследование и т.п.
Наследование в БД? Конечно, оно бывает, но достаточно редко.
>> Ещё очень часто нужны диаграммы состояний. H>А обозначения свои какие-то используете? Если да, то почему не УМЛ?
В диаграммах состояний? Там кроме квадратиков со стрелочками ничего и нет, собственно.
Вот диаграммы последовательностей — достаточно полезные.
Здравствуйте, akava, Вы писали:
A>Мне кажется, что формальный UML важен именно для кодогенерации. И именно этот аспект я хотел обсудить. По этому вопросы есть мысли? У меня кроме идеи ничего в голову не пришло. Не так часто "UML"-диаграммы использую.
Формальный UML НЕ НУЖЕН для кодогенерации. Реальная кодогенерация использует расширения и дополнения UML. Код в большинстве случаев пишется на target языке (C/C++/Java/etc) Есть специфические генераторы BPMN/WSDL/XSD. В этих случаях вообще следуют семантике target языка а UML используется сугубо для визуализации.
C>Для тех случаев, где надо показать взаимные отношения модулей или зависимости разных объектов — используем банальные "квадратики со стрелочками". Это нужно нам, кстати, достаточно часто, но никогда именно для диаграмм классов.
Ну вообще UML диаграммами классов не ограничивается.
C>Ещё очень часто нужны диаграммы состояний.
А говорите не используете.
"Вы не любите кошек? Вы просто не умеете их готовить"
Вообще очень часто люди воспринимают UML как нечно монстроузное, с кучей всяких непонятных тонокстей и т.д. Хотя выше я уже озвучивал, диаграмма не должна быть перегружена детализацией. И ваши квадраты не что иное как те же самые классы.
Я например слабо представляю как описать ключевые иерархии, последовательности вызвов, переброс из потока в поток и т.д.
У меня например нет и никогда не будет диаграм где 15 классов, с кучай стрелок и полным публичным контрактом.
Должно быть отражено, только все самое нужное и важное в данном функциональном аспекте модуля или ПО, все остальное лишнее.
Здравствуйте, diez_p, Вы писали:
C>>Для тех случаев, где надо показать взаимные отношения модулей или зависимости разных объектов — используем банальные "квадратики со стрелочками". Это нужно нам, кстати, достаточно часто, но никогда именно для диаграмм классов. _>Ну вообще UML диаграммами классов не ограничивается.
Тем не менее, под UML понимается именно диаграмма классов.
_>"Вы не любите кошек? Вы просто не умеете их готовить" _>Вообще очень часто люди воспринимают UML как нечно монстроузное, с кучей всяких непонятных тонокстей и т.д.
Оно так и есть.
_>Хотя выше я уже озвучивал, диаграмма не должна быть перегружена детализацией. И ваши квадраты не что иное как те же самые классы.
Диаграммов на уровене классов у меня нет нигде.
_>Я например слабо представляю как описать ключевые иерархии, последовательности вызвов, переброс из потока в поток и т.д.
Иерархий тоже почти нет. Последовательности вызовов — а зачем?
_>Я например слабо представляю как описать ключевые иерархии, последовательности вызвов, переброс из потока в поток и т.д.
Сейчас, когда термины "обсервер" или там "агрегация" или "visior" или "IoC" уже не вызывают ни у кого дикой попаболи, я, например, слабо представляю зачем может понадобиться описывать ключевые иерархии, последовательности вызовов и особенно переброса из потока в поток. Все обычно ясно при первом (втором) взгляде на код. Если не ясно, то имеем дело с говнокодом, которому UML не поможет.
С другой стороны, диаграмма состояний КА — вещь нужная, т.к. современные ЯП общего назначения хреновато подходят для реализации КА, если не сказать большего.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, diez_p, Вы писали:
C>>>Для тех случаев, где надо показать взаимные отношения модулей или зависимости разных объектов — используем банальные "квадратики со стрелочками". Это нужно нам, кстати, достаточно часто, но никогда именно для диаграмм классов. _>>Ну вообще UML диаграммами классов не ограничивается. C>Тем не менее, под UML понимается именно диаграмма классов.
Ну вообще UML содержит основные диаграммы и вспомогательные, загляните в стандарт.
_>>"Вы не любите кошек? Вы просто не умеете их готовить" _>>Вообще очень часто люди воспринимают UML как нечно монстроузное, с кучей всяких непонятных тонокстей и т.д. C>Оно так и есть.
Значит вы просто не умеете пользоваться
_>>Хотя выше я уже озвучивал, диаграмма не должна быть перегружена детализацией. И ваши квадраты не что иное как те же самые классы. C>Диаграммов на уровене классов у меня нет нигде. _>>Я например слабо представляю как описать ключевые иерархии, последовательности вызвов, переброс из потока в поток и т.д. C>Иерархий тоже почти нет. Последовательности вызовов — а зачем?
А скажите в личку вашу компанию и предметную область.
Вот тут два варианты, либо проект для специфичной области, либо плохой дизайн. Механизм наследования дает полиморфизм АТД, в ООП технологиях это делается на уровне платформы, без доп приседаний.
Как пример. Стримовый слой поставки данных.
Есть одна абстракция IDataNotifier, есть несколько абстракций провайдеров этих данных, есть абстрактная фабрика которая инстанцирует слой поставки данных, в зависимости от транспорта.
IDataNotifier имеет несколько имплементаций. Есть имплементации IDataNotifier которые оборачивают другие IDataNotifier. Есть ряд менеджеров которые рулят этой поставкой данных.
Есть другие примеры реализации тех же слоев поставки данных, когда несколько диаграмм, дают понимание того как этот код сделан.
Диаграммы классов, последовательностей, объектов.
Во всех этих проектах, код написан по качеству примерно как в Parallels и JetBrains в их хороших проектах.
Глядя только в код, достаточно сложно понять почему именно таким образом код решает поставленную задачу.
Диаграммы позволяют под разными аспектами посмотреть на идею того, как сделано. Они уменьшают вероятность того, что кто-то залепит гумно в этот код, только потому что ему надо побыстрее сделать задачу, а главную идею он не понял. Даиграммы доносят идею до разработчиков, которые этот код не писали, идею им объяснять не надо. На практике диаграммы, как правило очень редко меняются, чаще их читают, чем модифицируют и уж тем более пишут.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, diez_p, Вы писали:
L>я, например, слабо представляю зачем может понадобиться описывать ключевые иерархии, последовательности вызовов и особенно переброса из потока в поток. Все обычно ясно при первом (втором) взгляде на код. Если не ясно, то имеем дело с говнокодом, которому UML не поможет.
Лихо вы судите А если объем кода, мягко говоря не мал?
Там даже со второго раза не разобраться и с третьего, потому что его тупо много и код сложный и не говнокод
L>>я, например, слабо представляю зачем может понадобиться описывать ключевые иерархии, последовательности вызовов и особенно переброса из потока в поток. Все обычно ясно при первом (втором) взгляде на код. Если не ясно, то имеем дело с говнокодом, которому UML не поможет.
_>Лихо вы судите А если объем кода, мягко говоря не мал?
Какая разница?
_>Там даже со второго раза не разобраться и с третьего, потому что его тупо много и код сложный и не говнокод
Если это не говнокод, то разделение сущностей и связи между ними очевидны и видны сразу. Если не видны, то это таки говнокод.
Здравствуйте, diez_p, Вы писали:
C>>Иерархий тоже почти нет. Последовательности вызовов — а зачем? _>А скажите в личку вашу компанию и предметную область. http://moleculo.com , http://illumina.com , http://clusterk.com — биоинформатика и облачные вычисления.
_>Вот тут два варианты, либо проект для специфичной области, либо плохой дизайн. Механизм наследования дает полиморфизм АТД, в ООП технологиях это делается на уровне платформы, без доп приседаний.
"Наследование — не нужно" (c). Точнее, нужно в очень редких случаях и, в основном, в виде реализации интерфейсов.
_>IDataNotifier имеет несколько имплементаций. Есть имплементации IDataNotifier которые оборачивают другие IDataNotifier. Есть ряд менеджеров которые рулят этой поставкой данных.
И для чего тут нужен UML? IDataNotifier — интерфейс нотификатора данных (что за данные — смотрим в каменты). Оборачивающая реализация: IProxyDataNotifier или IDataNotifierWrapper.
_>Глядя только в код, достаточно сложно понять почему именно таким образом код решает поставленную задачу.
Для этого пишется короткая текстовая дока.
_>Диаграммы позволяют под разными аспектами посмотреть на идею того, как сделано. Они уменьшают вероятность того, что кто-то залепит гумно в этот код, только потому что ему надо побыстрее сделать задачу, а главную идею он не понял. Даиграммы доносят идею до разработчиков, которые этот код не писали, идею им объяснять не надо. На практике диаграммы, как правило очень редко меняются, чаще их читают, чем модифицируют и уж тем более пишут.
Не доносят. Скорее наоборот.
Здравствуйте, landerhigh, Вы писали:
L>Сейчас, когда термины "обсервер" или там "агрегация" или "visior" или "IoC" уже не вызывают ни у кого дикой попаболи, я, например, слабо представляю зачем может понадобиться описывать ключевые иерархии, последовательности вызовов и особенно переброса из потока в поток. Все обычно ясно при первом (втором) взгляде на код. Если не ясно, то имеем дело с говнокодом, которому UML не поможет.
В определенных областях sequence diagrams используются для генерации тестов и проверки поведения системы требованиям.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, landerhigh, Вы писали:
L>>Сейчас, когда термины "обсервер" или там "агрегация" или "visior" или "IoC" уже не вызывают ни у кого дикой попаболи, я, например, слабо представляю зачем может понадобиться описывать ключевые иерархии, последовательности вызовов и особенно переброса из потока в поток. Все обычно ясно при первом (втором) взгляде на код. Если не ясно, то имеем дело с говнокодом, которому UML не поможет.
_O_>В определенных областях sequence diagrams используются для генерации тестов и проверки поведения системы требованиям.
Sequence diagram, в отличие от диаграмм классов, полезны и сами по себе, т.к. как минимум позволяют наглядно обосновать те или иные решения, представив временнУю схему взаимодействия компонентов.
Только наиболее эффективное их использование подразумевает их автоматическую генерацию из кода или псевдокода (как в PlantUML). Рисовать их мышкой в целях последующей кодогенерации есть извращение.
