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>О каких 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, и используя единую методологию и подходы в проектировании и разработке -- но это в нашей стране скорее исключение, чем правило.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, byur, Вы писали:
B>>О каких UML диаграммах шла речь?
M>Например, договор является разновидностью внутреннего документа. Тут же рисунок --- класс внутреннего документа, от него наследован класс договора, показано какие свойства добавились, из чего состоит, ... и т. д.
Пардон, но это не ТРЕБОВАНИЕ ... это дизайн. Теперь мне все с вашим случаем понятно.
Здравствуйте, byur, Вы писали:
B> можете подробнее ваш case описать?
Он не мой, он классический. Закакзчик знает красивое слово UML он хочет, наблюдать за ходом разработки с помощю UML, совершенно не важно понимает он его или нет. Ни вопрос — в каждый отчет лепим диаграмки, отдаленно напоминающие проект и забываем о них, все довольны и заказчик и исполнитель.
AR>Я не считаю UML хорошим решением проблем собственно в качестве средства разработки. Но глупо отрицать его полезность как средства документирования сложных проектов и систем. Даже опытный разработчик, непосредственно участвовавший в проекте, возращаясь к своим "бумажкам и слюням" через пол года — год уже может запутаться в этом зоопарке. Что же говорить о проектах/системах, которые, к примеру, были куплены у другой компании, а теперь с ними
Разработчик который запутается в своих слюнях и бумагах, в равной степени запутается в своём UML, с некоторой погрешностью.
> начинает работу совершенно новая группа, не имеющая возможности что-то уточнить у своих предшественников. Попробуйте продать сложный продукт, если у вас есть только исходные коды (пусть даже хорошо откомментированные). За это без самих разработчиков никто гроша ломанного не даст. А вот за хорошо задокументированные (в т.ч. и с помощью стандартных UML-средств) проекты в мире иногда платят миллионы и более.
попробуйте продать код+uml, ценность вашего проекта возрастёт не более процентов < 10%.
я долго не ввязывался в спор не понимая его сути, ибо всё одно и тоже... может проще подойти системно к этому:
1. Информативность UML крайне низкая, средства работы крайне не удобные, идеология слабо проработаная.
Крупные компании управляются малограмотными в IT людьми, или точнее грамотными на обобщённом уровне, которые мыслят тенденциями, если есть тенденция развития UML, то её могут мягко начать внедрять, но в описаниях типа MSDN вы врядли увидите UML почему?
построить достаточно точный прогноз что если применять или не применять UML сложно, и главное мало кому хочется отвечать за неверно выбранное решение... вплоть до верхнего уровня.
2. Хорошо структурированный и бумажно описанный код, человеческим языком, сопровождённый схемами и рисунками, далеко не в UML формате, гораздо полезнее UML с коментариями, на порядок а то и два полезнее.. Жаль только документацию писать не многие умеют, так чтобы её могли читать другие.
3. Что касается mind и прочих решений на графах -- не то это всё, не то... ущербные реализации и рядом не стоящие с удобством.
AR>Взгляд на UML с точки зрения разработчика или даже руководителя проекта в целом ряде случаев действительно может оказаться весьма скептическим. Но посмотрите на это, например, с точки зрения финансового директора или собственника компании. А ведь существуют и другие действующие лица ...
Смотрю: Затраты на обучение UML, затраты на средства проектирования, затраты на обеспечения избыточных процессов, итп. Время простоя на восприятие UML, время простоя на поиск в UML, время выроботки стандарта понимания UML (написать можно и на UML по разному), время на поиск решений по отображению в ограничениях UML, итд. -- всё это стоит денег, которые можно потратить на что-то более интересное.
... B>Диаграмма классов показывает только статику ... как мне увиидить динамику взаимодействия объектов??? B>Кроме этого, пример из практики ... у нас например разработка ведеться на разных языках: Visual Basic, С++, Delphi, Java ... вы, что мне как проектировщику или архитектору предлагаете при проектировании систем автоматизации бизнеса знать все особенности этих языков ... чтобы общаться с разработчиками? Бред ... мне достаточно спроектировать модель анализа (да, да ... на UML) ... где я покажу реализацию юзкейсов, например, ... а в
Я предлагаю вам знать даже больше чем просто особенности всех этих языков, ибо архитектура -- это не только UML.
p.s. что такое модель анализа? вы придумали новое понятие... -- давайте ему тогда определение.
Здравствуйте, byur, Вы писали:
B>Поможет, например, управлять сложностью.
Зачем ей управлять? Ее надо просто не создавать...
B>Кроме этого, пример из практики ... у нас например разработка ведеться на разных языках: Visual Basic, С++, Delphi, Java ... вы, что мне как проектировщику или архитектору предлагаете при проектировании систем автоматизации бизнеса знать все особенности этих языков ... чтобы общаться с разработчиками?
Конечно, и как минимум не хуже чем разработчики, иначе такого напроектируешь, что никакой UML не спасет...
Здравствуйте, nixite, Вы писали:
AR>>Я не считаю UML хорошим решением проблем собственно в качестве средства разработки. Но глупо отрицать его полезность как средства документирования сложных проектов и систем. Даже опытный разработчик, непосредственно участвовавший в проекте, возращаясь к своим "бумажкам и слюням" через пол года — год уже может запутаться в этом зоопарке. Что же говорить о проектах/системах, которые, к примеру, были куплены у другой компании, а теперь с ними
N>Разработчик который запутается в своих слюнях и бумагах, в равной степени запутается в своём UML, с некоторой погрешностью.
А в чужом?
>> начинает работу совершенно новая группа, не имеющая возможности что-то уточнить у своих предшественников. Попробуйте продать сложный продукт, если у вас есть только исходные коды (пусть даже хорошо откомментированные). За это без самих разработчиков никто гроша ломанного не даст. А вот за хорошо задокументированные (в т.ч. и с помощью стандартных UML-средств) проекты в мире иногда платят миллионы и более.
N>попробуйте продать код+uml, ценность вашего проекта возрастёт не более процентов < 10%.
10% от 10 млн. $ = 1млн. $.
Полагаете мало существует проектов, ценность которых превышает 10М ?
AR>>Взгляд на UML с точки зрения разработчика или даже руководителя проекта в целом ряде случаев действительно может оказаться весьма скептическим. Но посмотрите на это, например, с точки зрения финансового директора или собственника компании. А ведь существуют и другие действующие лица ...
N>Смотрю: Затраты на обучение UML, затраты на средства проектирования, затраты на обеспечения избыточных процессов, итп. Время простоя на восприятие UML, время простоя на поиск в UML, время выроботки стандарта понимания UML (написать можно и на UML по разному), время на поиск решений по отображению в ограничениях UML, итд. -- всё это стоит денег, которые можно потратить на что-то более интересное.
Вам стоит почитать мое мнение относительно сферы применимости UML, высказанное ранее. Я отрицаю применимость UML как средства разработки — поддерживаю его только как помощь при документировании (т.е. это просто стандартный язык отображения уже построенных на чем-то еще моделей). В таком ракурсе из вашего перечня выпадает масса пунктов (ака "время простоя на восприятие UML", "время простоя на поиск в UML" и т.д.). Избыточных процессов я здесь тоже не наблюдаю, если не считать таковыми собственно документирование. Затраты на обучение и средства проектирования тем ниже, чем стандартнее и распространеннее используемое решение. Затраты на обучение проприетарным внутрифирменным методикам представления и документирования архитектуры систем могут оказаться существенно выше.
Вобщем ваш взгляд не соответствует взгяду грамотного финансиста. Это только романтики тратят деньги на "интересное". Профи ищут финансовую выгоду (прибыль или, что на западе не реже, рост капитализации компании). Зачем к примеру фирмы проходят сертификацию на соответствие стандартам по управлению качеством и т.п.? С точки зрения технологии в этом не найдешь никакого смысла (уточняю: не в управлении качеством, а в самой сертификации). Но так уж устроен мир. Внедрение RUP (а стало быть и использование UML) может сыграть свою роль в привлечении хороших заказов, а это деньги ...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, byur, Вы писали:
B>>Поможет, например, управлять сложностью. M>Зачем ей управлять? Ее надо просто не создавать...
B>>Кроме этого, пример из практики ... у нас например разработка ведеться на разных языках: Visual Basic, С++, Delphi, Java ... вы, что мне как проектировщику или архитектору предлагаете при проектировании систем автоматизации бизнеса знать все особенности этих языков ... чтобы общаться с разработчиками? M>Конечно, и как минимум не хуже чем разработчики, иначе такого напроектируешь, что никакой UML не спасет...
Выставляя такие условия (отсутствие сложности и знание архитектором ВСЕХ платформ, на которых будет развертываться система) вы просто сужаете сферу, в которой по вашему вообще возможна разработка информационных систем. Совершенно очевидно, что со временем архитектура и сложность информационных систем растет. И если раньше гении-одиночки могли выдавать на гора несколько действительно достойных программ в год, то сейчас в мире уникумы, которые умудряются в одиночку вести работу хотя бы над одним действительно серьезным продуктом, просто наперечет. Но с другой стороны и действительно удобных инструментов для обеспечения совместной работы больших (да и маленьких) коллективов вобщем-то нет. Но стоит признать, что UML в определенных условиях позволяет решить некоторые проблемы и, путь ценой ряда излишних трудозатрат, помочь в организации совместной работы над одним проектом крупного коллектива.
Впрочем для меня очевидно и другое. UML явно недостаточно для решения этой сложной проблемы. Для облегчения и ускорения разработки нужны другие более гибкие и более интегрированные с исходным кодом подходы. А UML вполне может оставаться в процессе, но уже только в качестве инструмента документирования.
Здравствуйте, Alexey Rovdo, Вы писали:
AR>А в чужом?
А в чужом тем более.
AR>Вам стоит почитать мое мнение относительно сферы применимости UML, высказанное ранее.
Не стоит, так как внятного обоснования Вы своему мнения не дали. То есть я в чем-то даже могу понять тех кто пытается использовать UML для разработки, но только для документации это просто лишено какого бы то ни было смысла.
AR>Я отрицаю применимость UML как средства разработки — поддерживаю его только как помощь при документировании (т.е. это просто стандартный язык отображения уже построенных на чем-то еще моделей).
Да бесполезен он в качестве документирования, так как понять его еще сложнее чем код.
AR> В таком ракурсе из вашего перечня выпадает масса пунктов (ака "время простоя на восприятие UML", "время простоя на поиск в UML" и т.д.).
Не выпадает, так как чтобы понять об-UML-енную документацию, надо на это затратить время и затратить время на составление этой документации и все ради чего? Кто потом этоу документацию будет читать?
AR>Избыточных процессов я здесь тоже не наблюдаю, если не считать таковыми собственно документирование. Затраты на обучение и средства проектирования тем ниже, чем стандартнее и распространеннее используемое решение.
Несмотря на всю стандартность UML малопонятен и далеко не однозначен, и преиведение всего к единому стандарту даже в рамках UML-я требует немалых усилий.
AR> Зачем к примеру фирмы проходят сертификацию на соответствие стандартам по управлению качеством и т.п.? С точки зрения технологии в этом не найдешь никакого смысла (уточняю: не в управлении качеством, а в самой сертификации). Но так уж устроен мир. Внедрение RUP (а стало быть и использование UML) может сыграть свою роль в привлечении хороших заказов, а это деньги ...
О! Вот об этом я уже давно говорю. Единственная практическая польза от UML это большие пальцы перед заказчиком и чисто формальное соответствие неким стандартам ведения проектов, дабы соответствовать общепринятым формальным же нормам, что в конечном итоге опять-таки служит целью привлечения клиентов и созданию имиджа компании.
То есть к реальной разработке это не имеет никакого отношения.
Здравствуйте, Alexey Rovdo, Вы писали:
AR>Выставляя такие условия (отсутствие сложности и знание архитектором ВСЕХ платформ, на которых будет развертываться система) вы просто сужаете сферу, в которой по вашему вообще возможна разработка информационных систем.
Во-первых, никто не обещал, что будет легко, а во-вторых, я абсолютно ничего не сужаю.
AR> Совершенно очевидно, что со временем архитектура и сложность информационных систем растет. И если раньше гении-одиночки могли выдавать на гора несколько действительно достойных программ в год, то сейчас в мире уникумы, которые умудряются в одиночку вести работу хотя бы над одним действительно серьезным продуктом, просто наперечет.
Причем тут гений-одиночка? Я где-то говорил, что архитектор должен самостоятельно написать весь код?
Проблема в том, что даже грамотно спроектировать систему невозможно не зная языка на котором она будет реализована и если уж случилось так, что система должна быть реализована на десятке языков и запроектирована одним архитектором (я в это не верю, но возьмем гепотетическую задачу), то если архитектор этих 10 языков не знает, то может даже и не браться.
Или Вы считаете, что можно совершенно спокойно проектировать не зная особенностей языка реализации?
AR> А UML вполне может оставаться в процессе, но уже только в качестве инструмента документирования.
На протяжении уже десятка постов Вы с достойным другого применения упорством продвигаете одну и ту же мысль, но так и не ответили на простой вопрос: Зачем нужно другое средство документирования (в данном случае UML) отличное от того, которое применялось в процессе разработки в качестве средства общения разработчиков (поскольку по Вашим словам UML дя этого не пригоден)? Какая практическая польза в таком подходе? Зачем тратить время и средства на отдельный язык документации и составление документации отдельно от разработки?
Мы уже победили, просто это еще не так заметно...
IT департамент со стороны заказчика даже вносил в них изменения, мол на самом деле к нас не так, а вто так.
