Здравствуйте, 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-я.
Здравствуйте, _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>И еще. Есть возможность иметь несколько моделей с различной степенью детализации на один и тот же проект?
Да. Плюс есть возможность формировать различные представления для модели.
Здравствуйте, Chupa_Kabra, Вы писали:
C_K>Как не делает ?
А так...
C_K>А это что прилитело на дисках с beta2?
И что там нового? VSS тоже в B2 новый, но функционал практически не поменялся, подозреваю, что та же история и с Visio.
Когда я спаршивал у них по этому поводу, то ответ был примерно таким:
"... Визио мы будем поддерживать для тех несчастных, которые без UML не могут...", за дословность цитаты не ручаюсь, но смысл передан верно.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Повторюсь и может не совсем в тему, но уж очень нравится:
iT>Ажиотаж вокруг UML значительно поутих после того, как выяснилось, что из неправильных картинок получаются неправильные программы
Вы, случайно не знаете кто это сказал первый раз? Это како-то гуру с мировым именем или так..?
Часто вижу эту фразу в различных девелоперских форумах... интересно стало.
MichaelXP wrote:
> iT>Повторюсь и может не совсем в тему, но уж очень нравится: > iT>Ажиотаж вокруг UML значительно поутих после того, как выяснилось, > что из неправильных картинок получаются неправильные программы > Вы, случайно не знаете кто это сказал первый раз? Это како-то гуру с > мировым именем или так..? > Часто вижу эту фразу в различных девелоперских форумах... интересно стало.
Здравствуйте, 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 и процветает — для этого то он (де факто) и был придуман.
Мы уже победили, просто это еще не так заметно...
