Расскажите, пожалуйста, используете ли вы 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 соотв. нужно уметь его читать.
Здравствуйте, Аноним931, Вы писали:
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования).
Полезен при составлении иллюстраций к ТЗ (иногда одна схема с успехом заменяет пару листов текста) или при рисовании на доске в ходе обсуждения.
На мой взгляд, схема предназначенная для использования внутри команды не должна требовать для своего понимания детального знания uml. На диаграммах не должно быть разных типов блоков, толстых-пунктирных стрелок с двойным ромбом и прочей магии. Если до такого дошло — диаграмма годится только для сопроводительной документации, и то в ней в обязательном порядке нужно подписывать разные типы стрелок (блоков), или размещать легенду c объяснениями в самом видном месте.
На практике большая часть диаграмм — это схемы данных (зависимостей), actor model и flow model. При обсуждении изредка всплывает sequence diagram, но это уже экзотика.
Не нужен, пытался использовать несколько раз. Намного эффективнее лист бумаги и карандаш.
А>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования). А>Также опрос
Здравствуйте, Donim, Вы писали:
D>Не нужен, пытался использовать несколько раз. Намного эффективнее лист бумаги и карандаш.
Это ведь не взаимоисключающие вещи.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А>Здравствуйте, Donim, Вы писали:
D>>Не нужен, пытался использовать несколько раз. Намного эффективнее лист бумаги и карандаш. А>Это ведь не взаимоисключающие вещи.
Да, но UML требует изучения его, соблюдения определеных правил, изучение софта для работы с ним, это сильно отвлекает от собственно задачи. Да и софта нормального нет, наиболее эффективным для меня был Modelmaker но он для паскаля и с#, Enterprise Architect вообще какой то монстр, работая с ним надо переключатся только на него, опять же сильно отвлекает от собственно задачи. Так что для программиста пока что лучший способ держать всё в голове, документ Word с описанием важных весчей, и бумага с карандашом под клавиатурой
Здравствуйте, Donim, Вы писали:
D>Да и софта нормального нет, наиболее эффективным для меня был Modelmaker но он для паскаля и с#, Enterprise Architect вообще какой то монстр, работая с ним надо переключатся только на него, опять же сильно отвлекает от собственно задачи
попробуйте plantuml. на входе исходник в довольно простой форме, на выходе изображение. может работать из командной строки, может быть подключен плагином к разным редакторам (eclipse, sublime, ещё какие-то), есть и отдельные редакторы.
оценить можно по онлайн версии, там и устанавливать ничего не надо: http://codeuml.com/
Здравствуйте, 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.
