Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: Galogen от 18 Февраля 2013, 22:51:11
-
Один товарищ сказал примерно следующее: "UML - это вагон, которые отцепили от состава и оставили. Ну и он катится по инерции не замечая, что движется в тупик".
Когда я высказал подобную мысль на иностранном форуме, то получил одно одобрительное сообщение и ссылку на SEMAT (детище Ивара Якобсона).
А чем вам не нравится UML? Может мы докажем или не докажем теорему от противного (ну мы все типа Uml lovers) ;)
-
Сама постановка вопроса мне кажется странной.
То же самое что и "Почему вам не нравится гаечный ключ?"
Не нравится ключ, бери отвертку. Аналогично с UML.
Может дело в применении? Что если не пихать UML куда надо и не надо, то и не тупик совсем?:)
-
Сама постановка вопроса мне кажется странной.
То же самое что и "Почему вам не нравится гаечный ключ?"
Не нравится ключ, бери отвертку. Аналогично с UML.
Да согласен, не удачно назвал. Может, Почему вы не хотите использовать UML?
Может дело в применении?
Да именно.
Что если не пихать UML куда надо и не надо, то и не тупик совсем?:)
Ну UML - это язык. А мастерство использования языка зависит от того, кто использует вероятно
-
>> Почему вы не хотите использовать UML?
Может быть: "В каких случаях UML вреден"? ;)
-
>> Почему вы не хотите использовать UML?
Может быть: "В каких случаях UML вреден"? ;)
Можно и так. Исправляю тогда
-
Если считать UML французским языком, то наша задача в каких случаях вреден французский язык?
Ваши друзья не любят французский и каждый раз, когда вы пытаетесь его использовать, они бьют тебя по лбу. В таких случаях он крайне вреден для здоровья. Но если вы поехали на экскурсию в Париж, то всегда можете спросить у прохожего француза дорогу на Нотер-Дам :)
Я думаю UML будет вреден, если вы попытаетесь описать процессы химической кинетики для демонстрации ваших выводов на научной конференции химиков.
Хотя если вы будете формализовать требования к системе моделирования таких процессов, UML может быть довольно полезен. Буду доказывать в этом году со своим дипломником.
-
сообщение устарело
-
Лично мое мнение такое. UML очень полезен когда надо развеять "туман войны" над разрабатываемым продуктом. Когда при минимуме затрат нужно максимально охватить структуру и реальную желаемую пользу от разработки, показать заказчику что мы понимаем, какой продукт ему нужен и что мы сделаем то что надо.
И соответственно наоборот, чем глубже и подробнее мы ныряем в задачу, полируя надфилем фюзеляж нашего продукта, тем меньше нужды в UML.
-
"UML - это вагон, которые отцепили от состава и оставили. Ну и он катится по инерции не замечая, что движется в тупик".
Интересная формулировка. И всё-таки не вполне ясно, что скрывается за этой метафорой. Изолированность UML-моделей от прочих артефактов проекта, несогласованность с ними? Или более глобально - некий грядущий кризис применения UML в IT-индустрии вообще, замену его другим стандартом? А каким?
Основная проблема UML, как мне сейчас представляется, это известная проблема семантического разрыва, то есть невозможность гладкого, плавного перевода (можно сказать, компиляции) в язык программирования высокого уровня (а еще лучше, в машинный код :)).
-
UML очень полезен когда… при минимуме затрат нужно максимально охватить структуру и реальную желаемую пользу от разработки, показать заказчику что мы понимаем, какой продукт ему нужен и что мы сделаем то что надо.
Очень интересно. Каким образом вам удаётся сделать это с помощью UML?
-
"В каких случаях UML вреден"?
В тех, когда его использует недостаточно опытный в области разработки и управления требованиями специалист.
UML, на мой взгляд, тем более эффективен, чем выше квалификация применяющего его человека. Начинающим аналитикам он скорее вреден.
-
А чем вам не нравится UML? Может мы докажем или не докажем теорему от противного (ну мы все типа Uml lovers) ;)
О вреде не скажу, это всего лишь инструмент, который можно использовать по-разному.
Но мне, например, очень не нравятся все эти трудноразличимые стрелочки, навязывание особых значений разным начертаниям шрифта и символам пунктуации, а также общая ориентированность нотации на прошлый век (чёрно-белые диаграммы, предназначенные для печати на бумаге).
В UML используется много мелких текстовых обозначений, которые убивают саму идею визуального представления и фактически превращают диаграммы в плохо структурированный текст, который трудно читать, и при чтении которого очень легко ошибиться.
Спецификация языка разбухла уже до двух книг суммарным объёмом больше чем в 1000 страниц. Это делает его очень узкоспециализированным. Я думаю, применимость UML как формального языка, нотацию которого нужно специально изучать и строго соблюдать, очень ограничена.
Лично я использую названия диаграмм из UML, никогда фактически не соблюдая нотацию. Для меня UML - это прежде всего способ обмена информацией между людьми. Удачные (с моей точки зрения, конечно) элементы я использую, а неудачные игнорирую.
-
P.S. Если Вы не против, я скопирую ваше сообщение к себе в блог, разумеется с ссылкой на ваш блог. Красивые и емкие образы.
Спасибо, за ваш комментарий. Я не против, если вы полагаете, что этот текст достоин копирования, пожалуйста.
Не соглашусь с вашей оценкой UML. Во-первых, UML и задумывался как унифицированный язык, то есть язык что-то объединяющий. На мой взгляд он объединяет структурные, поведенческие и коммуникационные особенности системы.
Во-вторых, считать UML единственной альтернативой конечно нельзя. Хотя реально пока другой пока нет.
-
И соответственно наоборот, чем глубже и подробнее мы ныряем в задачу, полируя надфилем фюзеляж нашего продукта, тем меньше нужды в UML.
Это как-то очень похоже на занятия единоборствами типа айкидо. Чтобы получить пользу, вам нужно заниматься 5, а лучше 10 лет.
Но как-то хочется сразу и много
-
Интересная формулировка. И всё-таки не вполне ясно, что скрывается за этой метафорой.
Я тоже не осознаю эту метафору, но видимо подразумевалось, что еще немного и UML уйдет на обочину как IDEF и им подобные...
Основная проблема UML, как мне сейчас представляется, это известная проблема семантического разрыва, то есть невозможность гладкого, плавного перевода (можно сказать, компиляции) в язык программирования высокого уровня (а еще лучше, в машинный код :)).
А мне кажется он и не должен этого обеспечивать просто так, иначе UML превращается в еще один язык программирования универсального типа, со всеми его достоинствами и недостатками. UML - это не язык программирования. Это ОО язык моделирования, нравится нам это или нет.
В UML на мой взгляд нативно не поддержан системный подход, он остается за кадром в голове того, что использует UML. Вместе с тем он типа претендует на некоторую универсальность, хотя говорит о унифицированности, что воспринимается часто как синонимы
-
Но мне, например, очень не нравятся все эти трудноразличимые стрелочки, навязывание особых значений разным начертаниям шрифта и символам пунктуации, а также общая ориентированность нотации на прошлый век (чёрно-белые диаграммы, предназначенные для печати на бумаге).
А что еще за трудно различимые стрелочки? Ты как различаешь Е от Ё или И от Й - это сложно для тебя? А каково чеху или французу или немцу с умляутами ...
Начертание шрифтов? Это ты имеешть в виду абстрактный класс или конкретный
А что за символы пунктуации? [] / {} - эти?
Про черно белость и соглашусь и нет, порой такую попугаистость на диаграммах видишь - впору застрелиться
В UML используется много мелких текстовых обозначений, которые убивают саму идею визуального представления и фактически превращают диаграммы в плохо структурированный текст, который трудно читать, и при чтении которого очень легко ошибиться.
будет проще, если ты приведешь небольшие примерчики
Спецификация языка разбухла уже до двух книг суммарным объёмом больше чем в 1000 страниц. Это делает его очень узкоспециализированным. Я думаю, применимость UML как формального языка, нотацию которого нужно специально изучать и строго соблюдать, очень ограничена.
А разве другой язык не следует изучать? Сколько лет пришлось изучать русский? А иностранный? Но я согласен, когда спецификация так велика, то понять язык маловероятно правильно когда-либо
Лично я использую названия диаграмм из UML, никогда фактически не соблюдая нотацию. Для меня UML - это прежде всего способ обмена информацией между людьми. Удачные (с моей точки зрения, конечно) элементы я использую, а неудачные игнорирую.
Главное, чтобы другие тебя понимали. И если изучая язык независимо от тебя, они легко понимают твои адаптированные диаграммы, может это не так уж и плохо?
-
Очень интересно. Каким образом вам удаётся сделать это с помощью UML?
Я один раз столкнулся с ситуацией когда одна ДВИ нарисованная за час в Rational Rose совершила прорыв в переговорах, находившихся в тупике уже несколько недель. Она предельно наглядно выявила точки непонимания между заказчиком и подрядчиком и буквально за пару дней все вопросы были решены и дальше дело пошло хорошо и без UML.
Вот это я и имел в виду. К сожалению более подробной статистики у меня нет, но если с выявлением ролей и полезной активности UML справляется успешно, почему бы и не использовать его?
-
сообщение устарело
-
Про "Унифицированный язык, что-то объединяющий" и обоснование моей позиции я написала подробнее. http://edu.reqcenter.pro/?p=3505 Лирика скорее для себя, можете первые два абзаца пропустить.
С интересом прочту опровержение моей точки зрения, подкрепленной цитатами и ссылками на различные исследования.
Пожалуй, возразить нечего. А анализ очень интересный.
Лишь миллиметровое замечание
"Для ссылки в научной работе, в соответствии с ГОСТ 7.1-2003, правильно использовать"
ГОСТ 7.1-2003 «Библиографическая запись. Библиографическое описание», а следует использовать ГОСТ Р 7.0.5-2008 «Библиографическая ссылка» (http://ru.wikisource.org/wiki/%D0%93%D0%9E%D0%A1%D0%A2_%D0%A0_7.0.5-2008)
-
Не сочтите за назойливость и педантство, но
Мадорская Ю.М. Неожиданно про UML… История и проблемы. [электронный ресурс]/Ю.М. Мадорская, 2013. — Режим доступа: http://www.reqcenter.pro, свободный. — Загл. с экрана
сейчас должно выглядеть как
Мадорская Ю.М. Неожиданно про UML… История и проблемы [Электронный ресурс] // ReqCenter.pro Согласованные знания для практического использования, 2013. URL: http://edu.reqcenter.pro/?p=3505 (дата обращения: 21.02.2013)
или
Мадорская Ю.М. Неожиданно про UML… История и проблемы [Электронный ресурс], 2013. URL: http://edu.reqcenter.pro/?p=3505 (дата обращения: 21.02.2013)
-
сообщение устарело
-
сообщение устарело
-
Не сочту! Большое спасибо за помощь! Ужасно не люблю составлять эти ссылки.
Не реально эти требования по электронным ссылкам вообще запутаны.
-
По теме есть две статьи Алекса Белла о "лихорадке UML", опубликованные в ACM Queue: 1 (http://queue.acm.org/detail.cfm?id=984495), 2 (http://queue.acm.org/detail.cfm?id=1053347).
По SEMATу вчера было выступление в МГУ Б. А. Позина, возглавляющего российский филиал SEMAT. SEMAT ортогонален нотациям и преследует, как мне кажется, другие цели. В том же ACM Queue появился [рекламный)] материал о SEMATовской книжке: 3 (http://queue.acm.org/detail.cfm?id=2389616).
-
сообщение устарело
-
Спасибо за ссылки! Подтвердили все гипотезы, написанные в статье.
Еще раз внимательно перечитал вашу статью. Заинтересовало открытие ШНоля, в чем вы видите здесь аналогию?
Далее вы цитируете, что производя объединение трех МЕТОДОВ, основатели UML столкнулись с трудностями. И решили стандартизировать нотацию.
Т.е. по сути создали язык, метод же его использования заложен в RUP или ICONIX, хотя RUP это же развитие Objectory от Якобсона, если я не ошибаюсь. Понимаю, метод остался за рамками языка и передан куда-то выше, ну вот мы видим в SEMAT. Правильно я понимаю?
Не совсем понятен вывод о влиянии понятия Клиент Абонент Заказчик услуг на архитектуру системы и частности языка UML. Что есть архитектура UML? Совокупность правил преобразования А в Б?
-
сообщение устарело
-
Попробуйте, пожалуйста, точнее сформулировать вопросы. Не совсем понятно, что именно Вы хотите спросить.
Я что-то сам уже не понял, что хотел спросить:)
Наверное, я хотел бы отметить, что может нет никакой проблемы UML, а есть проблема самого метода ООАП. На эту тему вот пост http://askofen.blogspot.ru/2011/11/1.html. Я вначале даже пытался найти возражения, но ведь реально, есть системный подход и системные методы.
А проблема использования нотаций неправильно или неверная интерпретация моделей, не уникальна для UML. Казалось бы, ну что сложного в IDEF0. А попробуйте порой решить, эта входящая стрелка действительно должна быть управлением? Или механизмом? А переход к DFD видимо производит у студентов когнитивный взрыв. Потому я UML стараюсь не преподавать сразу, делаю паузу и вообще отдаю это другому преподавателю :)