Цитата

Меня начинает угнетать тот факт, что даже в профессиональных и высоких IT-кругах когда я заикаюсь об UML`е, на меня начинают смотреть как на человека очень неопытного, романтика-мечтателя

Конечно ты романтик и мечтатель.

Правило номер один - не бывает хороших и плохих языков (технологий, методов, программных средств), бывают те, которые больше подходят для твоей задачи, и те, которые меньше подходят или не подходят для нее вообще.

Правило номер два - для каждой задачи нужно подобрать оптимальный метод решения.

Так вот поиск оптимального решения - это и есть задача АНАЛИТИКА. В этом ему могут помочь остальные члены команды - разработчики и тестеры, а также конечные пользователи. Поэтому вопрос о UML нахожу некорректным. Все средства хороши, когда знаешь, ГДЕ их применять.

Далее. UML - это средство МОДЕЛИРОВАНИЯ. Если ты не знаешь, что собираешься моделировать, он тебе не поможет. Это к тому, что, перед тем как рисовать красивые диаграммы по всем правилам, сделай набросок (процесса, структуры, и т.д.) на бумажке и покажи коллегам - если они не поймут, что ты пытаешься им сказать, то дальше двигаться бесполезно.

Это сообщение отредактировал(а) ida - 12.1.2006, 09:52

Наверное, мой опыт может быть полезен кому-то ещё, поэтому я им поделюсь. В этой теме я уже писал о том, как это на самом деле скучно изучать UML без практики. Теперь, когда у меня появился несколькомесячный опыт работы программистом в команде, я могу подтвердить, что UML вещь очень нужная!

Дело в том, что в фирме, где я прохожу практику, UML в ТЗ никто не использует. Главная проблема, с которой сталкиваются программисты - это то, что, когда над проектом работает определённое количество людей, то "посвящёнными" являются только они. Практически всегда приходит время, когда над проектом начинают работать люди, которые изначально в нём участие не принимали. ТЗ имеется, а вот более подробные детали не известны. Получается проблема: программисты идут к тем, кто писал проект и начинают спрашивать, что да как. Наверное, кто-то подумает, что всё дело в коде, который трудно понять. Это не всегда так. Бывают такие куски кода, где много логики, которую просто нужно знать, либо посвятить немало времени тому, чтобы в проекте разобраться. Так вот я это к тому, что UML-диаграммы бы значительно помогли. Раньше, видимо, таких проблем не возникало, но последние полгода программисты с этим сталкиваются очень часто, потому понимание важности UML пришло само. Гляда на диаграмму классов становится ясна их иерархия и взаимодействие. Кроме того, что диаграмма сама по себе ведь наглядная, она ещё и информативная, -- не нужно текстов, достаточно всё описать средствами UML.

А как вы пришли к тому, что UML - это нужно? Если вообще.. ?

Цитата(lovermann @ 3.12.2005, 23:06)

А как вы пришли к тому, что UML - это нужно?

К этому пришло мое начальство

Спустя два с половиной месяца... я уже

- знаю 9 разновидностей диаграмм
- могу отличить одну от другой визуально
- могу подобрать тип диаграммы, максимально подходящий для описания того или иного процесса или группы объектов
- могу найти недостатки в чужой диаграмме и предложить варианты их исправления
- могу построить свою диаграмму любого из 6-ти типов, и с некоторым напрягом - еще 2-х типов, но заметно худшего качества
- с горем пополам и разной степенью успешности обучила еще трех с половиной человек тому, что умею сама

Принимаюсь за букварь К.Лармана "Применение UML и шаблонов проектирования".

Это сообщение отредактировал(а) ida - 12.1.2006, 09:53

Вот у меня на работе идентичная проблема. Даже могу добавить, что в итоге все получается очень криво, код получается вообще нечитабельный, на работу тратится в несколько раз больше времени чем могло бы быть при благоприятном раскладе. C UML знаком не понаслышки, в общем то у нас в группе я единственный, кто занимается моделированием. У нас имеет место быть такая ситуация: для руководства важно только предоставить пару диаграмм заказчику, в виде документации, чтоб проект здать... А наши программеры с UML не знакомы и учиться не хотять. К сожалению, пока приходица рисовать диаграммы по имеющимся проектам, а не наоборот(((

Честно сказать, думаю, что в России Uml не приживется, кроме тех проектов где без него никак не обойтись в силу масштабов. На это много причин, даже тот же (или та же) XP, который в общем то искоренит UML для небольших программных проектов....

путаемся в показаниях.

ХР (если имеется в виду экстремальное программирование) - это технология разработки ПО.
UML - это язык моделирования.

Каким образом они могут быть взаимозаменяемы?...
По всей вероятноcти, вы RUP имели в виду (вместо UML)?
Не соглашусь. Просто, видимо, вы не работали в больших проектах. Делать госзаказ методом ХР не только не целесообразно - это опасно.
А UML не зависит от технологи разработки - его можно применять где угодно, как в ХР, так и в RUP. Результаты будут точно.
Думаю, всему в России найдется свое применение. И UML в том числе.

Это сообщение отредактировал(а) ida - 20.2.2006, 15:32

Я немного не понял. Насколько я знаю, UML применяться и в XP и UML. UML вообще применяться очень давно, по-моему пару тысячелетий ужеНазываеться: чертежи.

 chipset, неверная у тебя информация 

Моделирование используется человеком с тех пор, как он начал пользоваться вещами, которые слишком сложны для мгновенного понимания и которые невозможно увидеть и потрогать целиком до того, как они созданы. Когда точно это произошло - я не знаю. Возможно, кто-то из присутствующих в курсе - вам виднее... 

А универсальный язык моделирования придуман 20-м веке (точные даты лень смотреть по книгам).

Что такое моделирование

Как минимум, если вы прочитаете данную статью, вам станет ясно, что моделирование бывает физическое и знаковое. Схемы и чертежи - это знаковые модели.
Разновидностью знакового моделирования является математическое моделирование.

UML - это ЯЗЫК МОДЕЛИРОВАНИЯ, то есть, набор правил, определяющий, КАК изображать те или иные вещи на рисунках. Область его применения широка, но охватывает не все области человеческой деятельности, поэтому его никак нельзя назвать исчерпывающим. 

Цитируя из книги разработчиков языка:



В общем, джентльмены, давайте все же отделять котлеты от мух.  

Это сообщение отредактировал(а) ida - 15.3.2009, 19:40

UML можно применять очень широко в проектировании, даже слишком


И не только. Уже при 200 тысячах строк разобраться в проекте становиться очень непросто


а мое начальство к этому так и не пришло... Что, кстати, с этим можно сделать?

1. убедить начальство прийти к этому
2. поменять начальство на то, которое уже к этому пришло

Добавлено @ 12:18

Что имеется в виду под "альтернативными связями"?


Диаграммой последовательностей. Диаграммой деятельности.


Соответствующим стереотипом (импорт, использует или расширяет - смотря что конкретно имеется в виду) для классификаторов.


Диаграммой состояний.


Диаграммой последовательностей. Диаграммой деятельности.

Уважаемая ida!!!
Просто я считаю, что UML это одна из ключевая частей RUP.

Да действительно, не могу похвастаться таким опытом((
Но все-таки не могу согласиться с:

Ключевые моменты XP в том и заключаются, что методология базируется на эволюционном, а не предварительном проектировании. Конечно, в госзаказах и в еще чем-нибудь большом, применение только XP не выручит и, действительно, без описательных диаграмм не обойтись!! Но опять же, если проект не очень большой, то надо выбрать какую-либо одну, наиболее удобную для данного проекта, методологию разработки. Даже если брать самое лучшее из каждой методологии, то это только лишняя трата денег и времени. Да, результат будет, но цель не оправдает средства.

Это так и есть. Вот вопрос о целесообразности UML без RUP

 
Думаю, надо определиться, кто что чем называет. Чтобы не спорить беспредметно.

Итак, БОЛЬШОЙ проект - это, на мой взгляд, проект, который длится годами. Средний - проект, длительность которого не превышает года (ну полтора максимум). Маленький проект - это проект длительностью от недели до двух-трех месяцев.

Вы согласны?... Свой вариант. 

Это сообщение отредактировал(а) ida - 15.3.2009, 19:41

Канешна согласен. Плюс надо учитывать количество человек, принимающих участие в проекте.

Чтобы ответить на вопрос сабжа, достаточно вдуматься и расшифровать всего три буквы - UML.

Всё равно проблема будет одна: люди не хотят учиться. И я УЖЕ вижу, как это выглядит на практике. Даже молодые ребята, только после универа, уже ленятся читать книги про настоящее ООП и УМЛ.