Чем дальше я сталкиваюсь с проектированием ПО, создании и описании его архитектуры, попытками воссоздать структуру и архитектуру ПО, тем больше для меня становиться очевидным тот факт что 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? И кому он будет нужен по готовой модели?

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

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

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

Позиционируется кем и как (ссылки)?
Что же касается реальности, то вовсе я не говорил, что он от нее далек. UML включает массу конструкций, позволяющих представить огромное разнообразие возможных моделей как в статике, так и в динамике. Представить — показать, рассказать, описать в стандартных терминах. То же самое можно сделать просто на словах, в тексте или с помощью нестандартного но интуитивно понятного средства отображения неких графов.


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

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

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

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

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

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

Приведу такую аналогию.

Скажем есть самолет (вы его уже представили). Это турбовинтовой самолет. Оторвем ему крыло. Во втором крыле ровно посередине просверлим дырку...

Все это совершенно явственно можно себе представить. Более того, можно взять пластилин и очень быстро сделать простейшую модель, проведя с ней указанные манипуляции. При минимальном знакомстве со средствами 3D-моделирования все это элементарно проделать на компьютере. Причем в любой момент можно посмотреть модель на экране с любого ракурса, напечатать и даже изготовить на спецоборудовании.

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

Есть ли какое-то будущее у UML? Разумеется есть. Но, полагаю, только как средства визуализации моделей. Сама же разработка (как процесс формирования этой модели) будет либо инкорпорирована в процесс написания исходного кода, либо так и останется на доске или листе бумаги.

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

AR>Позиционируется кем и как (ссылки)?
Как средство разработки, а не описания исключительно готовой модели. Отцами основателями... Ссылки бумажные.

AR>Что же касается реальности, то вовсе я не говорил, что он от нее далек.
Это говорил я.

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

AR>Чтобы другие участники проекта смогли быстро понять структуру вашей модели (вашего предварительного варианта или части модели, если речь идет о коллективной разработке этой модели).
Для этого годится тот же самый инструмент, который применялся и при разработке. Вы же утверждаете, что для готовой модели почему-то нужен именно UML. Еще раз повторю свой вопрос: Зачем?
Зачем тратить усилия на перевод в UML то, что есть в другом виде и итак всем понятно?

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

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

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

AR> Сегодня местами нет никакой альтернативы использованию UML.
Ну здрасьте, карандаш, бумага и исходный код со внятными комментариями неплохо справляются.

AR> Однако это действительно приводит к массе ненужной или дублирующейся работы.
Вот именно, что не нужной.

AR> Как я уже и писал раньше, мне видится, что выход лежит в переводе системных архитекторов на работу непосредственно с исходными кодами.
Внятные архитекторы и так с ними и работают.

AR> Но сами языки, на которых эти исходники сегодня пишутся, пока не готовы предоставить архитекторам весь необходимый им инструментарий.
За инструментарием, велкам ту VS 2005 и DSL, вполне логичное развитие архитекторского инструментария.

AR>Приведу такую аналогию.
Опять много текста, но мысль не ясна... И я так и не услышал ответа на вопрос, во-первых, зачем разделять на фазы "разработки модели" и "готовой модели" и, во-вторых, если уж разделять, то зачем применять ко второй фазе другой язык формального описания, отлчный от применяемого в первой фазе?

AR>Есть ли какое-то будущее у UML? Разумеется есть.
Я бы не был так уверен.

AR> Но, полагаю, только как средства визуализации моделей.
Зачем нужна визуализация отдельно от процесса разработки?

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

AR>> Но сами языки, на которых эти исходники сегодня пишутся, пока не готовы предоставить архитекторам весь необходимый им инструментарий.
M>За инструментарием, велкам ту VS 2005 и DSL, вполне логичное развитие архитекторского инструментария.

1. Релиз пока не вышел.
2. Технология не прошла обкатки в реальных проектах.
3. На Windows свет клином не сошелся.
4. Есть достаточно много крупных компаний успешно применяющих UML для проектирования и разработки. Собственно, мы делаем продукт как раз на базе UML 2.0, который вполне успешно используется этими самыми компаниями.

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

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

AR>>Позиционируется кем и как (ссылки)?
M>Как средство разработки, а не описания исключительно готовой модели. Отцами основателями... Ссылки бумажные.


Почитал на досуге отцов-основателей (Рамбо, Якобсон, Буч). Ну что сказать? По их словам UML предназначен для всего. Особенно вдохновенно пишут об унификации. Впрочем, вчитавшись можно найти и такие фразы: "Мы не собирались делать из языка UML методологию, в нем нет пошагового описания процесса разработки ... При этом важно понимать, что UML и процесс разработки с использованием UML — совершенно разные вещи. UML призван поддерживать все или, по крайней мере, большинство существующих методологий..." И тут же: "Модель должна создаваться в удобной для работы среде. Например, модель здания может быть рисунком на бумаге, трехмерным макетом из картона и папье-маше или системой уравнений в конечных элементах. При этом она может изображать внешний вид этого здания, но также использоваться и для подсчета стоимости строительства. Модель программного продукта создается с помощью языка моделирования, например, UML. Модель может принимать различные формы ...". А потом уже взгляд такой: "Здесь описывается интерпретация модели в языке UML. Тем не менее во время реальной работы над проектом полезно пользоваться и другими источниками, которые могут интерпретировать информацию другим, отличным от UML способом."

Так для чего же нужен UML по мнению самих отцов-основателей? Для создания моделей или для их интерпретации? Я понимаю, что им хотелось бы сделать область применения этого языка максимально широкой. Именно поэтому язык насыщен массой конструкций, пришедших из самых разных областей инженерной деятельности. Но нельзя удовлетворить всех одинаково хорошо. Лично я придерживаюсь той точки зрения, что UML хорош именно как средство коммуникации, т.е. должен использоваться исключительно для интерпретации моделей. А вот для создания и управления моделями нужны иные средства.

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

В маленьких рабочих группах, да. Но в крупных компаниях и проектах UML востребован.

AR>>Чтобы другие участники проекта смогли быстро понять структуру вашей модели (вашего предварительного варианта или части модели, если речь идет о коллективной разработке этой модели).
M>Для этого годится тот же самый инструмент, который применялся и при разработке. Вы же утверждаете, что для готовой модели почему-то нужен именно UML. Еще раз повторю свой вопрос: Зачем?
M>Зачем тратить усилия на перевод в UML то, что есть в другом виде и так всем понятно?

Нет. Я вовсе не утверждаю того, что для готовой модели UML нужен обязательно. Просто UML — это удобное и стандартизованное средство представления готовых моделей. Я смотрю на него также как, например, на формат PDF, который является удобным средством для представления документов со сложной версткой. Но вот изначально создавать и верстать документы удобнее в других форматах.

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

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

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

В том то и дело. Работать с UML плохо. Лучше работать с исходным кодом, а UML-представления по мере надобности получать из исходного кода автоматически. Но сегодня более пополярна иная концепция — исходный код получать из UML-моделей. Но она не работает и создает массу ненужной суеты и проблем. Однако вынужден констатировать, что предлагаемый мною подход, к сожалению, чисто теоретический. Современные языки программирования и средства разработки пока не предоставляют нам такой возможности.

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

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

AR>> Как я уже и писал раньше, мне видится, что выход лежит в переводе системных архитекторов на работу непосредственно с исходными кодами.
M>Внятные архитекторы и так с ними и работают.

Внятные архитекторы все равно имеют дело с другими (невнятными) архитекторами и бюрократами, которых пруд пруди. И даже через много тысяч лет ситуация не изменится.

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

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

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

AR> Я смотрю на него также как, например, на формат PDF, который является удобным средством для представления документов со сложной версткой. Но вот изначально создавать и верстать документы удобнее в других форматах.
Не надо увлекаться ложными аналогиями. В случае PDF можно нажатием кнопки получить этот самый PDF из исходников и после этого исходники никого не интересуют, PDF стал основным документом. В случае же UML-я все наоборот, главное по прежнему продукт, а UML якобы помогает понять как он устроен...

AR>А зачем нам PDF? Просто всегда нужны какие-то стандартные средства представления данных.
Зачем нам какое-то другое представление данных, которое требует дополнительных усилий по применению и все равно полностью их не отражает?

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

AR>В том то и дело. Работать с UML плохо. Лучше работать с исходным кодом, а UML-представления по мере надобности получать из исходного кода автоматически.
Зачем получать это представление, даже автоматически? Понятнее от этого модель вряд ли станет.

AR> Современные языки программирования и средства разработки пока не предоставляют нам такой возможности.
В третий раз говорю, DSL.

AR>Можно научить всех этих людей тому внутреннему инструментарию, который используется в компании.
Не надо никого ничему учить. Внутренний инструментарий — это исходный код, карандаш, бумага, язык.

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

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

_O_>1. Релиз пока не вышел.
43B503F5-F490-4176-BCEF-4B7509A5D970. Речь шла о перспективах развития архитекторского инструментария, а не о реально используемых инструментах.

_O_>2. Технология не прошла обкатки в реальных проектах.
27281864-A314-4454-BA44-09A3ABB74E9C. Еще пройдет, главное идея здравая и, по большему счету, не новая, просто наконец-то появится хороший полноценный инструмент и не придется изобретать каждый раз что-то своё.

_O_>3. На Windows свет клином не сошелся.
EBA12DFA-E26D-42E5-985D-8490801BE482. А причем здесь Windows? На Windows только инструментарий, а основное это идея. Если она хорошо себя проявит, то и на других платформах появится...

_O_>4. Есть достаточно много крупных компаний успешно применяющих UML для проектирования и разработки. Собственно, мы делаем продукт как раз на базе UML 2.0, который вполне успешно используется этими самыми компаниями.
6503CBE9-6C79-4489-9D00-A8B8078C34EA. Но есть не меньшее количество таких же крупных компаний, которые не менее успешно не применяют UML и что?

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

_O_>>3. На Windows свет клином не сошелся.
M> А причем здесь Windows? На Windows только инструментарий, а основное это идея. Если она хорошо себя проявит, то и на других платформах появится...

Вся DSL сильно привязана к .Net и Visual Studio. Портирование на другие платформы будет затруднительно. А MS сама не будет этим заниматься.

_O_>>4. Есть достаточно много крупных компаний успешно применяющих UML для проектирования и разработки. Собственно, мы делаем продукт как раз на базе UML 2.0, который вполне успешно используется этими самыми компаниями.
M> Но есть не меньшее количество таких же крупных компаний, которые не менее успешно не применяют UML и что?

Какие крупные компании не используют UML и сколько их ?

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

AR>>Нет. Я вовсе не утверждаю того, что для готовой модели UML нужен обязательно. Просто UML — это удобное и стандартизованное средство представления готовых моделей.
M>Чем удобное? Разьве что тем, что стандартизированное, но это единственное преимущество, которое напрочь убивается тем, что UML представление имеет мало общего с реальным продуктом. Нет никакой связи, между реальным продуктом и UML-ем, архитектор нарисовал одно, разработчик написал совсем другое и синхронизировать одно с другим нет никакой возможности.

AR>> Я смотрю на него также как, например, на формат PDF, который является удобным средством для представления документов со сложной версткой. Но вот изначально создавать и верстать документы удобнее в других форматах.
M>Не надо увлекаться ложными аналогиями. В случае PDF можно нажатием кнопки получить этот самый PDF из исходников и после этого исходники никого не интересуют, PDF стал основным документом. В случае же UML-я все наоборот, главное по прежнему продукт, а UML якобы помогает понять как он устроен...

Ровно то же самое можно и с UML-ем. Например, продукты компании I-Logix или нашей обеспечивают полноценную генерацию исполняемого кода из UML моделей. Причем сгенерить все можно одной кнопкой.

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

_O_>Ровно то же самое можно и с UML-ем. Например, продукты компании I-Logix или нашей обеспечивают полноценную генерацию исполняемого кода из UML моделей. Причем сгенерить все можно одной кнопкой.

А вот об этом можно поподробнее? Особенно о том, как в UML-описании оказывается (чем и на чем пишется) вся информация, необходимая для генерации ИСПОЛНЯЕМОГО кода.

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

AR>А вот об этом можно поподробнее? Особенно о том, как в UML-описании оказывается (чем и на чем пишется) вся информация, необходимая для генерации ИСПОЛНЯЕМОГО кода.
Я как-то для прикола написал на visio С# программу. Сгенерил код. И откомпилировал. Но честно говоря, так работать невозможно.

С уважением, Gleb.

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

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

_O_>>Ровно то же самое можно и с UML-ем. Например, продукты компании I-Logix или нашей обеспечивают полноценную генерацию исполняемого кода из UML моделей. Причем сгенерить все можно одной кнопкой.

AR>А вот об этом можно поподробнее? Особенно о том, как в UML-описании оказывается (чем и на чем пишется) вся информация, необходимая для генерации ИСПОЛНЯЕМОГО кода.

В нашем случае мы используем UML 2.0. Он содержит необходимые классы для выражения action-ов (таких как вызов метода, посылка сигнала, присваивание выражения переменной и т.д.) Плюс мы несколько расширили объектную модель, добавив классы для представления выражений (чтоб выражения типа "a + b * 2" были не просто текстом, а частью модели).
Так же мы сделали текстовую нотацию для UML 2.0, как раз для удобного описания action-ов. (Стандарт определяет какие конструкции есть, но не опеределяет никакой нотации для них).

Все выглядит примерно так

А знаком ли кто-нибудь с такам инструментарием?

http://www.visual-paradigm.com/

И что о нем можете сказать?

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

_O_>Ровно то же самое можно и с UML-ем. Например, продукты компании I-Logix или нашей обеспечивают полноценную генерацию исполняемого кода из UML моделей. Причем сгенерить все можно одной кнопкой.
Во-первых надо наоборт, из исходного кода UML модель получить, речь-то об этом.
А во-вторых, еще раз повторюсь, в отличии от PDF-а, после генерации UML-я основным документом по прежнему являются исходники и после того как разработчик в них что-то поменял, всю нагенеренную красоту UML можно выкидывать.

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

AR>А знаком ли кто-нибудь с такам инструментарием?

AR>http://www.visual-paradigm.com/

AR>И что о нем можете сказать?

Не знаю, руками не трогал, судить не берусь. Я думаю, по части генерации кода и симуляция у нас (Telelogic) опыта больше будет.
В часности, нашел тул обеспечивает генерацию кода и в С, что позволяет его использовать (и он реально используется) для разработки embedded & real-time software.

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

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

_O_>>Ровно то же самое можно и с UML-ем. Например, продукты компании I-Logix или нашей обеспечивают полноценную генерацию исполняемого кода из UML моделей. Причем сгенерить все можно одной кнопкой.
M>Во-первых надо наоборт, из исходного кода UML модель получить, речь-то об этом.
M>А во-вторых, еще раз повторюсь, в отличии от PDF-а, после генерации UML-я основным документом по прежнему являются исходники и после того как разработчик в них что-то поменял, всю нагенеренную красоту UML можно выкидывать.

В нашем случае, исходником всегда ялвяется модель. В сгенеренный код можно вообще не лезть. Меняется всегда модель.

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

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

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

Впрочем, индустрия уже так далеко зашла именно в направлении интеграции языков программирования в UML-модели, что развернуться на 180 градусов ей будет трудновато. Скорее просто при достижении определенного уровня интеграции будет вообще трудно понять что и в кого интегрировали, а работа с исходниками на C++/Java и т.п. станет в чем то сродни написанию ассемблерных вставок в C++-коде: __asm { ... }. Но в таком случае сама генерация полных исходников на C++ и т.п. из описанной совмещенной модели может оказаться вообще ненужным шагом — можно сразу компилировать "исходный" UML + C++ код. И как тогда называть этот язык (UML + C++)?

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

_O_>Вся DSL сильно привязана к .Net и Visual Studio. Портирование на другие платформы будет затруднительно. А MS сама не будет этим заниматься.
Еще раз: К .Net привязан конкретный инструмент, а DSL — это идея. И реализовать эту идею можно где угодно, было бы желание.
Если же ставить вопрос о портировании, то на ту же Java перевести никакого труда не составит.

_O_>Какие крупные компании не используют UML и сколько их ?
Я статистику не веду, но та же Microsoft, AFAIK, UML не использует — это достаточно крупная компания?

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


AR>В том и состоит основной казус. Можно конечно пойти по пути переноса всей разработки в UML, как это показывает _Obelisk_ . Дескать мы получаем исходные коды как промежуточное звено и их вообще не правим, а правим только исходную UML-модель. Но тогда мы фактически вынуждены встраивать куски Java/C++/... кода прямо внутрь UML-нотации. Нельзя отрицать такую возможность напрочь. Но лично мне кажется, что заходить все-таки надо с другого конца.

У нас это как раз и реализовано. В большинстве случаев, хватает нашей текстовой нотации, но если очень надо, то можно прямо и target код вставлять. Для интеграции с библиотеками есть возможность импорта (h-файлов для C/C++ и Jar/class файлов для Java) в UML модель.
И roundtrip engineering у нас тоже поддерживается (для Java и С++. Для С нет, но там он не нужен).

AR>Впрочем, индустрия уже так далеко зашла именно в направлении интеграции языков программирования в UML-модели, что развернуться на 180 градусов ей будет трудновато. Скорее просто при достижении определенного уровня интеграции будет вообще трудно понять что и в кого интегрировали, а работа с исходниками на C++/Java и т.п. станет в чем то сродни написанию ассемблерных вставок в C++-коде: __asm { ... }. Но в таком случае сама генерация полных исходников на C++ и т.п. из описанной совмещенной модели может оказаться вообще ненужным шагом — можно сразу компилировать "исходный" UML + C++ код. И как тогда называть этот язык (UML + C++)?

Такого еще долго не будет, потому как любые мало-мальски сложные системы зависят от всяких внешних API и библиотек. При генерации в какой-нибудь язык программирования проще интегрировать со сторонними библиотеками.
Да и портация сгенеренного кода на всякие специальные платформы (используемые в embedded & telecom industry) проще, если генерить С/C++/Java.

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

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

_O_>>Вся DSL сильно привязана к .Net и Visual Studio. Портирование на другие платформы будет затруднительно. А MS сама не будет этим заниматься.
M>Еще раз: К .Net привязан конкретный инструмент, а DSL — это идея. И реализовать эту идею можно где угодно, было бы желание.

А нельзя ли чуть подробнее раскрыть суть этой идеи или дать ссылочки. Я лично с VS 2005 пока не работал, посему любопытно.

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

_O_>Такого еще долго не будет, потому как любые мало-мальски сложные системы зависят от всяких внешних API и библиотек. При генерации в какой-нибудь язык программирования проще интегрировать со сторонними библиотеками.
_O_>Да и портация сгенеренного кода на всякие специальные платформы (используемые в embedded & telecom industry) проще, если генерить С/C++/Java.

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

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

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

_O_>>Вся DSL сильно привязана к .Net и Visual Studio. Портирование на другие платформы будет затруднительно. А MS сама не будет этим заниматься.
M>Еще раз: К .Net привязан конкретный инструмент, а DSL — это идея. И реализовать эту идею можно где угодно, было бы желание.
M>Если же ставить вопрос о портировании, то на ту же Java перевести никакого труда не составит.

_O_>>Какие крупные компании не используют UML и сколько их ?
M>Я статистику не веду, но та же Microsoft, AFAIK, UML не использует — это достаточно крупная компания?

Lockhead Martin Corp, Thales, Raytheon, BAE Systems, Motorola и др — используют. Они, пожалуй, крупней Microsoft-а.

Кстати, ведь MS Visio делает, который UML поддерживает. Потом, они многие идеи стянули из UML.
Скажем, system definition model есть прямая калька с UML 2.0. composite structure diagrams.
Я и блоги разработчиков VS2005 читал, не открещивается MS от UML-я.

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

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

_O_>>Такого еще долго не будет, потому как любые мало-мальски сложные системы зависят от всяких внешних API и библиотек. При генерации в какой-нибудь язык программирования проще интегрировать со сторонними библиотеками.
_O_>>Да и портация сгенеренного кода на всякие специальные платформы (используемые в embedded & telecom industry) проще, если генерить С/C++/Java.

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

Главное идти к правильной цели, причем не важно с какой стороны

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

AR>А нельзя ли чуть подробнее раскрыть суть этой идеи или дать ссылочки. Я лично с VS 2005 пока не работал, посему любопытно.
В двух словах: архитектор создает свой DSL (Domain Specific Language) под конкретную задачу, и уже в терминах этого языка описывает модель. В момент описания модели код генерится на лету, нет необходимости даже нажимать нарошную кнопку для генерации исходников. В таком виде проект поступает к разработчику, разработчик правит код, и все его изменения моментально отражаются в модели, терминах DSL, и опять-таки нет никакой необходимости нажимать хитрые кнопки, чтобы получить актуальное состояние модели, это 100% on-line инструмент, оба представления проекта, и код, и DSL, всегд анаходятся в актуальном состоянии откуда бы проект не правили. DSL так же поддерживает валидацию, в отличии от UML-я.

http://msdn.microsoft.com/library/en-us/dnvs05/html/vstsmodel.asp

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

_O_>Lockhead Martin Corp, Thales, Raytheon, BAE Systems, Motorola и др — используют. Они, пожалуй, крупней Microsoft-а.
И софтверные проекты у них крупнее?
Да, написать "... и др." я тоже могу, кстати, IBM тоже далеко не на всех своих проектах использует UML в полный рост.

_O_>Кстати, ведь MS Visio делает, который UML поддерживает.
Уже не делает, а только поддерживает.

_O_> Потом, они многие идеи стянули из UML.
И что?

_O_>Я и блоги разработчиков VS2005 читал, не открещивается MS от UML-я.
Не открещиваются конечно, просто не используют..

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

_O_>В нашем случае, исходником всегда ялвяется модель. В сгенеренный код можно вообще не лезть. Меняется всегда модель.
Всё в модели все равно не сделаешь, исходники в любом случае придется менять, а отследить, что при изменении исходника поменялась модель нет никакой возможности.

Ой, тут много наговорили. Не скажу, что со всем не согласен.
Да, UML не универсален, потому как ограничен, и что-то описывать с его помощью — просто трата времени.
Но не скажу, что само описание модели в UML — трата времени. На мой взгляд UML должен (да за ради этого изначально все стандарты моделирования появлялись) обеспечивать возможность построения, модификации, изучения архитектуры на разных уровнях абстракции, с разных точек зрения при обеспечении наглядности и достаточной информативности. При нормальной реализации такого отношения к UML, исходник не будет главным документом, а скорее низшим уровнем детализации — конкретной, языкозависимой реализацией. То есть процесс разработки должен включать стадию переноса выбранной, может быть частично придуманной модели с бумажки, доски еще чего там в UML представление. После чего архитектура дорабатывается до кондиции первичной кодогенерации. Таким образом можно построить UML-модель, которая ни на йоту не будет отличаться от реального представления в реализации.
Дальше стоит вопрос взаимодействия уровней абстракции: когда начинается стадия программирования системы, либо при начале нового цикла разработки, возникает необходимость менять модель, то есть, так сказать, революция снизу получается. Здесь я вижу вполне актуальное решение: чтобы средство моделирования позволяло умный реинжиниринг, то есть не просто построение модели по коду, а связывание элементов реализации (они достаточно конкретны: методы, атрибуты) с их отражением в модели. Можно сказать, чтобы кусочки реализации цеплялись к модели. Тогда в процессе пересмотра архитектуры можно было бы параллельно производить рефакторинг уже наработанного материала (кода) до соответствия модификациям модели. Но на уровне модели нельзя точно сформулировать требования по модификации кода и возникает вопрос уже обратной связи: в коде, связанном с моделью вносить соот. изменения. Короче, я веду к нормальной интеграции средств проектирования и программирования. Чтобы инструментарий представлял не просто отдельное ПО для проектирования и для программирования, но комплексное решение, возможно, по приведенной схеме: все что выше конкретного языка, конкретной реализации — в UML. К этому (не совсем, конечно) сейчас идет Delphi с Together. Но не стоит рассматривать такую жесткую (прямо полную) интеграцию, как отход от идеи унификации UML. Модель всегда может быть перенесена (есть тому стандарт XMI), таким образом каркас всегда есть.

Еще один вариант использования UML от OMG — MDA. Забыли, да?
Тут уже модель стоит в центре разработки, она сама — объект, и с ее помощью (навигация, например, формализованные ограничения) производят определенные манипуляции с тем, что она представляет. В этом направлении пока все работают и ничего конкретного и до конца толкового пока нет. Однако, уже на сегодняшний день то, что из себя представляет ECO Framework мне лично определенно нравится.

Так что будущее у UML есть. И сомневаться глупо — стали бы над заведомо бесперспективным проектом такого масштаба работать такие крупные корпорации? Значит это кому-нибудь нужно! (с)

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

N>Ой, тут много наговорили. Не скажу, что со всем не согласен.
N>Да, UML не универсален, потому как ограничен, и что-то описывать с его помощью — просто трата времени.
+1
N>Но не скажу, что само описание модели в UML — трата времени. На мой взгляд UML должен (да за ради этого изначально все стандарты моделирования появлялись) обеспечивать возможность построения, модификации, изучения архитектуры на разных уровнях абстракции, с разных точек зрения при обеспечении наглядности и достаточной информативности. При нормальной реализации такого отношения к UML, исходник не будет главным документом, а скорее низшим уровнем детализации — конкретной, языкозависимой реализацией. То есть процесс разработки должен включать стадию переноса выбранной, может быть частично придуманной модели с бумажки, доски еще чего там в UML представление. После чего архитектура дорабатывается до кондиции первичной кодогенерации. Таким образом можно построить UML-модель, которая ни на йоту не будет отличаться от реального представления в реализации.
+1
Вот здесь ты сам и дал ответ — который обясняет все те проблемы, которые возникают вокруг UML. Проблемы возникают потому, что UML применяется не там и не так, как его применение было предусмотрено — как он должен был бы применяться. Почему то все забыли, что UML вовсе не является самостоятельной вещью — как многие его пытаются представить. UML был разработан как интсрументальная частица UP — и как варианта RUP. Он не отделим от этого процесса, а любая попытка это сделать мгновенно выявляет несоответствие UML для других задач.
Если у вас был опыт разработки по ГОСТ или ISO9000 или настоящему RUP — с написанием всех тех противных, но необходимых для процесса документов (включая как проектную документацию, так и нормативные документы), то вы бы ясно увидели, как хорошо ложится UML в эту схему. UML это вовсе не язык разработчиков. Это часть промышленного стандарта, такая же как изуверские правила написания документов по ГОСТ. Вот в этом качестве он великолепен. Но разве правила написания документов по ГОСТ применимы для чего то ещё?
Другое дело, что у нас большинство фирм "слышали звон да не знают где он" — то есть в действительности очень смутно представляют, для чего предуманы и как должны применяться новомодные западные технологии. Услышали модное слово UML — лет эдак 5-6 назад, и ну народ с UML искать. А народ что? Накупил книжек "UML за 24 часа" и через сутки уже уверен, что мастер по UML. Что и отражает в своём резюме.
В результате довольно часто наблюдаю картину, когда талантливый разработчик пытается найти общий язык с бизнесменом. И пытается использовать для этих целей UML (который бизнесмену изучать как то не хочется). В результате разочаровывается в UML и появляются посты, вроде того, который написал автор ветки. Мол UML не для всего подходит. Да он и не предназначался для этого! UML предназначался лишь для описания процессов в системе на уровне построения и реализации системы. Но не на уровне бизнес-логики. Для последнего существует IDEFx.

N>Так что будущее у UML есть. И сомневаться глупо — стали бы над заведомо бесперспективным проектом такого масштаба работать такие крупные корпорации? Значит это кому-нибудь нужно! (с)

Именно. Другое дело, что в нашей реальности большинство компаний хотят за копейку купить слона. То есть они не хотят следовать довольно дорогому процессу разработки (лишь малой частицей которого является UML), но при том ожидают от него той же отдачи, что и IBM.
Вместо этого они пытаются изобретать Silver Bullet для решения всех проблем сразу. Иногда это получается довольно удачно, что и называется "прогресс"

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

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

_O_>>Я и блоги разработчиков VS2005 читал, не открещивается MS от UML-я.
M>Не открещиваются конечно, просто не используют..

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

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

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

_O_>>В нашем случае, исходником всегда ялвяется модель. В сгенеренный код можно вообще не лезть. Меняется всегда модель.
M>Всё в модели все равно не сделаешь, исходники в любом случае придется менять, а отследить, что при изменении исходника поменялась модель нет никакой возможности.

Есть. Исходник парсится, строится модель, потом она мёржится в исходную.

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

_O_>>>В нашем случае, исходником всегда ялвяется модель. В сгенеренный код можно вообще не лезть. Меняется всегда модель.
M>>Всё в модели все равно не сделаешь, исходники в любом случае придется менять, а отследить, что при изменении исходника поменялась модель нет никакой возможности.

_O_>Есть. Исходник парсится, строится модель, потом она мёржится в исходную.

А дельше? Правим полученную модель, генерим по ней новый исходник. А изменения, сделанные в старом исходнике в этот новый попадут?

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

_O_>Есть. Исходник парсится, строится модель, потом она мёржится в исходную.
Всегда однозначно и без ошибок?
И еще. Есть возможность иметь несколько моделей с различной степенью детализации на один и тот же проект?

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

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

_O_>>>>В нашем случае, исходником всегда ялвяется модель. В сгенеренный код можно вообще не лезть. Меняется всегда модель.
M>>>Всё в модели все равно не сделаешь, исходники в любом случае придется менять, а отследить, что при изменении исходника поменялась модель нет никакой возможности.

_O_>>Есть. Исходник парсится, строится модель, потом она мёржится в исходную.

AR>А дельше? Правим полученную модель, генерим по ней новый исходник. А изменения, сделанные в старом исходнике в этот новый попадут?

Попадут. Модель генериться в вектор токенов, исходник сканится и тоже формируется вектор токенов, потом два вектора определенным образом мёржутся.
Детали алгоритмов раскрыть не могу, извините.

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

_O_>В нашем случае, исходником всегда ялвяется модель. В сгенеренный код можно вообще не лезть. Меняется всегда модель.

И это есть правильно.
Если модель построена правильно, хорошо продумана и исходят из неё, а не наоборот — то у вас всегда есть возможность переписать отдельный модуль, сохранив работоспособность системы. А вот чем это может кончится, если танцевать от исходного кода — большинству из нас прекрасно известно.

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

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

_O_>>Есть. Исходник парсится, строится модель, потом она мёржится в исходную.
M>Всегда однозначно и без ошибок?

В большинстве практическех случаев да. Очевидно, что если юзер вообще все удалил и переписал по новому, то импорт этого в модель влечет за собой исчезновение старой модели и возникновение новой.

M>И еще. Есть возможность иметь несколько моделей с различной степенью детализации на один и тот же проект?

Да. Плюс есть возможность формировать различные представления для модели.

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

_O_>>Кстати, ведь MS Visio делает, который UML поддерживает.
M>Уже не делает, а только поддерживает.

Как не делает ?
А это что прилитело на дисках с beta2?

Microsoft® Office Visio® for Enterprise Architects 2005 Beta 2 Readme File
March 2005

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

C_K>Как не делает ?
А так...

C_K>А это что прилитело на дисках с beta2?
И что там нового? VSS тоже в B2 новый, но функционал практически не поменялся, подозреваю, что та же история и с Visio.
Когда я спаршивал у них по этому поводу, то ответ был примерно таким:
"... Визио мы будем поддерживать для тех несчастных, которые без UML не могут...", за дословность цитаты не ручаюсь, но смысл передан верно.

_O_>Через неделю лечу в Редмонд, к своим друзьям работающим в MS. Вот и выясню, используют они UML или нет и как они его используют

Мда.. любит ли слонопотам поросят и КАК он их любит..

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

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

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

Вы, случайно не знаете кто это сказал первый раз? Это како-то гуру с мировым именем или так..?
Часто вижу эту фразу в различных девелоперских форумах... интересно стало.

MichaelXP wrote:

> iT>Повторюсь и может не совсем в тему, но уж очень нравится:
> iT>Ажиотаж вокруг UML значительно поутих после того, как выяснилось,
> что из неправильных картинок получаются неправильные программы
> Вы, случайно не знаете кто это сказал первый раз? Это како-то гуру с
> мировым именем или так..?
> Часто вижу эту фразу в различных девелоперских форумах... интересно стало.

Выстраданая многими программистами истина

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

_O_>>4. Есть достаточно много крупных компаний успешно применяющих UML для проектирования и разработки. Собственно, мы делаем продукт как раз на базе UML 2.0, который вполне успешно используется этими самыми компаниями.
M> Но есть не меньшее количество таких же крупных компаний, которые не менее успешно не применяют UML и что?

Без анализа какие компании применяют UML, в каких проектах и для чего — кроме беспредметного религиозного спора ничего не выйдет.
Например в каких секторах рынка (если это вообще рыночные сектора) работают компании, применяющие и не применяющие UML? В каких проектах он применяется и для чего? Что ставится на первое место в подобных проектах — код или модель?
Если вы потратите время, что бы честно и спокойно ответить на эти вопросы — спорить станет не о чём.
Во-первых выясниться, что упомянутые ранее крупные компании UML сам по себе никогда не применяют. Как вы никогда не услышите от них про применение C++ — даже если они им очень широко пользуются. Они могут применять или не применять процесс разработки, в котором UML используется или не используется как язык описания моделей определённого уровня и не более того. Да и то в разных проектах может быть разный процесс. Что, впрочем, совершенно не мешает специалистам компании широко применять тот же UML для общения друг с другом — рисования диаграмм на доске. Насколько мне известно — в том же Микрософт такое происходит достаточно часто.
Теперь по поводу Микрософт. То, что Микрософт не применяет RUP — совершенно естественно. Это тяжеловесная методология, а MS всю дорогу демонстировала, что скорость разработки новых технологий для них гораздо важнее качества (не верите — посмотрите список патчей к виндам за прошедший год). Что, с моей точки зрения, совершенно оправдано. Кроме того, MS ведёт свои разработки для себя самой. То есть выступает и как заказчик и как производитель. Потому лишний документооборот, который возникает между заказчиком и производителем им не нужен. Вспомните так же, что MS имеет уникальное по объёму и концентрации количество высококвалифецированных профи — для которых тот же UML не нужен — так как они вполне могут общаться на более высоком уровне, пропуская многие элементарные шаги. В общем MS — уникум — и нельзя ожидать от других компаний того же уровня и подхода к разработке, что и от MS.
Если брать компании, производители софта для софта (Sun, Borland, Intel, IBM (те их подразделения, что производят компиляторы, например)), то там картина та же. Она обусловлена простой вещью — на верхнем уровне компилятор, к примеру, как UML модель — элементарен, а на подробном — пока вы будете разрисовывать среднининький компилятор или JVM — вас на рынке просто похоронят. Да и пользы от такой модели будет не много. Часто будет проще посмотреть в код. Ведь для рисования алгоритмов UML как раз не очень то и подходит. Кроме того, компилятор или JVM или DB — абы кого делать не допустят. А те специалисты, которые этим занимаются в разжёвывании элементарных вещей просто не нуждаются. Потому ни экономического ни технологического смысла применения UML в подобных проектах — просто нет.
Совсем другая картина в компаниях, которые занимаются автоматизацией — внутренней или внешней. В таких проектах предсказуемость сроков и качества работ выходят на первое место (клиенту то специфику IT обяснять никому не охота или собственному начальсту). Кроме того, привлекать к подобным проектам спецов такого уровня как в MS или Sun — просто не выгодно экономически. Требуется процесс разработки, который позволяет вести проекты при, в среднем, довольно средней квалификации программистов. Причём делать это прогнозируемым образом. А такой процесс неизбежно требует средств описания тех же моделей — в первую очередь для самих разработчиков. Вот там то UML и процветает — для этого то он (де факто) и был придуман.

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

AF> Без анализа какие компании применяют UML, в каких проектах и для чего — кроме беспредметного религиозного спора ничего не выйдет.
Ну не я же этот спор начал.. Собственно цель моего замечания была показать, что факт использования или не использования UML различными компаниями не может служить доказательством его нужности/не нужности при разработке софта. Так что тут совершенно нечего возразить.

AF> Если вы потратите время, что бы честно и спокойно ответить на эти вопросы — спорить станет не о чём.
Если на это тратить время, то оно окажется потрачено в пустую..

AF> Совсем другая картина в компаниях, которые занимаются автоматизацией — внутренней или внешней. В таких проектах предсказуемость сроков и качества работ выходят на первое место (клиенту то специфику IT обяснять никому не охота или собственному начальсту).
Стоп-стоп, а каким образом UML влияет на предсказуемость сроков? Что-то ничего, кроме как гарантировать что N-ое количество времени уйдет на рисование схем, в голову не приходит..

AF> Требуется процесс разработки, который позволяет вести проекты при, в среднем, довольно средней квалификации программистов. Причём делать это прогнозируемым образом. А такой процесс неизбежно требует средств описания тех же моделей — в первую очередь для самих разработчиков.
Не пойдет, за отмазку не канает... Проблема в том, что UML сам по себе достаточно сложен, и чтобы его адекватно применять разработчик и так должен быть хорошей квалификации. Соответственно разработчик низкой квалификации UML не понимает, а как только он начинает его понимать то его квалификация уже достаточно хороша, чтобы UML ему был не нужен.
Таким образом делаем вывод, что UML хорош в качестве buzz word, чтобы красиво разогнуть пальцы перед заказчиком, мол "... наши разработки ведуться по RUP с применением UML... " и подсунуть клиенту красивые диаграмки, чтобы тот покивал с умным видом и ощутил свою причасность. Вот для этого UML и используется.. хм... дефакто.

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

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

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

<skipped>
Очень противоречивое послание!
Со одной стороны вы говорите о порочности идеи, с другой стороны оговорите о той идеи, которая заложена в UML.
Про стандартизацию диаграмм и их множество, так и в русском языке тоже есть стандартизованные начертание 33-х букв, но ведь это не мешает использовать великий и могучий.
UML — это язык со своими "буквами", а то как вы его будете использовать, зависит только от вас.

С уважением,
bw.

Господа, идея с графами не нова. Увы, а может и нет....
http://www.mindmap.ru/
Есть книга на русском языке про "Карты Ума"
http://www.books.ru/shop/books/137550
Например, у нас в проекте аналитик использует прогу "Mind Map" для "сбора требований".


С уважением,
bw.

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

AF>> Требуется процесс разработки, который позволяет вести проекты при, в среднем, довольно средней квалификации программистов. Причём делать это прогнозируемым образом. А такой процесс неизбежно требует средств описания тех же моделей — в первую очередь для самих разработчиков.
M>Не пойдет, за отмазку не канает... Проблема в том, что UML сам по себе достаточно сложен, и чтобы его адекватно применять разработчик и так должен быть хорошей квалификации. Соответственно разработчик низкой квалификации UML не понимает, а как только он начинает его понимать то его квалификация уже достаточно хороша, чтобы UML ему был не нужен.
M>Таким образом делаем вывод, что UML хорош в качестве buzz word, чтобы красиво разогнуть пальцы перед заказчиком, мол "... наши разработки ведуться по RUP с применением UML... " и подсунуть клиенту красивые диаграмки, чтобы тот покивал с умным видом и ощутил свою причасность. Вот для этого UML и используется.. хм... дефакто.

Например, в telecom-секторе UML становится заменителем SDL, вобрав в себя все фичи последнего.
Поэтому использование UML для тех задач, которые хорошо сводятся с statemachine-ам и синхронному/асинхронному обмену сообщениями, дает существенное преимущество перед ручным кодированием этих самых statemachine. Реализация ручками hierarchical statemachine с поддержкой save-ов и guard conditions черезвычайно муторное дело на любом языке программирования.

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

_O_>Например, в telecom-секторе UML становится заменителем SDL, вобрав в себя все фичи последнего.
Интересно, но тут я склонен думать, что скорее пошли от обратного. Сначала наворотили очень богатый инструментарий, а потом нашли как его применять. И опять-таки не сколько на финальном этапе, как предполагал Alexey Rovdo, сколько на начальном, для создания основного кода.

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

AF>> Совсем другая картина в компаниях, которые занимаются автоматизацией — внутренней или внешней. В таких проектах предсказуемость сроков и качества работ выходят на первое место (клиенту то специфику IT обяснять никому не охота или собственному начальсту).
M>Стоп-стоп, а каким образом UML влияет на предсказуемость сроков? Что-то ничего, кроме как гарантировать что N-ое количество времени уйдет на рисование схем, в голову не приходит..
Ответ содержался в следующей строке того же абзаца. А именнно — компании не применяют UML, как они не применяют C++ или Basic (хотя и могут писать на нём кучу софта). Они применяют процесс разработки, основанный в том числе и на использовании UML. Эффект даёт именно процесс в целом, а не только и не столько UML.

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

M>Таким образом делаем вывод, что UML хорош в качестве buzz word, чтобы красиво разогнуть пальцы перед заказчиком, мол "... наши разработки ведуться по RUP с применением UML... " и подсунуть клиенту красивые диаграмки, чтобы тот покивал с умным видом и ощутил свою причасность. Вот для этого UML и используется.. хм... дефакто.
Выводы каждый делает сам... Тем более, что заказчику чаще всего до фени, что вы там делаете или не делаете — ему нужен софт — хороший, надёжный и точно в срок.

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

AF> Они применяют процесс разработки, основанный в том числе и на использовании UML. Эффект даёт именно процесс в целом, а не только и не столько UML.
Вопрос не в этом, а в том, является ли UML неотъемлимой частью этого процесса и проиграет ли процесс вообще, если из него изъять UML или, наоборот, выиграет. И я все больше склоняюсь к тому, что скорее выиграет.

AF> Это софистика.
Ну ясен хвост.

AF> На практике покажи начинающему разработчику программу и попытайся обяснить на словах, как она работает (без рисования диаграмм или набросков) — крайне редко тебя поймут.
Хм.. Меня почему-то понимают.

AF>А потом нарисуй диаграммы классов, последовательностей или состояний (смотря что полезнее в данном случае) — поймут гораздо быстрее.
Да меня вообще не поймут, если не будут обладать достаточной для этого квалификацией, проходили уже, UML далеко не тривиален. А разработчиков с квалификацией сейчас не найти, а если найти, то они и без UML-я все поймут.

AF>Тем более, что мастерство часто и состоит в том, что бы тебя поняли.
Правильно, только UML здесь далеко не помощник.

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

AF>> Они применяют процесс разработки, основанный в том числе и на использовании UML. Эффект даёт именно процесс в целом, а не только и не столько UML.
M>Вопрос не в этом, а в том, является ли UML неотъемлимой частью этого процесса и проиграет ли процесс вообще, если из него изъять UML или, наоборот, выиграет. И я все больше склоняюсь к тому, что скорее выиграет.

Вряд ли можно изъять UML из процессов, которые априори основаны именно на использовании этого языка. Другое дело, что можно применять другие процессы разработки, в которых роль UML-диаграм будут выполнять другие инструменты. Такие процессы могут быть похожи на существующие, однако это все-таки будут другие процессы. К примеру, представьте себе какое влияние на RUP могла бы оказать такая возможность как параллельная работа над структурой классов, реализация этих классов и тестирование уже готового кода. Я не хочу сказать, что запараллеливание данных работ будет полезным всегда. Но сегодня мы практически не имеем технической возможности реализовывать код и дорабатывать структуру приложения одновременно (разве только действовать с помощью инструментария, описанного _Obelisk_ ).

AndreyFedotov wrote:

> Это софистика. На практике покажи начинающему разработчику программу и
> попытайся обяснить на словах, как она работает (без рисования диаграмм
> или набросков) — крайне редко тебя поймут. А потом нарисуй диаграммы
> классов, последовательностей или состояний (смотря что полезнее в
> данном случае) — поймут гораздо быстрее. Проверял многократно.

Обычно гораздо эффективнее помогают не диаграммы в РациональнойРозе, а
простые наброски в виде квадратиков и стрелочек с надписями То есть
формальный синтаксис UML скорее мешает, чем помогает — проще
использовать нечто UML-подобное.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Обычно гораздо эффективнее помогают не диаграммы в РациональнойРозе, а
C>простые наброски в виде квадратиков и стрелочек с надписями То есть
C>формальный синтаксис UML скорее мешает, чем помогает — проще
C>использовать нечто UML-подобное.

Абсолютно согласен. Сам обычно так и делаю. Только вы вспомните, что UML и RUP разрабатывался не для маленьких групп в 3-5-10 и даже в 20 человек, он создавался на случаи, когда над одним и тем же проектом работает параллельно более 100 человек. Вот тогда наброски на бумаге вообще перестают работать — просто не возможно рисовать и рассказывать каждому одно и тоже.

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

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

AF>> Они применяют процесс разработки, основанный в том числе и на использовании UML. Эффект даёт именно процесс в целом, а не только и не столько UML.
M>Вопрос не в этом, а в том, является ли UML неотъемлимой частью этого процесса и проиграет ли процесс вообще, если из него изъять UML или, наоборот, выиграет. И я все больше склоняюсь к тому, что скорее выиграет.
При условии лучшей или адекватной замены. А её пока нет.

AF>> На практике покажи начинающему разработчику программу и попытайся обяснить на словах, как она работает (без рисования диаграмм или набросков) — крайне редко тебя поймут.
M>Хм.. Меня почему-то понимают.
Всегда? И сколько времени на это требуется?

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

AF>>Тем более, что мастерство часто и состоит в том, что бы тебя поняли.
M>Правильно, только UML здесь далеко не помощник.
Это как применять.

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

AF> При условии лучшей или адекватной замены. А её пока нет.
Ну здрасьте, караднаш, бумага, слюни — замена вполне адекватная.

AF>Всегда? И сколько времени на это требуется?
Всегда. Мало. Намного меньше чем я потратил бы только на рисование, не считая объяснений.

AF>Странно, а у меня почему-то понимают...
Действительно странно.

AF> Это как применять.
А как не применяй.

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

AF> Только вы вспомните, что UML и RUP разрабатывался не для маленьких групп в 3-5-10 и даже в 20 человек, он создавался на случаи, когда над одним и тем же проектом работает параллельно более 100 человек. Вот тогда наброски на бумаге вообще перестают работать — просто не возможно рисовать и рассказывать каждому одно и тоже.
А что, действительно есть проекты где более 100 человек делают одно и тоже и всем надо одно и то же объяснять? Это что, соревнование кто быстрее решит одну и ту же задачу?

AndreyFedotov wrote:

> C>Обычно гораздо эффективнее помогают не диаграммы в РациональнойРозе, а
> C>простые наброски в виде квадратиков и стрелочек с надписями То есть
> C>формальный синтаксис UML скорее мешает, чем помогает — проще
> C>использовать нечто UML-подобное.
> Абсолютно согласен. Сам обычно так и делаю. Только вы вспомните, что
> UML и RUP разрабатывался не для маленьких групп в 3-5-10 и даже в 20
> человек, он создавался на случаи, когда над одним и тем же проектом
> работает параллельно более 100 человек. Вот тогда наброски на бумаге
> вообще перестают работать — просто не возможно рисовать и рассказывать
> каждому одно и тоже.

Тогда эти наброски сканируем и рассылаем вместе с объяснениями.

Серьезно, очень удобно получается.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

AF> При условии лучшей или адекватной замены. А её пока нет.

Русския язык является достаточно адекватной заменой

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

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

AF>> При условии лучшей или адекватной замены. А её пока нет.
M>Ну здрасьте, караднаш, бумага, слюни — замена вполне адекватная.

Берём проект человек на 300-400. Ты уверен что у тебя на всех карандашей, слюней и здоровья хватит?

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

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

AF>> Только вы вспомните, что UML и RUP разрабатывался не для маленьких групп в 3-5-10 и даже в 20 человек, он создавался на случаи, когда над одним и тем же проектом работает параллельно более 100 человек. Вот тогда наброски на бумаге вообще перестают работать — просто не возможно рисовать и рассказывать каждому одно и тоже.
M>А что, действительно есть проекты где более 100 человек делают одно и тоже и всем надо одно и то же объяснять? Это что, соревнование кто быстрее решит одну и ту же задачу?
Есть, но не одно и тоже, но работают над общей и достаточно крупной задачей. Тот же MS — не к столу будь сказано... В таких проектах часто на первое место выходит не скорость разработки, а управляемость процесса. Без документации при такой толпе народа её не достичь. UML в данном случае вовсе не лучший и не обязательный вариант, но система обозначений должна быть единой. Карандаш и слюни этого не обеспечивают

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

AF>Берём проект человек на 300-400. Ты уверен что у тебя на всех карандашей, слюней и здоровья хватит?

Ой, я бы первым делом оставил человек 50, я еще лучше 20 Так больше гарантии уложится в сроки

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

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

_O_>>Например, в telecom-секторе UML становится заменителем SDL, вобрав в себя все фичи последнего.
M>Интересно, но тут я склонен думать, что скорее пошли от обратного. Сначала наворотили очень богатый инструментарий, а потом нашли как его применять. И опять-таки не сколько на финальном этапе, как предполагал Alexey Rovdo, сколько на начальном, для создания основного кода.

Не совсем так. Просто на стандарт UML 2.0 очень сильное влияние оказал стандарт SDL2000, а на SDL2000 в свое время оказал влияние набирающий обороты UML. Внедрения UML в нишу SDL-я есть ответ на потребности производства. Народ захотел UML-я, вот софтверные компании и прореагировали.

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

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

AF>> Только вы вспомните, что UML и RUP разрабатывался не для маленьких групп в 3-5-10 и даже в 20 человек, он создавался на случаи, когда над одним и тем же проектом работает параллельно более 100 человек. Вот тогда наброски на бумаге вообще перестают работать — просто не возможно рисовать и рассказывать каждому одно и тоже.

M>А что, действительно есть проекты где более 100 человек делают одно и тоже и всем надо одно и то же объяснять? Это что, соревнование кто быстрее решит одну и ту же задачу?

Я видел UML модель, над которой работает порядка 200 человек. Делают они, конечно, не одно и тоже, но работают с одной и той же моделью.
Число типов в данной модели превышает 100 000.

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

AF>Берём проект человек на 300-400. Ты уверен что у тебя на всех карандашей, слюней и здоровья хватит?
Еще раз, можешь привести пример проекта, где 300-400 человекам надо объяснять одно и то же?
Конкретная задача ставится десятку людей.

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

AF> Есть, но не одно и тоже, но работают над общей и достаточно крупной задачей.
Над общей задачей работает десяток человек.

AF>В таких проектах часто на первое место выходит не скорость разработки, а управляемость процесса. Без документации при такой толпе народа её не достичь.
Правильно, только опять-таки, UML здесь не помощник.

AF>UML в данном случае вовсе не лучший и не обязательный вариант, но система обозначений должна быть единой. Карандаш и слюни этого не обеспечивают
Это обеспечивает сам код, очередной раз осмелюсь утверждать, что код не менее, если не более выразителен, нежели UML.

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

_O_> Внедрения UML в нишу SDL-я есть ответ на потребности производства. Народ захотел UML-я, вот софтверные компании и прореагировали.
Сдается мне, что ситуация развивалась примерно так: Потребность в программировании посредством неких визуальных инструментов для ряда задач была довольно давно, и каждый удовлетворял ее по своему. Потом появился UML и на волне энтузиазма, когда казалось, что все недостатки UML-я это лишь вопрос инструментария, всем миром начали создавать впечатляющие по функциональности конструкции для работы с UML-ем. И в какой-то момент оказалось, что эти конструкции великолепно справляются с задачами, для которых ранее предназначались собственноручно написанные поделки, что естественно привело к использованию UML-я для этого класса задач.

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

C>Тогда эти наброски сканируем и рассылаем вместе с объяснениями.
C>Серьезно, очень удобно получается.

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

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

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

AF>>Берём проект человек на 300-400. Ты уверен что у тебя на всех карандашей, слюней и здоровья хватит?
M>Еще раз, можешь привести пример проекта, где 300-400 человекам надо объяснять одно и то же?
M>Конкретная задача ставится десятку людей.

Любимый отцами основателями RUP проект системы управления воздушным движением в Канаде — устроит?

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

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

AF>>Берём проект человек на 300-400. Ты уверен что у тебя на всех карандашей, слюней и здоровья хватит?

M>Ой, я бы первым делом оставил человек 50, я еще лучше 20 Так больше гарантии уложится в сроки

Я бы тоже. Потому нас никогда рулить в крупную фирму и не запустят.

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

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

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

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

AF>> Есть, но не одно и тоже, но работают над общей и достаточно крупной задачей.
M>Над общей задачей работает десяток человек.

AF>>В таких проектах часто на первое место выходит не скорость разработки, а управляемость процесса. Без документации при такой толпе народа её не достичь.
M>Правильно, только опять-таки, UML здесь не помощник.
Кому как. Я тоже отнюдь не фанат UML, но как прогматик вижу, что есть места, где он применяется успешно. Их и условия, когда он успешно применяется я и постарался показать. Вы же повторяете то, что и так очевидно, а именно, что UML вовсе не панацея, более того — даже как огранниченный интсрумент — вовсе не лучшее решение.

AF>>UML в данном случае вовсе не лучший и не обязательный вариант, но система обозначений должна быть единой. Карандаш и слюни этого не обеспечивают
M>Это обеспечивает сам код, очередной раз осмелюсь утверждать, что код не менее, если не более выразителен, нежели UML.
Это смотря для кого.

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

AF>Любимый отцами основателями RUP проект системы управления воздушным движением в Канаде — устроит?
Там что 300-400 человек делали одно и то же, над одной общей моделью? "Не верю"

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

AF>Кому как. Я тоже отнюдь не фанат UML, но как прогматик вижу, что есть места, где он применяется успешно.
А я, как прагматик, вижу, что можно великолепно обходиться и без него..

AF> Их и условия, когда он успешно применяется я и постарался показать.
К сожалению не абсолютно не убедительно. Ни одного реального обоснования его использования я не увидел, только от _Obelisk_ был внятный пример в достаточно узкой области, и то, там UML не сколько инструмент моделирования, колько непосредственно разработки.

AF> Вы же повторяете то, что и так очевидно, а именно, что UML вовсе не панацея, более того — даже как огранниченный интсрумент — вовсе не лучшее решение.
Ну если очевидно, что это не лучшее решение, то зачем его использовать?

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

_O_>Я видел UML модель, над которой работает порядка 200 человек. Делают они, конечно, не одно и тоже, но работают с одной и той же моделью.
_O_>Число типов в данной модели превышает 100 000.

А сколько человек использует в проектах .NET Framework, VCL, MFC, ADO? В документации по ним UML диаграмма скорее исключение, чем правило.

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

M>>Ой, я бы первым делом оставил человек 50, я еще лучше 20 Так больше гарантии уложится в сроки

AF>Я бы тоже. Потому нас никогда рулить в крупную фирму и не запустят.

Хорошо, уточнюсь. Код системы разрабатывало бы не больше 20-30 человек. А остальных найдем чем занять. Пусть пишут документацию, учебники, разрабатывают примеры использования, тестируют, ... И даже могут по коду составлять UML-диаграммы, нотолько исключительно для заказчика

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

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

AF>>Любимый отцами основателями RUP проект системы управления воздушным движением в Канаде — устроит?
M>Там что 300-400 человек делали одно и то же, над одной общей моделью? "Не верю"
Это к отцам-основателям...

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

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

AF>>Кому как. Я тоже отнюдь не фанат UML, но как прогматик вижу, что есть места, где он применяется успешно.
M>А я, как прагматик, вижу, что можно великолепно обходиться и без него..
Разве я где то утвержал обратное?

AF>> Их и условия, когда он успешно применяется я и постарался показать.
M>К сожалению не абсолютно не убедительно. Ни одного реального обоснования его использования я не увидел, только от _Obelisk_ был внятный пример в достаточно узкой области, и то, там UML не сколько инструмент моделирования, колько непосредственно разработки.
Но и там можно обходиться без UML
В действительности нет такой области где без UML нельзя было бы обойтись. Я просто привёл примеры того, где он успешно применяется.

AF>> Вы же повторяете то, что и так очевидно, а именно, что UML вовсе не панацея, более того — даже как огранниченный интсрумент — вовсе не лучшее решение.
M>Ну если очевидно, что это не лучшее решение, то зачем его использовать?
Затем же, зачем используются все остальные не лучшие решения... Тем более — что лучшего, чем рисовать на бумажке, вы так и не смогли придумать.

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

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

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

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

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

M>>>Ой, я бы первым делом оставил человек 50, я еще лучше 20 Так больше гарантии уложится в сроки

AF>>Я бы тоже. Потому нас никогда рулить в крупную фирму и не запустят.

M>Хорошо, уточнюсь. Код системы разрабатывало бы не больше 20-30 человек. А остальных найдем чем занять. Пусть пишут документацию, учебники, разрабатывают примеры использования, тестируют, ... И даже могут по коду составлять UML-диаграммы, нотолько исключительно для заказчика

Это далеко не всегда возможно. Простой пример: разработка крупного программно-аппаратного комплекса. В таком комплексе зачастую одни и теже алгоритмы реализуются на различной аппаратуре, причём видов этой аппратуры — 30-40. Система структурируется и каждый уровень должен быть грамотно описан, что бы различные разработчики делали аппаратуру под один и тот же стандарт. Тем более, если часть аппратуры или ПО разрабатываются вовне — в другом городе и тем более стране. Вот и попробуй в таких условиях выделить 20-30 человек, которые всё сделают...

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

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

1. Я однажды уже высказывал тут мысль, что для систем написанных в стиле "спагетти" бесполезно пытаться "восстанавливать" архитектуру или дизайн. Что можно описать с т.з. дизайна, в клиент-серверной системе, написанной в классическом RAD стиле -- когда на формы накидано куча db-aware контролов? Если для этого попытаться применить UML, то он онечно же БЕСПОЛЕЗЕН в таком случае. Ибо говорить про архитектуру и дизайн такой системы довольно сложно. Да, такая система может использовать наборы своих контролов, которые можно описать в UML ... но это, пардон,описание дизайна этих конролов, а не дизайна и тем более не архитектуры конкретной прикладной системы.
2. Зачастую дают общую оценку применимости языка/нотации и т.п. не зная достаточно глубоко возможностей этого языка/нотации или делая попытку НЕ ПРАВИЛЬНОГО использования НЕ ПОДХОДЯЩИХ для решения данной задачи средств ... показателен один пример -- ко мне подошел один разработчик, говорит, что хочет использовать Rational Rose для описания кода его части системы. UML он почитал, сделал реверс инжиниринг системы в Rose ... у него куча всего там нарисовано -- он и говорит -- блин, Rose -- фигня, буду пробовать другие инструменты. Попробовал (я не в курсе правда что он еще пробовал) -- пришел к выводу, что UML -- вообще фигня. Стали разбираться ... после чего он пришел к выводу, что для описания того "как он себе представляет систему" UML не совсем то что нужно ... . И он пустился в творчество -- делая синтез из всех известных ему языков/нотаций -- результат долигх творческих мучений, как обычно нулевой . После того как его творческий запал иссяк ... мы просто поговорили про юзкейсы (в том проекте они были применимы) про отделение бизнес-логики ... и о чудо ... при таком подходе UML оказался пригоден .
3. UML действительно универсальный язык ... но потзоваться им желательно как это рекомендуют методологии ... тот же RUP, тогда все становится на свои места. И дизайн прослеживается и программная архитектура появляется с разных views описанная.

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

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

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

AF> В результате довольно часто наблюдаю картину, когда талантливый разработчик пытается найти общий язык с бизнесменом. И пытается использовать для этих целей UML (который бизнесмену изучать как то не хочется). В результате разочаровывается в UML и появляются посты, вроде того, который написал автор ветки. Мол UML не для всего подходит. Да он и не предназначался для этого! UML предназначался лишь для описания процессов в системе на уровне построения и реализации системы. Но не на уровне бизнес-логики. Для последнего существует IDEFx.

Есть один комментарий, по поводу использования UML для описания бизнес-процессов (видимо под бизнес-логикой имелось ввиду это). Во-первых нужно определиться в конкретном случае, что мы хотим от формализации бизнес-процессов. Если хотим их "измерять" с т.з. например эффективности и потом реинженирить ... то это один случай, и тут лучше использовать специализированный инструментарий для бизнес-моделирования. А если речь идет о том, что нам нужно понять как автоматизировать эти процессы (выдвигая предположение, что сами процессы упорядоченны), то в этом случае мы можем использовать UML. Например в нотации Rose для бизнес-моделирования -- и через реализацию бизнес-юзкейсов выйти на системные юзкейсы а оттуда и на дизайн системы. Другой вопрос, что бизнес-юзкейсы не всегда применимы, но и на этот случай есть свои решения. Использованию UML для понимания места информационной системы в деятельности предприятия и понимания границ системы и требований к системе, вполне имеет право на жизнь -- преимущество -- явный переход от БП к требованиям к системе и возможность использования единого языка. Недостатки -- в каждом конкретном случае свои ...

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

AF>Разве я где то утвержал обратное?
А зачем тогда было не соглашаиться?

AF>Но и там можно обходиться без UML
Можно, но, видимо, неудобно. Там он приносит пользу, в отличии от остальных способов применения, которые Вы пытались придумать.

AF> Я просто привёл примеры того, где он успешно применяется.
А зачем? Во всех этих примерах он мог с не меньшим, если не с большим успехом не применяться.

AF> Тем более — что лучшего, чем рисовать на бумажке, вы так и не смогли придумать.
Но это лучшее решение, чем UML, в предложенных областях, так зачем выбирать менее пригодный в реальном использовании UML?

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

AF>Я тут именно эту мысль и пытаюсь донести — что UML применять нужно чётко отслеживая условия его применения, желательно в рамках методологии, для которой он был разработан.
Но я так и не смог выяснить зачем надо применять UML, отслеживать условия его применения, обучать разработчиков и вообще тратить на него усилия, если все можно сделать и без него, с не менее стройной архитектурой?
В ответ только общие слова и ссылки на то, что большие дядьки его применяют — не серьезно.

AF>А в ответ раздаётся, что БД с контролами можно сделать и без UML, что он там вреден и на этом основании делается очень глубокий вывод, что UML вообще не применим...
Где такое раздается? Я не отрицаю, что UML применим, им даже пользуются, но практической выгоды, кроме дурения головы заказчику, за исключением специальных случаев, я не ощущаю.

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

AF>>Но и там можно обходиться без UML
M>Можно, но, видимо, неудобно. Там он приносит пользу, в отличии от остальных способов применения, которые Вы пытались придумать.
Если вы не способны увидеть приносимую пользу, ещё не означает, что её там нет.

AF>> Я просто привёл примеры того, где он успешно применяется.
M>А зачем? Во всех этих примерах он мог с не меньшим, если не с большим успехом не применяться.
Это утверждение нуждается в доказательствах. Их то я как раз и не видел.

AF>> Тем более — что лучшего, чем рисовать на бумажке, вы так и не смогли придумать.
M>Но это лучшее решение, чем UML, в предложенных областях, так зачем выбирать менее пригодный в реальном использовании UML?
В предложенных мной областях и упомянутых мной случаях это не является лучшим решением. Как и худшим. Вам не кажется, что немного наивно заочно рассуждать о крупных проектах и говорить о том, что там лучше, а что хуже? Тем паче, что у тех, кто имеет возможность судить об этом точка зрения совсем иная.

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

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

AF>> В результате довольно часто наблюдаю картину, когда талантливый разработчик пытается найти общий язык с бизнесменом. И пытается использовать для этих целей UML (который бизнесмену изучать как то не хочется). В результате разочаровывается в UML и появляются посты, вроде того, который написал автор ветки. Мол UML не для всего подходит. Да он и не предназначался для этого! UML предназначался лишь для описания процессов в системе на уровне построения и реализации системы. Но не на уровне бизнес-логики. Для последнего существует IDEFx.

B>Есть один комментарий, по поводу использования UML для описания бизнес-процессов (видимо под бизнес-логикой имелось ввиду это).
Да, именно это я и имел в виду.
B>Во-первых нужно определиться в конкретном случае, что мы хотим от формализации бизнес-процессов. Если хотим их "измерять" с т.з. например эффективности и потом реинженирить ... то это один случай, и тут лучше использовать специализированный инструментарий для бизнес-моделирования.

Совершенно согласен.

B>А если речь идет о том, что нам нужно понять как автоматизировать эти процессы (выдвигая предположение, что сами процессы упорядоченны), то в этом случае мы можем использовать UML. Например в нотации Rose для бизнес-моделирования -- и через реализацию бизнес-юзкейсов выйти на системные юзкейсы а оттуда и на дизайн системы. Другой вопрос, что бизнес-юзкейсы не всегда применимы, но и на этот случай есть свои решения. Использованию UML для понимания места информационной системы в деятельности предприятия и понимания границ системы и требований к системе, вполне имеет право на жизнь -- преимущество -- явный переход от БП к требованиям к системе и возможность использования единого языка. Недостатки -- в каждом конкретном случае свои ...
В общем согласен. Но тут есть одна тонкость. Называется плавный переход. Я имею в виду, что часто заранее не ясно, что будет делаться и какова конечная цель моделирования бизнесс процессов. Кому и зачем потребуется модель. В таком случае как правило выгоднее начинать таки с формального описания процессов в виде IDEFx и лишь потом переходить к UML. По следующим соображениям:
Нотация IDEF мне кажется более простой и понятной неискушённому наблюдателю (это подтверждается практикой), она принята именно для этих целей. Она более компактна — что в случае сложных бизнесс-процессов крайне важно, так как тут очень важна выразительность. И наконец от нотации IDEF довольно легко перейти "вниз" — к нотации UML.
Хотя если проект маленький и основное понятно на уровне интуиции... Тогда можно сразу использовать UML, ну а если совсем маленький — так и вообще карандашём обойтись.

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

AF>Если вы не способны увидеть приносимую пользу, ещё не означает, что её там нет.
Ну, во-первых, я не один такой. А во-вторых, рассуждать с позиции "Вам не понять, вы не любили" не самое удачное доказательство.

AF>Это утверждение нуждается в доказательствах. Их то я как раз и не видел.
Как раз наоборот. Утверждение, что UML может быть полезен нуждается в доказательствах. И пока таковых нет.

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

AF>Вам не кажется, что немного наивно заочно рассуждать о крупных проектах и говорить о том, что там лучше, а что хуже? Тем паче, что у тех, кто имеет возможность судить об этом точка зрения совсем иная.
Во-первых, мне именно так и кажется и поэтому мне совершенно не понятны Ваши постоянные кивки на большие проекты, особенно в свете того, что по Вашему же признанию UML Вы не используете, "но вот умные дядьки в больших проектах...".
А во-вторых, у тех кто имеет возможность регулярно сталкиваться с большими проектами частенько оказывается примерно та же точка зрения что я изложил.

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

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

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

Автор: AndreyFedotov
Дата: 14.06.05

.
Ну не ограничивается всё однотипными программками.

AF>>А в ответ раздаётся, что БД с контролами можно сделать и без UML, что он там вреден и на этом основании делается очень глубокий вывод, что UML вообще не применим...
M>Где такое раздается? Я не отрицаю, что UML применим, им даже пользуются, но практической выгоды, кроме дурения головы заказчику, за исключением специальных случаев, я не ощущаю.
Но так дело скорее всего в том, что в вашем случае этой выгоды может просто и не быть. Я видел не очень много ситуаций в России — особенно в мелких и средних фирмах, когда подобная документация себя бы окупала. Любая, даже не основанная на UML. Потому весьма вероятно, что для ваших условий вы абсолютно правы. Но это не основание не видеть пользы от UML вообще

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

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

AR>>А нельзя ли чуть подробнее раскрыть суть этой идеи или дать ссылочки. Я лично с VS 2005 пока не работал, посему любопытно.
M>В двух словах: архитектор создает свой DSL (Domain Specific Language) под конкретную задачу, и уже в терминах этого языка описывает модель. В момент описания модели код генерится на лету, нет необходимости даже нажимать нарошную кнопку для генерации исходников. В таком виде проект поступает к разработчику, разработчик правит код, и все его изменения моментально отражаются в модели, терминах DSL, и опять-таки нет никакой необходимости нажимать хитрые кнопки, чтобы получить актуальное состояние модели, это 100% on-line инструмент, оба представления проекта, и код, и DSL, всегд анаходятся в актуальном состоянии откуда бы проект не правили. DSL так же поддерживает валидацию, в отличии от UML-я.

M>http://msdn.microsoft.com/library/en-us/dnvs05/html/vstsmodel.asp

Вы будете смеяться, но это всё давно (лет уже как 5 — 7) реализовано в Togethersoft Control Center (который сейчас принадлежит Борланду) применительно к UML. Актуальность кода и диаграмм поддерживается автоматически, независимо от разработчика и количества людей, правивших этот код или диаграммы. Классы можно одновременно просматривать как в виде диаграмм, так и кода — в соседних видах. Изменение диаграммы автоматически приводит к изменению кода и наоборот. По методу класса можно автоматически построить sequence диаграмму, в которой отобразятся все внутренние и внешние вызовы, создания и уничтожения объектов, условные операторы, циклы. По любой диаграмме классов и последовательности выполнения (sequence) автоматически генерируется исходный код (болванка) на выбранном (C++, Java и др. объектно-ориентированные) языке. Создание документации (в формате javadoc) автоматизировано, при условии, что разработчик добросовестно комментирует код и придерживается некоторых простых правил, принятых в javadoc.
Работает это всё как под виндами, так и под юниксами, потому что написано на java.

Так что M$, как обычно, идёт своей путёй. И дело на в буквах DSL или UML, а в реализации.

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

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

AF>>Если вы не способны увидеть приносимую пользу, ещё не означает, что её там нет.
M>Ну, во-первых, я не один такой. А во-вторых, рассуждать с позиции "Вам не понять, вы не любили" не самое удачное доказательство.
Стоит ли передёргивать. Если вы не видите чёрную кошку в тёмной комнате — это ещё не значит, что её там нет. Тем более, что вы не один такой.

AF>>Это утверждение нуждается в доказательствах. Их то я как раз и не видел.
M>Как раз наоборот. Утверждение, что UML может быть полезен нуждается в доказательствах. И пока таковых нет.
Плохо учили математику батенька! Любое утверждение нужно либо доказать, либо опровергнуть. Вы не можете опровергнуть этого утверждения и не можете доказать обратного. Так что пока никто и ничего не доказал. Всего лишь спор пары софистов.

AF>>В предложенных мной областях и упомянутых мной случаях это не является лучшим решением.
M>Хорошо, это решение как минимум не хуже, чем UML,
Это всего лишь ваше частное мнение.
M>соответственно, для того, чтобы UML использовать он должен хоть как-то оправать свое использование, то есть быть хоть чем-то лучше. Пока этого не наблюдается.
Соответственно дальнейшие рассуждения и вывод под вопросом. А вот то, что инвестиции в UML пока растут — факт.

AF>>Вам не кажется, что немного наивно заочно рассуждать о крупных проектах и говорить о том, что там лучше, а что хуже? Тем паче, что у тех, кто имеет возможность судить об этом точка зрения совсем иная.
M>Во-первых, мне именно так и кажется и поэтому мне совершенно не понятны Ваши постоянные кивки на большие проекты, особенно в свете того, что по Вашему же признанию UML Вы не используете, "но вот умные дядьки в больших проектах...".
Напомню, что сами отцы основатели, хоть и говорили о применимости принципов разработки для проектов любого размера, при этом оговаривались, что применение как методологий, так и инструментария (в том числе и UML) — оправдано лишь в достаточно крупных проектах. Потому, во-первых не удивительно, что в нашем случае толку от UML не много, а во-вторых — только и остаётся, что ссылаться на эти проекты, так как я не копрорация IBM и по 30-40 крупных проектов за раз не веду...

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

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

AF> Для того, что бы было возможно общение между собой больших групп специалистов — в том числе из смежных областей. Я уже описывал подобную ситуацию здесь

Автор: AndreyFedotov
Дата: 14.06.05

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


AF>Но это не основание не видеть пользы от UML вообще
Равно ка ки не основание видеть эту пользу... "Так в чем польза, брат?" (c)

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

AF>Стоит ли передёргивать. Если вы не видите чёрную кошку в тёмной комнате — это ещё не значит, что её там нет.
Я то как раз не передергиваю, я лишь прошу эту черную кошку показать, если уж Вы утверждаете, что она там есть.

AF>Плохо учили математику батенька!
Это не математика, это логика.

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

AF> А вот то, что инвестиции в UML пока растут — факт.
Да не факт, энтузиазм по этому поводу сильно поутих в последнее время.

AF>Напомню, что сами отцы основатели, хоть и говорили о применимости принципов разработки для проектов любого размера, при этом оговаривались, что применение как методологий, так и инструментария (в том числе и UML) — оправдано лишь в достаточно крупных проектах. Потому, во-первых не удивительно, что в нашем случае толку от UML не много, а во-вторых — только и остаётся, что ссылаться на эти проекты, так как я не копрорация IBM и по 30-40 крупных проектов за раз не веду...
Ну и что Вы тогда с ним носитесь, если реальной пользы он Вам не приносит? Верите на слово большим дядькам? Зря, обманут и не поморщатся....

AF>А каков размер этих проектов?
Каков размер проектов Microsoft?
Или вот Mishka, который тоже засветился в этом топике, как то упоминал, что размер его проекта был порядка 50000 классов, если я правильно помню. И ничего, живут без UML-я и радуются...

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

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

AF>> Для того, что бы было возможно общение между собой больших групп специалистов — в том числе из смежных областей. Я уже описывал подобную ситуацию здесь

Автор: AndreyFedotov
Дата: 14.06.05

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

Ой, это очень по-разному ... и через руководителей и и между собой ... так что варианты имеются.

AF>>Но это не основание не видеть пользы от UML вообще
M>Равно ка ки не основание видеть эту пользу... "Так в чем польза, брат?" (c)

Что есть польза? Видимо для каждого она своя ... Например мы в небольшом проекте из 4-х человек использовали подход на базе RUP ... начиная с vision, требований (юзкейсов) и domain model, выстраивали, почти по Ларману, дизайн системы. Что нам это дало -- мы рассуждали в терминах наших бизнес-классов и в рамках сценариев наших юзкейсов. У нас был один разработчик-надомник -- он получал модели и это избавляло нас от неоднозначности в понимании реализации бизнес-логики и долгих пояснений что да как ... . Кроме этого мы трассировали наши требования (фичи и юзкейсы) с элементами дизайна (на уровне пакетов) -- и коонтролировали тем самым реализацию требований. Тестирование в целях экономии взялся сам заказчик.

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

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

_O_>> Внедрения UML в нишу SDL-я есть ответ на потребности производства. Народ захотел UML-я, вот софтверные компании и прореагировали.
M>Сдается мне, что ситуация развивалась примерно так: Потребность в программировании посредством неких визуальных инструментов для ряда задач была довольно давно, и каждый удовлетворял ее по своему. Потом появился UML и на волне энтузиазма, когда казалось, что все недостатки UML-я это лишь вопрос инструментария, всем миром начали создавать впечатляющие по функциональности конструкции для работы с UML-ем. И в какой-то момент оказалось, что эти конструкции великолепно справляются с задачами, для которых ранее предназначались собственноручно написанные поделки, что естественно привело к использованию UML-я для этого класса задач.

Ну SDL существует с середины 80-х. Основная проблема его была в алгебраическом подходе к определению типов данных и, как следствие, в навороченном name resolution by context. Этот подход чересчур формальный и неудобный. UML позволяет описывать типы проще. А недостатки UML-я были видны telecom-сообществу сразу, оно просто ждало, пока эти недостатки начнут устранять.

Могу попугать определяением типа Integer в SDL2000:

value type Integer
  literals unordered nameclass (('0':'9')*) ('0':'9'));
  operators
    "-"        ( this Integer                                ) -> this Integer;
    "+"        ( this Integer, this Integer    ) -> this Integer;
    "-"        ( this Integer, this Integer    ) -> this Integer;
    "*"        ( this Integer, this Integer    ) -> this Integer;
    "/"        ( this Integer, this Integer    ) -> this Integer raise DivisionByZero;
    "mod"    ( this Integer, this Integer    ) -> this Integer raise DivisionByZero;
    "rem"    ( this Integer, this Integer    ) -> this Integer;
    "<"        ( this Integer, this Integer    ) -> Boolean;
    ">"        ( this Integer, this Integer    ) -> Boolean;
    "<="    ( this Integer, this Integer    ) -> Boolean;
    ">="    ( this Integer, this Integer    ) -> Boolean;
    power    ( this Integer, this Integer    ) -> this Integer;
    bs in nameclass '''' ( (('0' or '1')*'''B') or ((('0':'9') or ('A':'F'))*'''H') )
                         -> this Integer;
axioms    noequality
    for all a,b,c in Integer (
/* constructors are 0, 1, +, and unary - */
/* equalities between constructor terms */
    (a + b) + c                        == a + (b + c);
    a + b                                        == b + a;
    0 + a                                        == a;
    a + (- a)                            == 0;
    (- a) + (- b)                == - (a + b);
    <<type Integer>> - 0    == 0;
    - (- a)                                == a;
/* */
/* definition of binary "-" by other operations */
    a - b                                        == a + (- b);
/* */
/* definition of "*" by applying it to all constructors */
    0 * a                                        == 0;
    1 * a                                        == a;
    (- a) * b                            == - (a * b);
    (a + b) * c                        == a * c + b * c;
/* */
/* definition of "<" by applying it to all constructors */
    a < b                                                                                == 0 < (b - a);
    <<type Integer>> 0 < 0                                        == false;
    <<type Integer>> 0 < 1                                        == true ;
    0 < a                                == true ==> 0 < (- a)        == false;
    0 < a and 0 < b        == true ==> 0 < (a + b)    == true ;
/* */
/* definition of ">", "equal", "<=", and ">=" by other operations */
    a > b                                        == b < a;
    equal(a, b)                        == not(a < b or a > b);
    a <= b                                    == a < b or a = b;
    a >= b                                    == a > b or a = b;
/* */
/* definition of "/" by other operations */
    a / 0                                                                                            == raise DivisionByZero;
    a >= 0 and b > a                    == true ==> a / b    == 0;
    a >= 0 and b <= a and b > 0    == true ==> a / b    == 1 + (a-b) / b;
    a >= 0 and b < 0                    == true ==> a / b    == - (a / (- b));
    a < 0 and b < 0                            == true ==> a / b    == (- a) / (- b);
    a < 0 and b > 0                            == true ==> a / b    == - ((- a) / b);
/* */
/* definition of "rem" by other operations */
    a rem b == a - b * (a/b);
/* */
/* definition of "mod" by other operations */
    a >= 0 and b > 0                                ==> a mod b    == a rem b;
    b < 0                                                                ==> a mod b    == a mod (- b);
    a < 0 and b > 0 and a rem b = 0    ==> a mod b    == 0;
    a < 0 and b > 0 and a rem b < 0    ==> a mod b    == b + a rem b;
    a mod 0 == raise DivisionByZero;
/* */
/* definition of power by other operations */
    power(a, 0)                            == 1;
    b > 0 ==> power(a, b)    == a * power(a, b-1);
    b < 0 ==> power(a, b)    == power(a, b+1) / a; );
/* */
/* definition of literals */
    <<type Integer>> 2    == 1 + 1;
    <<type Integer>> 3    == 2 + 1;
    <<type Integer>> 4    == 3 + 1;
    <<type Integer>> 5    == 4 + 1;
    <<type Integer>> 6    == 5 + 1;
    <<type Integer>> 7    == 6 + 1;
    <<type Integer>> 8    == 7 + 1;
    <<type Integer>> 9    == 8 + 1;
/* */
/* literals other than 0 to 9 */
    for all a,b,c in Integer nameclass (
    spelling(a) == spelling(b) // spelling(c),
    length(spelling(c)) == 1                                    ==> a == b * (9 + 1) + c;
    );
/* */
/* hex and binary representation of Integer */
    for all b in Bitstring nameclass (
    for all i in bs nameclass (
    spelling(i) == spelling(b)                                ==> i == <<type Bitstring>>num(b);
    ));
endvalue type Integer;

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

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

_O_>>Я видел UML модель, над которой работает порядка 200 человек. Делают они, конечно, не одно и тоже, но работают с одной и той же моделью.
M>А польза от этого есть? Может им проще было бы работать не с одной моделью, а с двадцатью, на каждую конкретную подзадачу?

Я же говорил, что для ряда задач UML очень хорошо подходит. Сия модель содержит гигантское число statemachine. Поэтому использование UML здесь оправдано. Насчет деления на мелкие подзадачи — не уверен, что возможно. Я не специалист в той области (разработка всяких девайсов для телекоммуникационных сетей нового поколения), чтобы адекватно оценить возможность разбития на подзадачи.
По косвенным данным могу сделать вывод, что это модель сама по себе уже есть некоторая подзадача другой задачи

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

M>Таким образом делаем вывод, что UML хорош в качестве buzz word, чтобы красиво разогнуть пальцы перед заказчиком, мол "... наши разработки ведуться по RUP с применением UML... " и подсунуть клиенту красивые диаграмки, чтобы тот покивал с умным видом и ощутил свою причасность. Вот для этого UML и используется.. хм... дефакто.

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

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

B>Вау ... вот уж чего я никогда не делал, так это не показывал заказчику UML ... это ж безумие заставлять заказчика понимать UML ...

Ну... а сели заказчик настаивает на UML? Если у заказчика есть отдел IT?

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


M>Хорошо, уточнюсь. Код системы разрабатывало бы не больше 20-30 человек. А остальных найдем чем занять. Пусть пишут документацию, учебники, разрабатывают примеры использования, тестируют, ... И даже могут по коду составлять UML-диаграммы, нотолько исключительно для заказчика

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

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

C>Обычно гораздо эффективнее помогают не диаграммы в РациональнойРозе, а
C>простые наброски в виде квадратиков и стрелочек с надписями То есть
C>формальный синтаксис UML скорее мешает, чем помогает — проще
C>использовать нечто UML-подобное.

... и потом долго пояснять напарникам или не дай бог субконтрактерам-кодировщикам что же ты имел ввиду

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

B>Полный бред, что UML это базворд для надувания счек перед заказчиком ... большинству заказчиков пофигу на UML ты проектируешь или просто код пишешь ...

Ну... в одном из проектов UML-диаграммы входили в ТЗ, Посему об этом и пишу IT департамент со стороны заказчика даже вносил в них изменения, мол на самом деле к нас не так, а вто так.

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

Я не считаю UML хорошим решением проблем собственно в качестве средства разработки. Но глупо отрицать его полезность как средства документирования сложных проектов и систем. Даже опытный разработчик, непосредственно участвовавший в проекте, возращаясь к своим "бумажкам и слюням" через пол года — год уже может запутаться в этом зоопарке. Что же говорить о проектах/системах, которые, к примеру, были куплены у другой компании, а теперь с ними начинает работу совершенно новая группа, не имеющая возможности что-то уточнить у своих предшественников. Попробуйте продать сложный продукт, если у вас есть только исходные коды (пусть даже хорошо откомментированные). За это без самих разработчиков никто гроша ломанного не даст. А вот за хорошо задокументированные (в т.ч. и с помощью стандартных UML-средств) проекты в мире иногда платят миллионы и более.

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

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


M>Я так и не услышал ответа на вопрос, чем может помочь UML построенный по готовой модели.

Поможет, например, управлять сложностью. Лично я предпочту увидеть картинку где будет изобраден некий фреймворк (в виде диагрмм классов).
Интересен момент, что говоря о UML вы как-то циклитесь только на диаграммах классов ... коллаборэйшн, деплоймент диаграммы как-то особо не упоминаются ...
Диаграмма классов показывает только статику ... как мне увиидить динамику взаимодействия объектов???
Кроме этого, пример из практики ... у нас например разработка ведеться на разных языках: Visual Basic, С++, Delphi, Java ... вы, что мне как проектировщику или архитектору предлагаете при проектировании систем автоматизации бизнеса знать все особенности этих языков ... чтобы общаться с разработчиками? Бред ... мне достаточно спроектировать модель анализа (да, да ... на UML) ... где я покажу реализацию юзкейсов, например, ... а в конкретной среде разработки ее будут имплементировать конкретные разработчики, подключая необходимые библиотеки и прочия ...

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

B>Вау ... вот уж чего я никогда не делал, так это не показывал заказчику UML ...
Ну, это была не моя идея... Я лишь ее творчески развил. А так, действительно, одно из реальных применений UML.

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


B>Полный бред, что UML это базворд для надувания счек перед заказчиком ...
Это не бред, это жизнь такая... Как раз такое, очень практическое применение UML-я, действительно приносит пользу.

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

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

AR> Но глупо отрицать его полезность как средства документирования сложных проектов и систем.
Глупо было бы считать что он полезен для документирования сложных проектов и схем.

AR> Даже опытный разработчик, непосредственно участвовавший в проекте, возращаясь к своим "бумажкам и слюням" через пол года — год уже может запутаться в этом зоопарке.
Опытному разработчику достаточно кода, а не опытному тем более.

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

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

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

B>>Вау ... вот уж чего я никогда не делал, так это не показывал заказчику UML ... это ж безумие заставлять заказчика понимать UML ...

M>Ну... а сели заказчик настаивает на UML? Если у заказчика есть отдел IT?

Вы что систему продаете вместе с исходниками???? Или разрабатываете вместе с представителями заказчика? Скорее всего нет ... но в любом случае желание заказчика нужно уважать ... в конце концов он деньги платит. Для начала стоит понять, а его отдел IT вообще в состянии говорить на UML?

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

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

B>>Полный бред, что UML это базворд для надувания счек перед заказчиком ... большинству заказчиков пофигу на UML ты проектируешь или просто код пишешь ...

M>Ну... в одном из проектов UML-диаграммы входили в ТЗ, Посему об этом и пишу IT департамент со стороны заказчика даже вносил в них изменения, мол на самом деле к нас не так, а вто так.


О каких UML диаграммах шла речь? В пределе, что допустимо запихнуть в ТЗ из UML так это диаграмму юзкейсов -- и то как оглавление, предваряющее собственно спецификации юзкейсов. ТЗ это документ о ТРЕБОВАНИЯХ к ПО ... а вы туда дизайн системы чтоли пихали? Тогда это откровенная безграмотность ... и тогда понятно почему UML в таких случаях не удовлетворяет.

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

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


B>>Полный бред, что UML это базворд для надувания счек перед заказчиком ...
M>Это не бред, это жизнь такая... Как раз такое, очень практическое применение UML-я, действительно приносит пользу.

Я бы хотел оззнакомиться с этим применением поближе ... можете подробнее ваш case описать?

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

B>Вы что систему продаете вместе с исходниками???? Или разрабатываете вместе с представителями заказчика? Скорее всего нет ...

Любопытно продолжить. А если да ?

B>но в любом случае желание заказчика нужно уважать ... в конце концов он деньги платит. Для начала стоит понять, а его отдел IT вообще в состянии говорить на UML?

Вопрос ведь не в том, что вы думает об отделе IT заказчика. А в том как этот отдел IT думает о себе сам. И если он считает, что в состоянии говорить на UML, то станет работать только с таким исполнителем, который ему в этом мнении потрафит.

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

B>Вы что систему продаете вместе с исходниками????

Да

B> Для начала стоит понять, а его отдел IT вообще в состянии говорить на UML?

В состоянии... Более того, для поддержки системы лучшие наши умы уходили к заказчику

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

B>О каких UML диаграммах шла речь?

Например, договор является разновидностью внутреннего документа. Тут же рисунок --- класс внутреннего документа, от него наследован класс договора, показано какие свойства добавились, из чего состоит, ... и т. д.

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

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

B>>Вы что систему продаете вместе с исходниками???? Или разрабатываете вместе с представителями заказчика? Скорее всего нет ...

AR>Любопытно продолжить. А если да ?

Вау, все становиться интересней ... не вопрос ... тогда имеет смысл использовать методологический подход к проектированию и разрботке приложения ... например на основе RUP. Правила поведения там даются ... не вопрос -- начинаем с требований, или опять нет? ... У нас сложный случай ... никто не знает что вообще нужно делать ... тогда моделируем бизнес процессы (надеемся что они стабильны на промежутке времени разработки и ввода в эксплуатацию ПО), чтобы понять где место ПО в них ... что нам нужно для этого? Видимо "общий язык" для описания ... и еще чтобы перейти потом к требованиям и желательно иметь связи трассировки требований с БП (тут не придираемся к терминологии, ОК?). Да, заказчик же понимает UML ... ОК, рисуем это в UML. Будем считать что нам повезло и мы можем использовать подход с бизнес-юзкейсами . Описываем их, тут нам здорово помогут UML activity диаграммы с object flows. Считаем, что задачу перехода от моделирования бизнеса к требованиям к системе, выраженную в т.ч. и через UC системного уровня мы решать умеем, пропускаем ... . Итак мы уже имеем системные юзкейсы ... утверждаем их, естетсвенно после утверждения вносим в них изменения ... ну заказчик изменил свою точку зрения ... бывает . Потом делаем модель анализа, ведь же тоже умеем это делать? Можно коротенько ... просто domain model ...
Теперь самое интересно .. по сценариям юзкейсов нужно понимать как нанши классы должны взаимодействовать? Да, collaboration диаграммы нам очень пригодяться -- мы сможем описать динамику поведения для выполнения юзкейса. Это ж имплементация UC realization ... . Ну дальше все прозаично ... не будем описывать. Хотя при желании можно и дальше


B>>но в любом случае желание заказчика нужно уважать ... в конце концов он деньги платит. Для начала стоит понять, а его отдел IT вообще в состянии говорить на UML?

AR>Вопрос ведь не в том, что вы думает об отделе IT заказчика. А в том как этот отдел IT думает о себе сам. И если он считает, что в состоянии говорить на UML, то станет работать только с таким исполнителем, который ему в этом мнении потрафит.

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