_mashuta_Кто что думает об UML? Мода прошла?
Просто IMHO люди, которые с ним игрались (и активно говорили о нём), разделились на 2 категории: тех, кто научился применять его для решения реальных задач (и молча его используют, никого не спрашивая), и тех, кто разочаровался в нём (и тоже молчит). UML не стал серебряной пулей.
А за таинственные диаграммы, описывающие изящные абстрактные конструкции и последовательности, больше никто не платит.
Тем более, что Rational, которая активно пиарила UML и RUP, растворилась в недрах IBM, и пока IBM думала, что делать с этим ПО - у него появились нормальные альтернативы.

_mashuta_Сейчас вождь (слабый, кратковременный) собрался у нас внедрять что-то вроде "использование UML".
Вот я и пытаюсь выработать свое отношение к этой инициативе.
Даже плохой вождь может делать правильные вещи. Другое дело, что взяться он может за UML ради UML. А UML - всего лишь средство, при правильном внедрении и применении помогающее:
- думать от целей пользователя (с помощью UC, хотя сам оперирует со структурой UC, но не их наполнением), постепенно доходя до реализации
- общаться, более-менее однозначным и стандартным образом документировать принятые архитектурные решения, накапливать знания, облегчать ввод новичков в курс дела (если все в говорят на UML хотя бы "со словарём")
- помогать (при помощи обратного инжиниринга) разбираться с древним злом (чужим, брошенным или забытым кодом): видел на практике, если бы не UML и не возможности средства - шиш смогли бы повторно использовать пару мегабайт кода
- сколько-нибудь проектировать, а не сразу кидаться в безумно гибкий "code & fix"
- создавать статические аспекты архитектуры от динамических
- иногда - экономить время на кодировании "скелетов" классов: видел на практике, реально экономило довольно много времени
- упрощать документирование, особенно сертификационное
- поддерживать целостное представление о системе, позволять её разрабатывать после того, как она перестаёт полностью помещаться в голове одного человека.

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

_mashuta_<...>
Я не сомневаюсь в ценности UML. Но вот вопрос - насколько велика эта ценность?
Мне почему-то кажется, что близка нулю.
<...>
Ценность ООП, СУБД, компьютера, ножа и мяса близка к нулю. Можно насоздавать багов, потерять данные, уронить на ногу, порезаться, отравиться. Если не уметь готовить :) .

MasterZiv<...>
Я использовал в примерно 3 проектах. На С++.
Со сквозной кодогенерацией, полностью сделанный проектов было 2 на самом
деле. Я бы делал так ещё проекты, да вот только не пишу я сейчас на С++.
А для CLOS-а генератора нет.
Я - в трёх, один на PHP + PostgreSQL:) , один на C#.Net + MS SQL 2000, один гетерогенный (J2EE + C++ + Hibernate). Кодогенерация была частичной.

MasterZiv
Использовал я в основном диагаммы классов (для генерации кода и документации),
диаграммы взаимодействия и последовательностей - для пояснения и проектирования.
Ну и, конечно, диаграммы компонент.

Использовали всё, deployment - в меньшей степени.

MasterZiv
Это - очень полезная штуковина, потому что С++ -- довольно громоздок
и ты не видишь за кучей кода сути. Проектировать на UML при этом удобно,
и case делает за тебя много черновой работы.

+1, это свойства всех языков

MasterZiv
Да, использовалась rose 2000. C++ classic plugin.
Он самый сложный, но других - не хватает для работы.

Использовали Rational Rose 2003, затем Sparx Systems Enterprise Architect 6.5 - 7.1 как есть.

MasterZiv
все остальные диаграммы очень и очень абстратны, они
скорее - картинки.

Помогают думать и договариваться.

MasterZiv
И совсем оцтой - я считаю - это use case diagrams.
Я их не понимаю и не знаю , нафига они вообще нужны.
Они-то и были на самом деле "самой проталкиваемой" штукой.
Использовали их чуть ли не больше всего.

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

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

Если Вам интересно, как использовать UC - почитайте Коберна.

MasterZivЯ не хочу даже с ними разбираться.
"Не знаю и знать не хочу"? Наверное, на Вас слишком много рутинной работы, улучшайте процессы, автоматизируйте, делегируйте.

MasterZiv
Там просто идея была в том,
что потом все UC преобразуются в конкретные вызовы конкретных методов.
Это неправильная и неприменимая идея. "Системные" варианты использования (уровня "моллюсков" по Коберну) делать пробовали, не нужны они.

MasterZiv
Но это не так, потому что UC отражают очень поверхностный взгляд
на систему, укрупнённый.
К вопросу о терминах: лично для меня глубокий взгляд на систему - это не столько определить, какой фабричный метод какой декоратор создаёт, сколько понять, что действительно нужно пользователю. А по Вашим постам складывается впечатление, что пользователь для Вас - вообще никто, лишь бы код писался... Вот только именно пользователи (отвечающие для них заинтересованные лица) оплачивают разработку, в меру того, насколько результат соответствует тому, что им нужно. Да, да, знаю, у нас всё не так, а лапша на ушах ЛПР, дорогие игрушки, понты, кумовство и откаты.

MasterZiv
Мне кажется , что вот это переход на конкретную систему, на конкретные классы реализации очень
сомнителен, никогда такого не видел и не понимаю, как можно
так сделать, чтобы это всё вылилось в реальные классы.

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

MasterZiv
Как картинки это - ну да, красиво иногда, но и только.

Это если в них нет смысла. Ну или Вы его не видите.

Ничего личного, просто извечный спор аналитика с программистом.

iscrafmAlex, а как собственно UML помогает именно пользователю?Как и любое другое удобное средство, увеличивает вероятность получить более качественный продукт в несколько более короткие (как ни парадоксально - казалось бы, что-то ещё проектировать, описывать, думать о том, как пользователи работать будут) сроки.

Как и любой другой язык, увеличивает вероятность того, что применяющие его люди понимают и думают категориями, присущими его предметной области (в эскимосском - много видов снега, в английском - точная и однозначная характеристика состояния работы, в ассемблере - особенности архитектуры платформы, в UML - опыт разработки ПО от учёта целей пользователя (UC) до развёртывания разработанной системы (deployment)).

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

А так - никаких гарантий: заставь дурака Богу молиться - он лоб разобьёт. Более того: позволяет коммерсам от разработки успешнее продавать воздух, водить заказчиков или инвесторов, и говорить, что у нас, мол, всё круто, всё по науке и новейшим технологиям.
iscrafmAlexTheRaven
Это можно, через динамическую модель поведения системы, соответствующую UC.а можно через действующий прототип, который гораздо более точно отражает поведение системы.
Одно другому помогает: проектирование позволяет разрабатывать продукт с применением меньшего количества более разумных прототипов. Важен баланс между проектированием и прототипированием.

MasterZiv
> складывается впечатление, что пользователь для Вас - вообще никто, лишь
> бы код писался...

В идеале - да !
<...>
Значит, либо можете себе позволить (разрабатываете open source технологические компоненты, и/или работаете на науку кибернетику, и/или программирование - Ваше хобби), либо у Вас в команде есть кто-то, кто выполняет функции аналитика.

iscrafm<...>
Не могу согласится с тем, что
1. UML позволяет уменьшить сроки разработки
Согласен, не слишком сложную вещь, при наличии головы и прямых рук, быстрее сделать по эскизу, или даже совсем без него. А для сложной, которую, к тому же, делают сразу несколько десятков человек, эффективнее иметь чертёж, масштабную модель, прототип.

UML, кстати, всего лишь некий аналог ЕСКД для ПО, использовать именно его необязательно, просто он хорошо ложится на ООП. Раньше вот на листах ватмана А1 блок-схемы рисовали, и тоже ничего, System V, System R и OS/360 как-то сделали :) .

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

iscrafm<...>
2. Знание и применение UML повышает компетентность разработчика (точно так же, как и знание языка не делает из человека писателя или программиста)
Конечно, само по себе не повышает, но даёт к этому предпосылки, упорядочивая мышление. При изучении литературы по UML тут же всплывают примеры хорошей архитектуры, паттерны, да и сама идея, что до того, как набивать код, хорошо бы сесть и подумать, для чего он нужен и как должен работать, весьма полезна.

iscrafm<...>
3. Процесс описанный при помощи UML является более зрелым. С какой это кстати.

Я имел в виду не использование UML для описания бизнес-процессов, а использование UML в процессе разработки ПО. Доказательство такое: как только используется UML - методология разработки уже включает проектирование и документирование, уже не "code & fix".

Хотя и для бизнес-процессов, их описание с использованием каких-либо средств, даже UML, который IMHO для этого не предназначен и не удобен, означает переход к CMM 3 "Defined Level", довольно высокому.

iscrafm<...>
Впрочем по этому поводу у каждого свое мнение и оно уважаемое.
+1
Если бы все так думали - мир был бы лучше.
Практика - критерий всего: если Ваша команда выпускает отличный продукт в срок безо всякого UML, то UML ей не нужен.

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

private
- просто супер как упрощает работу с закачиками
- красиво выглядит
- ...

Нормальный заказчик скажет - "весь ваш процесс разработки, весь UML, всё программирование, планирование, тестирование - это ваш overhead; просто сделайте мне хорошо, а будет там C++ или чёрная магия - мне неважно". Заказчик лезет во внутренние дела разработки не от хорошей жизни, а либо по собственной глупости, либо потому, что разработчики не могут сами всё нормально разработать, и их нужно постоянно контролировать..

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

Всё это в корне неверно. Результат - критерий всего, а многие замечательные системы разработаны безо всякого UML.

private
И еще один аргумент, почему UML лучше чем код? Потому-что эта абстракция более близка людям, люди думают картинками а не текстом (кто в теме или работал с народом, тот понимает, что правильная презентация - это картинки а не текст, смотрите как сделана реклама).
1) Не факт, что эта абстракция более близка к людям. Многие, углубляясь в UML, вообще идут в бесполезные абстракции, небесные выси и турбулентные потоки сознания.
2) Люди воспринимают по-разному. Учите психологию восприятия. А думает каждый по-своему. Скорее всего - некими паттернами внктреннего языка. И не факт, что внутренний язык хорошего разработчика хуже, чем UML.
3) Правильная презентация - это и картинки, и текст, и звук, и кинестетические ощущения.

igor250973
<...>
совершенно в дырочку :-)
а ещё даёт наглядность для многих наглядных вещей.

Русский язык позволяет написать отличное, полное красоты и смысла произведение. Полное правды, вымысла или намеренной дезинформации. Ещё позволяет написать полную, отвратительную ерунду.

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

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

igor250973<...>
UML средства разработки просто на порядок повышают производительность труда (сам сижу на MM для дэлфы и на БорландТугезере для VisualStudio).
Вашей производительности труда.

igor250973<...>
Другой вопрос, что люди, использующие UML должны уметь мыслить категориями ООП, а не жить в процедурных джунглях.
Джунгли в голове зависят не от методологии, а от философии, в т.ч. типа личности, образования, ответственности, образа жизни :) .