Погода: -12°C
  • Люди, поделитесь сабжем!

  • что надо то?
    инфу? дистрибутив? где применять?

    Автор благодарит алфавит за любезно предоставленные буквы...

  • Под такой фразой обычно подразумевают дистриб...:улыб:

  • Вообще мне дистрибутив нужен. Хотя и от остального не отказался бы =)
    Имеется?

  • Приветствую,

    тоже интересуюсь предметом,
    raeen - удалось найти ?
    Поделиться можете?

    4ward 4ever

  • Cactus & Master,

    можете помочь или подсказать, где найти дистриб RR или Rational Suite?
    И еще интересно, появился ли сейчас плагин для реинжиниринга и генерации кода на C#?

    4ward 4ever

  • Господа!

    А расскажите мне пожалуйста, кто-нибудь и где-нибудь использует RR в реальных проектах? И для чего?

    А то все это слова типа генерации кода и реинжиниринга так красиво звучает...да вот есть ли от них толк?

  • Пишите в личку. Помогу с дистрибом.
    По поводу генерации на С# - вроде бы пока тихо. Я писала диплом как раз на такую вот тему, как генерация кода по диаграммам на С#.

    и опыт , сын ошибок трудных....

  • В ответ на: А то все это слова типа генерации кода и реинжиниринга так красиво звучает...да вот есть ли от них толк?
    Мне кажется, что нет. По диаграммам удобно код писать. Но самому, ручками. А не генерировать автоматически.

    и опыт , сын ошибок трудных....

  • В ответ на: Я писала диплом как раз на такую вот тему, как генерация кода по диаграммам
    на С#.
    Слушай, а ты какое учебное заведение заканчивала?

  • НГУ

    и опыт , сын ошибок трудных....

  • Могу тоже поделиться Rational Rose(последний) и Rational Rose XDE(не очень последний :), как раз XDE и генерит C# код и встраивается в VS .NET.
    Типа все в личку :))))

  • Код генерит ? Неужели всяческие диаграммы состояния и т.п. можно превратить в код ? IMHO максимум возможно сгенерировать объявления классов, методов и т.п, а код то придется писать ручками. Как потом доказать соответствие написанного тому, что было в диаграммах ? Не голимамая ли это интуитивщина ?

  • Ну конечно же только по статическим диаграммам. :ухмылка:

    и опыт , сын ошибок трудных....

  • А что бывают динамические диаграммы ? ;-)
    IMHO альтернативой может быть спецификация на основе переписывания графов (см. язык Clean). UML хорош для сбора требований и определении каркаса приложения, но IMHO между каркасом и реализацией лежит пропасть. То есть по реализации практически невозможно формально доказать ее соответствие UML спецификации.

    А Вы, если не секрет, где используете Розу и UML ? В каких проектах ?

    С уважением
    Lisper

  • Ну есть диаграммы, отображающие динамику.

    и опыт , сын ошибок трудных....

  • Но рабочий код с них не сгенерируешь.

  • Согласна.
    Вот я и говорю, что только статика

    и опыт , сын ошибок трудных....

  • Дело не в статике, не будете же Вы заниматься мультипликацией при рисовании диаграмм ;-)

    UML неплохо выглядит для сбора требований и описания всяческих прецедентов, однако IMHO переход к рабочему коду довольно мутный и интуитивный и опирается главным образом на ООП, которое не для всего применимо.

    Меня интересует, какие вещи люди рисуют в Розе, для какого типа проектов ? Я вижу применимость только для хорошо формализуемых областей типа автоматизации документооборота и т.п., но как спроектировать, например, какой-нибудь чат-бот с помощью UML - задача которая хорошо решается с помощью Лиспа и всяких XML/AIML, но в ней нет фиксированного сценария работы и т.п. А игры ?

  • Присоединяюсь к вопросу, интересно какое место в информационных технологиях занимают языки спецификацией типа UML и где они находят своё реальное применение?

  • UML можно использовать везде, и классы с интерфейсами генерировать как семечки щелкать.
    Если мы условно разобьем приложение на 2 части -
    1) объекты и их взаимодействие друг с другом
    2) код, оперирующий определенными объектами
    то UML прекрасно справляется с "1", а после этого в "2" потенциал для ошибки уже меньше.

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

    Первое, что приходит на ум, если UML можно использовать везде, то как насчет:

    1) Компилятор написать ?
    2) Чат-бот ?
    3) Экспертную систему или оболочку для
    экспертных систем ?
    4) Видео-кодек ?
    5) Драйвер ?

    А что если, например, пользователь сам добавляет сценарии, классы, структуры данных по ходу работы? Если приложение - это некий метауровень, который позволяет пользователю создавать свой языковой уровень и решать задачу на нем ?

    Тем более, что классы и интерфейсы - это сущности из сферы ООП. Как насчет Generic Programming, Functional Programming ? IMHO при всей бездне возможностей и множестве всяческих подходов применимость UML весьма ограничена.

  • > но ведь их можно и руками набить гораздо быстрее, чем заполнять красивые формочки

    Снова прибегну к примеру дома. Зачем чертить какой-то проект, если можно просто замесить раствор, взять кирпичи – и вперед!
    От проекта программы можно отказаться только при соблюдении следующих условий –
    1. Проект уже есть в вашей голове;
    2. Никто, кроме Вас, интересоваться им не будет.

    UML на сегодня – наиболее мощное и широко признанное средство написания таких проектов.

    Теперь об OOP, GP и FP. Generic Programming – подобласть ООП и честно скажу, что в UML с этим не работал. Functional Programming – это не главное направление, а скорее underground в мире программирования. Так что я не удивляюсь, что у создателей UML не было никакого желания адаптировать UML к FP.

  • Про набивание объявлений классов, интерфейсов, методов руками я сказал не для того, чтобы показать, что стадия проектирования не нужна. Однако на определенном этапе проектирования начинается переход на уровень языка реализации: рисование классов, интерфейсов и т.п. Но согласитесь, есть более мощные не визуальные инструменты генерирования этих сущностей. То есть сами языки программирования мощнее визуальных языков, иначе все программирование сводилось бы к визуальному.

    Отказаться от UML не значит отказаться от проектирования.

    Рекламное заявление про "UML на сегодня наиболее мощное и широко признанное средство написания таких проектов" звучит странно. Каких проектов ? Тех задач, что я перечислил ? Кем признанное ?

    Generic Programming - не подобласть ООП, IMHO просто оно было адаптировано к ООП и поддерживается языками вроде С++ и т.д. Но взгляните на языки Haskell, Clean, OCaml, Common Lisp, в которых средства обобщенного программирования были с самого начала.
    Насчет функционального программирования, я не понял, что такое "главное направление", говорится про направление кого и куда ? Известно, что на функциональных языках сегодня пишут реальные вещи и ФП не собирается проваливаться ни в какой Underground ;-) Посмотрите на множество идей пришедших в Java, C#, другие языки и технологии вроде CLR из мира функционального программирования.

    Быть может для ФП такие вещи как UML совершенно не подходят. IMHO универсальность - это миф и ООП вряд ли панацея.

    Вопрос остается. Для каких именно проектов люди реально используют Розу и UML ?

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

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

    Несомненно, но здесь задачи-то разные.

    > Но взгляните на языки Haskell, Clean, OCaml, Common Lisp
    При всем моем уважении к Вам к к этим языкам программирования, «узок круг этих языков, страшно далеки они от народа»

    > IMHO универсальность - это миф и ООП вряд ли панацея.
    Здесь я тоже согласен.

    > Вопрос остается. Для каких именно проектов люди реально используют Розу и UML ?

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

    В общем, здесь тоже действует принцип 80/20. Для 20% типов задач пишут 80% программистов (и идет 80% финансирования), и для этих 20% задач UML подходит прекрасно.

Записей на странице:

Перейти в форум

Модератор: