Чем дальше я сталкиваюсь с проектированием ПО, создании и описании его архитектуры, попытками воссоздать структуру и архитектуру ПО, тем больше для меня становиться очевидным тот факт что UML никуда не годен По крайней мере по моим рассуждениям, он как минимум не удобен, а то и вовсе не информативен в той степени какой хотелось бы...
Во первых, я понимаю что UML строго ориентирован на то что его будут печатать и вставлять документы. Мне часто этого не нужно, и многим это не нужно, будь это средство описания и отображения более интерактивно, я бы был весьма за, в ущерб его не пригодности к выдаче на бумажный лист. Мне очень часто хотелось бы видеть связи между классами и структурам, а иногда даже файлами, причём так чтобы уровень отображения связей я мог выбрать прямо на этапе просмотра. Зачастую информация о содержании класса, его методах и прочем, является вторичным и может быть вовсе не нужно на диаграмме классов, если такая диаграмма в её сущ. виде вовсе нужна. Я не сомневаюсь что описание класса нужно, но не в таком виде и не так. Да и вовсе зачастую реализации UML мне кажутся не удобными к пользованию и не логичными. Плотность информации жутко низкая, зачастую приходится довольно долго ковыряться по всей модели, лазить по этим каталогам чтобы найти то что нужно... очень явно не хватает интерактивности. При том каждый архитектор или именуемый им, как я вижу, использует тот же RRose в его понимании нотации, и пытается выразится каждый раз своими методами в тех ограничениях что его запихали.. зачастую вручив человеку лист бумаги можно получить куда более информативный документ. Может эта ограничивающая и организующая нотация, которая вроде бы всем ясна (но каждый думает по своему) изживает себя? есть ли альтернативы?

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

Возможно я не очень понятно выражаюсь, просто некоторая сублимация опыта сводится на данный момент к тому, что зачастую проще взять лист бумаги и нарисовать, чем пользоваться чем-то вроде Rational Rose.

На данный момент я вовсе подумываю о некотором редакторе графов, но пока что не нашёл ничего достойного... может кто-то пробовал работать в этом направлении?

Мне интересно кто-нибудь размышляет на тему убогости UML или все готовы использовать его и считают это удобным?

кто-нибудь TouchGraph (http://sourceforge.net/projects/touchgraph/) видел? довольно интересная модель управления графом, особенно советую взглянуть wikibrowser. Это конечно далеко не всё что хотелось бы видеть и несколько не так, но идея навигации нравится...
хотя вот ява-решения как правило однотипно не удобны ;( минимум тормозят, а ещё и управление как правило не очень удобно... но сама идея навигации нравится...

Здравствуйте, nixite, Вы писали:

Из всего прочитанного я понял что не uml плох, а вы не нашли нужного инструмента для работы с ним.

N> Мне очень часто хотелось бы видеть связи между классами и структурам, а иногда даже файлами, причём так чтобы уровень отображения связей я мог выбрать прямо на этапе просмотра. Зачастую информация о содержании класса, его методах и прочем, является вторичным и может быть вовсе не нужно на диаграмме классов, если такая диаграмма в её сущ. виде вовсе нужна.
Так и не делайте, каждая диаграмма отвечает за конкретную мысль которую хотели донести до разработчика. Если информация о спецификации класса не нужна так и не надо ее вставлять, есть такое понятие перегруженность. Одна диаграмма одна мысль.

N> Я не сомневаюсь что описание класса нужно, но не в таком виде и не так. Да и вовсе зачастую реализации UML мне кажутся не удобными к пользованию и не логичными.
"Критикуешь предлагай" даешь uml 3.0!!!

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


N>Мне кажется, что необходим некоторый редактор/browser графа, позволяющий работать в нескольких плоскостях или уровнях абстракции, и позволяющий динамически определять критерии просмотра этого графа, такие как абстракции, связи, отображаемый уровень вложенности. Очень важным аспектом была бы интерактивность в смене критерия отображения информации, имхо уже пора уходить от печатности документа, я давно не видел чтобы UML печатали, думаю это архаизм.
Я вот все понять не могу может все проблемы в инструменарии? А спецификация UML здесь не причем?

N>Возможно я не очень понятно выражаюсь, просто некоторая сублимация опыта сводится на данный момент к тому, что зачастую проще взять лист бумаги и нарисовать, чем пользоваться чем-то вроде Rational Rose.
А Что нарисовать? UML диаграммы? или что ?

Здравствуйте, nixite, Вы писали:

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

Честно говоря, сама идея — взять несколько видов диаграмм (из потенциално бесконечного множества), затем их стандартизировать и заставить всех на свете пользоваться этими и только этими диаграммами — кажется порочной. Кстати, косвенно это подтверждается гораздо меньшим распространением UML, чем предрекали его апологеты.
Вообще ситуация очень похоже на ту, что наблюдается с шаблонами проектирования. О шаблонах не говорит только ленивый. Но тем не менее — можно спроектировать хорошую систему ничего не зная о шаблонах, зато нельзя её спроектировать только лишь исходя из них. Очень похоже на ситуацию с UML.
Кроме того есть ряд областей, где стандартно используются другие графические нотации — например диаграммы потоков данных, или диаграммы, описывающие базы данных, или диаграммы развёртывания. В общем то для меня очевидно, что на ту роль, на какую прочили UML — универсального языка диаграм для описания программных систем — он не годится.
Что было бы действительно интересно — это создание культуры описания систем с использованием всех широкоиспользуемых сегодня видов диаграмм, с дальнейшей возможностью формализации — что бы получить как минимум возможность верификации — а в перспективе — и генерации кода. То есть расширение графического языка таким образом, что бы он охватывал хотя бы основные области современного IT.
Что же до общения с зачазчиками в живую — то тут лучше чем карандаш и лист бумаги — до сих пор ничего не предумали. Если, конечно, заказчики — не гуру в UML

Здравствуйте, nixite,

N>Мне интересно кто-нибудь размышляет на тему убогости UML или все готовы использовать его и считают это удобным?

С некоторой периодичностью утверждаю на этом форуме, что UML абсолютно бесполезен, а также прошу всех присутсвующих опровергнуть это утверждение. Пока что всё, что я слышал, это оскорбления в адрес людей, не принимающих маркетинговой политики IBM (владельца UML), а также мнения людей, использующих UML, просто потому, что так все делают (я не видел никого, кто бы серьёзно использовал UML в своей работе, а работал я в больших фирмах с мировыми именами).
Все читали Буча, все ему верят, забывая две важные вещи: 1. Буч работает на IBM, 2. создавая свою нотацию, Буч работал над системами, размеры которых смехотворны по современным меркам. Я давно уже не видел системы, которая содержала бы менее пары сотен классов, так или иначе связанных друг с другом (а сказки про то, что это ошибка проектирования, я тоже в детсве читал). Отобразить их с помощью UML можно, но... зачем? Смотреть на диаграмму классов формата A0 на экране с разрешением 1600х1200 не самое большое удовольствие, к тому же она устаревает настолько быстро, что не хватает никакого терпения поддерживать всё это безобразие.
И это не правда, что нормальный архитектор не может удержать в голове строение системы, хоть она и состоит из нескольких тысяч классов. UML не нужен для этого. А для документации... вы что, действительно её пишите? С UML диаграммами? Не смешите народ — вас уволят за напрасную трату времени и правильно сделают.

Повторюсь и может не совсем в тему, но уж очень нравится:

Ажиотаж вокруг UML значительно поутих после того, как выяснилось, что из неправильных картинок получаются неправильные программы

OM> Что было бы действительно интересно — это создание культуры описания систем с использованием всех широкоиспользуемых сегодня видов диаграмм, с дальнейшей возможностью формализации — что бы получить как минимум возможность верификации — а в перспективе — и генерации кода. То есть расширение графического языка таким образом, что бы он охватывал хотя бы основные области современного IT.

Я и говорю, почему бы не использовать граф с удобной навигацией и прозрачной нотацией для всех целей. Начиная от activity заканчивая use case, хотя use case вообще отдельная песня и целесообразность оного сомнительна... Некоторый поименованный граф, и навигатор с возможностью поиска, выборки, фильтра по уровню вложенности и т. д. И возможность каждому элементу графа приписать описание -- табличное, текстовое, да и возможно сам исходник... Разве это не облегчило бы жизнь и удобство проектирования...

p.s. Я чаще бумагой пользуюсь если мне надо что-то придумать, а перенос это в UML кажется не удобным и нудным. А некоторый графо-построитель быстрый мне бы явно не помешал заменить и бумагу и UML. + ещё разную нотацию и цветность стрелочек и уже довольно высокая информативность и удобство навигации по сотне классов...

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

Здравствуйте, Mishka, Вы писали:

M>... Отобразить их с помощью UML можно, но... зачем? Смотреть на диаграмму классов формата A0 на экране с разрешением 1600х1200 не самое большое удовольствие, к тому же она устаревает настолько быстро, что не хватает никакого терпения поддерживать всё это безобразие.

Как и QwErTys хочу заметить, что необходимость в диаграмме, отражающей всю систему на таком уровне абстракции (сотни классов), на вряд ли может появиться. Диаграмма развертывания (deployment) и несколько диаграмм классов, где, возможно, одни и те же классы повторяются, но выступают, например, в разных ролях.
Извините, если не прав, но лично мне так удобно.

M>И это не правда, что нормальный архитектор не может удержать в голове строение системы, хоть она и состоит из нескольких тысяч классов. UML не нужен для этого. А для документации... вы что, действительно её пишите? С UML диаграммами? Не смешите народ — вас уволят за напрасную трату времени и правильно сделают.

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

На тему документации полностью согласен.

Здравствуйте, nixite, Вы писали:

N>p.s. Я чаще бумагой пользуюсь если мне надо что-то придумать, а перенос это в UML кажется не удобным и нудным. А некоторый графо-построитель быстрый мне бы явно не помешал заменить и бумагу и UML. + ещё разную нотацию и цветность стрелочек и уже довольно высокая информативность и удобство навигации по сотне классов...

Используй ARIS... Позволяет построить собственную методологию, на основе кучи диаграмм входящих в него(в том числе и UML)... Важное значение там придаётся цвету... Но в таком случае теряется самый главный плюс UML — простота и унифицированность. Унифицированность — в том смысле, что семантика диаграмм будет понятна большинству разработчиков.

Здравствуйте, QwErTys, Вы писали:

QET>"Критикуешь предлагай" даешь uml 3.0!!!
Отказать.
DSL — наше всё.

Здравствуйте, Max Matveev, Вы писали:

MM>Здравствуйте, nixite, Вы писали:

N>>p.s. Я чаще бумагой пользуюсь если мне надо что-то придумать, а перенос это в UML кажется не удобным и нудным. А некоторый графо-построитель быстрый мне бы явно не помешал заменить и бумагу и UML. + ещё разную нотацию и цветность стрелочек и уже довольно высокая информативность и удобство навигации по сотне классов...

MM>Используй ARIS... Позволяет построить собственную методологию, на основе кучи диаграмм входящих в него(в том числе и UML)... Важное значение там придаётся цвету...
+1
MM>Но в таком случае теряется самый главный плюс UML — простота и унифицированность. Унифицированность — в том смысле, что семантика диаграмм будет понятна большинству разработчиков.
Плюс весьма сомнительный, так как главное, что должен обеспечить любой язык — это выразительность. Ну а если каждый кусочек по отдельности очевиден, а общая картина не видна (что частенько бывает при использовании UML), то в наличии этой самой выразительности возникают большие сомнения. Да и достижение понятности любому разработчику за счёт примитивизации и выкидывания всего, что примитивизировать не удалось — подход весьма сомнительный.

Здравствуйте, Igor Trofimov, Вы писали:

iT>Повторюсь и может не совсем в тему, но уж очень нравится:

iT>Ажиотаж вокруг UML значительно поутих после того, как выяснилось, что из неправильных картинок получаются неправильные программы

iT>)

Именно. Знакомство с UML как с чёткой системой и графическим языком — как мне кажется весьма полезно. А вот ограничение себя его рамками — это крайне вредно.

Здравствуйте, Mishka, Вы писали:

M>И это не правда, что нормальный архитектор не может удержать в голове строение системы, хоть она и состоит из нескольких тысяч классов. UML не нужен для этого. А для документации... вы что, действительно её пишите? С UML диаграммами? Не смешите народ — вас уволят за напрасную трату времени и правильно сделают.

С последним утвержденим позволю себе не согласиться. На предыдущем проекте я писал спеки для девелоперов в том числе и с диаграмками. Правда UML там не придавалось первостепенного значения. В основном для наглядности и никак не для демонстрации болльших частей системы. Но обязательно были подробные ER диаграмы и всевозможные таблички с описанием типов, валидацией и прочими мелочами, которые необходимы девелоперам. Всё это было очень полезно и это не так уж трудно было поддерживать. На текущем проекте ничего подобного нет. Только ER диагрммы. В результате мы имеем кучу проблем, которые можно охарактеризовать как отсутствие дизайна.

Кстати, насчёт любви IBM к UML. IBM — ОЧЕНЬ большая контора. Проекты о которых идёт речь как раз проекты IBM и как видишь в разных ситуациях всё по разному.

А давайте все-таки взглянем на проблему с широкой точки зрения. Зачем и почему вообще появился UML?

Мне кажется, что разработка UML стала логичной попыткой повторить тот успех, который сопутствовал C/C++, только немного на другом уровне. Действительно, в какой-то момент разработчики поняли, что использование C выгоднее, чем ассемблера или других языков такого же уровня. Методология ООП и появление C++ стали логичным развитием идей этого языка. Причем в C++ удалось, с одной стороны, сохранить всю гибкость, присущую C, а с другой — обеспечить возможности для абстракций высокого уровня. Именно ООП вкупе с С++ и Smalltalk и стали основой для UML. Предполагалось, вероятно, что удастся слить эти подходы в некоторую единую платформу. Но в жизни этого пока не произошло и думаю и не произойдет.

Не так давно Компьютерра посвятила несколько статей как раз вопросам проектирования программных систем, в которых данная тема была препарирована довольно подробно. Так вот там тоже проскакивала интересная идея. А именно, не стоит ли еще раз взглянут на C++ именно под ракурсом дальнейшего развития этого языка? Возможно именно интеграция базовых идей UML в существующие ОО-языки программирования поможет решить одну важную проблему? Ведь существует явный разрыв между потребностями архитекторов и рядовых программистов. С одной стороны архитектуру системы очень сложно понять по исходному коду, а с другой — UML-диаграммы почти ничем не помогают этот самый код создавать. Кодирование и проектирование архитектуры системы входят в клинч, порождая споры о том что важнее и, как следствие, о том какой инструментарий (средства информационного взаимодействия между разработчиками) лучше использовать.

Вероятно, если удастся интегрировать средства моделированиря (многоуровнего моделирования!) в состав типовых инструментов разработки, обеспечив параллельную работу над одной программой множеству участников проекта (архитекторам, программистам, тестерам), то обсуждаемых проблем удастся избежать. Тут важно также понимать, что сами средства визуализации моделей могут быть различными. Важна только совместимость этих средств с используемой парадигмой моделирования. UML приспособлен для ООП. ERD — вотчина реляционных баз данных. Можно стандартизировать графические и семантические конструкции, облегчая взаимопонимание, но стандартизировать методики моделирования гораздо сложнее. Разработчики выбирают C++ зачастую именно из-за той гобкости, которую дает им этот язык. При необходимости они могут свободно менять концепции написания кода и свой подход к архитектурному проектированию (ООП, функциональное программирование и т.п.) даже в рамках одного проекта. Сегодняшний UML такой гибкости не обеспечивает. Наоборот — он либо загоняет в жесткие рамки ООП, либо используется только на отдельных этапах проектов, что неудобно само по себе. Это сродни тому, как если бы мы сначала разрабатывали приложение на VB .NET, а после выхода первой альфа-версии вдруг брались все переписывать на Pascal. Это явно расточительная методика.

Можно ли предложить универсальное решение? Как обычно нельзя. Но наверняка можно искать частные решения, которые позволят совместить типовые методики моделирования с инструментами кодирования. Причем работать они должны в обе стороны. Поскольку исходный код программы несомненно содержит информацию об архитектуре системы, мы должны иметь возможность работать с ним также, как сегодня работаем с UML-моделями. А визуализация этих моделей — вопрос в общем то производный.

AR>Можно ли предложить универсальное решение? Как обычно нельзя. Но наверняка можно искать частные решения, которые позволят совместить типовые методики моделирования с инструментами кодирования. Причем работать они должны в обе стороны. Поскольку исходный код программы несомненно содержит информацию об архитектуре системы, мы должны иметь возможность работать с ним также, как сегодня работаем с UML-моделями. А визуализация этих моделей — вопрос в общем то производный.

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

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

Здравствуйте, Alexey Rovdo, Вы писали:

AR>А давайте все-таки взглянем на проблему с широкой точки зрения. Зачем и почему вообще появился UML?
Нет уж, давайте лучше не будем, а то совсем каша получается.

AR> Ведь существует явный разрыв между потребностями архитекторов и рядовых программистов.
Угу, ровно с того момента, как архитекторы перестают программировать...

AR>С одной стороны архитектуру системы очень сложно понять по исходному коду,
На самом деле не сложно, иногда даже проще чем UML.

AR> а с другой — UML-диаграммы почти ничем не помогают этот самый код создавать.
Это и есть главный недостаток UML. UML диаграммы, как правило, не имеют ничего общего с реальной системой, а затраты на приведение одного в соответствие другому себя не оправдывают.

AR>Вероятно, если удастся интегрировать средства моделированиря (многоуровнего моделирования!) в состав типовых инструментов разработки, обеспечив параллельную работу над одной программой множеству участников проекта (архитекторам, программистам, тестерам), то обсуждаемых проблем удастся избежать.
Вэлкам то VS 2005 и DSL.

AR> Можно стандартизировать графические и семантические конструкции, облегчая взаимопонимание, но стандартизировать методики моделирования гораздо сложнее. Разработчики выбирают C++ зачастую именно из-за той гобкости, которую дает им этот язык.
Хм.. В целом постинг был длинный, но такое впечатление, что часть расссуждений осталась за кадром...

Mishka -> Re: UML

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

Ээээ.. я тут подумал...

Во-первых — фанатизм не уместен при работе с UML
Во-вторых — UML помогает нужных случаях упрощать описание требований в разы.
Но нужно учитывать пункт 1

Так что лучше связки текст + UML сложно что-то придумать.

<!-- Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно
гармонист -->

Здравствуйте, Merle, Вы писали:

M>Хм.. В целом постинг был длинный, но такое впечатление, что часть расссуждений осталась за кадром...

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

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

Здравствуйте, nixite, Вы писали:

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

Что же до идеи с редактором графов — она кажется мне интересной и явно заслуживает внимания. Но для этого её нужно сначала основательно проработать. Глядишь — что-нибудь и получится.

Здравствуйте, Alexey Rovdo, Вы писали:

AR>Однако еще раз подчеркну. Сегодня UML — это средство представления уже разработанных моделей.
Да ну, позиционируется-то он по другому. К тому же какая польза от средства представления, если оно довольно далеко от реальности...

AR> А готовые модели никто не мешает представить и с помощью UML.
А зачем? Если есть некий способ наглядно представить модель в процессе разработки, то зачем от этого способа отказываться, когда модель уже готова?

AR>Короче, одно вовсе не исключает другого, но важно понять, что мы имеем дело именно с двумя разными задачами (разработка и формализованное описание разработанного).
Зачем для уже разработанного иметь другой язык формального описания, чем тот который применялся в процессе разработки?
Зачем вообще выделять эти две фазы? В реальной жизни практически не сталкиваешься с ситуацией, когда продукт готов и гарантировано не будет изменяться. Ну допустим, и что, в этот момент садиться и изнурительно писать UML? И кому он будет нужен по готовой модели?