Здравствуйте, landerhigh, Вы писали:
L>Для генерации диаграмм по коду есть doxygen, например. А идея генерировать код из UML... вообще не понимаю, как ее кто-то мог воспринять всерьез.
Есть области где генерится дофига кода. Сотни мегабайт кода. И из UML. Правда допиленного и со своей семантикой но тем не менее из UML. Причем делают это уже лет 15 а то и побольше.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Аноним931, Вы писали:
А>>Расскажите, пожалуйста, используете ли вы UML (Unified Modeling Language) при проектировке ПО, насколько интенсивно, какой применяете софт, и как вы оцениваете практическую ценность UML (исходя из опыта использования). C>Ко всем кто пишет, что UML в виде диаграмм классов у них часто нужен и активно используется — пишите свои компании, пожалуйста. Буду знать с кем в будущем НЕ работать.
Простите, а как вы шарите знание о структуре проекта? Если вы так рьяно отрицаете UML, то вам в такие компании даже и не надо
Вот пример приходит новый сотрудник или кто-то другой хочет разобраться поверхностно в том, как работает 200к локов. Откуда ему черпать знания?
Здравствуйте, diez_p, Вы писали:
C>>Ко всем кто пишет, что UML в виде диаграмм классов у них часто нужен и активно используется — пишите свои компании, пожалуйста. Буду знать с кем в будущем НЕ работать. _>Простите, а как вы шарите знание о структуре проекта? Если вы так рьяно отрицаете UML, то вам в такие компании даже и не надо
Ага. Мы предпочитаем что-нибудь удобное.
_>Вот пример приходит новый сотрудник или кто-то другой хочет разобраться поверхностно в том, как работает 200к локов. Откуда ему черпать знания?
Из текстового описания. С содержанием, кратким обзором и описанием модулей.
Диаграмма классов из UML — совершенно не нужна. Она слишком низкоуровневая, чтобы понять крупную структуру проекта и слишком высокоуровневая, чтобы понять детали реализации.
On 21.02.2014 14:13, Cyberax wrote:
> C>>Ко всем кто пишет, что UML в виде диаграмм классов у них часто нужен > и активно используется — пишите свои компании, пожалуйста. Буду знать с > кем в будущем НЕ работать. > _>Простите, а как вы шарите знание о структуре проекта? Если вы так > рьяно отрицаете UML, то вам в такие компании даже и не надо > Ага. Мы предпочитаем что-нибудь удобное.
Поделитесь — что именно пользуете. Я сам особо UML не увлекаюсь, но
иногда надо что-то задокументировать (как правило — E/R подобное), не
изобретать же для этого свои обозначения )
Здравствуйте, hrensgory, Вы писали:
>> Ага. Мы предпочитаем что-нибудь удобное. H>Поделитесь — что именно пользуете. Я сам особо UML не увлекаюсь, но H>иногда надо что-то задокументировать (как правило — E/R подобное), не H>изобретать же для этого свои обозначения )
Для ER обычно достаточно стандартных средств реверса БД, потому мы их не документируем. Какой смысл, если разработчик может нажать пару кнопок в IDE и получить ту же диаграмму.
Для тех случаев, где надо показать взаимные отношения модулей или зависимости разных объектов — используем банальные "квадратики со стрелочками". Это нужно нам, кстати, достаточно часто, но никогда именно для диаграмм классов.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, akava, Вы писали: A>>Что еще вам приходит в голову? A>>Какие UML диаграммы "выживут" после такого анализа? S>Пока существует взаимодействие нескольких систем, диаграммы последовательности будут необходимы. S>Диаграммы состояний также крайне полезны безотносительно применяемой внутри технологии. Вот, к примеру, в документацию по API от Office365 входит диаграмма состояний для объекта "подписка". При этом совершенно неважно, на чём там внутри написан этот сервис. S>Диаграмма пакетов тоже вполне себе имеет смысл независимо от того, что является частью пакета. Ведь в ФП никто не обязывает сваливать абсолютно все функции в глобальное пространство. К примеру, в том же JS вообще нет никакого понятия пакетов (ну, до недавних версий), что никак не мешает по факту использовать пакетную структуру со всеми её атрибутами — зависимостями, делением по слоям и т.п. S>Так и в ФП — вот, функция А является композицией функций X::B и Y::C, полученной при помощи вызова комбинатора Z::D.
Это UML с точки зрения документирования. На эту сторону UML никто не нападет. Другое дело, что с такой точки зрения UML стал слишком формальным.
Ведь "квадратики/кружочки со стрелочками" неплохо заменяют UML во всех случаях, что ты указал. Эффект тот же, но я бы побоялся назвать это UML.
Мне кажется, что формальный UML важен именно для кодогенерации. И именно этот аспект я хотел обсудить. По этому вопросы есть мысли? У меня кроме идеи ничего в голову не пришло. Не так часто "UML"-диаграммы использую.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, landerhigh, Вы писали:
L>>Для генерации диаграмм по коду есть doxygen, например. А идея генерировать код из UML... вообще не понимаю, как ее кто-то мог воспринять всерьез. _O_>Есть области где генерится дофига кода. Сотни мегабайт кода. И из UML. Правда допиленного и со своей семантикой но тем не менее из UML. Причем делают это уже лет 15 а то и побольше.
А можно, плиз, конкретнее? Вопрос не в невозможности такого (в это я охотно верю), а в вопросе почему UML для этих областей подходит лучше чем что-то еще. Например XML, DSL.
Примером может служить SOAP + WSDL. Идея та же, но без UML.
On 21.02.2014 15:23, Cyberax wrote:
> Для ER обычно достаточно стандартных средств реверса БД, потому мы их не > документируем. Какой смысл, если разработчик может нажать пару кнопок в > IDE и получить ту же диаграмму.
Я не случайно написал "подобное" — это именно что не чистый E/R, надо
допустим заодно показать наследование и т.п.
> Для тех случаев, где надо показать взаимные отношения модулей или > зависимости разных объектов — используем банальные "квадратики со > стрелочками". Это нужно нам, кстати, достаточно часто, но никогда именно > для диаграмм классов. > > Ещё очень часто нужны диаграммы состояний.
А обозначения свои какие-то используете? Если да, то почему не УМЛ?
Здравствуйте, hrensgory, Вы писали:
H>Я не случайно написал "подобное" — это именно что не чистый E/R, надо H>допустим заодно показать наследование и т.п.
Наследование в БД? Конечно, оно бывает, но достаточно редко.
>> Ещё очень часто нужны диаграммы состояний. H>А обозначения свои какие-то используете? Если да, то почему не УМЛ?
В диаграммах состояний? Там кроме квадратиков со стрелочками ничего и нет, собственно.
Вот диаграммы последовательностей — достаточно полезные.
Здравствуйте, akava, Вы писали:
A>Мне кажется, что формальный UML важен именно для кодогенерации. И именно этот аспект я хотел обсудить. По этому вопросы есть мысли? У меня кроме идеи ничего в голову не пришло. Не так часто "UML"-диаграммы использую.
Формальный UML НЕ НУЖЕН для кодогенерации. Реальная кодогенерация использует расширения и дополнения UML. Код в большинстве случаев пишется на target языке (C/C++/Java/etc) Есть специфические генераторы BPMN/WSDL/XSD. В этих случаях вообще следуют семантике target языка а UML используется сугубо для визуализации.
Здравствуйте, akava, Вы писали:
A>А можно, плиз, конкретнее? Вопрос не в невозможности такого (в это я охотно верю), а в вопросе почему UML для этих областей подходит лучше чем что-то еще. Например XML, DSL.
Исторические причины. Ряд крупных компаний в духе Ericsson-а в свое время подсел на UML Room. Другие использовали SDL и UML был вариантом миграции с него.
Кто-то поддался рекламе.
A>Примером может служить SOAP + WSDL. Идея та же, но без UML.
UML используется телкомом, военными, производителями периферии (например они http://global.oce.com/ ). Компании выстраивают целые процессы разработки вокруг UML и средств моделирования.
UML это не только бизнесс-приложения (WSDL и т.п.) , это и моделирование систем(смотреть SysML), real-time, embedded и прочее. Просто на просторах СНГ про это мало кто знает и еще меньше тех, кто с этим на практике сталкивается.
Когда процессы разработки в компании построены вкруг какого-то языка и набора средств моделирования, то мигрировать на что-то другое КРАЙНЕ сложно а подчас невозможно. Можно начать новый проект на чем-то новом, но существующее надо продолжать поддерживать.
C>Для тех случаев, где надо показать взаимные отношения модулей или зависимости разных объектов — используем банальные "квадратики со стрелочками". Это нужно нам, кстати, достаточно часто, но никогда именно для диаграмм классов.
Ну вообще UML диаграммами классов не ограничивается.
C>Ещё очень часто нужны диаграммы состояний.
А говорите не используете.
"Вы не любите кошек? Вы просто не умеете их готовить"
Вообще очень часто люди воспринимают UML как нечно монстроузное, с кучей всяких непонятных тонокстей и т.д. Хотя выше я уже озвучивал, диаграмма не должна быть перегружена детализацией. И ваши квадраты не что иное как те же самые классы.
Я например слабо представляю как описать ключевые иерархии, последовательности вызвов, переброс из потока в поток и т.д.
У меня например нет и никогда не будет диаграм где 15 классов, с кучай стрелок и полным публичным контрактом.
Должно быть отражено, только все самое нужное и важное в данном функциональном аспекте модуля или ПО, все остальное лишнее.
Здравствуйте, diez_p, Вы писали:
C>>Для тех случаев, где надо показать взаимные отношения модулей или зависимости разных объектов — используем банальные "квадратики со стрелочками". Это нужно нам, кстати, достаточно часто, но никогда именно для диаграмм классов. _>Ну вообще UML диаграммами классов не ограничивается.
Тем не менее, под UML понимается именно диаграмма классов.
_>"Вы не любите кошек? Вы просто не умеете их готовить" _>Вообще очень часто люди воспринимают UML как нечно монстроузное, с кучей всяких непонятных тонокстей и т.д.
Оно так и есть.
_>Хотя выше я уже озвучивал, диаграмма не должна быть перегружена детализацией. И ваши квадраты не что иное как те же самые классы.
Диаграммов на уровене классов у меня нет нигде.
_>Я например слабо представляю как описать ключевые иерархии, последовательности вызвов, переброс из потока в поток и т.д.
Иерархий тоже почти нет. Последовательности вызовов — а зачем?
_>Я например слабо представляю как описать ключевые иерархии, последовательности вызвов, переброс из потока в поток и т.д.
Сейчас, когда термины "обсервер" или там "агрегация" или "visior" или "IoC" уже не вызывают ни у кого дикой попаболи, я, например, слабо представляю зачем может понадобиться описывать ключевые иерархии, последовательности вызовов и особенно переброса из потока в поток. Все обычно ясно при первом (втором) взгляде на код. Если не ясно, то имеем дело с говнокодом, которому UML не поможет.
С другой стороны, диаграмма состояний КА — вещь нужная, т.к. современные ЯП общего назначения хреновато подходят для реализации КА, если не сказать большего.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, diez_p, Вы писали:
C>>>Для тех случаев, где надо показать взаимные отношения модулей или зависимости разных объектов — используем банальные "квадратики со стрелочками". Это нужно нам, кстати, достаточно часто, но никогда именно для диаграмм классов. _>>Ну вообще UML диаграммами классов не ограничивается. C>Тем не менее, под UML понимается именно диаграмма классов.
Ну вообще UML содержит основные диаграммы и вспомогательные, загляните в стандарт.
_>>"Вы не любите кошек? Вы просто не умеете их готовить" _>>Вообще очень часто люди воспринимают UML как нечно монстроузное, с кучей всяких непонятных тонокстей и т.д. C>Оно так и есть.
Значит вы просто не умеете пользоваться
_>>Хотя выше я уже озвучивал, диаграмма не должна быть перегружена детализацией. И ваши квадраты не что иное как те же самые классы. C>Диаграммов на уровене классов у меня нет нигде. _>>Я например слабо представляю как описать ключевые иерархии, последовательности вызвов, переброс из потока в поток и т.д. C>Иерархий тоже почти нет. Последовательности вызовов — а зачем?
А скажите в личку вашу компанию и предметную область.
Вот тут два варианты, либо проект для специфичной области, либо плохой дизайн. Механизм наследования дает полиморфизм АТД, в ООП технологиях это делается на уровне платформы, без доп приседаний.
Как пример. Стримовый слой поставки данных.
Есть одна абстракция IDataNotifier, есть несколько абстракций провайдеров этих данных, есть абстрактная фабрика которая инстанцирует слой поставки данных, в зависимости от транспорта.
IDataNotifier имеет несколько имплементаций. Есть имплементации IDataNotifier которые оборачивают другие IDataNotifier. Есть ряд менеджеров которые рулят этой поставкой данных.
Есть другие примеры реализации тех же слоев поставки данных, когда несколько диаграмм, дают понимание того как этот код сделан.
Диаграммы классов, последовательностей, объектов.
Во всех этих проектах, код написан по качеству примерно как в Parallels и JetBrains в их хороших проектах.
Глядя только в код, достаточно сложно понять почему именно таким образом код решает поставленную задачу.
Диаграммы позволяют под разными аспектами посмотреть на идею того, как сделано. Они уменьшают вероятность того, что кто-то залепит гумно в этот код, только потому что ему надо побыстрее сделать задачу, а главную идею он не понял. Даиграммы доносят идею до разработчиков, которые этот код не писали, идею им объяснять не надо. На практике диаграммы, как правило очень редко меняются, чаще их читают, чем модифицируют и уж тем более пишут.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, diez_p, Вы писали:
L>я, например, слабо представляю зачем может понадобиться описывать ключевые иерархии, последовательности вызовов и особенно переброса из потока в поток. Все обычно ясно при первом (втором) взгляде на код. Если не ясно, то имеем дело с говнокодом, которому UML не поможет.
Лихо вы судите А если объем кода, мягко говоря не мал?
Там даже со второго раза не разобраться и с третьего, потому что его тупо много и код сложный и не говнокод
L>>я, например, слабо представляю зачем может понадобиться описывать ключевые иерархии, последовательности вызовов и особенно переброса из потока в поток. Все обычно ясно при первом (втором) взгляде на код. Если не ясно, то имеем дело с говнокодом, которому UML не поможет.
_>Лихо вы судите А если объем кода, мягко говоря не мал?
Какая разница?
_>Там даже со второго раза не разобраться и с третьего, потому что его тупо много и код сложный и не говнокод
Если это не говнокод, то разделение сущностей и связи между ними очевидны и видны сразу. Если не видны, то это таки говнокод.
Здравствуйте, diez_p, Вы писали:
C>>Иерархий тоже почти нет. Последовательности вызовов — а зачем? _>А скажите в личку вашу компанию и предметную область. http://moleculo.com , http://illumina.com , http://clusterk.com — биоинформатика и облачные вычисления.
_>Вот тут два варианты, либо проект для специфичной области, либо плохой дизайн. Механизм наследования дает полиморфизм АТД, в ООП технологиях это делается на уровне платформы, без доп приседаний.
"Наследование — не нужно" (c). Точнее, нужно в очень редких случаях и, в основном, в виде реализации интерфейсов.
_>IDataNotifier имеет несколько имплементаций. Есть имплементации IDataNotifier которые оборачивают другие IDataNotifier. Есть ряд менеджеров которые рулят этой поставкой данных.
И для чего тут нужен UML? IDataNotifier — интерфейс нотификатора данных (что за данные — смотрим в каменты). Оборачивающая реализация: IProxyDataNotifier или IDataNotifierWrapper.
_>Глядя только в код, достаточно сложно понять почему именно таким образом код решает поставленную задачу.
Для этого пишется короткая текстовая дока.
_>Диаграммы позволяют под разными аспектами посмотреть на идею того, как сделано. Они уменьшают вероятность того, что кто-то залепит гумно в этот код, только потому что ему надо побыстрее сделать задачу, а главную идею он не понял. Даиграммы доносят идею до разработчиков, которые этот код не писали, идею им объяснять не надо. На практике диаграммы, как правило очень редко меняются, чаще их читают, чем модифицируют и уж тем более пишут.
Не доносят. Скорее наоборот.
Здравствуйте, landerhigh, Вы писали:
L>Сейчас, когда термины "обсервер" или там "агрегация" или "visior" или "IoC" уже не вызывают ни у кого дикой попаболи, я, например, слабо представляю зачем может понадобиться описывать ключевые иерархии, последовательности вызовов и особенно переброса из потока в поток. Все обычно ясно при первом (втором) взгляде на код. Если не ясно, то имеем дело с говнокодом, которому UML не поможет.
В определенных областях sequence diagrams используются для генерации тестов и проверки поведения системы требованиям.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, landerhigh, Вы писали:
L>>Сейчас, когда термины "обсервер" или там "агрегация" или "visior" или "IoC" уже не вызывают ни у кого дикой попаболи, я, например, слабо представляю зачем может понадобиться описывать ключевые иерархии, последовательности вызовов и особенно переброса из потока в поток. Все обычно ясно при первом (втором) взгляде на код. Если не ясно, то имеем дело с говнокодом, которому UML не поможет.
_O_>В определенных областях sequence diagrams используются для генерации тестов и проверки поведения системы требованиям.
Sequence diagram, в отличие от диаграмм классов, полезны и сами по себе, т.к. как минимум позволяют наглядно обосновать те или иные решения, представив временнУю схему взаимодействия компонентов.
Только наиболее эффективное их использование подразумевает их автоматическую генерацию из кода или псевдокода (как в PlantUML). Рисовать их мышкой в целях последующей кодогенерации есть извращение.
