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 должны уметь мыслить категориями ООП, а не жить в процедурных джунглях.
Джунгли в голове зависят не от методологии, а от философии, в т.ч. типа личности, образования, ответственности, образа жизни :) .